NocoDB: self-hosting an Airtable-style database on top of Postgres or SQLite

What NocoDB is for, and who ends up using it

NocoDB is a web application that sits in front of a relational database and presents it as a spreadsheet. The README describes it as "the fastest and easiest way to build databases online" and positions it as a free, self-hostable Airtable alternative. The practical consequence is that the data lives in a database you control, not in a vendor's cloud, while non-engineers get grids, forms, and Kanban boards instead of SQL clients.

The audience follows from that. Teams that already run Postgres or MySQL and keep getting asked for a friendlier editing surface are the natural fit. So are small groups that want a shared base without paying per-seat SaaS pricing. The README lists field types such as ID, Links, Lookup, Rollup, SingleLineText, Attachment, Currency, Formula and User, plus view types Grid, Gallery, Form, Kanban and Calendar. That is a fairly complete spreadsheet vocabulary, and it is the reason people reach for NocoDB instead of writing another internal admin panel.

It is not a database. NocoDB does not replace Postgres, and it does not give you query planning, indexes, or migrations beyond what the underlying engine offers. If your problem is data modelling, NocoDB is the wrong layer.

How NocoDB works: a metadata layer over your own database

The repository is a pnpm and lerna monorepo. The root package.json defines a bootstrap script that installs and builds nocodb-sdk first, then installs nocodb, nc-mail-templates and nc-gui, then builds and registers integrations. Separate scripts start the frontend (start:frontend runs the dev server for nc-gui) and the backend (start:backend runs the nocodb package). That split is the architecture in miniature: a TypeScript backend that talks to your database and a Vue frontend that renders the spreadsheet.

The backend connects either to its own SQLite file or to an external Postgres, MySQL or similar instance. The README's Postgres example passes the connection string through the NC_DB environment variable in the form pg://host:port?u=user&p=password&d=database, and a separate NC_AUTH_JWT_SECRET variable supplies the token signing secret. Views, fields, filters and permissions are stored as metadata; the rows themselves stay in your tables. That is why you can point NocoDB at an existing schema and start editing.

On top of that layer the README advertises an App Store for workflow automations, with integrations grouped into categories. It also documents sharing bases and views publicly or privately with password protection, and fine-grained role-based access control at different levels. The most recent releases add Interfaces, Realtime Presence, Folders, Calendar Sync and Image Annotations, which suggests the product is moving toward being a front-end builder rather than only a grid.

Installing NocoDB with Docker and creating a first base

The README's first install path is Docker with SQLite. The command below mounts a local directory at /usr/app/data/ so the SQLite file survives container restarts, and publishes port 8080.

docker run -d \
  --name noco \
  -v "$(pwd)"/nocodb:/usr/app/data/ \
  -p 8080:8080 \
  nocodb/nocodb:latest

After the container starts, the README says to open http://localhost:8080/dashboard. The first screen asks you to create a base; that base is backed by the SQLite file inside the mounted volume. If you would rather use Postgres, the README gives a second variant that adds the NC_DB and NC_AUTH_JWT_SECRET environment variables:

docker run -d \
  --name noco \
  -v "$(pwd)"/nocodb:/usr/app/data/ \
  -p 8080:8080 \
  -e NC_DB="pg://host.docker.internal:5432?u=root&p=password&d=d1" \
  -e NC_AUTH_JWT_SECRET="569a1821-0a93-45e8-87ab-eb857f20a010" \
  nocodb/nocodb:latest

Note the host.docker.internal hostname: from inside the container, localhost is the container itself, so a Postgres instance on the host has to be addressed differently. The JWT secret in the README is an example value; generate your own before running this anywhere reachable.

For a server rather than a laptop, the README points to Auto-upstall, a single command that generates a docker-compose file and sets up NocoDB with PostgreSQL, Redis and a Traefik gateway, requesting a domain or subdomain so it can configure and renew SSL.

