如果你关心开发者工具与开源数据库,一定不会对 Supabase 这个名字感到陌生。作为 Y Combinator 2020 年夏季班(YC S20)走出来的公司,Supabase 以"开源 Firebase 替代品"的定位,在极短时间内聚集了大量开发者关注。与许多只是把数据库当作黑盒的创业公司不同,Supabase 很早就强调自己完全建立于 PostgreSQL 之上,并能给开发者提供实时、安全、可扩展的数据体验。最近,一条招聘信息引起了更多人的注意:Supabase 正在为 OrioleDB 招聘工程师。这件事本身看起来像一次普通的人才扩张,但放在数据库生态的背景下,它可能预示着新的时代。 Supabase 的核心理念是让开发者不需要重新学习数据库知识,却能够获得商业数据库级别的体验。
它通过构建在 PostgreSQL 之上,把数据库的后端复杂性藏起来,同时保留 SQL 的全部能力。从实时订阅到身份认证,从对象存储到边缘函数,Supabase 的所有功能都依赖 PostgreSQL 来处理核心数据。这样的架构非常有远见,但也意味着它必须把数据库性能放在最重要的位置。过去,PostgreSQL 可能是开发者在开发阶段的最爱,但到了生产环境,它会面对写放大、表膨胀、vacuum 调度等一大堆问题。而 OrioleDB 的设计目标,正是解决这些与存储引擎相关的深层矛盾。 OrioleDB 并不是一个全新的数据库,而是一个为 PostgreSQL 设计的可扩展存储引擎。
要理解它的价值,需要先了解 PostgreSQL 默认的存储机制。PostgreSQL 传统上使用堆表,每一行在更新时并不会原地覆盖,而是会生成一个新的行版本,旧版本要继续保留,以便那些仍在执行中的事务可以读到一致的快照。这种多版本并发控制为 ACID 提供了支持,但同时也在表页中留下大量死元组。当更新和删除比较频繁时,表会变得越来越臃肿,索引也会变大。为了回收这些空间,系统必须运行 vacuum 进程。即使 PostgreSQL 已经有自动清理进程,在负载很大时,清理仍可能跟不上数据产生的速度,最终导致数据库进程变慢、磁盘空间异常增长。
OrioleDB 走的是一条不同的路线。它把最新版本的数据放在主存储中,而把旧版本写到撤销日志里,这样主表就不再需要保留大量过期的行版本。当一个事务需要回滚时,系统可以通过撤销日志回到之前的状态,而当所有旧版本都不再需要时,后台清理也可以在更低成本下进行。这种设计让存储布局更加紧凑,也让热更新不会像以前那样迅速制造出很大的"空洞"。可以把它类比成 InnoDB 与传统 MyISAM 的区别,不过 OrioleDB 是专门为 PostgreSQL 生态而生的扩展,它能做到与 Postgres 的查询规划器、事务系统与索引机制深度集成。 从性能角度来说,OrioleDB 最大的贡献在于减少写放大和降低 I/O 开销。
在传统的 PostgreSQL 堆表中,一条 UPDATE 不仅要写新的行版本,还可能因为更新索引字段而修改索引项;而每一次脏页面最终要被刷新到磁盘,这会带来很大的 I/O 放大。OrioleDB 通过更聪明的日志存储和页面管理,尝试让写入路径更短、更高效。对于大量小事务、高频更新以及物联网设备上报这类写密集场景,这种能力能够带来非常直观的体验提升。开发者可能不再需要为了提升写入性能而引入一套缓存层,也不必通过定期重建表来控制膨胀。 那么,Supabase 为什么要在这个时间点亲自下场为 OrioleDB 招人?答案与它自身的商业模式密切相关。Supabase 的目标不是做一个简单的云数据库壳子,而是希望把 PostgreSQL 变成一个完整的开发平台。
如果存储引擎始终是黑盒,那么许多性能问题就只能通过扩容来解决,这不仅贵,也未必能根除。通过支持 OrioleDB,Supabase 可以在数据库层面提供"开箱即用的抗膨胀"能力,这能够让它免费套餐或基础套餐中的数据库,更从容地应对开发者的真实流量。与此同时,这些贡献也能帮助 OrioleDB 获得更多反馈,形成良性循环。 从招聘的岗位类型推断,Supabase 需要的不仅仅是会用 PostgreSQL 的工程师,而是能够深入 C 语言、文件系统、事务日志和数据库缓冲池的人。这类人一直是技术行业里最稀缺的角色之一。愿意为一个开源存储引擎投入专门团队,说明 Supabase 并不满足于永远做云端 API 层。
它正在把触角伸向数据库内核,直接参与最底层设计。这种深度对于任何一家公司来说都不是一件小事。它意味着更长的产品周期、更严格的质量要求,以及需要与整个 PostgreSQL 社区持续对话。但这也会构建出极强的技术壁垒,让对手很难轻易复制。 对开发者社区而言,这个消息最令人兴奋的地方在于:开源项目不再只是靠个人英雄主义。OrioleDB 背后有一个真正使用它的公司,而这家公司愿意为它的持续性发展支付薪水、招募人才、修复 bug。
很多开源软件的问题不在于代码缺陷,而在于没有足够的维护者。现在,Supabase 的加入可以让 OrioleDB 的 issue 更快被处理,新特性测试更充分,也更容易吸引那些原本观望的数据库工程师参与。最终获益的,是所有使用 PostgreSQL 的人。 当然,机遇与挑战总是并存的。OrioleDB 要进入生产环境,还要走过一段艰难的路。PostgreSQL 功能非常多,除了事务和索引,还有分区表、逻辑复制、并行查询、扩展模块、流式备份等。
任何一项功能如果在新存储引擎中表现不一致,都很难被大型团队采用。Supabase 如果计划在托管环境中大规模提供 OrioleDB,就必须建立完善的自动化测试与迁移工具,确保现有应用可以平滑过渡。从目前的开源路线图来看,OrioleDB 已经启用了很多实验特性,但离全面可用还需要时间。这一过程考验的不仅是技术能力,还有团队的耐心。 从行业竞争来看,数据库引擎的争夺从来没有像今天这样激烈。Snowflake 专注于大数据仓库,PlanetScale 拥抱 MySQL 生态,MongoDB 守着文档模型,而 Supabase 则下注 PostgreSQL。
PostgreSQL 拥有最强健的 SQL 实现、最活跃的插件生态,以及从 OLTP 到 OLAP 都能扩展的灵活性。OrioleDB 代表着让这些能力在默认存储层上持续进化的可能性。如果它能够取得成功,Supabase 的数据库可能是所有云服务里最接近"开发者定义的基础设施"的存在。 另一个值得注意的地方是,Supabase 选择公开招聘,等于是在向整个行业释放信号:它愿意把核心投资放在开源领域。过去也有不少云厂商既提供托管数据库,也向内核提交补丁,但像 Supabase 这样从第一天起就完全基于开源、并把开源数据库引擎作为核心商业价值的企业,仍然不多见。这种做法的透明度和社区友好度,会让开发者对 Supabase 产生更多信任,也让长期使用该项技术的人更加安心。
数据没有供应商锁定,反过来说,Supabase 也通过持续贡献巩固了自身在 PostgreSQL 生态中的领导地位。 回到产品层面,用户可以预期什么?如果未来某一天,Supabase 在创建项目时默认使用 OrioleDB 引擎,开发者会得到更稳定的写入性能、更少的内存与磁盘占用,以及更加可预测的数据库行为。大多数情况下,他们不需要修改任何 SQL 代码,因为 OrioleDB 这样的存储引擎只负责管理数据在物理设备上的组织方式,不会改变 SQL 的语义。开发者的业务层可以保持原封不动,数据库内部却已经完成一次重要的升级。这恰恰是现代数据库平台应该具备的特质:把复杂留给自己,把简洁还给用户。 展望未来,PostgreSQL 生态的活跃度让人欣慰,而 OrioleDB 正是其中最值得关注的实验项目之一。
Supabase 的招聘决定,等于用真金白银为这个项目投下了一张信任票。对于普通开发者来说,这可能只是看到了一个职位空缺,但在表面之下,一场关于数据存储、事务处理和云原生架构的深层变革已经在进行。未来几年,我们很可能会看到 OrioleDB 成为许多 Supabase 实例的默认后端,也可能会看到它影响 PostgreSQL 社区对存储引擎的思考方式。 在数据库世界里,没有什么比存储引擎更底层,更没有什么比它更难在短期见成果。但正是这种难而正确的事,才能构建出真正的护城河。Supabase 为 OrioleDB 招聘,走出的是从应用厂商到数据库厂商的关键一步。
这条路不会轻松,但方向已经足够清晰。对于看着 PostgreSQL 一步步走到今天的开发者来说,能够在场见证一个开源存储引擎走向成熟,本身就是一件令人兴奋的事情。未来已来,而这次,Supabase 和 OrioleDB 正站在潮头。 。
