# 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.

## Key takeaways
- Whalesync syncs Airtable formulas, rollups, and lookups one way, as read-only values. In Postgres they are plain static columns that never recalculate. AT Migrator translates them into SQL, so the logic runs in your database.
- Whalesync does not build your Postgres schema. Its docs say tables must be created in advance, with auto-generated primary keys, and that renaming a table or column later breaks the mapping. AT Migrator reads your base and creates the tables, foreign keys, and junction tables itself.
- Whalesync is a monthly subscription: you pay for the mirroring and syncing, sized by the records in your synced tables, and it keeps making API calls to Airtable while it runs. AT Migrator is a one-time payment for the migration.
- Attachments synced to Postgres can show as broken images within hours, because Airtable file URLs expire. AT Migrator copies files to your own S3-compatible bucket.

## 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.

> Why this decides the comparison: Formulas, rollups, and lookups are where the business rules in an Airtable base live. A tool that carries across the values but not the rules has copied the data and left the working part of the base behind.

## 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.

## FAQ
**Does Whalesync convert Airtable formulas, rollups, or lookups to SQL?** No. Whalesync syncs them one way from Airtable as read-only values. In Postgres they are static columns that do not recalculate. AT Migrator translates formulas into SQL expressions and recreates rollups and lookups as joins and aggregate queries.

**Does Whalesync create the tables in my Postgres database?** No. Its docs say Postgres tables must be created in advance, with auto-generated primary keys, and that renaming a table or column later breaks the mapping. AT Migrator reads your Airtable base and creates the tables, foreign keys, and junction tables.

**Does Whalesync support Airtable linked records?** Yes, in both directions, as long as you have built the matching foreign keys, array columns, or junction tables in Postgres and mapped both sides of the link.

**Will Airtable attachments still work after a Whalesync sync?** Not reliably. Airtable file URLs expire, and Whalesync's known-issues page says synced images can appear broken after a few hours. File names may also change. AT Migrator copies files to your own S3-compatible bucket.

**How does Whalesync charge?** It is a monthly subscription for mirroring and syncing, sized by the records in your synced tables. Because it keeps both sides matched, it also makes ongoing API calls to Airtable, so your Airtable plan needs room for them.

**How does AT Migrator charge?** A one-time payment for the migration. There is no subscription after it is done.

**Does Whalesync need a paid Airtable plan?** Its docs recommend Airtable Business or Enterprise for heavier use, because Whalesync makes a lot of API calls and Airtable meters them by plan.

**When is Whalesync the better choice?** When Airtable stays your working tool and you only need Postgres to hold a live, two-way copy of the data.

---
*Considering a migration? Book a free discovery call with AT Migrator: https://www.atmigrator.com*