Baserow: a self-hosted Airtable replacement with an open-core licence split

The problem Baserow solves, and the licence problem it creates

Teams that outgrow spreadsheets usually move to Airtable, and then discover that their operational data lives inside someone else's product. Baserow targets that moment. The README frames it as a spreadsheet database hybrid and positions the project explicitly as the best alternative to Airtable, with the pitch built on data ownership and no vendor lock-in. The intended user is a team that wants grid editing and form views without writing a schema migration for every new column, but also wants the rows to sit in a PostgreSQL instance it controls.

The licence story is the part to read carefully. The README says Baserow is open-core, with all non-premium and non-enterprise features under the MIT License, and the Meta section repeats that it distributes under the MIT license. The repository metadata, however, reports the licence as NOASSERTION, which means GitHub could not map the LICENSE file to a recognised SPDX identifier. Both statements can be true at once: an open-core project often ships a LICENSE file that is not plain MIT, because it covers the premium and enterprise tiers too. The practical consequence is that the MIT grant applies to a subset of the tree, not to everything you can install. If permissive licensing across the whole product is a requirement, this repository does not confirm it. Read LICENSE and the licence headers of the specific modules you plan to modify before you assume MIT covers them.

Django, Vue and PostgreSQL: the architecture behind the grid

The README names the stack directly: Django, Vue.js and PostgreSQL. That combination explains most of the behaviour you will observe. PostgreSQL is not an implementation detail here, it is the storage engine, so the platform inherits PostgreSQL's type system, indexing and backup tooling rather than inventing a proprietary store. Django provides the application server, the permission model and the REST layer. Vue renders the front end, which is why the grid, kanban, form and dashboard views all live in the same browser application.

Around that core the README lists the surfaces Baserow exposes: a database with multiple view types, an application builder for portals published on your own domain, automations, dashboards, and Kuma, described as an AI assistant that builds complete solutions from natural language. The project also calls itself headless and API first, and points to a Redoc page and an OpenAPI schema at api.baserow.io/api/schema.json. For an engineering team, the OpenAPI schema is the more useful artefact of the two: it means you can generate a client and treat Baserow as a backend rather than only as a UI. The repository migration notice is worth knowing about too. Baserow moved from GitLab to GitHub, issues were migrated, but merged and closed merge requests were not imported, so the pre-migration history of the code review record is incomplete on GitHub and lives at gitlab.com/baserow/baserow.

Getting a running instance from one Docker command

The README gives the shortest path first. A single command starts the published image with two ports mapped and a named volume for persistence:

docker run -v baserow_data:/baserow/data -p 80:80 -p 443:80 baserow/baserow:2.3.3

The tag matters. The README pins 2.3.3, which matches the most recent release listed in the repository metadata, dated 2026-07-21. The volume mount at /baserow/data is what survives a container replacement, so any backup plan has to cover that path. Port 443 is mapped in the example, which implies the image handles TLS termination itself rather than expecting a reverse proxy in front of it. If you already run a proxy, that is a design decision you will have to work around.

For anything beyond a trial, the README links installation guides for Helm, Docker Compose, Heroku, Render, Digital Ocean, AWS, Cloudron, Railway and Elestio. The spread is unusually wide and tells you the project expects to meet teams wherever they already deploy. The AWS and Helm guides are the ones to read if you need horizontal scaling, because a single container with a local volume is not a scaling story. For contributors, the development environment uses just recipes: git clone, then just dc-dev build --parallel and just dc-dev up -d, with the dev instance on localhost:3000 and hot reloading enabled. That is a lower barrier than most Django plus Vue projects offer, but it assumes just is installed.

The open-core boundary is the real adoption decision

Every feature list in the README comes with an unstated qualifier, because the project is open-core. The AI assistant, the application builder, automations and dashboards are all named as capabilities of the platform, but the README only guarantees MIT for the non-premium, non-enterprise portion. It does not enumerate which features fall on which side of that line. That gap is the single most important thing to resolve before a pilot, and it cannot be resolved from the README alone. You have to open the pricing page or the repository's licence documentation and map it against your own feature list.

