# How to move from Airtable to Supabase without downtime > A seven-step Airtable to Supabase migration: decide it is time, design the Postgres schema, extract data within API limits, load, secure with RLS and cut over. - Author: Pranav Mahaveer, Founder, SBD - Updated: 2026-10-29 - Level: Advanced. Time to do: Two to six weeks, depending on bases, tables and automations - For: Operations leads and engineers whose Airtable bases now carry the business and need a real database underneath - You will end with: Your data in Postgres on Supabase with keys, relations and row level security, a front end the team accepts, and Airtable read-only as a fallback - Canonical: https://smallbaydigital.com/guides/how-to-move-from-airtable-to-supabase/ ## Steps 1. **Decide it is time to move.** Check the signs: volume near plan limits, constant syncs hitting rate limits, outside users, and permissions that must be enforced per row. 2. **Inventory bases, tables, fields and automations.** List every table, field type, linked field, formula, view and automation in use, with who relies on each. 3. **Design the Postgres schema.** Turn tables into Postgres tables with primary keys, foreign keys for linked records, types, constraints and a column for the Airtable record ID. 4. **Extract the data within the API limits.** Page through every table with a personal access token, respecting five requests per second per base, and keep the raw export. 5. **Load, link and verify.** Load parent tables first, resolve linked record IDs into foreign keys, then compare row counts and totals with Airtable. 6. **Secure the data and rebuild the front end.** Enable row level security on every table, write policies per role, and give the team an interface for daily edits. 7. **Run in parallel and cut over.** Keep a sync running while the team tests, then switch in one step and leave Airtable read-only as a fallback. > **The short answer.** Inventory what you have, design a Postgres schema that makes Airtable's implicit rules explicit, extract every table through the API within its rate limits, load parents before children and resolve linked record IDs into foreign keys, verify counts, turn on row level security, give the team a front end, and cut over after a parallel run with Airtable kept read-only. 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](/compare/airtable-vs-supabase/) first. ## 1. Decide it is time to move Any two of these four signs 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 rather than 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 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 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. Aim for parity first: every task they did in Airtable works on the first day. ## 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](/integrations/tools/airtable/), [Supabase consulting](/integrations/tools/supabase/), [Moving off Retool](/blog/moving-off-retool/) and [Modernise](/services/modernise/). ## Checklist - [ ] Reason for the move written down, with the signs that triggered it - [ ] Inventory of tables, fields, linked fields, formulas, views and automations, each with an owner - [ ] Postgres schema with primary keys, foreign keys, types, constraints and an airtable_id column on every table - [ ] Formulas and rollups listed and rebuilt as views, generated columns or application code - [ ] Extraction script uses a personal access token, pages 100 records at a time and backs off on 429 - [ ] Raw JSON export archived before any transformation - [ ] Parent tables loaded before children, linked record IDs resolved to foreign keys - [ ] Row counts and key totals match Airtable for every table - [ ] Row level security enabled on every exposed table, with policies per role, and default grants reviewed - [ ] Secret keys used only server-side; client code uses the publishable key - [ ] Serverless functions connect through the transaction pooler on port 6543 - [ ] Front end accepted by the people who edit the data daily - [ ] Parallel sync running until cut-over; Airtable set to read-only afterwards, not deleted ## Sources - Airtable Web API, [Rate limits: 5 requests per second per base, 50 per second per user token, 30 second wait after a 429, checked 29 October 2026](https://airtable.com/developers/web/api/rate-limits) - Airtable Web API, [List records: pageSize up to 100, offset pagination, linked records returned as record ID arrays, checked 29 October 2026](https://airtable.com/developers/web/api/list-records) - Airtable Support, [API key deprecation: personal access tokens and OAuth replaced API keys, completed 1 February 2024, checked 29 October 2026](https://support.airtable.com/docs/airtable-api-key-deprecation-notice) - Supabase Docs, [Row level security: enable on exposed tables, review default grants, secret keys bypass RLS, checked 29 October 2026](https://supabase.com/docs/guides/database/postgres/row-level-security) - Supabase Docs, [Connecting to Postgres: direct connection, session and transaction pooler, port 6543 for serverless, checked 29 October 2026](https://supabase.com/docs/guides/database/connecting-to-postgres) - Supabase Docs, [Import data: dashboard CSV import up to 100MB, pgloader, COPY and the API, checked 29 October 2026](https://supabase.com/docs/guides/database/import-data) ## Questions ### Can I export Airtable to CSV and import it into Supabase? For a small, flat table, yes: the Supabase dashboard imports CSV files up to 100MB. For linked tables it loses the relationships, because CSV exports show linked records as names rather than IDs. Extracting through the API keeps the record IDs you need to rebuild foreign keys. ### Will the team lose the Airtable experience? Only if you give them a bare database. A front end such as Retool, Softr, Noloco or a custom interface on top of Supabase keeps daily editing familiar, and can be better for the job than a grid. ### What happens to Airtable automations and formulas? They are rebuilt. Formulas and rollups become database views, generated columns or application code. Automations become database triggers, scheduled jobs or workflows in n8n or Make that read from Postgres. ### How long does it take? One base with a handful of tables can move in days. Several bases with many linked tables, formulas and automations take weeks, most of it on schema design, verification and the front end rather than on moving rows. ### Should every Airtable user move? No. If a small team edits records by hand and volume fits the plan, Airtable is a good tool to stay on. Our comparison of Airtable and Supabase lists the signs that it is time.