Rowy and NocoDB are routinely mentioned in the same breath: both grew out of the idea of “Airtable, but open source and without record limits”. In practice they are two different tools with different architectures — and very different trajectories. NocoDB is a layer on top of a relational database that turns tables into a usable interface. Rowy is a low-code layer on top of Firebase/Firestore, aimed at product teams that need a backend without a backend developer.
We compared both on licences, supported databases, self-hosting scenarios, APIs, automation, pricing and — often the most important criterion — development activity. Spoiler: in 2026 that last one can be decisive.
Sites: rowy.io | nocodb.com
The short version
What Rowy and NocoDB share:
- open source code and the option to self-host;
- a spreadsheet-style grid with typed columns;
- roles and permissions, team invitations;
- REST APIs and webhooks for integrations;
- a free cloud tier plus paid per-seat plans.
The difference is the foundation. NocoDB acts as a frontend to a database: you either create a base inside NocoDB or connect an existing MySQL, PostgreSQL, SQLite or SQL Server instance and get a friendly interface on top. Your data stays in your database, and NocoDB is the presentation and collaboration layer.
Rowy works differently: it is a data editor and cloud function environment tied to Firestore (Google Cloud/Firebase NoSQL). It offers computed columns, action fields, serverless JavaScript/TypeScript functions and an instant API. In essence it is a low-code backend for an application, not a tool for working with a corporate SQL database.
The conclusion follows: if you already run PostgreSQL or MySQL, the “Rowy or NocoDB” question answers itself in favour of NocoDB. If you are building a Firebase product and want an admin panel without code, Rowy is closer in spirit — but it comes with a risk we cover below.
Comparison table
| Parameter | NocoDB | Rowy |
|---|---|---|
| Licence | Sustainable Use License (free internal and personal use, reselling as a service prohibited) | Apache License 2.0 |
| Data storage | Native NocoDB database or external MySQL, PostgreSQL, SQLite, SQL Server | Firebase / Firestore (NoSQL, Google Cloud) |
| Stack | TypeScript, Node.js | TypeScript, React, Node.js |
| Self-hosted | Yes: Docker, npm, Kubernetes manifests | Yes, but requires a Firebase and GCP project |
| Primary purpose | Interface for relational data, an Airtable/Google Sheets replacement for teams | Low-code backend and CMS for a Firebase product |
| Views | Grid, Gallery, Form, Kanban, Calendar plus interfaces (dashboards, pages) | Grid with advanced column types, forms on higher tiers |
| Column types | Text, number, date, links between tables, formulas, attachments, select | 30+ types, including derivative and action fields |
| API | REST and GraphQL (v2 and v3), auto-generated | Automatic REST API over Firestore |
| Automation | Automations (record triggers and schedules), webhooks | Cloud Functions (JS/TS), action fields, webhooks, scheduled jobs |
| External SQL databases | Yes (Business tier and above in cloud; unlimited when self-hosted) | No |
| Free cloud tier | 3 users, 1,000 records, 1 GB | 1 project, unlimited records |
| Paid tier | Plus $12/seat/month (annual), Business $24, Scale $45 | Pro $12/seat/month |
| GitHub | 65,300+ stars, active commits (latest October 2026) | 6,800+ stars, repository moved to buildship-ai/rowy, last commit November 2024 |
| Abandonment risk | Low | High |
NocoDB in detail
NocoDB started as “open-source Airtable” and grew into a platform for building internal tools: CRMs, ticket tracking, catalogues, inventory, dashboards. Its headline feature is working on top of an existing SQL database. Connect MySQL or PostgreSQL, NocoDB reads the schema and generates the interface: tables, forms, links, views. No data migration required — a major advantage over Airtable and similar SaaS products.
Features people actually use
Views and interfaces. Beyond the grid there is Gallery (cards with cover images), Form (a public form that writes straight into a table), Kanban (by status field) and Calendar. Separately, “interfaces” are a page builder where dashboards are assembled for managers: charts, lists, buttons. The free tier includes one interface with up to three pages; paid tiers lift the limit.
Relations. Link-to-record, lookup, rollup and formulas behave like Airtable but on top of a proper relational schema. For SQL veterans this is the compromise: a convenient UI, while the data model stays predictable and portable.
API. NocoDB auto-generates REST and GraphQL APIs for every table, so a frontend or mobile app can connect to the same data the team edits in the grid. Both v2 and v3 APIs exist, and v2 is being phased out — new integrations should target v3.
Automation. Triggers on record creation or update, scheduled actions, webhook delivery, email and messenger integrations. The free tier allows 100 automation runs per month, Plus 30,000, Business 120,000, Scale 240,000. That quota matters: per-record automations burn through it quickly.
Access control. Roles at base and table level, email invitations, commenters separate from editors. Business adds private bases and SAML SSO; Scale adds row-level security and audit logs. For compliance-sensitive companies this is essential, and the Airtable equivalents cost considerably more.
Self-hosting
NocoDB deploys with a single Docker command, ships ARM images (handy for Raspberry Pi and cheap VPS instances), supports npm and Kubernetes manifests. A VPS with 2 GB of RAM is enough for a small team. Cloud record limits and external connection caps do not apply to self-hosted installs — you only pay for infrastructure. That is why NocoDB is popular with teams moving data out of foreign SaaS.
For companies in Russia this is an extra bonus: the server can come from a local provider and the data stays in the same jurisdiction. Hardware requirements are modest, so even a budget VPS will do — we usually look at FirstVDS and Timeweb, where a container is up in minutes.
NocoDB pricing
- Free — $0: up to 3 users (3 editors, 10 commenters), 1,000 records, 1 GB storage, 100 automation runs, 1,000 API calls/month, one interface up to three pages.
- Plus — $12/seat/month billed annually, in practice $108/month for unlimited seats once you pass 9 users: 50,000 records, 20 GB, 30,000 automation runs, 100,000 API calls, unlimited extensions and interfaces. External database connections are not available on Plus.
- Business — $24/seat, $216/month for unlimited seats: 300,000 records, 100 GB, 120,000 automation runs, 1M API calls, 10 external database connections, private bases, SAML SSO.
- Scale — $45/seat, minimum 3 seats: 1M records, 150 GB, 240,000 automation runs, 5M API calls, row-level security and audit logs.
- Enterprise — on request: SCIM provisioning, IdP group sync, dedicated account manager.
Note the “pay for 9 seats, the rest are free” logic: for a 20-person team NocoDB Business costs less than most per-user competitors.
NocoDB drawbacks
- The interface is dense; newcomers spend the first days hunting for settings.
- Performance on very large tables (millions of rows) depends on the external database — NocoDB is not an analytical warehouse.
- Several advanced features (external connections, SSO, row-level security) are locked behind expensive tiers.
- Automations are less flexible than a full workflow engine; complex logic still belongs in code.
- The Sustainable Use License is not classic open source: internal use is free, but you cannot build a public commercial service on NocoDB.
Rowy in detail
Rowy was designed as a backyard for Firebase: a table view of Firestore collections plus the ability to write server functions right in the browser. For a Firebase product team this is genuinely convenient — admin panel, CMS and API appear without a dedicated backend developer.
Features
Firestore integration. Rowy connects to a Firebase project and renders collections as tables. Edits in the UI land in the database and vice versa. It is two-way sync, not import/export.
Column types. More than thirty: text, numbers, dates, arrays, geolocation, files, references to other collections, plus derivative fields (values computed from other columns) and action fields (buttons that run a cloud function).
Cloud Functions. Write JavaScript/TypeScript functions from the interface, triggered by record changes or by a button in a row. This is Rowy’s strongest scenario: for example, email on new order, discount calculation, calling an external API.
Import and export. CSV, TSV, JSON and Airtable — one-off import and continuous Airtable sync on higher tiers. Free-tier export is capped at 10,000 rows; Pro is unlimited.
Search and filtering. Full-text search and advanced filters are Pro features.
Rowy pricing
- Base — $0: one project, unlimited tables and records, unlimited cloud functions and team members, data import/export, 30+ column types, row-level audit.
- Pro — $12/seat/month (10% off annually): unlimited projects, full-text search, exports above 10,000 rows, advanced filtering, code cloning between projects, GCP spending cap, email support.
- Business — on request: custom domain, priority support, data version control, field-level audit, automated backups, forms.
The pricing looks attractive, especially the unlimited-record free tier. But there is a catch: the free tier relies on your own Firebase project, so Firestore and Cloud Functions bills still arrive separately at Google Cloud rates.
The main risk: development has stalled
This is the point that outweighs the technical merits. The Rowy repository moved from rowyio/rowy to buildship-ai/rowy, and the last commit is dated November 2024. For a project positioned as an actively developed open-source tool, that is nearly two years of silence. The company appears to have shifted focus to BuildShip, a visual backend workflow builder.
What that means in practice:
- no new features or security patches;
- nobody guarantees compatibility with Firebase/GCP changes;
- the Discord community is going quiet and complex questions go unanswered;
- if Rowy is part of a production process, you are effectively maintaining a fork.
For an internal tool that works and needs no changes, this is tolerable. For a new project in 2026, it is a serious argument against.
Other Rowy drawbacks
- Hard coupling to Firestore: migrating to SQL means rewriting the data model.
- Total cost is the subscription plus GCP spend — on an active project the second can exceed the first.
- No support for external relational databases (unlike NocoDB).
- Self-hosting means wrangling a Firebase project and service accounts; without DevOps this is a barrier.
Test scenarios: choosing for your task
We ran both tools through the typical tasks readers bring to us.
Scenario 1: replacing Airtable in a sales team
You need a deals table, website lead forms, a status kanban and roles for reps and managers. NocoDB covers all of it on Plus, with data living in your own PostgreSQL. Rowy can do it too, but you must move data into Firestore — changing storage for the sake of an interface. Winner: NocoDB.
Scenario 2: an interface on top of an existing database
You have MySQL with e-commerce data and want support staff to browse it without an SQL client. NocoDB connects read-write and shows the tables immediately. Rowy cannot do this at all. Winner: NocoDB, no contest.
Scenario 3: an admin panel for a Firebase mobile app
The app already lives on Firebase with data in Firestore, and you need a content manager panel plus a couple of server functions. Rowy is up in an evening: connect the project, pick collections, write a function. NocoDB would need an intermediate layer and synchronisation. Winner: Rowy — if the project is not meant to grow for years.
Scenario 4: ten people, strict data residency requirements
Data must sit on your own server, you need an audit trail and per-row access control. Self-hosted NocoDB solves it for the price of a VPS; in the cloud the equivalent lives on Scale at $45/seat. Rowy requires GCP with foreign billing. Winner: NocoDB.
Scenario 5: a weekend backend prototype
Form, database, API, a couple of automations. Both fit; Rowy starts a little faster on Firebase, NocoDB is a little more predictable to maintain. The choice depends on what you already run.
Cost on real teams
| Team | NocoDB | Rowy |
|---|---|---|
| 3 people, up to 1,000 records | Free — $0 | Base — $0 + GCP costs |
| 10 people, up to 50,000 records | Plus — $108/month (annual) | Pro — $120/month |
| 20 people, up to 300,000 records | Business — $216/month (annual) | Pro — $240/month + GCP |
| 50 people, SSO required | Business — $216/month | Business — on request |
| Own infrastructure | Self-hosted, server cost only | Self-hosted + Firebase |
On paper the tiers are similar — $12 per seat for both. But past nine paid seats NocoDB stops charging as the team grows, while Rowy’s bill scales linearly and Google Cloud costs pile on top. At 20–30 people the gap is noticeable.
Who should pick what
Choose NocoDB if:
- you have or plan a relational database (PostgreSQL, MySQL, SQLite, SQL Server);
- you need self-hosting with data on your own server;
- predictability matters: active development, frequent releases, a live community;
- you build internal tools: CRM, inventory, accounting, table-based knowledge bases;
- you want forms, kanban, calendar and dashboards in one place.
Choose Rowy if:
- your product already runs on Firebase/Firestore;
- you need an admin panel with JavaScript/TypeScript cloud functions and no separate backend;
- the project is internal and does not require long-term development;
- you are ready to maintain a fork yourself if changes are needed.
Choose neither if you need analytics over tens of millions of rows (that is ClickHouse and BI territory) or a full workflow engine with branching and complex orchestration (look at n8n and similar tools).
Verdict
In 2026, NocoDB is the safer bet. It is actively developed, supports external SQL databases, offers predictable pricing and does not lock you to a single cloud provider. For the typical task — “give my data a decent interface and let the team use it” — it covers 90% of needs.
Rowy remains an interesting tool with an elegant idea: a table as an interface to Firestore plus server functions in the browser. If you are already in the Firebase ecosystem and need an admin panel this week, Rowy will deliver. But betting a new multi-year project on it is risky: almost two years without commits is a signal you cannot ignore.
Our recommendation: start with NocoDB and treat Rowy as a tactical fix for a specific Firebase task, with a plan B in case support stops entirely.
Which side are you on — already using one of these tools, or still choosing? Tell us what you are trying to build; reader experience usually makes it obvious where a tool hits its limits.