NocoDB: The Open-Source Airtable Alternative — Check the License Before You Build

"Airtable's bill tracks your headcount. Your database doesn't care how many people look at it."

Airtable is genuinely good software with a genuinely punishing pricing model. Team runs about $20 per seat per month annually, Business around $45, and both cap records — 50,000 per base on Team. Add a read-mostly stakeholder and the invoice grows. NocoDB (GitHub: nocodb/nocodb) is the open-source answer: as of September 2026 it carries roughly 64,000 stars, the most of any Airtable clone by a wide margin, and it does something the others find hard to match — it wraps a database you already have in an Airtable-style interface instead of forcing a migration.

But there's a caveat that most "best Airtable alternatives" lists still get wrong, and if you're going to build anything on this you need to know it: NocoDB changed licenses in January 2026. It is no longer OSI open source. More on that in section 3, and I'm not burying it because it's the kind of detail that matters.

1. What NocoDB Actually Does

Point NocoDB at a SQL database — PostgreSQL, MySQL, MariaDB, SQLite, or MSSQL — and it introspects the schema and renders it as a spreadsheet-style interface: grid, gallery, kanban, form, and calendar views, with sorting, filtering, grouping, relations, and lookups.

That "bring your own database" model is the architectural distinction. Most Airtable clones reinvent storage; NocoDB layers on top of yours. Practically, this means:

• No migration. Your data stays where it is, in tables other applications can also read and write.
• No second copy to keep in sync. There is exactly one source of truth.
• Non-technical colleagues get an Airtable-like editor over production data without learning SQL.
• You keep SQL. Everything remains queryable with ordinary tools, reporting systems, or a BI layer.

It also generates REST APIs automatically, supports webhooks, offers multiple view types per table, and provides user and role management. For internal tooling — an inventory tracker, a content calendar, a lightweight CRM, an ops dashboard — it hits the sweet spot between "spreadsheet everyone can use" and "database that doesn't corrupt itself."

If you don't have an existing database, NocoDB can create one for you, backing onto SQLite by default or Postgres if you point it there.

2. Why Teams Actually Leave Airtable

The arithmetic, stated plainly:

• Airtable Team: ~$20/seat/month billed annually, ~$24 monthly. 50,000 records per base.
• Airtable Business: ~$45/seat/month. 125,000 records. That's a 125% per-seat increase to escape the record cap.
• Five seats on Team: ~$1,200/year. Ten seats: ~$2,400. Twenty: ~$4,800.

Two structural problems compound this. First, everyone with edit permission is billable, so the finance person who opens a base twice a month costs the same as the ops lead living in it. Second, Airtable changed its seat-removal rule so that removing a billable collaborator doesn't reduce the invoice until renewal — the cost ratchets up but not down.

Self-hosting inverts the model: infrastructure cost stays roughly flat regardless of headcount. Adding a viewer costs nothing. Adding 100,000 records costs nothing. That's the entire pitch, and for growing teams it's compelling.

The trade-off is the standard one — you become the operator. Patching, backups, upgrades, and uptime are yours.

3. The License Change: What Happened in January 2026

This is the part most comparison articles haven't updated.

NocoDB was previously AGPL-3.0. On 8 January 2026, a commit titled "chore: change to sustainable use license" replaced it with the Sustainable Use License, and the license file was revised again on 29 January to clarify which branches it covers.

What the Sustainable Use License allows:

• Use and modification for your own internal business purposes.
• Non-commercial and personal use.
• Distribution only if free of charge and for non-commercial purposes.

What it restricts: you may not sell it, resell access to it, or offer it as part of a paid service. It's the same license family n8n uses, and GitHub's detection now reports the repository as NOASSERTION rather than a recognised open-source license.

What this means in practice:

• Running NocoDB for your own team's internal base — squarely permitted. For most readers, nothing changes.
• Embedding it in a product you sell — not permitted without a commercial agreement.
• Offering it to clients as a hosted service — not permitted.
• Organisations with a policy requiring OSI-approved licenses in production — NocoDB no longer clears that bar, and your legal team will flag it.

If you need a genuinely OSI-approved alternative in this category, look at Baserow (MIT for the open-source edition), Teable (AGPL-3.0), or Grist (Apache-2.0, and the cleanest license of the group).

None of this is a reason to avoid NocoDB for internal use. It is a reason to stop repeating "NocoDB is open source" without the qualification — because the January 2026 change made that phrase inaccurate.

