How to move from Airtable to Supabase without downtime

Airtable is a good place for operations data to start. Supabase is where it goes when the data has to carry the business: more records, more systems writing to it, outside users, and permissions enforced row by row. The move is predictable if you treat it as a schema project first and a data transfer second.

If you are still deciding, read Airtable or Supabase first.

1. Decide it is time to move

Four signs, any two of which justify costing a move:

• Volume. Records are approaching your plan’s limits, or bases have slowed down.
• Syncs. Other systems write to the base constantly, and the API limit of five requests per second per base, with a 30 second wait after a 429, has started to shape how integrations are built.
• Outside users. Customers, suppliers or partners need logins and must see only their own rows.
• Permissions. Rules about who can see or change what must be enforced, not just hidden in a view.

If none apply, stay on Airtable and keep the data model tidy.

2. Inventory bases, tables, fields and automations

List every table and field the team actually uses, with its type, plus every linked field, formula, rollup, lookup, view and automation, and who relies on each. Mark what to keep, merge or retire. Views often encode business rules (“Orders to dispatch today”) that must become queries or screens later.

3. Design the Postgres schema

Each table becomes a Postgres table with a real primary key. Linked record fields become foreign keys, or join tables for many-to-many links. Single selects become constrained text or lookup tables. Add an airtable_id column to every table: it makes loading, verification and the parallel sync far simpler, and it can be dropped later.

Formulas and rollups do not move as data. Decide for each whether it becomes a view, a generated column or application logic.

4. Extract the data within the API limits

Create a personal access token with read scopes for the bases you need; API keys no longer work. Page through each table 100 records at a time using the offset the API returns, keep to five requests per second per base, and back off for 30 seconds on a 429. Save the raw JSON before transforming anything, so you can always rerun the load.

Linked record fields come back as arrays of record IDs, which is exactly what you need to rebuild relationships. CSV exports show linked records as display names instead, which is why the API is the safer route for linked tables.

5. Load, link and verify

Load parent tables first, then children, translating each linked record ID into the parent row’s primary key through the airtable_id column. For small flat tables the dashboard’s CSV import is fine; for larger loads use a script, COPY or pgloader.

Then verify: row counts per table, totals of key numeric fields, and a sample of records checked by someone who knows the data.

6. Secure the data and rebuild the front end

Enable row level security on every table in an exposed schema. Once it is on, nothing is readable through the API with the publishable key until you write policies, so write one per role and per action. Review the default grants new tables receive, and keep secret keys, which bypass row level security, on the server only.

Serverless functions should connect through Supabase’s transaction pooler on port 6543, with prepared statements turned off in the driver.

Then give the team an interface: Retool, Softr, Noloco or custom code, depending on who uses it and how. Parity first: every task they did in Airtable must work on day one.

7. Run in parallel and cut over

Keep a one-way sync from Airtable to Supabase running while the team tests the new front end on real data. When everyone agrees, run a final sync, switch users over in one step, and set Airtable to read-only rather than deleting it. Watch the first full working days closely and keep the raw export archived.

Related: Airtable consulting, Supabase consulting, Moving off Retool and Modernise.