How to migrate from Airtable to NocoDB

Airtable is a good tool until the base becomes a system your organisation depends on. Then the questions change: where the records are stored, who can export them, what the next price change costs, and whether a department’s staff register belongs in a US SaaS at all.

NocoDB gives the same spreadsheet-style interface over a real PostgreSQL database that you control. This guide walks through a migration the way we run it: inventory first, then the import, then the rebuild of what the importer leaves behind, then the switch.

What moves across and what does not

Set expectations before anyone starts. The NocoDB importer handles the data well. What it does not handle is the logic built on top of the data.

Since January 2026, NocoDB is source-available under the Sustainable Use Licence: free for your own internal business use, restricted for offering it to third parties as a service. Pilae runs a dedicated instance for your organisation, which fits those terms, and we confirm the licence position with NocoDB before deployment rather than assuming it.

Step 1: inventory your Airtable workspace

A migration goes wrong when someone discovers a dependency after the switch. Spend an hour on the inventory before touching the importer.

1. List every base in the workspace, with its owner and the team that uses it.
2. For each base, count the tables and records. Airtable shows record counts per table, and your plan’s limits tell you which bases are near the ceiling.
3. List every formula field. Open the field configuration and copy the formula text into a spreadsheet, one row per field.
4. List every automation, with its trigger, its actions and whether it has run in the last three months. Many have not.
5. List every interface, every form shared outside the organisation, and every integration that reads or writes the base through the Airtable API or a tool such as Zapier or Make.
6. Mark any base that holds personal data. These need your data protection officer’s sign-off on access rights before go-live.

The inventory usually shrinks the job. Bases nobody has opened in a year are archived as CSV rather than migrated.

Step 2: prepare NocoDB and PostgreSQL

NocoDB stores its metadata and your tables in PostgreSQL. Plan for:

• PostgreSQL 15 or later, backed up daily.
• S3-compatible object storage for attachments, so the database stays small and backups stay fast.
• Single sign-on through OIDC, for example with Keycloak or Microsoft Entra ID, so accounts follow your directory. On self-hosted NocoDB, SSO is part of the paid licence tiers; if you need it, the licence is held in your name and named in the proposal. Without it, access is limited to the private network and local accounts.
• An SMTP relay for invitations and notifications.

With Pilae, this environment is provisioned on your premises or on dedicated machines in Pilae Cloud, with backups, monitoring and updates included.

Step 3: run the Airtable import

NocoDB’s importer reads the base through Airtable’s API.

1. In Airtable, create a personal access token with at least the data.records:read scope, limited to the bases you are importing.
2. In the base, open Share, create a shared link to the whole base and turn on full base access. Copy the shared base URL or ID.
3. In NocoDB, choose Import from Airtable, paste the token and the shared base ID, and pick the data source the tables should land in.
4. Choose the options: import records or schema only, include secondary views or only the primary grid, and include rollups, lookups and attachments.
5. Run the import and watch the log. Large bases with many attachments take the longest.
6. Back in Airtable, turn the shared base link off. Leaving a full-access public link active after the import is the most common security mistake in this migration.

Run a schema-only import first on a large base. It lets you check field types and links in minutes, before the full copy.

Check the imported data

Compare record counts table by table against your inventory. Spot-check a sample of records with links, dates, currencies and multi-select values, which are the field types most likely to need a correction. Airtable attachment URLs expire after a few hours, so confirm that attachments were copied into your storage rather than referenced.

Step 4: rebuild formulas, automations and interfaces

This is where most of the effort goes, and it is worth doing deliberately.

Formulas

Work through the formula list from your inventory. NocoDB’s formula field supports the usual text, numeric, date and conditional functions, and many Airtable formulas translate line for line with a change of function name. Where a formula depends on a function NocoDB lacks, choose between a simpler formula, a lookup or rollup, or a PostgreSQL view that computes the value in the database.

Automations

NocoDB triggers webhooks when records are created, updated or deleted. For anything beyond a simple notification, connect those webhooks to a workflow tool such as n8n, which gives you branching, retries and connections to email, chat and other systems. Rebuild only the automations that ran in the last three months.

Interfaces and forms

Airtable interfaces become NocoDB views with filters, sorts and field visibility per audience. NocoDB forms replace Airtable forms, including shared forms for external respondents. Test each form end to end before you publish new links.

Step 5: reconnect integrations

Anything that called the Airtable API needs a new target. NocoDB exposes a REST API for every table, with tokens you create per integration. Because the data sits in PostgreSQL, reporting tools such as Metabase or Grafana can read it directly, often replacing a scheduled CSV export.

Step 6: switch users over

1. Freeze the Airtable base. Set it to read-only for everyone except the migration owner, and announce the date.
2. Run a final delta. Re-import the records created since the first import, or rerun the full import into a clean data source if the base is small.
3. Give access through your directory. Assign NocoDB roles per base, owner, creator, editor, commenter or viewer, from your identity provider groups.
4. Run in parallel for a week. Keep Airtable read-only as a reference, and collect questions from users in one channel.
5. Export and close. Download a final CSV of every table as an archive, then cancel the Airtable seats.

Keep the data in a database you own

The main change after the move is not the interface. It is that your records now sit in a PostgreSQL database in the location you choose, under your contract, backed up daily and queryable with SQL. If NocoDB ever stops fitting, the data is already in the most portable format there is.

Let Pilae run the move

Pilae runs Airtable to NocoDB migrations at a fixed price agreed before the work starts: the inventory, the import, the formula and automation rebuild, single sign-on and a parallel run, followed by operation of NocoDB with backups, monitoring and updates. See migration services, or read how NocoDB compares on the Airtable alternative page.