4. Deployment Walkthrough

The minimal start is one command:

docker run -d --name noco -p 8080:8080 nocodb/nocodb:latest

That uses SQLite and is fine for evaluation. For anything real, use Compose with Postgres:

services:
  nocodb:
    image: nocodb/nocodb:2026.06.2
    container_name: nocodb
    restart: unless-stopped
    ports:
      - "8080:8080"
    environment:
      NC_DB: "pg://postgres:5432?u=noco&p=${DB_PASSWORD}&d=nocodb"
      NC_AUTH_JWT_SECRET: "${JWT_SECRET}"
      NC_PUBLIC_URL: "https://nocodb.example.com"
      NC_DISABLE_TELE: "true"
    volumes:
      - ./nc_data:/usr/app/data
    depends_on:
      postgres:
        condition: service_healthy

postgres:

    image: postgres:16-alpine

    restart: unless-stopped

    healthcheck:

      test: ["CMD-SHELL", "pg_isready -U noco -d nocodb"]

      interval: 10s

      retries: 5

    volumes:

      - ./pgdata:/var/lib/postgresql/data

    environment:

      POSTGRES_USER: noco

      POSTGRES_PASSWORD: ${DB_PASSWORD}

      POSTGRES_DB: nocodb

Details that matter:

• Pin the version. NocoDB releases frequently; :latest will surprise you mid-week.
• NC_DB is the connection for NocoDB's meta database — where it stores views, field formatting, permissions, and UI state. Your actual data lives in the database you connect, not here.
• NC_PUBLIC_URL must be exactly right or share links and OAuth flows break.
• NC_AUTH_JWT_SECRET — set it. Without it, sessions invalidate on restart.
• NC_DISABLE_TELE: "true" — disables telemetry.
• Use Postgres for the meta store with more than one user. SQLite is fine solo and a bottleneck beyond that.

Then reverse-proxy with TLS. NocoDB handling credentials over plain HTTP is not acceptable even on a LAN.

5. The Hidden Risk: You're Giving a UI Write Access to Real Data

This is the honest risk that deserves more attention than it gets.

NocoDB's killer feature — connecting to an existing database — is also its sharpest edge. When a non-technical colleague edits a cell in a grid view, they are issuing UPDATE statements against your actual tables. There is no staging layer, no review step, no dry run.

Mitigations that work:

• Point NocoDB at a read replica, not the primary. Non-technical editing flows to a replica; anything that must reach production goes through your normal application path.
• Create a dedicated database user with grants limited to the tables and operations you actually want exposed.
• Use view-level permissions to hide sensitive columns entirely rather than relying on people not to edit them.
• Back up before you connect. Test that the backup restores.
• Consider a separate schema for NocoDB-managed tables if the data is NocoDB-native anyway.

Treat connecting NocoDB to production data with the same caution you'd treat giving someone direct SQL access — because that is precisely what you're doing, just with a friendlier face on it.

6. The Honest Limitations

The license is source-available, not open source. Covered above; the most important caveat.

Write access to live data is a real risk. See above. This is a design trade-off, not a bug, but teams that skip the mitigations get burned.

Data-safety gaps exist relative to Airtable. Reports include limited granular recovery and weaker safeguards around accidental mass edits. Airtable's maturity in undo, revision history, and permission granularity is genuinely ahead.

The Docker story is messier than the one-liner suggests. There's no single canonical compose file at the repo root, and production deployments typically need Postgres plus Redis plus a proxy. Expect to assemble it yourself.

Performance degrades with very large tables and complex views. It's comfortable for tens of thousands of rows and gets sluggish with heavy relational views over millions.

Automations are less mature than Airtable's. If your workflow depends on sophisticated automation chains, test before migrating.

Upgrades occasionally break things. Pin versions, read release notes, keep backups.

It's a big TypeScript monorepo. Building from source requires pnpm and patience. Use the prebuilt images.

7. What It Costs

| Item | Cost |
|---|---|
| NocoDB license | $0 for internal business use |
| VPS (2 vCPU / 4 GB for a small team) | ~$20–30/month |
| Managed Postgres (or self-hosted) | ~$0–15/month |
| Backups | ~$2–5/month |
| Total | ~$22–50/month, flat |

Against Airtable at ten seats (~$2,400/year), self-hosting saves roughly $1,800–2,000/year — and the gap widens with every person you add.

