Developer tools#Extraction#Deployment
NocoDB: turn PostgreSQL, MySQL or SQLite into a spreadsheet interface
NocoDB puts grid, kanban, form and calendar views plus a REST API on top of an existing database. One Docker command to start; no data migration required.
Project facts
GitHub Ecosystem- Language
- TypeScript
- Stars
- 65,281
- Data checked
- 2026-10-15
Snapshot figures reflect the check date and may change over time.
Turning an internal data table into something the business team can use tends to split into two bad options: get engineering time to build an admin console, or move the data into Airtable — the first needs a sprint, the second moves your data into someone else’s cloud. NocoDB (TypeScript, about 65.3k stars as of 2026-10-15) leaves the database alone and wraps it in an online spreadsheet instead: grid, kanban, form and calendar views plus a REST API, all out of the box.
Core features
- Your database stays: connect an existing PostgreSQL, MySQL or SQLite database; the Docker deployment stores its own metadata in SQLite by default and takes
NC_DBwhen it should sit on a production PostgreSQL. - Four views: grid (default), kanban, form and calendar, plus collaborative and locked view permissions — the form view goes straight to the person filling in data, no account or filter tutorial needed.
- Column types that match spreadsheet habits: ID, links, lookup, rollup, single-line text, attachment, currency, formula, and so on; sort, filter, group and hide all survive the move.
- Layered permissions: from field to view, with the option to share a Base or a view publicly behind a password.
- App Store for automation: chat (Slack, Discord, Mattermost), email (AWS SES, SMTP, MailerSend) and storage (S3, GCS, Minio) connectors.
- Programmatic access: REST APIs and an SDK, authorized with a JWT or social-auth token.
Typical use cases
- A developer taking a small business’s “get us off Excel” contract: a form-backed ledger view in a day beats writing a backend from scratch by an order of magnitude.
- A team with a database and no interface: leave the schema to SQL, let operations work in the view.
- An indie developer building a light CRM: one table each for customers, follow-ups and orders, forms to collect, kanban to track.
Quick start
docker run -d \
--name noco \
-v "$(pwd)"/nocodb:/usr/app/data/ \
-p 8080:8080 \
nocodb/nocodb:latest
Open http://localhost:8080, create an account, and connect an existing database — the table views generate from the schema. For an external PostgreSQL, pass -e NC_DB="pg://host:5432?u=user&p=password&d=database"; production installs also have an auto-upstall command that generates the docker-compose for you.
Three things worth doing right after a Base exists: switch any table people fill in to the form view and share its public link; give read-only colleagues a collaborative view instead of an account; and use the Link and Lookup column types to relate a customers table to an orders table. That last step is the one Excel migrations forget — in the database it is a foreign key, while in the spreadsheet it was copy-paste. To pull data over the REST API, generate a token in settings and send it as the xc-token header.
Summary
For teams whose data already lives in a database and whose interface is the missing piece, and for developers picking up small-business digitization work. It is not the tool for deeply custom interactions — NocoDB offers the spreadsheet abstraction, and anything beyond it still needs a front-end. One fact to check yourself: gh api reports the license as NOASSERTION and the repo carries no standard SPDX identifier, so read the LICENSE file before adopting. As of 2026-10-15 the repo sits at 65,281 stars in TypeScript with pushes landing the same day, so development is active.
For a more purist self-hosted Airtable, Baserow (about 6.2k stars as of the same date, also NOASSERTION) is the closest comparison; if what you want is a database plus automation hub rather than a table UI, Activepieces is a different shape of tool. And when the goal is a full CRM rather than a spreadsheet layer, Twenty attacks the same problem from the other end — one gives you the table, the other gives you the product.