Choosing an Open-Source Airtable Alternative: The Four Axes I Actually Check

People ask me for “the best open-source Airtable” as if there’s a single winner. There isn’t, and the reason is interesting: Baserow, NocoDB, Teable and Grist disagree about something more fundamental than features. They disagree about what a record is and where it lives. Once you see that split, the choice gets easier.

I haven’t run a six-month production migration on each of these, and I won’t pretend otherwise. What follows is how I read their public repositories, license files and docs, and the four questions I work through before I’d put any of them under a team’s data.

Axis 1: What’s the data model really doing?

Airtable’s mental model is “a spreadsheet that’s secretly a database.” All four honor that surface, but underneath they diverge sharply.

Baserow owns its schema. You create databases and tables inside Baserow, persisted in its own PostgreSQL store (github.com/baserow/baserow). It’s the most straightforwardly Airtable-shaped of the group: a tidy, self-contained app where Baserow is the source of truth.

Teable also owns its schema, but on top of real PostgreSQL, and exposes that fact deliberately — the repo bills itself as “No-Code Postgres,” with SQL querying as a first-class feature (github.com/teableio/teable). Your spreadsheet UI sits over genuine Postgres tables, so you keep the no-code surface without locking data behind a proprietary representation.

Grist is the odd, elegant one: every document is a SQLite database, with a built-in Python formula engine instead of a bespoke formula language (github.com/gristlabs/grist-core). A Grist doc is a single portable .grist file that owns its own schema. If you think in terms of self-contained, relational, computable documents rather than one big shared workspace, this model is genuinely different from the rest.

NocoDB is the only one that will treat your existing database as the source of truth. Point it at a MySQL or PostgreSQL instance and it becomes a spreadsheet UI layer over tables you already have (github.com/nocodb/nocodb). It can also create its own schema, but the headline capability — “bring your own database” — is the one nothing else here matches.

That last distinction is the whole ballgame for some teams. If you already have an operational database and want a friendly grid on top without copying data into a second system, NocoDB is in a category of one.

Axis 2: How hard is it to get data in?

Everyone advertises CSV. The interesting questions are the Airtable escape hatch and the existing-database path.

• Grist has a direct “Import from Airtable” path plus CSV, Excel and Google Sheets. For a clean exit from Airtable specifically, this is the most reassuring story in the docs.
• NocoDB imports from Airtable (via a personal access token and a shared base), plus CSV, Excel and JSON — and, again, can simply connect to an existing DB instead of importing at all.
• Baserow has an Airtable import in beta (via a public shared link) alongside CSV/JSON/XML and paste-from-spreadsheet. Worth noting its import has a documented 5,000-rows-per-table cap, which matters if you’re moving anything large.
• Teable lists import/export as a feature with CSV and Excel, but I could not confirm a dedicated Airtable importer from primary sources, so I’d treat that as “verify before you commit.”

My rule: if the migration is the project — you’re leaving Airtable with real data tomorrow — Grist or NocoDB give me the most confidence today. If the data already lives in a database, NocoDB skips the migration entirely.

Axis 3: How painful is self-hosting?

This is where good intentions meet your ops budget. Roughly lightest to heaviest:

1. Grist — single container, SQLite by default, no required external services. Postgres and Redis are optional upgrades. The one I’d hand to someone who just wants a docker run and to be left alone.
2. NocoDB — one-line docker run or an install script, SQLite by default, no mandatory external database. Low friction to a first instance.
3. Baserow — an all-in-one container exists, but a real deployment is Postgres and Redis plus worker processes. Manageable, not trivial.
4. Teable — docker-compose with PostgreSQL and Redis both required, S3-compatible object storage recommended for production. The heaviest to stand up — the cost of its Postgres-native ambitions.

None of these are hard for someone comfortable with Docker. But “SQLite, one container” versus “Postgres + Redis + object storage” is a real difference in who can own the thing long-term, and for how long.

Axis 4: The license — read it before you fall in love

This is the axis people skip, and it’s the one that bites later.

• Grist is Apache-2.0 — the cleanest, least surprising license here.
• Baserow is MIT at its core, with premium and enterprise features under separate licenses. Classic open-core: the base is genuinely permissive, the upsells are not.
• Teable is AGPL-3.0 for the apps (MIT for its shared packages). AGPL is real open source, but if you plan to offer a modified version as a network service, understand the copyleft obligations going in.
• NocoDB is the one to flag loudly: its current license is the Sustainable Use License, which GitHub does not classify as OSI-approved open source. It’s source-available and restricts commercial redistribution. If “open source” is a hard requirement — for compliance, resale, or principle — NocoDB no longer qualifies, regardless of how good the product is.

None of these is disqualifying on its own. They’re facts you must know on day one, not discover during an acquisition review.

So which would I choose?

• Grist, when the unit of work is a self-contained, computable document, I want the lightest self-host, and a clean Apache-2.0 license matters. Its Python formula engine and single-file portability are a real edge for analysts.
• NocoDB, when there’s already a database I want to put a grid on top of — that “your DB is the source of truth” model is unmatched here. But only with eyes open about the Sustainable Use License.
• Teable, when I specifically want a Postgres-native foundation I can query with SQL and grow to large row counts, and I have the ops appetite for Postgres + Redis. I’d verify its Airtable import path before promising a migration.
• Baserow, when I want the most faithful Airtable-style experience as a tidy self-contained app, and the MIT core covers what I need without the paid tiers.

The mistake I see most often is picking on feature checklists. Features converge; data models and licenses don’t. Decide where your data should live and what license you can live with first — the rest sorts itself out.