The honest subtraction: your time. Budget a few hours a month for upgrades, backups, and the occasional fix. At some headcount and some hourly rate, the SaaS bill becomes the better deal. That's a legitimate conclusion, not a failure.

8. Where Your Data Lives

Self-hosted NocoDB:

• Your actual business data — in your Postgres/MySQL, in tables you control, queryable by you with SQL. This is the strongest data-ownership story in the category.
• Meta data (views, permissions, formatting) — in the NC_DB database, on your disk.
• Credentials — your environment variables or secrets store.
• File attachments — your configured storage volume.

What leaves by default: telemetry, unless you set NC_DISABLE_TELE=true.

Also note: if you connect external integrations or use NocoDB's AI features, those requests go to third parties. Audit what you enable.

The key advantage over Airtable isn't just privacy — it's portability. Your data is in Postgres. If NocoDB disappeared tomorrow, your data is still a Postgres database you can query, export, and point a different tool at. That is not true of Airtable bases.

9. NocoDB vs Baserow vs Teable vs Grist

| | NocoDB | Baserow | Teable | Grist |
|---|---|---|---|---|
| Stars | ~64.5k | ~5.6k (new repo) | ~21.7k | ~11.5k |
| License | Sustainable Use | MIT (OSS edition) | AGPL-3.0 | Apache-2.0 |
| OSI-approved | No | Partly | Yes | Yes |
| Storage | Your SQL DB | Its own Postgres | Postgres | SQLite per doc |
| Real-time collab | Limited | Yes | Yes | Yes |
| Best at | Existing databases | Friendly UI | Spreadsheet feel | Formulas/access rules |
| Resource use | Light | Heavy (Django+PG+Redis) | Moderate | Light |

The decision rule:

• Your data already lives in Postgres/MySQL → NocoDB. The ability to layer a UI over existing tables with no migration is unmatched.
• License purity matters → Grist (Apache-2.0, cleanest) or Teable (AGPL-3.0).
• Non-technical team, real-time collaboration → Baserow, with the caveat that SSO and advanced views sit in paid tiers.
• Spreadsheet-grade feel with formulas → Grist.

10. Who Should Not Self-Host NocoDB

• You need an OSI-approved license. Post-January 2026, NocoDB isn't it. Use Grist or Teable.
• You plan to resell or embed it. The license forbids it.
• You have no one to operate it. Unmaintained infrastructure fails quietly.
• You need Airtable-grade automations. Test first; you may be disappointed.
• You'd be pointing it at irreplaceable production data with no replica and no backups. Set those up first.

11. Getting Started

A safe sequence:

1. Decide what database it will sit on. Existing Postgres? New? Read replica? Decide before installing.
2. Deploy with Compose, pinned version, Postgres for the meta store, telemetry off.
3. Set NC_PUBLIC_URL correctly and put it behind TLS.
4. Create a dedicated database user with the narrowest grants that still work.
5. Connect one non-critical table first. Verify edits behave as expected.
6. Configure view-level permissions to hide sensitive columns.
7. Back up both the meta database and your data database, and do one restore test.
8. Invite one colleague and watch what they do. You'll learn where your permissions are too loose.

What Non-Technical Colleagues Actually Get

If you're deploying NocoDB for other people, it helps to know precisely what they'll experience.

Views. Each table can have multiple views with different filters, sorts, and visible columns, and different users can be shown different views. Someone in ops sees open orders; someone in finance sees invoiced ones. Same table, no duplication. This is the feature that makes NocoDB feel like a product rather than a database admin tool.

Forms. Any table can generate a public or internal form for data entry. This is genuinely useful — it's how you get people to submit structured data without giving them grid access. Form responses land directly in the table.

Kanban and calendar. Group records by a status field for a board view, or by a date field for a calendar. For project tracking and content planning, these are the views people actually want.

Relations and lookups. Link tables together — orders to customers, posts to authors — and pull fields across. This is where NocoDB stops being a spreadsheet and becomes a relational database with a friendly face.

What they won't get: real-time collaborative editing where you see someone else's cursor (Baserow and Teable are ahead here), sophisticated automation chains, or the polish of Airtable's Interface Designer. NocoDB's UI is good, occasionally rough at the edges, and improving steadily.

The realistic pitch to a team: "it's like Airtable, it's connected to the real database, and it costs us nothing per person." That framing lands well. Then spend an hour building the views they need — nobody discovers a good workflow from an empty grid.