The compliance claims deserve the same treatment. The README states GDPR, HIPAA and SOC 2 Type II compliance. Those certifications apply to the hosted offering and to the vendor's processes, not automatically to a self-hosted deployment that you operate. Running the Docker image on your own infrastructure gives you data control, which is the actual benefit the README is selling, but it does not transfer an audit report to your organisation. If you need HIPAA coverage, the self-hosted path means you own the controls, the logging and the business associate agreement question.

Where Baserow is the wrong tool

Baserow is a database with a spreadsheet interface, not a general application framework, and the difference shows up under load. The default install is a single container writing to a mounted volume, which is a fine shape for an internal tool and a poor shape for anything that needs to survive an availability zone failure without extra work. The README offers Helm and AWS guides for scalable installs, so the path exists, but it is a separate project from the one-line Docker command and it carries its own operational cost.

The second limitation is the one nobody documents: schema design. A spreadsheet grid encourages columns to be added casually, and PostgreSQL underneath will accept that until it does not. A team that treats Baserow as a place to dump heterogeneous data will accumulate a table with dozens of sparse fields and no constraints, and the API-first promise then exports that mess to every downstream consumer. The tool does not prevent this. It also does not replace a real ETL layer. If your requirement is scheduled transformation between systems with typed contracts, a workflow engine plus a warehouse is the honest answer, and Baserow is the wrong layer. Finally, if you need a fully permissive licence across every feature you plan to use, the open-core split is a blocker rather than a detail.

NocoDB and Appsmith occupy different points on the same axis

The closest comparison is NocoDB, which also turns a relational database into a spreadsheet interface and also targets the Airtable refugee. The approaches differ in where the database comes from. Baserow ships PostgreSQL as part of its own stack and manages the schema through its UI, so the database is Baserow's. NocoDB is commonly pointed at an existing database and generates a grid over tables that already exist. If your data is already in PostgreSQL and you want a UI on top without migration, that distinction decides the choice. If you want the platform to own the schema from the start, Baserow's model is the cleaner one.

Appsmith sits on a different axis entirely. It is for building internal tools with drag-and-drop widgets wired to queries, which overlaps with Baserow's application builder but not with its database. A team that mainly needs a CRUD admin panel over existing services may find Appsmith's model more direct, while a team whose core need is structured data with multiple views will find Baserow closer. The honest framing is that Baserow's application builder competes with Appsmith, and its database competes with NocoDB, and no single alternative covers both halves the same way.

Release cadence, upgrades and what to verify first

The release history in the repository metadata shows 2.3.1 on 2026-07-10, 2.3.2 on 2026-07-15 and 2.3.3 on 2026-07-21. Three patch releases inside eleven days is a fast cadence, and it cuts both ways. Security fixes arrive quickly, but so do upgrade events, and a self-hosted deployment on the pinned 2.3.3 image will fall behind within weeks unless someone owns the update. The upgrade mechanics themselves are not described in the README beyond the installation guides, so the migration path between minor versions, and whether database migrations run automatically on container start, is something to confirm from the Docker installation doc and the changelog before you commit to a version. Pin the image tag rather than tracking latest, and back up the /baserow/data volume before each bump.

The repository is not archived and the default branch is develop, with master referenced in the Heroku deploy template URL, so the two branch names coexist and you should check which one your deployment guide actually tracks. The project is maintained by Baserow B.V. and accepts sponsorship through GitHub Sponsors, which is a signal about funding model rather than about code quality. The concrete next step is small: pull the 2.3.3 image, run the docker command from the README, create one table with the field types you actually use, and export it through the OpenAPI schema. If the export gives you what your downstream systems need, the platform fits. If it does not, no amount of additional evaluation will change that.

Editorial conclusion

Adopt Baserow if you want a spreadsheet-style database you control, can run Docker or Helm, and are comfortable that the free tier is the MIT part while premium and enterprise features sit behind a separate licence. Do not adopt it if you need a permissively licensed application builder end to end, or if you cannot run PostgreSQL and a container runtime. Before committing, verify three things: the exact contents of LICENSE, which features your team actually needs fall on the premium side of the open-core line, and whether the 2.3.x release cadence (three patch releases in July 2026) matches your upgrade window.

Official sources

1. baserow/baserow on GitHub
2. Issues
3. Project website
4. README
5. Releases