Whalesync vs AT Migrator: Sync Tool or Migration Tool for Airtable to PostgreSQL?

Whalesync and AT Migrator both connect Airtable to PostgreSQL, but they are built for different jobs. Whalesync keeps two databases in step with each other, indefinitely. AT Migrator moves you out of Airtable and leaves you with a Postgres database that runs on its own. What decides which one you need is what lands in Postgres: linked records, lookups, rollups, and formulas that still work, or a copy of the values they showed on the day they last synced.

What each tool is

Whalesync is a two-way data sync platform. It connects Airtable, Notion, Webflow, HubSpot, PostgreSQL, and many other apps, and keeps records matched between them in near real time. That is a genuinely useful thing if you want Airtable to stay your working tool while another system mirrors its data. AT Migrator is a dedicated migration product: moving an Airtable base into PostgreSQL, structure and logic included, is the whole product, not one connector among many.

Does Whalesync turn Airtable formulas, rollups, and lookups into SQL?

No. Whalesync copies the computed result into Postgres as a read-only value, and nothing recalculates it there. Whalesync's own Airtable documentation lists formula, lookup, and rollup fields as one-way only, and explains why: two-way sync cannot work on read-only fields, because “a formula field cannot be overwritten.” So the value flows from Airtable to Postgres and stops there. It is the number Airtable calculated at the last sync, sitting in an ordinary column.

That is fine as long as Airtable stays alive and keeps recalculating. It stops being fine the moment Postgres is meant to be the real database. Change an input in Postgres and the total next to it does not move. Add a new row and the rollup column is empty until Airtable computes it and the sync carries it over. Switch Airtable off and every one of those columns freezes at its last value. You have the numbers, but not the logic that produced them.

AT Migrator treats this as the core of the job. Formulas are translated into SQL expressions, so a value that used to be computed by Airtable is computed the same way by Postgres. Rollups and lookups are recreated as joins and aggregate queries that read from the new foreign keys, rather than a stored snapshot.

Does Whalesync build your Postgres schema and relationships?

No. You create the Postgres tables first, and Whalesync maps Airtable fields onto them. Its Postgres documentation says tables must be pre-created, that every table needs a primary key, and that the key must be auto-generated by the database. Renaming a table or column after setup breaks the existing mapping and can create duplicates. The ready-made CREATE TABLE scripts it publishes cover tools like HubSpot, Shopify, and WordPress, not an Airtable base. For a migration, that means you or your developer design the target schema by hand before the first record moves.

Linked records are the part Whalesync handles best, and it is fair to say so. It supports them in both directions, and on the Postgres side they can be foreign keys, UUID array columns, or junction tables. But that works when you have built those columns and tables yourself and mapped both ends of the link. Its own guidance is to keep reference fields small and to avoid syncing both sides of a mirrored link. AT Migrator reads the setting Airtable stores on each side of a link field for whether that side allows one record or many, then does the design for you: one-to-many becomes a foreign key column, many-to-many becomes a junction table.

What happens to attachments?

They arrive as Airtable-hosted links that expire, and their file names may change along the way. Whalesync's docs note that attachment file names may change when syncing, and its known-issues page says images synced from Airtable to Postgres appear broken after a few hours, because Airtable's image URLs expire. Its recommended fix is to host the files yourself. For a database you intend to keep, that is exactly the work you wanted the migration to do. AT Migrator copies attachments to your own S3-compatible bucket and stores each file's URL, name, and size alongside the row it belongs to. If a file fails to copy, only that file is retried on a re-run.

How does the cost model differ?

Whalesync is a subscription you pay for as long as the sync runs. AT Migrator is a one-time payment for the migration. With Whalesync you subscribe for the mirroring and syncing itself, and the plan is sized by how many records you keep in sync across your tables, so the bill follows the size of your base. There is also a third thing to plan for. Because Whalesync keeps the two sides matched continuously, it makes API calls against Airtable the whole time it runs, and Airtable meters those by plan. Whalesync's own docs suggest an Airtable Business or Enterprise plan for heavier use, so your Airtable plan needs room for it.

None of that is unreasonable for a tool built to run for years. It is simply what keeping two live systems in step involves. A migration is a different shape of job: it has a start and an end. AT Migrator is priced once for the move, and when it finishes you are not left with a monthly line item or a pipe that keeps calling Airtable.

Is this about syncing, or about leaving Airtable?

This is the real dividing line, and it matters more than any single feature. Whalesync assumes Airtable stays the source of truth and Postgres follows it. AT Migrator assumes Airtable is going away. If you also need a short bridge while teams finish moving across, AT Migrator has one, covered in how to sync Airtable to Postgres after a migration, and it is built to end once you have left.

Which one fits your situation

• You are leaving Airtable and the base has linked records, rollups, lookups, or formulas: AT Migrator builds the schema and recreates the logic as SQL. Whalesync gives you static values and a schema you design yourself.
• Your files need to survive after Airtable is gone: AT Migrator copies them to your own bucket. Synced Airtable URLs expire.
• You want a one-time payment for a one-time job: AT Migrator is a single payment for the migration, with no subscription after.
• Airtable stays your working tool and Postgres only needs a live copy of the data: Whalesync is a reasonable fit for that, especially if you also want edits to flow back into Airtable.

For a full walkthrough of what a migration involves, see the step-by-step migration guide, or how AT Migrator compares to sync tools, NocoDB, and DIY scripts in Airtable to PostgreSQL: migration options compared.