Moving Off Airtable

The practical migration question, since that's usually why people arrive here.

What transfers cleanly: your data. Export each Airtable base to CSV, import into Postgres or let NocoDB create tables, and reconnect relations manually. Records, field values, and attachments come across.

What doesn't transfer: automations, Interface Designer layouts, formulas (they'll need rebuilding as NocoDB formula fields, and syntax differs), and any script or app built on Airtable's API.

A sane sequence:

1. Export everything to CSV before your Airtable billing renews. Keep the export archived.
2. Design the target schema deliberately. Airtable bases often have accumulated cruft; migrating is a good moment to clean up.
3. Load into Postgres, either directly or via NocoDB's import.
4. Rebuild relations and formula fields. Test with a subset.
5. Recreate views — grid, kanban, calendar — for each audience.
6. Run both in parallel for two weeks. Do not cancel Airtable on day one.
7. Migrate automations last, and accept that some will become external scripts or n8n workflows.

Expect roughly 90% of your data and 50–60% of your structure to survive automatically, with automations requiring genuine rework. That's normal for any platform migration, not specific to NocoDB.

Performance, Scaling, and When It Starts to Hurt

NocoDB is comfortable for the workloads most teams actually have and gets uncomfortable in predictable places.

Comfortable: tens of thousands of rows per table, a handful of concurrent editors, moderate relational complexity. This covers the overwhelming majority of internal bases — inventory, content calendars, CRM-lite, ops tracking.

Starts to hurt:

• Tables with millions of rows. Grid views paginate, but filters and sorts over unindexed columns become slow. The fix is usually at the database layer — add indexes on columns you filter by — which is exactly the advantage of sitting on real Postgres.
• Deeply nested relational views. Lookups across three or four linked tables generate complex queries. Each hop multiplies cost, and a view that felt instant at 5,000 rows can crawl at 500,000.
• Many concurrent editors. The meta database becomes a contention point. Postgres (rather than SQLite) for NC_DB is the single biggest mitigation, and Redis helps with caching in larger deployments.
• Large attachment volumes. Files stored through NocoDB accumulate in your data volume; plan storage and backups accordingly.

Practical mitigations: put indexes where your filters are, use Postgres for the meta store, keep views narrow (fewer columns, tighter filters), archive old rows out of hot tables, and monitor Postgres rather than NocoDB when diagnosing slowness — the bottleneck is almost always the query, not the UI.

The useful framing: because NocoDB sits on a real database, performance problems are diagnosable and fixable with ordinary DBA techniques. That's a genuine advantage over closed platforms where slowness is simply something you wait out.

12. Modelling Data Properly: Links, Lookups, and Rollups

Most people bring spreadsheet habits to NocoDB and end up with a spreadsheet wearing a database costume. The difference matters, because the tool's real power is in three field types that have no spreadsheet equivalent.

Link to Another Record. This is the one to understand first. Instead of typing a client's name into every row of a projects table, you create a link to the clients table. Now a project points at a client record. Rename the client once and every project reflects it. This is what makes a database a database, and teams that skip it end up with the same name spelled four ways across nine tables.

Lookup. Once a link exists, a lookup pulls a field from the linked record into your current view — show the client's email on the projects table without duplicating it. Read-only, always current, never stale. The mental model: links define the relationship, lookups display it.

Rollup. The one that replaces a category of spreadsheet pain. A rollup aggregates across linked records: total value of all invoices for a client, count of open tasks, latest activity date. No formulas to maintain, no drift, no "did anyone update the summary tab." Set it once and it is correct forever.

Formula fields exist too and are useful, but they are the escape hatch rather than the foundation. If a number can be expressed as a rollup over links, prefer the rollup — it is computed by the database rather than recalculated per row in application code, and it stays correct when someone edits a linked record directly.

The failure mode to watch for is using select fields instead of links. A dropdown of client names feels simpler and is wrong for anything you will ever want to aggregate, rename, or attach metadata to. It is fine for genuine enumerations — status, priority, region — and a trap for anything that is really an entity. If you find yourself editing the dropdown options more than once a quarter, it should have been a link.

One more that saves real pain: name your tables and fields as if a stranger will read them. Six months from now, when you are writing an automation against this schema, client_primary_contact_email beats Email 2. NocoDB exposes your schema through its API verbatim, so field names become API field names, and renaming later means updating everything that references them.

13. Views, Forms, and the Public Sharing Trap

