Open-source alternatives to Airtable: 3 spreadsheet-database tools compared
All three of these replace a hosted base with a database you run yourself, and in exchange you take on backups, upgrades and a licence that is not simply MIT. nocodb/nocodb is the one to look at first if you already have Postgres or MySQL and want a grid and a REST API over it.
What Airtable does, and why people look elsewhere
Airtable is a hosted database with a spreadsheet interface: typed fields, linked records, views, forms and automations.
- per-seat pricing and record limits per base
- data stays on Airtable's servers
- no way to point it at a database you already run
The candidates at a glance
| Project | Licence | Maintenance | Language | GitHub stars | Install | Best for |
|---|---|---|---|---|---|---|
| nocodb/nocodb | Custom licenceCustom licence: read the LICENSE file | Commits in the last six monthsLast push October 11, 2026 | TypeScript | 65,246 | See analysis | You already run Postgres or MySQL and want a spreadsheet interface plus a REST API over that same database, rather than a second copy of the data. It is the shortest route on this page when the records are already relational. |
| teableio/teable | Custom licenceCustom licence: read the LICENSE file | Commits in the last dayLast push October 11, 2026 | TypeScript | 21,881 | Command documented | You want a spreadsheet over PostgreSQL plus the three things people ask an alternative for by name: an AI chat over your data, an app builder that publishes to its own URL, and automations triggered by record changes, schedules and webhooks. All three exist in the full self-hosted deployment. |
| baserow/baserow | Custom licenceCustom licence: read the LICENSE file | Commits in the last six monthsLast push October 2, 2026 | Python | 6,078 | See analysis | You want the spreadsheet and database hybrid with an application builder you can publish on your own domain, automations and dashboards, self-hosted with no storage restrictions. The non-premium and non-enterprise features are under MIT for commercial and private use, and the Django, Vue.js and PostgreSQL stack is ordinary to run. |
Each alternative in detail
nocodb/nocodb🔥 🔥 🔥 A Free & Self-hostable Airtable Alternative
- Best for
- You already run Postgres or MySQL and want a spreadsheet interface plus a REST API over that same database, rather than a second copy of the data. It is the shortest route on this page when the records are already relational.
- What you give up
- The Sustainable Use License is not OSI approved, so read LICENSE.md before you put this in front of anyone outside the company, and check that its terms cover your intended use. There is also no stated way back from a version upgrade: our analysis of NocoDB is blunt that the README does not explain upgrades or rollback. Pointing it at a production instance also means confirming your database version is supported before you do.
teableio/teable✨ AI Spreadsheet for Business
- Best for
- You want a spreadsheet over PostgreSQL plus the three things people ask an alternative for by name: an AI chat over your data, an app builder that publishes to its own URL, and automations triggered by record changes, schedules and webhooks. All three exist in the full self-hosted deployment.
- What you give up
- The standalone image is not the full product. The README deployment table marks AI features and the App Builder as absent from standalone self-host and present in the full self-host, so the image you choose decides what you get. The full deployment also runs an isolated container per AI session and a long lived container per published app, which is more moving parts than a grid needs. Licence terms sit in two files, AGPL_LICENSE and LICENSE, and have to be read separately.
- First install step
- Full setup guide
# Enabling the Help Management Package Manager corepack enable # Install project dependencies pnpm install
baserow/baserowBuild databases, automations, apps & agents with AI — no code. Open source platform available on cloud and self-hosted. GDPR, HIPAA, SOC 2 compliant. Best Airtable alternative.
- Best for
- You want the spreadsheet and database hybrid with an application builder you can publish on your own domain, automations and dashboards, self-hosted with no storage restrictions. The non-premium and non-enterprise features are under MIT for commercial and private use, and the Django, Vue.js and PostgreSQL stack is ordinary to run.
- What you give up
- It is open core, so the features living in the premium/ and enterprise/ directories are the ones to check the licence files for before you plan a commercial deployment, and self-hosting does not remove that boundary. You also own the upgrade path: the install command pins an image tag, so matching that tag against the changelog is part of keeping current, and the most recent release listed is 2.3.3 from 2026-07-21 while the last push was 2026-09-17.
Three ways to put a grid over a database
Airtable is a hosted database with a spreadsheet interface: typed fields, linked records, views, forms and automations. People look elsewhere for specific reasons, and they are worth naming before any feature comparison: per-seat pricing and record limits per base, data held on Airtable's servers, and no way to point the interface at a database you already run.
Those complaints produce three different answers here.
nocodb/nocodb goes furthest in the direction of not owning your data. It presents an existing SQL database, Postgres or MySQL, as a grid, with forms and a REST API on top. The data stays in the database you already back up, and NocoDB is a presentation layer over it. That also means a migration is a matter of pointing it at a different connection rather than moving records.
teableio/teable also sits on PostgreSQL but pushes further into features. The README describes four platforms in one self-hosted deployment: a spreadsheet and collaboration platform with API and automations, an AI chat and agent sandbox where every session runs in its own container, an app deployment platform where each published app gets a long lived container, and an AI workflow engine reacting to record changes, schedules and webhooks.
baserow/baserow is a full application platform rather than a view. It builds databases, applications and portals you can publish on your own domain, automations, dashboards, and a Kuma AI assistant, in Python on Django and Vue.js with PostgreSQL underneath.
What is missing across all three is also worth naming. All three keep your records in a SQL database you can query directly, so backups are your database's backups and exports are ordinary database work. What you give up is the setup-free experience: there is no vendor here who creates the base, hosts the apps and answers the phone at 02:00.
Choosing by scenario: one person, a small team, a company under review, a developer embedding it
The three differ less in their grid than in how much of the platform they insist on running.
One person building a tracker or a content list should start with nocodb/nocodb. One Docker run, or one auto-upstall command, and the data is a table you control. teableio/teable is a reasonable second look for the same person if the AI chat is the feature that would make them use it, but that feature lives in the full deployment, not the standalone image.
A small team that has outgrown a shared spreadsheet usually wants forms, permissions and an application other people can use rather than a grid. That is baserow/baserow's centre of gravity: applications and portals published on your own domain, automations, dashboards, and a REST API. Its README states that self-hosted installs carry no storage restrictions, which is the specific Airtable complaint about record limits per base.
A company with compliance or data residency requirements is looking for the same thing all three offer, so the decision turns on operations and licence rather than on features. The README for Baserow states GDPR, HIPAA and SOC 2 Type II compliance, and its no-sign-up self-hosted path is the reason to read its licence files carefully. Rocket.Chat-style vendor dependence is not a factor here, but who patches the server is.
A developer embedding the tool in a product is the case where the licence decides it before the features do. A front end over a database you already have is nocodb/nocodb, with the Sustainable Use License as the thing to resolve. A published app on your own URL is baserow/baserow or the App Builder in teableio/teable, and both carry terms you cannot skip.
What each one asks you to run and keep patched
The install commands on this page are the shortest way to see the difference.
nocodb/nocodb gives you a single container with a volume mounted at /usr/app/data, and the README also documents a Postgres variant behind the NC_DB environment variable. Underneath it is a database you already run, so there is one new service rather than a new stack. There is also an auto-upstall path that generates a Docker Compose setup with PostgreSQL, Redis and a Traefik gateway, sets up SSL and renews it, and upgrades NocoDB when you run the command again. That is a full production shape, and it is a different commitment from the single container.
teableio/teable is the most demanding of the three. The README splits the deployment into Teable Cloud, full-featured self-host and standalone self-host, and the difference between the last two is the AI features and the App Builder. The command on this page, corepack enable followed by pnpm install, is a source build, which is a signal about how the project is developed rather than how you should deploy it. If you want the full self-host you are running an agent sandbox and an app container platform, not just a grid.
baserow/baserow is a container with a named volume and ports 80 and 443, and the README lists Docker, Helm, Docker Compose, and managed paths on AWS, Cloudron, Railway and Heroku. Behind it are PostgreSQL, a Django application and a Celery-style job runner, so the background work is yours to watch.
The common cost across all three is the same and it is the real one: a database you back up, a service you restart, and an upgrade you test before you apply.
Licence terms: source available, AGPL, and open core
None of these three is a single permissive licence covering everything, and the differences matter for a company.
nocodb/nocodb is distributed under the Sustainable Use License, which is not an OSI approved licence. Our analysis of NocoDB puts it plainly: internal use is workable, but a component you embed in a product you sell is not, and the text in LICENSE.md has to be read before you decide. This is the licence most often underestimated on pages like this one.
teableio/teable carries an AGPL_LICENSE file alongside LICENSE, and our analysis of Teable tells you to verify the terms of both. AGPL is the obligation that reaches out to users of a network service, so if you run a modified Teable and let people outside the company reach it, the copyleft question is live. It is comfortable for internal use and needs thought before it goes further.
baserow/baserow is the clearest of the three to reason about. The README states that all non-premium and non-enterprise features are under the MIT License allowing commercial and private use, and that the project is open core. The boundary is the premium/ and enterprise/ directories, and our analysis of Baserow says to read the licence files in those directories before planning a commercial deployment rather than after.
So the pattern is consistent. baserow/baserow gives you the widest permissively licensed core, teableio/teable asks you to read two files and think about AGPL reach, and nocodb/nocodb asks you to accept a source available licence that a legal team will have to classify for itself.
Getting data back out, and what you take over
The reason most people leave a hosted base is that the data is not theirs to keep. All three projects here invert that, and it is worth being concrete about what changes.
The records live in Postgres or MySQL. For nocodb/nocodb that is explicit, since the tool connects to a database you already run. For teableio/teable the README describes a database collaboration platform on PostgreSQL with tables, views, permissions and API. For baserow/baserow the README describes a Django, Vue.js and PostgreSQL stack and states the platform is headless and API first, with an OpenAPI schema published alongside the API documentation.
What that means in practice is that a nightly dump of the database is your backup, a CSV export is a query, and a data export is a table copy. Those are ordinary operations you can script and schedule, which is the strongest argument for the whole page.
What you take over is less glamorous. Someone has to run upgrades, watch disk, and notice when a nightly job stops. Somebody has to decide what a breaking change in a release means for the forms and automations people depend on. None of these tools has a managed tier that takes that, which is the same trade every self-hosted project makes, and the reason to pick one here rather than another is the licence and the operational shape, not the feature list.
Bottom line
Pick nocodb/nocodb when the data is already in Postgres or MySQL and you want the smallest thing that puts a grid and an API over it; pick baserow/baserow when you want applications, portals and dashboards with the widest permissively licensed core; pick teableio/teable when the AI chat and the app builder are the features you will actually use, and take the full deployment. Before committing, read the licence file that covers the features you plan to enable, confirm which deployment image includes them, and decide who runs the database backup.