bash <(curl -sSL http://install.nocodb.com/noco.sh) <(mktemp)

The README states that running the same command again upgrades NocoDB to the latest version. It also notes that the binaries for macOS, Linux and Windows are "only for quick testing locally", so treat those as a way to try the interface, not as a deployment method.

Where NocoDB is the wrong tool

The licence is the first constraint. The root package.json declares "Sustainable Use License", and the repository carries a LICENSE.md file. That is not an OSI-approved open source licence, even though the project is described as open source in common usage. If you intend to redistribute NocoDB inside a commercial product, or to offer it as a hosted service, read LICENSE.md before you build anything on it. This article cannot tell you whether your specific use is permitted.

The second constraint is the database connection itself. NocoDB works on top of your schema, which means an accidental column rename or a deleted table in the grid is a change to the real database, subject to whatever the underlying engine enforces. The README does not describe an undo history, a staging copy, or a rollback path. Teams that need change review before a schema edit reaches production should not hand NocoDB to users who do not understand that.

The third is operational. The README documents how to start NocoDB and how Auto-upstall upgrades it, but it does not document how to downgrade, how to migrate between SQLite and Postgres, or what happens to metadata when a release changes it. The release notes name features, not migration steps. If you run a version pinned months behind and then jump forward, you are relying on the project's own testing rather than on a documented upgrade procedure. For a single internal base that is usually fine. For a system other people depend on, it is a risk you should price in before adopting.

Finally, the README does not document a backup procedure. The mounted volume at /usr/app/data/ holds the SQLite file when you use the default install, so backing that directory up is the obvious move, but the project itself does not say so.

NocoDB compared with Baserow and Airtable

The closest self-hosted comparison is Baserow, and the difference is architectural. NocoDB is explicitly a layer over a database you already have: you can point it at an existing Postgres or MySQL instance and it will present those tables. Baserow is built around its own storage model, so adopting it usually means moving data into Baserow rather than exposing data that is already there. If your goal is a friendlier interface on a schema your application already writes to, that difference decides the choice. If your goal is a standalone base with no existing database, it matters much less.

Against Airtable the difference is control, not features. Airtable is hosted, priced per seat, and its data lives with the vendor. NocoDB is self-hosted, and the README's pricing question is answered by the fact that you run the container yourself; the cost becomes your server, your backups, and your upgrade time. That trade is real: you gain control over data residency and per-seat cost, and you take on operations that a SaaS product would otherwise absorb.

One more distinction worth stating plainly. NocoDB's recent releases added Interfaces, Realtime Presence and Folders. That moves it toward being an application builder, which overlaps with a different category of tool than the grid-and-API product the README leads with. Readers comparing it to a pure database front end should check whether the features they need are in the part of the product that has stabilised.

Maintenance, upgrades and licence cost

The repository is not archived, and the last push was on 2026-08-19, which coincides with the 2026.08.1 release. Releases arrive on a roughly monthly cadence: 2026.07.0 on 2026-07-14, 2026.08.0 on 2026-08-05, and 2026.08.1 on 2026-08-19. Monthly feature releases with names like "Introducing Interfaces" and "Introducing Realtime Presence" mean the surface area keeps growing, and the upgrade cost is not zero even when the command is one line.

Auto-upstall is the documented upgrade path: rerun the same command and it pulls the latest version. That is convenient, but it also means the default posture is to track latest rather than to pin. If you want a reproducible deployment, the Docker examples let you substitute a specific tag for nocodb/nocodb:latest, and the README does not discourage that. What the README does not provide is a documented way to move backwards.

On licence, the Sustainable Use License is the fact to check. It is not the MIT or Apache 2.0 licence that many self-hosted tools ship under, and the project's own package.json is the source for that claim. Whether it affects you depends on whether you are running NocoDB internally or building it into something you distribute; the LICENSE.md file is where the answer lives, and this article is not legal advice.

Editorial conclusion

Adopt NocoDB if you already run Postgres or MySQL and want a spreadsheet front end plus a REST API for internal tools, and you are comfortable with the Sustainable Use License rather than a standard open source licence. Do not adopt it if you need a permissively licensed component to embed in a product you sell, or if you expect the README to explain upgrades and rollback; it does not. Verify first whether the Sustainable Use License text in LICENSE.md covers your intended use, and check that your database version is supported before pointing NocoDB at a production instance.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes