Migrate from Airtable to PostgreSQL with Teable or Mathesar

A read-only freeze is the simplest approach. Airtable is set to view-only for everyone who edits data, the final export runs from a clean snapshot, and the new PostgreSQL tables and the Teable or Mathesar interface become the only place where records change. Because nothing is written to two places, there is no reconciliation to design, but the business pauses while the import, attachment re-linking and checks run.

• User expectations: Every editor needs to know the start and end of the freeze, and any work that must continue during it needs an agreed holding process, such as a shared intake form or a paper log.
• Permission change: Remove edit rights from Airtable collaborators at the cutover point, and confirm that API tokens and automations that write to Airtable are disabled too.
• Snapshot discipline: Export each table as CSV from a view after the freeze begins, because Airtable has no whole-base export and the files must reflect one agreed moment.
• Attachment links: Airtable attachment URLs expire, so download attachments during the freeze rather than relying on links taken earlier.
• Rollback path: Keep Airtable read-only rather than deleted until the new system has been checked by its owners.

Before choosing this approach, confirm with the table owners how long the business can wait for updates and whether any integration writes to Airtable on a schedule.

Dual entry keeps Airtable open for editing while the PostgreSQL side is populated and tested. Users enter records in one system during a defined period, and reconciliation queries compare the two copies to find missing, duplicated or differing rows. This avoids a business pause, but it creates the most write conflicts and needs the most discipline from users.

• Named system of record: Decide which system wins for each table during the period, so a conflict always has a clear answer.
• Reconciliation keys: Use Airtable record IDs, stored in a dedicated column in PostgreSQL, as the join key so comparisons do not depend on names or titles that users can edit.
• Conflict hotspots: Conflicts appear most often on records edited in both systems, on linked-record fields that point at rows created after the import, and on attachments added in only one place.
• Reconciliation queries: Write SQL that lists rows missing on either side, rows whose key fields differ and rows with unexpected link counts, and run them on a fixed schedule that the owners agree on.
• Sync tooling: Any script that copies changes between systems needs its own tests and logging, and it should not be treated as a permanent integration.

Ask the team who owns each table which fields are edited most often, because those fields determine how much reconciliation effort the period will need.

A staged cutover moves one table at a time. Each table is frozen, imported, checked and handed to users before the next table starts. Tables with few links and few attachments are usually moved first, while tables that many others depend on are moved last, once their links and lookups have been tested in PostgreSQL. This limits the blast radius of any problem to a single table, though cross-table links still need a plan.

• Dependency order: Map which tables link to which, then move parent tables before the tables that reference them so foreign keys can be created in the right order.
• Links across the boundary: While a table sits in Airtable and its neighbor sits in PostgreSQL, linked fields and lookups will not work across the two systems, so agree which users must work in which place during that window.
• Per-table freeze: Each table gets a short freeze of its own, and its owner signs off on row counts and key fields before the switch.
• Interface placement: Decide whether Teable or Mathesar views for a moved table point only at PostgreSQL, so no user sees stale Airtable data for it.
• Ordering risk: A table that has been moved cannot be edited in Airtable without creating a second copy, so block edits at the Airtable side as each table moves.

Before starting, confirm the dependency map with the people who build the Airtable formulas and automations, because they usually know links that are not visible from the table list alone.

A base run by one team, with a handful of tables and no outside consumers, is the simplest case. Most of the effort sits in schema design: you export each table as CSV from a view, decide which columns become typed PostgreSQL columns, and turn Airtable link fields into foreign keys. Because one team owns the data, cutover can be a short window agreed in advance, with the team switching to the Mathesar or Teable interface once the import checks pass.

• Schema work: Map single-select and linked-record fields to lookup tables and foreign keys, and choose data types before importing, since PostgreSQL will not infer them the way a spreadsheet does.
• Attachments: Download attachments separately, store them in a location you control, and re-link them to the rows after import.
• Cutover: Freeze edits in Airtable for the agreed window, run a final export, and compare row counts per table against the source.
• Integrations: Usually few or none, so the main integration work is re-creating any Airtable automations by hand.
• Record count: Check the base against Airtable's per-base caps on your plan first, since exporting a base near a cap may need several passes.

Before planning, confirm the record count and attachment volume for each table with your Airtable admin, so the import window reflects the real size of the base.

An operation where several bases share linked tables, such as a customer list referenced by orders, support tickets and billing, needs a schema decision that a single base does not. In Airtable, the same logical table often appears in more than one base, with copies that drift apart over time. Moving these into one PostgreSQL schema forces you to choose a single source of truth for each entity, then give each team a view or role that reflects its own access.

• Schema work: Consolidate duplicated tables into one set of tables with shared keys, and record the decisions in a data dictionary before importing.
• Access: Mathesar uses PostgreSQL roles and privileges, so plan which teams need read, write or schema rights and create those roles before go-live.
• Cutover: Move bases in an order that respects dependencies, and agree which base remains authoritative for each shared table during the transition.
• Integrations: Expect more work here, because each base may feed a reporting tool, a form or a script that must point at the new tables.
• Record count: Add up records across bases that share data, because cross-base duplication can push a combined dataset past what one plan allows.

Confirm with each base owner which fields they actually use, since consolidation is easier to scope once unused fields are removed.

A base that other systems read from or write to is an operational system of record, and it carries the highest risk. Changing its structure can break integrations that depend on field names, table IDs or Airtable's API behavior. The project therefore needs a compatibility plan: either the consuming tools are updated to query PostgreSQL directly, or a compatibility layer is built while they are migrated in turn.

• Schema work: Keep field names stable where consumers depend on them, and document any renamed or split fields so each consumer can be updated.
• Integrations: Inventory every script, automation and API client that touches the base, and plan their move to PostgreSQL connections or to the API of the chosen interface.
• Cutover: Run old and new in parallel for a validation period, comparing outputs from both sides before retiring Airtable access.
• Operations: PostgreSQL gives you backups, replication and point-in-time recovery options, but you must configure and test them, since a system of record needs them from day one.
• Rate limits: Airtable's API caps may have shaped how consumers were written, so review their call patterns before moving them.

Confirm the list of consumers and their owners in writing before choosing a cutover date, since an unknown consumer is the most common cause of a failed switch.