Rowy 和 NocoDB 经常被放在一起讨论：两者都源自同一个想法——「开源版的 Airtable，而且不限制记录条数」。但在实际使用中，它们是两个架构完全不同的工具，命运也截然不同。NocoDB 是架在关系型数据库之上的一层界面，把数据表变成好用的操作面板。Rowy 则是构建在 Firebase/Firestore 之上的低代码层，面向需要后端但没有后端开发人员的产品团队。
我们从许可证、支持的数据库、自托管场景、API、自动化、价格，以及往往最重要的「开发活跃度」这几个维度做了对比。剧透一句：在 2026 年，最后这一项可能具有决定性意义。
官网：rowy.io | nocodb.com
简要结论
两者的共同点：
- 开源代码，支持自行部署；
- 类电子表格的表格界面，支持字段类型；
- 角色与权限管理、团队成员邀请；
- 提供 REST API 与 Webhook 用于集成；
- 云端有免费套餐，付费按席位计费。
区别在于底层基础。NocoDB 相当于数据库的前端：你可以直接在 NocoDB 里建库，也可以连接已有的 MySQL、PostgreSQL、SQLite 或 SQL Server，然后在这之上获得友好的操作界面。数据始终留在你的数据库里，NocoDB 只负责呈现与协作。
Rowy 的逻辑不同：它是绑定 Firestore（Google Cloud/Firebase 的 NoSQL）的数据编辑器和云函数环境。它提供计算字段、Action 字段、JavaScript/TypeScript 无服务器函数以及开箱即用的 API。本质上，它是应用的低代码后端，而不是用来操作企业 SQL 数据库的工具。
结论因此很清楚：如果你已经有 PostgreSQL 或 MySQL，「Rowy 还是 NocoDB」几乎自动倒向 NocoDB。如果你在 Firebase 上做产品、想要一个无代码后台，Rowy 更贴近需求——但有一个风险，下面会详细说。
对比表
| 项目 | NocoDB | Rowy |
|---|---|---|
| 许可证 | Sustainable Use License（内部与个人使用免费，禁止作为服务转售） | Apache License 2.0 |
| 数据存储 | NocoDB 自带数据库，或外部 MySQL、PostgreSQL、SQLite、SQL Server | Firebase / Firestore（NoSQL，Google Cloud） |
| 技术栈 | TypeScript、Node.js | TypeScript、React、Node.js |
| 自托管 | 支持：Docker、npm、Kubernetes 清单 | 支持，但需要 Firebase 与 GCP 项目 |
| 主要用途 | 关系型数据的操作界面，团队版 Airtable/Google Sheets 替代品 | Firebase 产品的低代码后端与 CMS |
| 视图 | Grid、Gallery、Form、Kanban、日历，以及界面（仪表盘、页面） | 高级字段类型的 Grid，表单需更高套餐 |
| 字段类型 | 文本、数字、日期、表间关联、公式、附件、单选 | 30 多种，含衍生字段与 Action 字段 |
| API | REST 与 GraphQL（v2 和 v3），自动生成 | 基于 Firestore 的自动 REST API |
| 自动化 | Automations（记录触发与定时）、Webhook | Cloud Functions（JS/TS）、Action 字段、Webhook、定时任务 |
| 外部 SQL 数据库 | 支持（云端 Business 及以上；自托管无限制） | 不支持 |
| 云端免费额度 | 3 位用户、1,000 条记录、1 GB | 1 个项目、记录数不限 |
| 付费套餐 | Plus 12 美元/席位/月（年付）、Business 24、Scale 45 | Pro 12 美元/席位/月 |
| GitHub | 65,300+ 星，持续提交（最近一次 2026 年 10 月） | 6,800+ 星，仓库已迁至 buildship-ai/rowy，最后提交 2024 年 11 月 |
| 停更风险 | 低 | 高 |
NocoDB 详解
NocoDB 起步时是「开源版 Airtable」，几年间成长为构建内部工具的平台：CRM、工单管理、商品目录、库存、仪表盘。它的核心能力是架在现有 SQL 数据库之上。连接 MySQL 或 PostgreSQL，NocoDB 读取表结构并生成界面：表格、表单、关联、视图。数据无需迁移——相比 Airtable 一类的 SaaS，这是巨大优势。
真正会被用到的功能
视图与界面。 除了表格，还有 Gallery（带封面的卡片）、Form（公开表单，数据直接写入某张表）、Kanban（按状态字段）和日历。另外「界面」是一个页面构建器，可以为管理层拼装仪表盘：图表、列表、按钮。免费版包含一个最多三页的界面，付费版不限制。
表间关联。 Link-to-record、lookup、rollup 和公式的体验接近 Airtable，但建立在规范的关系模型上。对熟悉 SQL 的人来说这是一种折中：界面舒服，同时数据模型保持可预测、可迁移。
API。 NocoDB 为每张表自动生成 REST 与 GraphQL API，前端或移动端应用可以直接访问团队在表格里编辑的同一份数据。v2 和 v3 并存，v2 正在退役，新集成应直接使用 v3。
自动化。 支持记录创建/修改触发、定时动作、Webhook 投递，以及邮件和即时通讯集成。免费版每月 100 次自动化执行，Plus 30,000 次，Business 120,000 次，Scale 240,000 次。这个配额很关键：按记录触发的自动化消耗得很快。
权限控制。 库级与表级角色、邮件邀请、评论者与编辑者分离。Business 增加私有库和 SAML 单点登录，Scale 增加行级安全和审计日志。对有合规要求的公司来说这是刚需，而 Airtable 的同类功能要贵得多。
自托管
NocoDB 用一条 Docker 命令即可部署，提供 ARM 镜像（适合树莓派和低价 VPS）、npm 方案和 Kubernetes 清单。小团队用 2 GB 内存的 VPS 就够。云端的记录数与外部连接限制在自托管版中不适用——你只需为基础设施付费。这也是它在希望把数据迁出境外 SaaS 的团队中受欢迎的原因。
对俄罗斯企业来说这是额外好处：服务器可以选本地服务商，数据不出司法辖区。硬件要求不高，便宜的 VPS 就够——我们通常看 FirstVDS 和 Timeweb，几分钟就能起一个容器。
NocoDB 价格
- Free — 0 美元：最多 3 位用户（3 位编辑者、10 位评论者）、1,000 条记录、1 GB 存储、100 次自动化、每月 1,000 次 API 调用、一个最多三页的界面。
- Plus — 年付 12 美元/席位/月，实际上超过 9 位用户后是每月 108 美元不限席位：50,000 条记录、20 GB、30,000 次自动化、100,000 次 API 调用、扩展与界面不限。Plus 不支持外部数据库连接。
- Business — 24 美元/席位，不限席位每月 216 美元：300,000 条记录、100 GB、120,000 次自动化、100 万次 API 调用、10 个外部数据库连接、私有库、SAML 单点登录。
- Scale — 45 美元/席位，至少 3 个席位：100 万条记录、150 GB、240,000 次自动化、500 万次 API 调用、行级安全与审计日志。
- Enterprise — 按需报价：SCIM 账号同步、IdP 用户组同步、专属客户经理。
注意「付 9 个席位，其余免费」的逻辑：20 人的团队用 Business，比大多数按人计费的竞品都便宜。
NocoDB 的不足
- 界面信息密度大，新手前几天容易找不到设置。
- 超大表（数百万行）的性能取决于外部数据库，NocoDB 不是分析型数据仓库。
- 部分高级功能（外部连接、SSO、行级安全）只在贵套餐里。
- 自动化不如完整工作流引擎灵活，复杂逻辑仍要写代码。
- Sustainable Use License 不是经典开源：公司内部使用自由，但不能基于 NocoDB 做公开的商业服务。
Rowy 详解
Rowy 最初被设想为 Firebase 的后院：把 Firestore 集合显示成表格，并且能在浏览器里直接写服务端函数。对 Firebase 产品团队来说确实方便——后台、CMS 和 API 都不需要专职后端开发。
功能
Firestore 集成。 连接 Firebase 项目后，集合以表格形式呈现。界面上的修改直接写入数据库，反之亦然——是双向同步，而不是导入导出。
字段类型。 超过三十种：文本、数字、日期、数组、地理位置、文件、指向其他集合的引用，还有衍生字段（由其他字段计算的取值）和 Action 字段（触发云函数的按钮）。
Cloud Functions。 在界面里编写 JavaScript/TypeScript 函数，由记录变更或行内按钮触发。这是 Rowy 最强的场景：比如新建订单时发邮件、计算折扣、调用外部 API。
导入导出。 支持 CSV、TSV、JSON 和 Airtable——既能一次性导入，也能在高级套餐里与 Airtable 持续同步。免费版导出上限 10,000 行，Pro 不限。
搜索与筛选。 全文搜索和高级筛选属于 Pro 功能。
Rowy 价格
- Base — 0 美元：1 个项目、表格与记录不限、云函数与成员不限、数据导入导出、30 多种字段类型、行级审计。
- Pro — 12 美元/席位/月（年付 9 折）：项目不限、全文搜索、导出超过 10,000 行、高级筛选、跨项目克隆代码、GCP 支出上限、邮件支持。
- Business — 按需报价：自定义域名、优先支持、数据版本管理、字段级审计、自动备份、表单。
价格看起来很有吸引力，尤其是记录数不限的免费版。但有个细节：免费版依附于你自己的 Firebase 项目，所以 Firestore 和 Cloud Functions 的费用会单独按 Google Cloud 价格结算。
主要风险：开发已经停摆
这一点比技术优劣更重。Rowy 仓库已从 rowyio/rowy 迁到 buildship-ai/rowy，最后一次提交是 2024 年 11 月。对一个定位为持续开发的开源项目来说，这几乎是两年的沉默。公司显然把重心转向了 BuildShip——一个可视化后端工作流构建器。
实际影响：
- 没有新功能，也没有安全补丁；
- 没人保证与 Firebase/GCP 变更的兼容性；
- Discord 社区逐渐冷清，复杂问题无人回应；
- 如果 Rowy 在生产流程里，你实际上是在维护一个分支。
对运行稳定、无需改动的内部工具，这可以接受。但对 2026 年的新项目，这是明确的反对理由。
Rowy 的其他不足
- 与 Firestore 强绑定：迁回 SQL 意味着重写数据模型。
- 总成本是订阅费加 GCP 消耗，活跃项目里后者可能超过前者。
- 不支持外部关系型数据库（与 NocoDB 不同）。
- 自托管需要 Firebase 项目和服务账号，没有 DevOps 就是门槛。
实测场景：按需求选型
我们让两个工具都跑了一遍读者最常提出的典型任务。
场景 1：销售团队替换 Airtable
需要商机表、官网线索表单、按状态的看板，以及销售与主管的角色区分。NocoDB 的 Plus 全部覆盖，数据还可以放在自己的 PostgreSQL 里。Rowy 也能做，但要把数据搬进 Firestore——为了界面而换存储。胜出：NocoDB。
场景 2：给现有数据库加界面
你有一台存电商数据的 MySQL，希望客服不用 SQL 客户端也能查。NocoDB 读写连接，表格立刻可见。Rowy 完全做不到。胜出：NocoDB，毫无悬念。
场景 3：Firebase 应用的运营后台
应用已经在 Firebase 上，数据在 Firestore，需要内容管理面板加两个服务端函数。Rowy 一个晚上就能跑起来：连接项目、选集合、写函数。NocoDB 则需要中间层和同步。胜出：Rowy——前提是项目不打算长期演进。
场景 4：十人团队，数据落地要求严格
数据必须留在自己的服务器，需要审计轨迹和按行授权。自托管 NocoDB 只需一台 VPS；云端等效功能在 Scale，45 美元/席位。Rowy 需要带境外账单的 GCP 项目。胜出：NocoDB。
场景 5：周末做后端原型
表单、数据库、API、两个自动化。两者都能胜任；Rowy 在 Firebase 上起步更快，NocoDB 维护更可预测。选择取决于你现有的技术栈。
真实团队的成本
| 团队 | NocoDB | Rowy |
|---|---|---|
| 3 人，最多 1,000 条记录 | Free — 0 美元 | Base — 0 美元 + GCP 费用 |
| 10 人，最多 50,000 条记录 | Plus — 每月 108 美元（年付） | Pro — 每月 120 美元 |
| 20 人，最多 300,000 条记录 | Business — 每月 216 美元（年付） | Pro — 每月 240 美元 + GCP |
| 50 人，需要 SSO | Business — 每月 216 美元 | Business — 按需报价 |
| 自有基础设施 | 自托管，只付服务器 | 自托管 + Firebase |
纸面上两家都是每席位 12 美元，差距不大。但超过 9 个付费席位后，NocoDB 不再随团队增长收费，而 Rowy 的账单线性增长，还要额外叠加 Google Cloud 费用。20 到 30 人时差距就很明显了。
谁该选哪个
选 NocoDB，如果：
- 已有或计划使用关系型数据库（PostgreSQL、MySQL、SQLite、SQL Server）；
- 需要自托管、数据留在自己服务器上；
- 看重可预期性：活跃开发、频繁发版、活跃社区；
- 你在做内部工具：CRM、库存、记账、表格型知识库；
- 希望表单、看板、日历和仪表盘集中在一处。
选 Rowy，如果：
- 产品已经在 Firebase/Firestore 上运行；
- 需要一个带 JavaScript/TypeScript 云函数、且不需要独立后端的后台；
- 项目是内部使用，不要求长期演进；
- 一旦需要改动，你愿意自己维护分支。
两者都别选，如果你需要对几千万行数据做分析（那是 ClickHouse 和 BI 工具的领域），或者需要带分支和复杂编排的完整工作流引擎（可以看 n8n 一类工具）。
结论
2026 年，NocoDB 是更稳妥的选择。它开发活跃、支持外部 SQL 数据库、定价可预测，也不会把你锁死在某一家云厂商。对典型需求——「给数据一个像样的界面并让团队用起来」——它能覆盖 90%。
Rowy 依然是个有意思的工具，想法也优雅：用表格作为 Firestore 的界面，再在浏览器里写服务端函数。如果你已经在 Firebase 生态里，而这周就要一个后台，Rowy 能交付。但把未来数年的新项目押在它身上是有风险的：近两年没有提交，这个信号不能忽视。
我们的建议是：从 NocoDB 开始，把 Rowy 当作针对具体 Firebase 任务的战术性方案，并准备好支持彻底停止时的 B 计划。
你站在哪一边——已经在用其中一个，还是仍在选型？说说你要解决的问题；从读者的经验看，往往很快就能看出工具会在哪一步触到上限。