NocoDB

Last reviewed Aug 26, 2026 · 798 words

Before you create a single table in NocoDB, set the NC_DB environment variable to point at Postgres. Skipped, NocoDB happily stores everything — your bases, views, users, automations — in a bundled SQLite file inside the container, and that default works right up until the day you want proper backups, concurrent users, or a migration, at which point it becomes the chore you deferred. One line in your compose file avoids it:

services:
  nocodb:
    image: nocodb/nocodb:latest
    ports:
      - "8080:8080"
    environment:
      - NC_DB=pg://postgres:5432?u=nocodb&p=change-me&d=nocodb
    volumes:
      - ./nc-data:/usr/app/data
    restart: unless-stopped

With that settled, NocoDB is one of the easiest wins in self-hosting: the catalogue rates it Easy at a 1 GB RAM minimum, and both are accurate. It is AGPL-3.0 TypeScript with 64,733 GitHub stars, and it earns its "open-source Airtable alternative" billing better than most tools earn theirs.

A spreadsheet interface your non-technical people will actually use

The core trick is presenting relational data as something spreadsheet-shaped. Tables render as grids with typed columns — links between tables, attachments, formulas, single-selects — and every table can also be viewed as a gallery, a kanban board, or a form you can hand to outsiders for data entry. That last one is quietly the killer feature: a public form URL that writes rows into your database replaces a surprising amount of Google Forms plus copy-paste. Households run inventories and chore trackers on it; small teams run CRMs and content calendars. The people entering data never need to know Postgres exists.

Every table ships with an API you didn't write

NocoDB auto-generates REST endpoints (with token auth) for every table, plus webhooks that fire on row creation and changes. In practice this turns it into a casual backend: pair a webhook with n8n and a new row in a "job applicants" table can send a Slack message, create a calendar hold, and file a follow-up task, all without writing an application. For a lot of internal tooling, NocoDB-plus-automation is the 20-minute alternative to building a web app, and the grid doubles as your admin panel for free.

Know the limits before you lean on it

Two cautions from the catalogue deserve expansion. First, large bases can lag — tables in the tens of thousands of rows stay usable, but views stacking multiple filters, sorts, and lookups get noticeably slower as data grows, so this is not the place for your million-row event log. Second, some features sit behind paid tiers, and the boundary has shifted over the project's life; check the current feature matrix on nocodb.com before architecting around a specific capability rather than assuming everything in a screenshot is free. The core — tables, views, forms, APIs, webhooks — has stayed open source, and for most self-hosters that core is the whole use case.

Where it sits among the spreadsheet-database crowd

The category has real depth now. Baserow is the closest rival — a similar Airtable-style experience with a plugin system and its own hosting-friendly design. Grist is the pick when your problem is actually spreadsheet-shaped: it has genuinely powerful formulas and Python scripting where NocoDB has lighter formula support. NocoDB's distinctive card is its relationship with existing databases — it grew up as a layer over the SQL you already have rather than a walled garden — which makes it the natural choice when Postgres is already the center of your setup. If you would rather browse the whole shelf, the dev-tools section of the directory lists the neighbors.

Migrating off Airtable is a weekend, not an afternoon

Getting data out of Airtable and into NocoDB works — CSV export per table, or NocoDB's import tooling — but structure transfers imperfectly. Linked records need re-linking, formulas need rewriting in NocoDB's syntax, automations need rebuilding as webhooks, and Airtable-specific field types degrade to text. Plan roughly a weekend for a multi-table base with relations, and treat it as a chance to prune: every Airtable base I have ever migrated contained three tables nobody had touched in a year.

What I'd do

Compose file above, Postgres backing it from minute one, nightly pg_dump plus a copy of the data volume for attachments. Start with one real base — the household inventory, the client tracker — and add the form view and a webhook before deciding whether you need more tools. For spreadsheet-first workloads with heavy formulas I would pick Grist instead, but for "Airtable, except it is mine and the API is free", NocoDB is the default I hand people, and Easy-difficulty ratings this deserved are rare.