← 返回创业生死簿(525 家阵亡公司)
生死簿 · 第 518 页 · 信息技术 · 美国

RethinkDB 🇺🇸 为什么倒闭?

🔥 烧掉 $1200万美元 · 2009 年崛起 → 2016 年阵亡 · 存活 7 年
死因:无市场需求

让数据库变化实时推送前端,开发者订阅查询结果即可,告别轮询和 pub/sub——Node.js 实时 web 浪潮里最有开发者缘的数据库:漂亮的 admin UI、JSON 原生、带 join 的 MongoDB 超集。社区爱它,没人肯迁移,1200 万美元烧完 2016 年停摆。

开发者在理论上爱它,在实践中不为之付费。实时订阅是 nice-to-have:大多数应用用 Redis pub/sub、WebSocket 或轮询 100 行代码就能凑合,而换数据库是拿公司下注的迁移决策——为一个小功能承担整个数据层的迁移风险,没人干。开源只有企业支持与托管两条变现路,但产品运维复杂,每个客户都要重度手把手,CAC 高得离谱;真做托管,RethinkDB 比 MongoDB/Postgres 更吃内存 CPU,毛利也薄。更糟的是两头堵死:低端有 Firebase 免费送实时(Google 补贴),高端 MongoDB 多年企业销售领先,Postgres 回潮吃掉 NoSQL 热度。卡在中间:对创业公司太复杂,对企业太不成熟。开发者之爱换不来迁移意愿,$1200 万买不来一次赌上职业生涯的决定。

⚰️ 三条核心教训

  1. 开发者的喜爱不等于迁移意愿:换数据库是 bet-the-company 决策,nice-to-have 撑不起它
  2. 开源基建的托管版必须比自建好 10 倍而非方便 2 倍,否则免费社区只是慈善
  3. 需求是真的,载体错了:Firebase/Hasura/Supabase 证明实时该长在现有数据库上,而非独立品类

🔧 转世方案:SyncLayer 通用实时同步引擎

不换数据库,让任何数据库实时:尾随事务日志(Postgres WAL、MySQL binlog、Mongo oplog)转成统一事件流,通过 WebSocket/SSE 推给订阅客户端,提供 RethinkDB 式 changefeeds 与响应式查询。核心洞察:开发者不想要新数据库,只想要现有数据库有实时感。楔子是「生产级 Postgres 实时」——切正在用轮询或自建同步逻辑的团队;与 Supabase Realtime(绑定自家托管 Postgres)不同,SyncLayer 支持任意数据库、本地部署与多云。护城河是运维功力:背压、冲突解决、schema 演进比自建方案强。

技术栈:Postgres WAL/logical replication / WebSocket/SSE / Go/Rust 事件流处理 / Vercel / Supabase 管理面板

❓ 关于 RethinkDB 的常见问题

RethinkDB为什么倒闭?

死因是「无市场需求」。开发者在理论上爱它,在实践中不为之付费。实时订阅是 nice-to-have:大多数应用用 Redis pub/sub、WebSocket 或轮询 100 行代码就能凑合,而换数据库是拿公司下注的迁移决策——为一个小功能承担整个数据层的迁移风险,没人干。开源只有企业支持与托管两条变现路,但产品运维复杂,每个客户都要重度手把手,CAC 高得离谱;真做托管,RethinkDB 比 MongoDB/Postgres 更吃内存 CPU,毛利也薄。更糟的是两头堵死:低端有 Firebase 免费送实时(Google 补贴),高端 MongoDB 多年企业销售领先,Postgres 回潮吃掉 NoSQL 热度。卡在中间:对创业公司太复杂,对企业太不成熟。开发者之爱换不来迁移意愿,$1200 万买不来一次赌上职业生涯的决定。

RethinkDB一共烧了多少钱?

累计烧掉约 $1200万美元(美元),2009 年创立,2016 年停止运营,存活 7 年。

它留下了哪些教训?
  1. 开发者的喜爱不等于迁移意愿:换数据库是 bet-the-company 决策,nice-to-have 撑不起它
  2. 开源基建的托管版必须比自建好 10 倍而非方便 2 倍,否则免费社区只是慈善
  3. 需求是真的,载体错了:Firebase/Hasura/Supabase 证明实时该长在现有数据库上,而非独立品类