Rowy 评测 2026：Firestore 低代码后端全解析
Firebase 几乎把一切交给了应用：身份认证、文件存储、数据库和 Serverless 函数。它唯一没给的，是一个能看清自己数据、并手动改上两笔的合理方式。项目一旦走出「Hello World」，Google Cloud 控制台里的 Firestore 编辑器就变成了折磨：文档只能一条一条点开，批量修改无从下手，更不该让运营同事或内容编辑靠近它。
Rowy 正是针对这一点。它是一个开源低代码后端，把 Firestore 集合渲染成一张普通表格（很像 Airtable），并允许你在同一个页面里直接用 TypeScript 写服务端逻辑。数据始终留在你自己的 Google Cloud 项目里，不会被搬到别人家的 SaaS。
本文拆解 Rowy 的架构、2026 年的能力、踩坑之处，以及每个席位 12 美元是否值得——还是说该直接去看自托管方案。
Rowy 是什么
Rowy 是架在 Firebase 与 Google Cloud 之上的一层 Web 界面。架构很简单：Rowy 不保存你的数据。它连接你的 GCP 项目，读取 Firestore 集合，再以表格形式呈现。每一次操作——改单元格、上传文件、触发函数——都以你的项目身份执行，不经过 Rowy 的中转服务器。
由此有两个推论：
- 数据主权完整保留。 存储区域由你选，GDPR 由你负责，读请求与流量由你付给 GCP。Rowy 永远不会成为你的数据处理者。
- 成本由两部分组成——Rowy 订阅费加 Google Cloud 账单。小体量下第二部分通常落在免费额度内，但它从不存在为零的幻觉。
产品有两种形态：rowy.io 上的托管应用，以及可以部署进自己项目的开源 GitHub 仓库。官方称已有 3 万多名开发者、GitHub 上约 6800 颗星。需要说明的是：仓库已迁移到 buildship-ai 组织，开源代码的最后活跃时间是 2024 年底，团队重心已转向 BuildShip。
另外值得提一句 BuildShip：同一团队作为独立产品推进的低代码平台，覆盖 API、定时任务与工作流。它其实就是对「我们还需要后台任务，不只是数据」的回答，也揭示了整条产品线的走向：从带函数的表格，走向完整的后端构建器。
优点与缺点
让人满意的地方
- 用表格替代 Firestore 控制台。 排序、筛选、批量操作、从剪贴板粘贴——原生编辑器多年缺失的都在这里。
- 30 多种字段类型，外加数据变化时自动重算的派生字段。
- 云函数写在界面里。 TypeScript 与数据同屏，可用任意 npm 包。
- 数据留在自己的 GCP 项目。 离开平台时无需迁移，也不会被锁死。
- 免费层不限制函数数量与 API 调用次数。 这很罕见，多数竞品恰好卡的就是这两项。
- 给非开发者的权限控制。 字段级角色、行级审计：谁在何时改了什么。
- 开源。 代码可读、可 fork、可修改，许可证不阻碍商用。
让人恼火的地方
- 强绑 Firestore。 如果你的数据库是 PostgreSQL、MySQL 或 Supabase，那它不是你的工具，也没有绕路。
- 需要开通计费的 Google Cloud 项目才能用函数和部分集成——对小团队是额外行政负担。
- 免费版只给一个项目。 第二个项目就要升级 Pro，而 Pro 按席位计费。
- 产品重心明显移向 BuildShip。 工程注意力去了新产品，更新日志能看出来：核心版本变少了。
- 界面信息密度高。 新手面对几十个字段、扩展和设置，前半小时基本是在乱点。
- 没有移动端。 只能用浏览器。
功能拆解
数据表格
主界面是一张很像 Airtable 的网格。列对应 Firestore 文档字段，行对应文档。字段类型从字符串、数字，到文件、图片、指向其他集合的引用、地理坐标、JSON、数组，以及带时区的日期。
控制台缺失的能力在这里都有：区域选择加 Excel 粘贴、复制行、双击即改、集合内搜索、多条件筛选和保存视图。大集合有分页与虚拟滚动，几万条文档也不会卡死。
派生字段是默默无闻的主力。经典例子是 total 由 price × qty 自动算出。逻辑存放在字段配置里，而不是散落在客户端与服务端，这大幅减少了 Firestore 项目常见的数据漂移。
**操作字段（Action fields）**是行内按钮，点击即调用你的函数——「一键确认订单 / 发邮件 / 重建索引」，对运营团队能省下大量时间。
云函数
Rowy 内置 Monaco 编辑器，支持高亮、自动补全和任意 npm 包。函数绑定到集合与触发器：创建、更新、删除文档，或从操作字段手动触发。
实践中这是 Rowy 最强的理由。普通 Firebase 项目里加一个触发器，要配本地环境、装 Firebase CLI、在单独仓库写函数、部署，还得记得以后重新部署。在 Rowy 里流程是：打开集合、加函数、保存。对于「状态变化时发邮件」「把变更写进分析表」这类运维任务，这个短循环很快回本。
限制同样存在。调试弱于经典部署——没有本地运行器、没有断点，只能看日志。依赖通过界面里的 package.json 管理：一两个库还行，十个函数共享模块时就开始混乱。
Webhook 与扩展
Webhook 把数据请进来：网站表单、支付回调、外部 API 响应。Rowy 给你一个 URL，你 POST 一段 JSON，集合里就多一条文档。这是不写自己服务器、最快把落地页接进数据库的方式。
扩展把数据送出去：SendGrid 发邮件、Slack 与 WhatsApp 发通知、Algolia 与 Typesense 做全文搜索。每个扩展配置几个字段即可，作为集合变更的后台订阅运行。
我们完整跑过的一条链路：落地页线索打到 Webhook → 文档进入 leads 集合 → 派生字段按公司规模打分 → 函数用 SendGrid 发邮件并推送 Slack 通知 → Algolia 为后台搜索建立索引。全部在同一屏完成，零基础设施代码。
权限与审计
对团队来说很关键：非开发者能访问数据，却不会多出额外权限。角色可按表、按字段设置——内容编辑能改 status，改不了 price。行级审计（创建人、修改人、时间戳）在免费层就有；字段级审计与自动备份属于 Business。
一个限制：用户管理走 Firebase Auth，因此 Rowy 不能替代企业 SSO。若公司要求只能用 Okta 登录，这就是硬阻塞，需要另外把 Firebase 对接外部身份提供商。
价格
- Base — 0 美元。 一个项目、集合与记录不限、云函数不限、API 调用不限且无限流、30 多种字段、CSV/TSV/JSON 导入导出、行级审计、角色、Discord 社区支持。
- Pro — 每席位每月 12 美元（年付九折）。项目不限、全文搜索、导出超过一万行、高级筛选、跨项目克隆代码、GCP 账单硬上限、邮件支持。含一个月免费试用。
- Business — 按需报价。 含 Pro 全部，外加自定义域名、优先支持、数据版本管理、字段级审计、自动备份与表单。
最常被忽略的一点：12 美元不是全部账单。 Google Cloud 的费用另算。小项目通常为零——Firestore 读写额度宽松，Cloud Functions 每月 200 万次调用——但集合活跃、触发器频繁时账单会往上走，而且没人替你盯着。用 Pro 就应立刻开启 GCP 账单上限。
算账很简单：如果 Rowy 帮开发者省下一天做后台的时间，或者把改数据的杂活从工程师手里拿走，12 美元瞬间回本。独立开发者用免费 Base 跑一个生产项目完全可行。
我们的测试
我们把 Rowy 部署到一个测试 Firebase 项目上，集合是订单（约 1.2 万条文档、18 个字段，含指向客户集合的引用和订单明细数组），重点观察三件事：界面速度、函数表现、非开发者的上手难度。
接入。 Web 向导完成：Google 登录、选项目、给服务账号分配角色、初始化 Rowy 集合。首次搭建大约十分钟，大头在计费与 IAM，而不是产品本身。
表格。 1.2 万条文档下界面依然跟手：滚动流畅；筛选有明显但可接受的延迟，因为每次查询都打到 Firestore 并按读取计费。粘贴 200 行 CSV 没有报错，但比本地表格慢不少——这是 Serverless 模型的代价，不是 Rowy 的 bug。对 500 条文档批量改一个字段试了几次：部分批次撞上了 Firestore 批量操作的上限。
函数。 状态变更触发、经 SendGrid 发邮件的函数第二次保存才跑通——第一版因为缺少依赖包失败，因为依赖必须手动写进 package.json。之后稳定。日志在界面里能读，但也印证了调试是短板：没有本地模拟器，「保存—看日志」的循环很快让人烦躁。
非开发者。 一位毫无技术背景的内容编辑大约 20 分钟就掌握了筛选与字段编辑——这大概是产品最好的信号。字段级限制也如预期：被禁止的字段根本无法编辑。
测试结论：Rowy 确实消除了 Firestore 周边的琐事，但它并没有把 Firebase 变成关系型数据库，批量操作上也别指望奇迹。
替代方案
- Airtable — 更漂亮更简单，但数据在 Airtable 手里而不在你手里，团队版价格也不便宜。Rowy 胜在数据主权与后端逻辑。
- Retool — 做内部工具（表单、看板、几十种组件）更强，但它不是数据 CMS，也不是 Firestore 后台的替代品。两者往往互补而非竞争。
- NocoDB 与 Baserow — 面向 SQL 数据库（PostgreSQL、MySQL）的开源表格前端。技术栈不是 Firebase 就看它们。
- 自建 React Admin 后台 — 灵活且免费，但要几周开发加永久维护。任务标准时，Rowy 更便宜。
适合谁
该买，如果： 你用 Firebase/Firestore，有需要经常手工维护的运营数据（订单、线索、目录、用户），尤其当非开发者也需要访问、又不想自建后台。一个好信号：你已经会为了改一个字段打开 GCP 控制台，为五秒钟的事花掉五分钟。
别买，如果： 数据库不是 Firestore；需要开箱即用的企业 SSO；打算做重分析与批量 ETL——那是 BigQuery 和专用工具的活。如果产品方向的确定性很重要，也要再想一遍：团队重心已经移向 BuildShip。
中间情形是那种从 Firebase 起步、正慢慢迁往 PostgreSQL 的创业公司。Rowy 帮不上：它不简化迁移，迁完就没用了。只有当你有把握 Firestore 在一两年内仍是主库时，才值得把它当作长期后台基础。
结论
Rowy 是一件窄而锋利的工具。它不想成为通用低代码平台，也不跟 Retool 抢看板构建器；它只堵住 Firebase 的一个具体窟窿——缺少面向人的数据界面——而且堵得干净。
强项：表格、派生字段与操作字段、内置 TypeScript 函数、完整数据主权。短板：只支持 Firestore、函数调试偏弱、团队注意力被 BuildShip 分流。
对于数据每周要手工改不止一次的 Firebase 项目，免费 Base 已覆盖大部分需求；Pro 每席位 12 美元换来项目不限与全文搜索，价格公道。其他技术栈，Rowy 就是不对的工具——它也从未声称自己通用。
评分：8 / 10 —— 优秀的垂直工具，定价诚实，但有一个不小的限制：只支持一种数据库。