NocoDB

What is NocoDB?

NocoDB converts MySQL, PostgreSQL, SQLite and other databases into a smart spreadsheet interface. Non-technical teammates can edit structured data through a familiar grid view while the data stays in a real database you control.

Best for

Teams that want Airtable-style views over their own database

Why choose NocoDB

NocoDB takes an existing database and gives it a spreadsheet face. That is a deceptively practical idea: your data stays in Postgres or MySQL where it belongs, accessible to your applications and safe from the tool's own opinions, while your colleagues get the grid, kanban, gallery and form views they already know how to use. It is Airtable's usability without Airtable's lock-in, and it means a small team can get a usable internal database without hiring anyone.

Replaces

• Airtable
• Notion database
• Google Sheets

Key features

• Grid, gallery, kanban and form views
• Works with existing SQL databases
• REST APIs and webhooks
• Collaboration and permissions

What to watch out for

Spreadsheet interfaces encourage spreadsheet-shaped data, and that is the risk: it is easy for people to start maintaining a table that really should have been a proper schema. Views and formulas are capable but not as deep as a dedicated database admin tool, and some advanced operations still mean writing SQL elsewhere. The interface can also feel slow on large tables, since it is rendering a web grid over a live database — tens of thousands of rows scattered across wide tables are not its happy place.

How to deploy

• Docker
• Binary
• npm

Getting started

Connect it to an existing database rather than letting it create one, so your schema stays where you can see it. Create a dedicated database user with the permissions the tool actually needs rather than reusing an admin account. Set up shared views with restricted fields for anyone outside the core team, since the default grid shows everything. Take a look at the webhook and API features early — they are how you get data back out, which is the part spreadsheet tools usually make painful.

Typical setup

In most deployments it sits on top of a database that already existed, on the same network or the same host, with a dedicated restricted user. Teams use it to give colleagues a friendly interface to operational tables while applications keep talking to the database directly. Shared views with hidden fields are common for anyone outside the core group, and webhooks or the REST API are how the data flows back out into whatever else needs it.

Who should look elsewhere

Not a replacement for proper database design. A spreadsheet interface on top of SQL makes it easy for people to maintain data that should really have a normalised schema, and that debt arrives later. Anyone needing strong transactional guarantees for a high-write application should keep the application talking to the database directly and use this only for human-facing views.

Project health

• GitHub stars: 65,135
• Last code push: 2026-10-01
• Open issues: 716
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.