# 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. ## Key takeaways - Syncing copies Airtable rows into Postgres on a schedule; migrating converts linked records to foreign keys and recreates formulas as SQL. - Sync tools copy row values into Postgres but do not translate Airtable formula logic into native SQL. - Sequin was a popular Airtable → Postgres sync option until Notion acquired it and shut down the service in October 2025. - NocoDB can import Airtable bases into Postgres-backed storage, but formula fields are not supported and linked records default to many-to-many — not a full schema migration. - AT Migrator maps linked records by cardinality: one-to-many links become foreign keys; many-to-many links become junction tables — not a blanket many-to-many import. - DIY n8n or ETL workflows can move raw cell values, but rebuilding rollups, lookups, and formulas in SQL is the hard part most scripts skip. - Use a sync tool when Airtable stays authoritative. Use AT Migrator when you are leaving Airtable and need Postgres to own the logic. ## 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. 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 pulls a base via API token and can target an external Postgres data source. 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. 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. ## 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. > The technical distinction that matters: Sync and ETL answer "how do I get Airtable values into Postgres?" Migration answers "how do I make Postgres behave like my Airtable base without Airtable?" Only the second path produces foreign keys, SQL-native rollups, and formulas that recalculate from Postgres data alone. ## 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. 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. ## FAQ **What's the difference between syncing and migrating Airtable to PostgreSQL?** Syncing copies row values from Airtable into Postgres while Airtable remains the source of truth. Migrating moves schema and logic one-way into Postgres — linked records become foreign keys and formulas become SQL — so Postgres can run independently of Airtable. **Does Whalesync convert Airtable formulas to SQL?** No. Whalesync syncs the computed values of formula fields as static column data. It does not generate PostgreSQL expressions that recalculate from underlying columns. **Is Sequin still available for Airtable → Postgres sync?** No. Sequin shut down in October 2025 after Notion acquired the company — it is not an option for new syncs. For a one-way cutover, use a migration tool. For temporary mirroring, evaluate currently available sync tools, but none recreate Airtable formula logic as live SQL. **Does NocoDB migrate Airtable formulas to PostgreSQL?** No. NocoDB's native Airtable import explicitly does not support formula fields — the import toggle is greyed out in their docs. CSV import also cannot handle formula or linked-record columns. Formulas must be recreated manually or via a purpose-built migration tool. **Does NocoDB preserve Airtable linked-record cardinality?** No. NocoDB's Airtable import treats all linked-record fields as many-to-many, even when the relationship in Airtable is one-to-many. NocoDB maintainers have confirmed link types cannot be converted in place after import — users must recreate relationships manually. **How does AT Migrator handle Airtable linked-record cardinality?** AT Migrator maps each link field based on its relationship shape in the base. One-to-many links become a foreign key column on the child table. Many-to-many links become a junction table with both foreign keys. This avoids the common import problem where every link is treated as many-to-many regardless of how it was configured in Airtable. **Is a CSV export enough to migrate off Airtable?** No. CSV drops linked-record relationships, attachment metadata, and formula logic. A proper migration preserves foreign keys and recreates computed fields as SQL. --- *Considering a migration? Book a free discovery call with AT Migrator: https://www.atmigrator.com*