NocoDB Review 2026: a full look at the open-source Airtable alternative
Sooner or later almost every team hits the same wall: data lives in Google Sheets, the sheet grows a hundred linked tabs, formulas break on every row insert, and half the team is editing the wrong column. Airtable solved this beautifully — and brought along a per-seat bill plus an awkward question about keeping customer data in someone else’s cloud.
NocoDB is the most popular answer to both problems at once. It is an open-source platform that turns an ordinary SQL database into a smart spreadsheet with forms, kanban boards, roles and a REST API. The project started from the idea of “Airtable on top of your own database” and by 2026 has collected more than 50,000 GitHub stars, tens of thousands of self-hosted installs and a full commercial cloud product.
In this review we look at how NocoDB works inside, what it genuinely does well, where it hurts, what the cloud costs and what running it on your own server really implies — with an honest verdict at the end: who should migrate, and who is better off staying on Airtable or looking at Baserow.
What NocoDB is and how it is built
The core architectural idea is simple, and that is exactly why it matters: NocoDB does not store your data in a proprietary format. It connects to an existing relational database — PostgreSQL, MySQL/MariaDB, SQLite, and in recent versions Microsoft SQL Server — and renders a spreadsheet-style web UI on top of it.
What that means in practice:
- Every NocoDB table is a real table in your database. Every column is a real column. Every row is an ordinary record.
- You can connect to the same database with
psql, run SQL, feed a BI tool or hand the data to an existing application at any moment. - If NocoDB disappeared tomorrow (open-source projects are mortal), your data would still sit in a standard database, not in a closed export.
The stack is not exotic either: a Node.js backend, a Vue frontend, everything packaged as a Docker image. For self-hosting that means one docker run plus a couple of environment variables — no cluster, no object storage requirement, no mandatory Redis.
It is worth spelling out the difference between the two delivery formats, because confusion here is constant:
- NocoDB Open Source — the free version you deploy yourself. Core features: tables, views, roles, API, webhooks. The limits concern advanced enterprise items such as SSO, audit logs and fine-grained permissions.
- NocoDB Cloud — the managed service run by the developers, where they own the infrastructure. Paid tiers with larger limits live here.
The third, least obvious option is External Database: you can attach a Postgres instance already powering your product and get a convenient admin UI over production data. Useful for support and analytics, but be careful — a web UI is not a replacement for migrations.
Who actually needs NocoDB
Based on real-world rollouts, NocoDB shines in four scenarios.
Internal operations tables. Lightweight CRM, customer base, ticket tracker, inventory, contract register. Everything that used to live in Google Sheets but outgrew it.
Replacing a hand-rolled admin panel. If you have a database and need an interface for operators — forms, filters, permissions — NocoDB covers 80% of the job with no frontend code at all.
A layer over a legacy database. An old MySQL base from an accounting system nobody dares to touch. NocoDB gives it a safe human interface with role-based access.
A fast product prototype. When you need a working CRUD backend with an API overnight rather than a Nest.js sprint.
And where you should not use NocoDB:
- As the primary database of a high-load product with thousands of concurrent users — that is not its job.
- As a file store or media library — attachments work, but this is not S3.
- As a replacement for a proper BI system: pivots and charts exist, deep analytics do not.
- For teams that need offline mode and native mobile apps on the Airtable level.
Pros and cons
Pros
- Open source with genuine self-hosting — no “cloud-only” caveats.
- Data lives in your SQL database, fully accessible via SQL and any client.
- The free tier is functionally complete for teams of 10–20.
- REST and GraphQL APIs out of the box for every table, documented in the UI.
- Many views: grid, form, gallery, kanban, calendar, map.
- Roles and permissions from owner down to viewer and commenter.
- Webhooks and record-triggered automations.
- Active community and frequent releases; the project is alive.
Cons
- The UI can feel heavy: with 50+ columns and tens of thousands of rows the browser starts to think.
- Formulas and rollups work but lag behind Airtable in depth and debuggability.
- Automations are modest: complex branching and external triggers need workarounds.
- No native mobile apps — only a responsive web version.
- Self-hosting requires skills: Docker, reverse proxy, backups, upgrades are on you.
- Major version upgrades occasionally need manual schema migration.
- Some enterprise features (SSO, audit, granular permissions) are paid-only.
Features: what NocoDB really does in 2026
Views
One table, many views — and this is not a marketing line. Grid is the base mode with filters, sorting, grouping and frozen columns. Form publishes a public link and collects data from outsiders without database access. Gallery shows records as cards with covers — handy for catalogues. Kanban groups records by a status field with drag-and-drop. Calendar ties records to dates, map to coordinates.
Each view stores its own filters and settings separately. For an operator this means the same dataset looks like “all tickets”, “my open tickets” and “overdue” without duplicating tables.
Field types
The field set is broad: text, number, date and time, checkbox, single and multi-select, email, URL, phone, currency, percent, rating, formula, rollup, lookup, relations (one-to-one, one-to-many, many-to-many), file attachments, JSON, geo data, barcode, long text, and a user/assignee field.
Relations are implemented with real foreign keys rather than text identifiers — noticeable during migrations and when working with the data from outside.
API
Every table automatically gets a REST API: list records with filters and pagination, create, update, delete, bulk operations. Plus a GraphQL endpoint for complex queries and access tokens scoped to tables.
This is the point that separates NocoDB from “just a pretty spreadsheet”: you can write a bot, a Python script or a mobile app against the same database through a documented API while managers keep editing data by hand in the browser.
Roles and access
Levels: Owner, Creator, Editor, Commenter, Viewer. Permissions are granted per base and per table. Plus public view links — with or without a password, with attachment downloads optionally disabled.
In the open-source edition granular permissions (row- and column-level) are limited — one of the main reasons companies buy a paid licence.
Webhooks and automations
Webhooks fire on record create, update and delete and post JSON to your endpoint. The built-in automation builder handles simple chains: “on status change — send an email”, “on schedule — create a record”, “on new record — call an external API”.
That is not enough for full orchestration — typically NocoDB is used as the data source and the logic lives in n8n, Make or your own service.
Pricing: cloud versus your own server
Naming things clearly matters here, because NocoDB’s pricing grid has changed more than once and exact figures should be checked on the official site when you read this.
Open Source (self-hosted) — free. The full Docker image, with no limits on records, tables or users. You only pay for the server.
Cloud Free — a free tier for a small team: good for trying the product, but capped on users and rows.
Cloud paid tiers — priced per seat on annual billing. Upper plans lift the seat limits: you will find offers of “unlimited users for a flat monthly fee” — for a team of 15–30 that is mathematically cheaper than Airtable Team.
Self-hosted Business/Enterprise — a paid licence for your own installation, priced per editor (not per reader). Brings SSO, audit, extended permissions and priority support.
The simple arithmetic worth keeping in mind: one VPS that can hold NocoDB with a 5–10 GB database costs less than ten cloud seats. That is exactly why self-hosting is the primary scenario for this product.
Hands-on: deploying NocoDB on a VPS
We deployed NocoDB twice: with Docker Compose and PostgreSQL on a VPS, and as “SQLite inside the container” for comparison.
Resource requirements
- Minimum: 2 vCPU, 2 GB RAM, 20 GB SSD — for a team of up to 10 and a database of hundreds of thousands of records.
- Comfortable: 4 vCPU, 4–8 GB RAM, NVMe — for 20–50 active users and millions of rows.
- PostgreSQL, not SQLite — if you have more than a couple of gigabytes of data or more than five users. SQLite is fine for a test, but write locks will bite.
A two-service Compose file (nocodb + postgres) comes up in five minutes. Only port 8080 needs to face the internet behind a reverse proxy with TLS — Nginx or Caddy, the latter being simpler for certificates.
Where to host it
Choose a host with local hardware and hardware you control. We ran the installation on Timeweb Cloud — it offers Docker-ready images and private networking, handy if you later move Postgres to its own machine. For a minimal budget FirstVDS worked well: simpler configurations, but honest KVM with no panel surcharge. The domain was registered at REG.RU, which also provides free DNS management.
What we tested by hand
Interface speed. A table with 60,000 rows and 25 columns opens in 1.5–2 seconds, filtering is instant, pagination works. At 500,000 rows the grid starts to lag noticeably: NocoDB pages the data, but sorting on an unindexed field forces a wait. Conclusion: indexes in the database still matter, and adding them is easier in SQL than through the UI.
CSV import. A 40 MB file with 200,000 rows uploaded in about a minute with correct type inference. Non-ASCII headers and data survived the import intact — important for localised projects.
Search. Full-text search works for non-English text at the database ILIKE level, which means no stemming. For serious search you will add pg_trgm or an external index.
Roles. We tested “operator sees only their own tickets”: in the open-source edition this is a view filter plus a separate account, not true row-level security. Real RLS is paid-only or done through views in the database itself.
Backups. There is no built-in backup scheduler. The working scheme is pg_dump on cron into object storage plus a separate backup of the attachments volume. Set this up first: restoring an interface without its database is pointless.
Upgrades. Replacing the image tag and running docker compose up -d is all it takes. Minor versions were painless; one major upgrade required a manual migration — read the release notes before jumping.
Attachments. Files are stored locally in a container volume or in S3-compatible storage. If the team uploads scanned contracts, S3 is mandatory, otherwise the volume backup grows uncontrollably.
What was missing
- A proper per-record audit log — not available in the free edition.
- Bulk formula editing through the UI.
- Clear slow-query diagnostics: you end up in the Postgres logs.
NocoDB versus the competition
Airtable. Airtable is still nicer in the details: interfaces, automations, mobile apps, ecosystem. But your data sits with the vendor and per-seat pricing for 20 people gets unpleasant. NocoDB wins on control and cost of ownership, Airtable wins on polish.
Baserow. The closest open-source competitor. Baserow bets on simplicity and its own data format (though it now supports external databases too). Baserow’s UI is nicer and faster; NocoDB goes deeper on connecting to existing SQL databases and on the API layer.
SeaTable. Strong on formulas and spreadsheet logic, closer to Excel. A German project with solid self-hosting, but a smaller community.
Teable. A young project with a modern interface and a performance focus; promising for very large tables, but its ecosystem and docs are still thinner.
Google Sheets. Free and familiar, but it gives you no roles, no relations and no API discipline. Once you have more than two editors and linked entities, it is time to move.
Verdict
NocoDB is the best choice in 2026 if you need an Airtable-like layer over your own SQL database and are willing to spend one evening on Docker, a domain and backups. For that work you get full control of your data, free usage for a team of any size and an API you can wire anything into.
Skip NocoDB if the whole team is non-technical and nobody will own the server; if you need Airtable-grade automations; if native mobile apps are critical; or if strict audit and row-level security are required without buying a licence.
Best fit: product and ops teams of 5–30, agencies, small SaaS projects already on Postgres, and anyone tired of paying per seat for cloud spreadsheets.
Rollout advice: start with the self-hosted version on a VPS with 4 GB RAM and PostgreSQL — enough for the first year. Treat NocoDB as a layer over the database, not the only place the data lives, set up pg_dump on day one and move attachments to S3. If the team is still active after a month, look at a paid licence for SSO and audit — not the other way round.
How are your internal tables organised today — still Google Sheets, or something like NocoDB already?