Airtable to PostgreSQL: migration options compared

If you search for how to move Airtable data into PostgreSQL, you will see sync tools, NocoDB, and DIY n8n workflows alongside purpose-built migration tools — and older threads still mention Sequin, which shut down in 2025. They are not interchangeable. Sync tools keep Airtable as the source of truth and mirror rows into Postgres. Migration tools move schema, relationships, and computed-field logic into PostgreSQL so Postgres becomes the system of record. The right choice depends on whether you want a live bridge or a one-way cutover.

What's the difference between syncing and migrating?

Syncing keeps Airtable as the source of truth and copies row values into PostgreSQL on a schedule or in near real time. Migration moves your base one-way: tables become Postgres tables, linked records become foreign keys, and formulas, rollups, and lookups are recreated as SQL rather than stored snapshots. After a sync, editing in Airtable still drives what Postgres holds. After a migration, Postgres is authoritative and Airtable is optional or retired. Sync tools excel at hybrid setups — Airtable for editing, Postgres for reporting. Migration tools excel at cutover — when seat costs, record caps, or API limits mean Airtable should no longer be the backend.

Does Whalesync preserve Airtable formulas as live SQL?

No. Whalesync mirrors Airtable field values into Postgres columns; it does not compile Airtable formulas into PostgreSQL expressions. If a formula field shows a computed result in Airtable, Whalesync can write that result into a Postgres column, but the column holds the last synced value — not the formula logic itself. Change the underlying fields in Postgres without updating Airtable and the value will not recalculate unless you edit Airtable and sync again. That is fine when Airtable remains your editing surface and Postgres is a read replica for BI. It is not a substitute for migration when you need Postgres to own the business logic independently of Airtable.

Is Sequin still an option for Airtable → Postgres?

No — not for new projects as of late 2025. Sequin was acquired by Notion and Sequin Cloud shut down on October 23, 2025. Notion confirmed the acquisition in its January 2026 announcement. Before the shutdown, Sequin streamed Airtable changes into PostgreSQL so Postgres stayed current with Airtable edits — but as synced values, not recreated schema logic. Linked records landed as ID references or flattened columns, and rollups and formulas arrived as computed-at-sync-time values rather than SQL views or generated columns. NocoDB's own community historically relied on Sequin as an intermediate step — migrate Airtable to Postgres with Sequin, then connect NocoDB to that database — a path that no longer exists. If you land here from an older Reddit or community thread recommending Sequin, treat it as historical context. You will need a currently available sync tool for temporary mirroring, or a purpose-built migration for a one-way cutover.

Is NocoDB a migration path off Airtable?

NocoDB can import an Airtable base directly — including into a Postgres-backed data source — but it does not migrate Airtable formulas and mishandles linked-record cardinality. NocoDB's native “Import from Airtable” flow (documented on their site) pulls a base via API token and can target an external Postgres data source, so rows can land in Postgres tables. Formula fields are explicitly not supported — the import toggle is greyed out in NocoDB's docs. CSV import cannot handle linked records, lookups, or formulas either, per NocoDB maintainers. Linked-record fields are imported as many-to-many regardless of how the relationship is configured in Airtable, and link types cannot be converted in place after import. NocoDB also assigns its own autoincrement primary key rather than preserving Airtable record IDs. Import reliability varies by base, and users have reported attachment edge cases such as PDFs failing to download while images succeed. NocoDB maintainers once recommended Sequin → Postgres → NocoDB before native import existed — that workaround is obsolete since Sequin shut down. NocoDB remains useful as a spreadsheet UI after a proper migration, or for simple bases without formulas or complex links. For bases where Postgres must own the schema, AT Migrator maps one-to-many links to foreign keys and many-to-many links to junction tables, and recreates formulas as SQL — see our step-by-step migration guide.

Can n8n / DIY ETL recreate Airtable formulas in Postgres?

DIY workflows can move raw cell values row by row, but faithfully rebuilding Airtable formulas, rollups, and lookups in PostgreSQL is where most hand-rolled scripts fail or stall. An n8n flow that calls the Airtable API and INSERTs into Postgres handles the easy 20%: text, numbers, and simple selects. Linked records need junction tables and foreign keys. Rollups need aggregate queries or materialised views. Formulas need parsing Airtable's expression language and emitting valid SQL — including edge cases for dates, arrays, and cross-table references. Maintenance burden grows with every field type. DIY makes sense for a one-table export with no computed fields. For production bases with relationships and logic, purpose-built migration tooling avoids months of script maintenance.

When should you use AT Migrator vs a sync tool?

Choose a sync tool when Airtable stays authoritative and Postgres is a downstream copy for analytics or integrations. Choose AT Migrator when you are cutting over — Postgres becomes the system of record and you need linked records, formulas, rollups, and lookups to work as native SQL. AT Migrator runs a one-way migration: it reads your base, maps schema, converts links to foreign keys or junction tables based on each field's relationship shape, generates SQL for computed fields, validates row counts, and delivers a Postgres database you own. It reads each link field's direction and structure in your base and maps one-to-many relationships to foreign keys and many-to-many relationships to junction tables. It does not keep Airtable in the loop. That is the right fit when seat costs, record limits, or product requirements outgrow Airtable. If you are not ready to leave Airtable but want Postgres in the picture, a sync tool can mirror row values temporarily while Airtable stays authoritative — but it will not recreate formulas, rollups, or lookups as native SQL. When Postgres needs to own that logic, migrate one-way with a purpose-built tool. See our step-by-step migration guide for cutover mechanics, or compare migration pricing for your record volume.