Open-source alternatives to Airtable

The right question to ask of these three is not “which looks most like Airtable” but: take a real base — say a thousand-plus rows across linked tables, formula fields, a few views per table — and ask what each project does with it after import. I have not run that experiment end-to-end myself; the comparison below is assembled from each project’s import docs, schema-handling design, and the migration reports users publish — and the answer differs far more than the READMEs suggest.

The one project this comparison deliberately excludes is Directus. Directus is in the list above and is excellent in its own right, but it is honestly not in the same product category as Airtable — Directus is a “headless CMS over your database” with a spreadsheet-shaped admin, whereas the others are “Airtable-shaped products that happen to use a database”. If your team’s mental model is “spreadsheet first, database second”, Directus will feel weirdly inverted on day one and you will spend more time explaining the model than using the tool.

NocoDB — the spreadsheet that grew up the most

NocoDB is the most battle-hardened of the three. ≈64.8k★, the biggest community in this list — but the more telling signal is in its issue tracker, which shows years of fixes for exactly the ugly edge cases (hand-altered columns in the underlying Postgres, half-broken imports) that quietly kill spreadsheet-database hybrids. Two things to know before you commit:

1. The GitHub API returns no SPDX id for NocoDB, and the licence in the repo is not AGPL — it is the Sustainable Use License 1.0. We read LICENSE.md on 2026-09-05 (the card links to the exact commit): the master and develop branches are under that licence, and its terms allow use and modification only for your own internal business purposes or for non-commercial or personal use, and redistribution only free of charge for non-commercial purposes. That is a “fair-code” licence, not an OSI-approved open-source one. Running NocoDB as your team’s internal database is exactly the permitted case; if you plan to embed it in something your customers pay for, get legal advice on the boundary first.
2. NocoDB owns the schema. It will write its nc_* metadata tables into the database you point it at. If you are sharing that Postgres with other apps, give NocoDB its own schema or its own database — do not point it at a database with public.users you care about.

Baserow — the most Airtable-shaped UX, with a price

Baserow’s UI is the closest pixel-for-pixel match to Airtable in this list. If you are migrating non-technical users who know Airtable, the training cost is the lowest here. The ≈5.8k★ count under-represents how polished it is — Baserow’s growth has been steadier and quieter than the TypeScript-heavy alternatives. The trade-off shows up in extensibility: the formula language is Baserow’s own (not Airtable’s), so most non-trivial formulas will need a hand-rewrite during migration; the more unique formulas your source base has, the more of the project that rewrite becomes. Python backend, which is easier to read and patch than the TypeScript projects if you need to fork.

Teable — the database-first bet

Teable’s framing — “spreadsheet-simple on the surface, real PostgreSQL underneath”, in the words of its README (default branch, read 2026-09-06: https://github.com/teableio/teable#readme) — is the key to where it fits. Like NocoDB and Baserow it creates and manages its own schema; the README describes tables, views, permissions and the API all resting on a PostgreSQL database that Teable manages, self-hosted or in its cloud. Whether you can point it at a database you already run is not something the current README settles — verify against the docs before you plan around it. If your scenario is “I want a spreadsheet UI now, and I want the data to stay in Postgres”, Teable is the cleanest fit here. The cost: it is the youngest of the three (≈21.8k★ but a younger codebase), and some of the Airtable features Baserow has shipped (rich text, kanban polish) are not fully there yet.

The migration step everyone underestimates

All three of these projects import Airtable CSVs cleanly for the data. None of them import Airtable automations or interfaces — those have to be rebuilt from scratch. If your Airtable base has 20 automations firing Slack messages on row changes, the work of wiring them back up is a line item of its own for whichever project you pick. NocoDB has the most mature webhooks story, Baserow’s automations UI is the most spreadsheet-user-friendly, Teable expects you to do automations outside the product (Postgres triggers, a self-hosted automation tool — see the Zapier comparison — or your own service).

Where each one lands

If the use case is a non-technical team’s shared tracker (the original Airtable use case), Baserow — the UX is closest and nobody has to relearn the tool. If engineers also want to query the data with raw SQL or wire external jobs to it, Teable, because its tables stay plain Postgres you can read from outside the product. NocoDB is the pick when a non-technical team needs an Airtable replacement and can spend an hour on the UI differences — in exchange you get the deepest webhooks story and the largest community when something breaks.