NocoDB's views are where a database becomes something a team will actually use, and they are also where data leaks happen.

Grid is the default spreadsheet view. Gallery works well for anything with images. Kanban turns any single-select field into a board, which is usually the first thing a non-technical colleague asks for. Calendar needs a date field and is genuinely useful for content planning and deadlines. Form is the interesting one: it renders a table as a public or internal submission form.

That form view is the highest-value feature and the highest-risk one, so it deserves specifics.

A public form lets someone without an account create a record. That is exactly right for intake — bug reports, applications, contact submissions — and it is also a write endpoint on your database exposed to the internet. Before you share one:

• Put a password on it unless the form is genuinely meant for the public. NocoDB supports password-protected shared views; use it.
• Decide which fields are exposed. A shared view should not include your internal notes column, your cost field, or anything you would not want a stranger reading in the browser's network tab.
• Understand it is a write, not just a read. Someone can submit arbitrary values into every exposed field. If that record later feeds an automation, you have let an anonymous person trigger it.
• Add a hidden flag field for anything ingested this way — a "source" or "unreviewed" marker — so submissions are distinguishable from records your team created.

The same caution applies to shared views generally, including read-only ones. A shared view is a URL that grants access outside your user management; it does not appear in your permission matrix in an obvious way, and it survives employees leaving. Audit them periodically.

On the positive side, forms are the fastest way to make a database feel approachable. A colleague who would never open a table will happily fill in a form, and the record lands in the same schema you then roll up and report on. That combination — friendly input, structured storage — is what NocoDB does better than most competitors.

14. Automation, Webhooks, and the API

NocoDB is not an automation platform, and it is worth being clear about that before you design a workflow around it.

What it has: webhooks that fire on record create, update, and delete, with a payload containing the row. That is enough to connect to anything — send it to n8n, to a serverless function, to a Slack incoming webhook, to your own script — and it is the correct way to build around NocoDB rather than hoping for built-in steps.

What it does not have: a visual workflow builder comparable to what you get in Airtable's automations or in a dedicated tool. No conditional branching, no scheduled triggers, no retry semantics, no run history you can debug. If your requirement is "when a status changes to Approved, create three related records and notify two people," NocoDB will fire the webhook and the rest is your problem — which is fine if you already run an automation layer, and frustrating if you expected it to be included.

This is not a criticism so much as a boundary. NocoDB's job is to be a good interface and API over your data. Pairing it with n8n for orchestration is a genuinely strong combination, and it keeps each tool doing what it is good at.

The API itself is the real product for technical users. Every base exposes a REST API with token authentication, and it reflects your schema directly — which is why the field-naming advice from earlier matters. You can treat NocoDB as a quick way to stand up a CRUD backend with a usable admin UI, and have your application talk to the API rather than to the database. That is a legitimate architecture for internal tooling, and dramatically faster than writing an admin panel.

Two caveats if you go down that path: the API is row-oriented, so complex queries with joins are better done against the underlying Postgres directly; and you have now made NocoDB a dependency in your application's request path, which means its availability is your availability. For internal tools that is an acceptable trade. For customer-facing systems, think harder.

15. Access Control: Who Can See and Change What

NocoDB's permission model is simple enough to explain in a paragraph and has enough sharp edges to be worth a section.

Roles run roughly from Super Admin down through Creator and Editor to Commenter and Viewer, applied per base and, in newer versions, with table-level granularity. For a small team this maps cleanly onto reality: most people are Editors on the tables they own and Viewers everywhere else.

The part that surprises people:

Database credentials are shared at the connection level. When NocoDB connects to your Postgres, it connects as one database user with broad rights. Row-level restrictions inside NocoDB are application-layer, not database-enforced. Anything that reaches the database by another route — a BI tool, a script, a backup restore into a different NocoDB instance — sees everything. If you need true enforcement, do it in Postgres with row-level security and accept that NocoDB's own permissions become a convenience rather than a boundary.

Public and shared views bypass your user list. Covered above, repeated here because it is the most common real-world leak: a well-designed permission matrix plus one forgotten shared view equals full read access to whoever has the URL.

Field-level sensitivity is not a first-class concept. You can hide a field from a view, but hiding is not securing — the data is still in the API response for anyone with table access. If you have genuinely sensitive columns, keep them in a separate table with its own permissions, or in a database NocoDB does not touch.

