Baserow: a self-hosted Airtable alternative with an API-first core

What Baserow replaces, and for whom

Baserow positions itself as a spreadsheet-database hybrid: a grid interface for entering and relating records, plus views on top of the same data. The README lists forms, kanban, dashboards, an application builder and automations, and describes the product as headless and API first. The audience is teams that have outgrown a shared spreadsheet but do not want to hand their records to a hosted vendor. The README states the platform is GDPR, HIPAA and SOC 2 Type II compliant, and that self-hosting carries no storage restrictions or sign-up. That combination, a familiar grid plus a REST surface, is the niche it occupies. It is not a general-purpose relational modelling tool in the PostgreSQL sense: the unit of design is the table and its fields, not schemas and migrations you write by hand. If your team already writes SQL migrations and reviews them, Baserow will feel like an extra layer rather than a shortcut. If your operations staff maintain the data and engineering only needs an API, the trade is reversed.

How the pieces fit: Django, PostgreSQL, Redis and Caddy

The repository layout separates backend/ and web-frontend/, with PostgreSQL and Redis as the two stateful dependencies named in the compose configuration. The advanced docker-compose.yml explains the routing decision: a Caddy reverse proxy sits in front, routing requests to the backend or the web-frontend, handling websockets, and serving uploaded files. The file recommends forwarding your own proxy to Caddy rather than bypassing it, because the Caddy configuration already knows the internal topology. Configuration reaches the backend as environment variables. The compose file groups them under an x-backend-variables anchor and marks SECRET_KEY, DATABASE_PASSWORD and REDIS_PASSWORD as required, with BASEROW_JWT_SIGNING_KEY optional but recommended. BASEROW_PUBLIC_URL defaults to http://localhost and is used to build API links and emails, so a wrong value shows up as broken links rather than a crash. There is also a docker-compose.no-caddy.yml variant for deployments where something else terminates TLS, and a docker-compose.all-in-one.yml that the compose comments describe as the simpler option for non-advanced users. The API itself is documented at api.baserow.io, with an OpenAPI schema published as JSON, which is what makes the API-first claim checkable rather than marketing.

Installing Baserow with Docker and creating the first table

The README gives a single-container command as the shortest path. It maps ports 80 and 443 and mounts a named volume for persistence, so the data survives container replacement.

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

After the container starts, the instance is reachable on the host at the mapped ports. The README points to https://baserow.io for a hosted start instead, and the installation section links separate guides for Docker, Helm, Docker Compose, Heroku, Render, Digital Ocean, AWS, Cloudron, Railway and Elestio. For the multi-service compose file, the repository ships .env.example and the compose comments describe a three-step setup: copy the example file, fill in the first three variables, then adjust the rest. The example file suggests generating each secret with a command rather than typing one.

tr -dc 'a-z0-9' < /dev/urandom | head -c50

That value goes into SECRET_KEY, DATABASE_PASSWORD and REDIS_PASSWORD in .env. The same file shows DATABASE_USER and DATABASE_NAME defaulting to baserow, with commented entries for an external PostgreSQL or Redis and for SMTP and S3. Once the instance is up, the workspace is the container for your databases, and each database holds tables whose fields define the columns. From there the API is the practical integration point: the OpenAPI schema at api.baserow.io/api/schema.json describes the endpoints, and the README lists the REST API as a core feature rather than an add-on.

Where Baserow gets awkward

The licence is the first constraint. The repository reports NOASSERTION for its licence field, and the README describes the project as open-core, with MIT covering all non-premium and non-enterprise features. That wording implies premium/ and enterprise/ directories exist at the top level, and they do. Anyone planning commercial use should read those directories rather than assume the MIT label applies to the whole repository. The second constraint is operational. The advanced compose file exists because a real deployment has a proxy, a database, a cache and a worker tier; the all-in-one image is convenient but the compose comments themselves steer advanced users away from it. Self-hosting means you own upgrades, backups and the PostgreSQL instance, and the README does not document a rollback procedure. Third, the AI features are described in the README as Kuma, an assistant that builds databases and workflows from natural language, but the README gives no statement about where prompts or generated schemas are processed in a self-hosted install. If your data cannot leave your network, treat that as an open question to resolve before enabling it. Finally, Baserow is a database product with a grid interface, not a CRM. Search traffic asking whether Baserow is a CRM reflects a mismatch the README does not address: there is no pipeline or deal-stage model out of the box.

Baserow against NocoDB and Airtable

Airtable is the closed hosted product Baserow explicitly targets, and the difference is deployment and data custody rather than features. With Airtable you get a managed service and no server to run; with Baserow self-hosted you get the reverse, plus the README's claim of no storage restrictions. NocoDB is the closer comparison, and it is the one search data keeps pairing with Baserow. Both present a grid over a relational store and both are open source, but the repository evidence here points to a difference in scope: Baserow ships an application builder, dashboards and an automations engine as first-class parts of the product, and its backend is a Django application with Celery-style workers implied by the compose topology. NocoDB's appeal is usually described as sitting directly on top of an existing database, which is a different starting assumption. If your data already lives in PostgreSQL and you want a UI over it, that assumption matters more than any feature list. If you are starting from a blank workspace and want forms, views and automations in one place, Baserow's packaging is the more opinionated of the two.

Maintenance, releases and licence cost

The repository is not archived and the last push was on 2026-09-10, so the project is being worked on now. Releases are frequent: 2.3.1 on 2026-07-10, 2.3.2 on 2026-07-15 and 2.3.3 on 2026-07-21, with the README stating version 2.3.3. That cadence is good for fixes and less good for operators, because a self-hosted install has to decide how often to move. The Docker image is tagged by version, so pinning to baserow/baserow:2.3.3 is possible, and the changelog directory at the repository root is where upgrade notes would live. The README does not describe a supported upgrade path between major versions, and no rollback steps appear in the README. On licensing, the MIT grant covers non-premium and non-enterprise features only, and the top-level premium/ and enterprise/ directories are the places to check what falls outside it. Nothing here is legal advice; the point is that a licence field reading NOASSERTION plus an open-core README means the boundary has to be read from the files, not inferred from the badge.

Editorial conclusion

Adopt Baserow if you need a spreadsheet-style database you can run yourself, with a REST API and no storage restrictions on self-hosted installs. Do not adopt it if you expect every feature under a single permissive licence, or if you want a vendor to run the upgrade path for you. Verify first that the Docker image tag you intend to run matches a release listed in the changelog, and read the licence files in the premium/ and enterprise/ directories before you plan a commercial deployment.

Frequently asked questions

Official sources

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