NocoDB vs AT Migrator: Airtable Import or Real Migration to PostgreSQL?

NocoDB and AT Migrator both take an Airtable base and put it somewhere that is not Airtable. NocoDB does it as one feature of an open-source, Airtable-style app. AT Migrator does it as the whole product, and the target is PostgreSQL. What decides which one you need is what survives the move: the formulas and the shape of your relationships, or only the tables, rows, and a joined-up approximation of the links.

What each tool is

NocoDB is an open-source platform that gives a database a spreadsheet-style interface, with views, forms, automations, and an API. It can run on its own database or connect to an external one, including PostgreSQL, and it has an “Import from Airtable” option so you can bring a base into it. AT Migrator is a dedicated migration product: moving an Airtable base into PostgreSQL, structure and logic included, is the whole product, not one import option among many. The first question to ask is whether you want a new app to work in or a database you own, because that changes what a good import looks like.

Does NocoDB import Airtable formulas?

No. NocoDB's own documentation says it does not support importing formula fields, and the import setting for them is greyed out. The import code agrees: a formula column is skipped during column creation and logged as “column type not supported yet”. Even in the code path where formula import can be switched on, the formula expression is replaced with an empty placeholder and the original Airtable formula is kept only in the field's description. In a public GitHub discussion on Airtable import, a user wrote in January 2025 that the developers had told them on Discord this was not a priority. So a base that leans on formulas arrives with its formula columns missing, and the logic is yours to rebuild.

Rebuilding them means writing each one again in NocoDB's own formula syntax, with field names in curly braces. That works inside NocoDB, but the documentation describes no column, view, or function created in your PostgreSQL database for it. AT Migrator translates Airtable formulas into SQL expressions, so a value that used to be computed by Airtable is computed the same way by Postgres. Rollups and lookups are recreated as joins and aggregate queries that read from the new foreign keys.

Does NocoDB keep the shape of your linked records?

No. NocoDB creates every Airtable link as many-to-many, with its own join table for each link. A comment in NocoDB's import code says it directly: all links are hardwired as many-to-many, and many-to-many generates additional tables per link. In Airtable, most links are really one-to-many: one client has many invoices, each invoice has one client. After a NocoDB import that relationship is stored as a pair of IDs in a join table, so you query it with an extra join, and your schema has a table for every link that never needed one.

AT Migrator reads the setting Airtable stores on each side of a link field for whether that side allows one record or many, and maps the relationship accordingly: one-to-many becomes a foreign key column, many-to-many becomes a junction table. When two tables are linked in more than one way, each link gets its own junction table.

What else changes on the way in?

A handful of field types are converted, and NocoDB tells you which in an import report. Credit where it is due: after an import NocoDB lists every item as skipped, approximated, or failed, and you can download the report as a CSV. The import carries on past failures, except when creating a table fails, which stops the whole run. The maintainers' import notes list the conversions: percent values become fractions (1% becomes 0.01), durations become seconds, collaborator and phone number fields become single-line text, rich text becomes plain text, and created-time and last-modified fields stop updating when a record is edited in NocoDB. Those notes were written in 2022, so check them against the version you run. None of this is a defect so much as a description of an import into an app with its own field types. It does mean you should read the report line by line before you trust the result.

How does it behave on a large or complicated base?

There is no documented way to resume a failed import, and public reports describe complex bases importing without their records. NocoDB's docs do not describe resuming. In the public GitHub discussion on Airtable import, users report imports that hang, bases that import their structure but no records, and a duplicate-column error that stopped an import when a column was named “alias”, with leftover tables after a failed run. Those reports span several years and versions, so treat them as a sign of what to test, not a statement about today's release. AT Migrator reads Airtable one table at a time and retries automatically when it hits Airtable's limit of 5 requests per second per base. A migration keeps running after you close the tab, and if it is interrupted it resumes from where it stopped: tables already finished are skipped, and a partly-read table picks up where it left off.

How does the cost model differ?

NocoDB is software you run or subscribe to. AT Migrator is a one-time payment for the migration. NocoDB's community edition is free to self-host, which means you deploy it, host it, and keep it updated. Its cloud plans are priced per editor seat, with limits on records, API calls, and automation runs that rise with the plan, and some features such as single sign-on and audit logs sit on paid tiers. That is a reasonable model for a tool your team works in every day. A migration has a start and an end, and AT Migrator is priced once for the move. When it finishes, you have a PostgreSQL database and no subscription attached to it.

What about setup?

This part is worth knowing but should not decide much on its own. NocoDB's import needs an Airtable personal access token and a shared base link, which means turning on full base access in Airtable's Share menu. You then pick the data source the base should land in: NocoDB's default database, or an external connection. AT Migrator authenticates over OAuth or a personal access token, reads every table and field in your base automatically, and connects to Postgres over a standard TLS connection string.

Which one fits your situation

• You are leaving Airtable and the base has formulas, rollups, or a lot of linked records: AT Migrator translates formulas to SQL and maps links by cardinality. NocoDB skips formulas and makes every link many-to-many.
• You want an Airtable-style interface on open-source software you control: NocoDB is built for that, and for a small, flat base its import is a quick way to get started.
• You want both a proper PostgreSQL database and a spreadsheet interface on top: migrate with AT Migrator, then connect NocoDB to the resulting database as an external data source.
• A large base, or one you cannot guarantee will finish uninterrupted: AT Migrator resumes an interrupted run and emails you the status when it finishes.

For a full walkthrough of what a migration involves, see the step-by-step migration guide, or how AT Migrator compares to sync tools, NocoDB, and DIY scripts in Airtable to PostgreSQL: migration options compared.