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
Repositorygithub.com/nocodb/nocodb
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_DB when 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.