Audit trails are limited. If you need to know who changed a specific cell and when, NocoDB's history is not a compliance-grade audit log. For regulated environments, this alone can be disqualifying.

For a five-person team working on operational data, none of this is a problem, and NocoDB is more than adequate. For a company putting customer records in front of thirty people with varying trust levels, these are the questions that should be answered before the migration, not after.

16. When to Stop Using NocoDB and Just Use Postgres

This sounds like an argument against the tool, and it is actually the strongest argument for it — but only if you understand it.

NocoDB's least-discussed capability is that it can sit on top of a database you already have. Point it at an existing Postgres instance and it becomes a friendly interface over tables you already own, with no migration, no lock-in, and no data duplication. Your application keeps talking to Postgres; your operations team gets a grid view, filters, and forms over the same data.

That property means the decision is not "NocoDB or Postgres." It is "does this table benefit from having humans click at it?"

Tables that do: anything operations people maintain by hand — content calendars, inventory, vendor lists, applicant pipelines, internal request queues. These are exactly the tables where a spreadsheet is the natural interface and a database is the correct storage, and NocoDB is the bridge.

Tables that do not: high-volume event data, anything written thousands of times per minute, anything requiring complex transactional logic, anything where a schema change needs a reviewed migration. Point NocoDB at a fifty-million-row table and you will have a bad day — the UI is designed for a few hundred thousand rows, and no amount of hardware changes that.

Which gives a clean rule: use NocoDB as a human interface layer over a real database, not as the database. Connect it to Postgres, let it handle the tables humans maintain, and keep your application's hot path on queries you wrote yourself. When a base outgrows NocoDB, you drop the interface and keep the database — which is a far better failure mode than discovering your data is trapped in a proprietary format.

The corollary is a warning about the hosted version: if your data lives in NocoDB Cloud rather than your own Postgres, that escape hatch does not exist in the same form. Self-hosting against your own database is what makes the exit cheap.

17. Troubleshooting and Operational Realities

Changes made directly in Postgres do not always show up immediately. NocoDB caches schema and some query results. If you add a column in psql and NocoDB does not see it, reload the base rather than assuming the connection is broken.

"Hot" tables with large attachments will bloat your database. Attachments are stored as data, and a base of records with images grows fast. If you expect heavy attachment use, plan storage accordingly and think about whether files should live in object storage with only references in NocoDB.

Upgrades occasionally require a schema migration. NocoDB stores its own metadata tables alongside yours. Take a database snapshot before upgrading — it costs seconds and it is the difference between a minor inconvenience and a very bad afternoon.

Performance complaints are usually a missing index. NocoDB generates queries against your database; if a filter over 200,000 rows is slow, the fix is in Postgres, not in NocoDB. Look at the generated query, add the index, and the problem disappears.

Heavy concurrency reveals the single-database-connection design. Many simultaneous editors on the same base will contend. For ten people this is invisible; for a hundred it is not. This is the point at which you are running a real internal application and should be provisioning accordingly.

Backups are your job. Self-hosted means nobody is doing it for you. If NocoDB points at your own Postgres, you are already backing that up — which is another quiet argument for that deployment shape. Remember to include NocoDB's own metadata tables, not just your data tables.

18. The Verdict

NocoDB is the most popular open-source Airtable alternative for good reason. The bring-your-own-database model is genuinely the right architecture: no migration, no second copy, no lock-in, and your data stays in Postgres where you can always reach it. For internal teams with data already in SQL, it's the obvious first choice, and the cost saving at even modest headcount is substantial.

The caveats are two, and both are serious. First, the license changed in January 2026 — source-available, not OSI open source, and unsuitable for resale or embedding. Second, giving a friendly grid UI write access to real tables is a genuine risk that requires deliberate mitigation: a replica, a restricted database user, and real backups.

If your use case is "our team needs an Airtable-like interface over data we already own," NocoDB is excellent and will save you real money. Just go in knowing exactly what you agreed to when you pulled the image — and if license purity is a hard requirement, Grist and Teable are waiting.

Related

• Supabase: The Open-Source Firebase Alternative That Gives You a Real Postgres — the developer-facing counterpart; NocoDB can even sit on top of it.
• Meilisearch: The Open-Source Search Engine That Makes Your App Feel Instant — add fast search once your NocoDB tables outgrow filters.
• Grafana: The Self-Hosted Observability Layer That Turns Your Metrics Into Answers — visualise the same Postgres data you've just exposed through NocoDB.