数据库工程师这份工作,很多时候是从修一个很难复现的锁等待开始的。Supabase 最近围绕 OrioleDB 的招聘,正好把这种苦功夫放到了台前。作为 YC S20 的明星公司,Supabase 一直以"开源 Firebase 替代品"被开发者熟知,但它的真实野心从来不是做一个简单的 API 包装层,而是把 PostgreSQL 做成下一代云原生数据库的基础设施。既然目标如此,存储引擎自然就成了绕不开的战场。OrioleDB 这个名字,对很多 PostgreSQL 用户来说还有点陌生,但对数据库内核圈子来说,它代表着一种非常重要的可能性。Supabase 愿意为这个方向专门招人,实际上是在向外界释放一个强烈信号:它不只想做一个托管 Postgres 服务,更想参与甚至主导 Postgres 底层技术创新。
要理解这个信号,先要回到 PostgreSQL 默认的存储方式。PostgreSQL 从一开始就采用堆表结构,配合 MVCC 实现并发控制。每个事务写入数据时,系统会生成一个新版本的数据行;如果多个事务并发访问同一行,旧版本并不会立刻被清除,而是以死元组的形式继续留在页面中。时间一长,表会不断膨胀,索引也会变大,查询性能会跟着逐渐下降。为了解决这个问题,PostgreSQL 需要定期运行 VACUUM,将不再可见的元组清理掉。这个机制在设计上非常成熟,也经过了长期验证,但它并不是没有代价。
VACUUM 本身会产生大量的 I/O,在高并发写入场景下还容易出现主备不一致、延迟波动、CPU 被反复消耗等问题。对于运维团队来说,表膨胀和 VACUUM 优化一直是 PostgreSQL 最让人头疼的事情之一。 很多人以为这是 PostgreSQL 无法避免的宿命,但事实上 PostgreSQL 早就留出了一个扩展空间。从 PostgreSQL 12 开始,表存储接口被抽象成 Table Access Method,开发者可以在原有堆表之外实现自己的存储引擎。这个变化的意义在于,PostgreSQL 不必再用千篇一律的方式管理数据。不同应用场景可以选择不同的存储结构,比如面向 OLTP 的行式存储,面向分析场景的列式存储,或者针对特别高写入吞吐的日志型存储。
OrioleDB 正是这个方向的先行者,它选择了一条更加激进也更接近现代硬件特性的技术路径。 OrioleDB 的核心理念,是彻底解决堆表因 MVCC 带来的元组膨胀问题。它不再像传统 PostgreSQL 那样为每次更新生成一个完整的死元组,而是采用专门设计的 undo 日志来记录变更,让行版本的可见性判断变得更加轻量。换句话说,旧版本数据不再需要长时间残留在堆表中,而是能够被快速回收,这样数据文件就可以保持在一个相对稳定的状态,表的体积不会随着写入量的增加而无限膨胀。对于大量偶发更新、频繁小事务、以及需要长时间保持数据库连接的应用来说,这种机制能显著降低存储成本,同时减少清理线程对主业务的干扰。 除了消除膨胀,OrioleDB 还在数据如何落盘上做了不少文章。
传统 PostgreSQL 的 WAL 日志以数据页为核心,每次提交都需要把页面的修改写入文件系统。这种设计虽然可靠,但在高并发、高写入场景下,日志写入和页面刷盘会带来几乎翻倍的放大效应。OrioleDB 从行级日志和页面结构下手,尝试减少这种不必要的写放大。它让系统在恢复时不需要重新应用整个页面,而是可以更精确地还原行级别的变更。这意味着在云环境常见的 NVMe SSD 和持久化内存上,OrioleDB 有机会把性能压得更好,延迟也更稳定。 Supabase 之所以会坚定地选择 OrioleDB,和它的业务模式有直接关系。
Supabase 本质上是在大量的 PostgreSQL 实例之上构建一个托管平台,它把每个用户的应用连接到一个独立或者共享的 Postgres 数据库,然后在这个基础之上提供认证、实时订阅、对象存储、边缘函数等服务。为了让商业模式成立,Supabase 必须保证每个数据库实例的资源使用率足够高,同时降低运维成本。如果存储引擎继续沿用旧有的堆表机制,那么托管服务的硬件密集度、节点数量以及人工介入次数都会变得不可控。OrioleDB 如果成熟,能够极大地提高单机密度,减少因为膨胀和垃圾回收造成的资源浪费,让每个节点在同样硬件条件下承载更多活跃数据库。这个优势不仅影响最终客户的账单,也会直接影响 Supabase 的毛利率。 从招聘职位来看,Supabase 要找的不是普通的后端工程师,而是能够深入 PostgreSQL 内存结构、锁管理、日志提交和存储模型的人。
这类人必须理解 B 树的结构优化,必须能看懂崩溃恢复时 WAL 的回放路径,还必须对 Linux 内核的 I/O 调度有一定的敏感度。在 OrioleDB 项目中,工程师的工作不会只是维护一个扩展,而是要想办法让它真正成为生产环境中可以被依赖的存储底座。比如需要设计一种新的 undo 回收策略,处理长时间运行事务对历史版本的影响;又比如要优化 B 树叶子节点的分裂方式,让高并发插入下的小型事务不会产生锁冲突。再比如,为了让 OrioleDB 能够融入 Supabase 的自有平台,工程师还必须考虑它与 Supabase 的自动备份、只读副本、水平扩展和故障切换机制如何紧密配合。 这些工作听起来非常底层,但恰恰是现代数据库公司最需要掌握的硬核能力。过去很长一段时间,我们习惯了把数据库当作黑盒来用,遇到性能问题就加索引,加机器,或者直接换一个更贵的数据库。
可当应用规模大到一定程度,性能瓶颈往往不在某个 SQL 语句本身,而是存储引擎对 CPU 缓存、磁盘 I/O 和内存访问模式的利用效率。Supabase 想要解决的是这个更深层的问题。靠它的体量完全可以直接用现成的存储方案,比如在 PostgreSQL 外面套一层分库分表工具,或者改成别的存储引擎。但它在这些常规路线之外,选择押注 OrioleDB,说明它认为传统方案的边际收益已经不够了,必须从存储层开始重新设计。 当然,OrioleDB 现在还处于非常早期的阶段。作为一门新技术,它要在生产环境中得到广泛部署,还需要经历大量真实场景的考验。
首先是事务隔离级别的兼容性。PostgreSQL 的用户已经习惯了 READ COMMITTED 和 REPEATABLE READ 语义,OrioleDB 在处理快照和回滚时,不能出现任何偏差。其次是复制和备份协议。PostgreSQL 的逻辑复制、物理复制、流复制、PITR 等功能,都建立在固定的数据格式和日志协议之上,OrioleDB 要在不破坏这些能力的前提下做性能优化,难度非常高。还有数据恢复能力。数据库一旦崩溃,恢复过程必须快速、确定、不丢数据,任何存储引擎都不能有侥幸心理。
Supabase 敢于在这个阶段投入大量工程师,肯定已经对这些问题做过深入研究。这不是一次冲动的社区贡献,而是一场有策略的长期投资。 对于 Postgres 生态系统来说,Supabase 的选择还有一个很重要的意义:它打破了"一个 PostgreSQL 只能有一种存储形态"的固有思维。过去,很多企业选择 PostgreSQL,是因为它的可靠性和生态丰富。伴随着 OrioleDB 这样的项目成熟,PostgreSQL 的多存储引擎生态会变得越来越完整。未来,不同负载可以更加自然地被路由到不同存储引擎上,比如热数据放在内存引擎,冷数据放在列式引擎,而需要严格事务的数据继续使用默认存储。
这种演进如果能被主流云厂商接受,整个 Postgres 的边界就会被极大地拓展。Supabase 作为一家创业公司,选择了在最艰难的阶段进入存储引擎研发,这本身就说明了它对 Postgres 的信仰不是停留在口号上。 对开发者社区而言,Supabase 的招聘也是一个积极信号。它意味着不再只有大公司和传统数据库厂商才会投入这类基础设施研究。像 Supabase 这样的开源创业公司,也可以利用 YC 生态的资源,把资金和工程师时间投入到极度底层的数据库内核开发中。这样的人才岗位,对于想要进入数据库行业的人来说,是一次难得的机会。
很多有经验的工程师可能只是在应用层做过不少优化,但真正的数据库内核开发经验,需要长期浸泡在 C 语言、指针、内存页、原子操作和并行调度这些细节中。Supabase 愿意提供一个环境,让工程师在做真实产品的同时,把成果回馈到开源社区,这对整个行业都是非常有吸引力的。 更重要的是,Supabase 并没有因为 OrioleDB 是一个技术项目就忽略了产品价值。它清楚地知道,任何存储引擎最终都要落到用户体验上。用户不关心后端是不是用 B 树,也不关心快照隔离具体是怎么实现的。他们最关心的几个问题是:我的数据库查询能不能更快,我的表会不会越用越大,我的数据库维护是不是更简单。
OrioleDB 在这几个维度上的潜力都非常可观。如果它能够在 Supabase 的生产环境中稳定运行,那么用户几乎不需要改动多少代码,就能感受到更低的延迟和更小的存储占用。对于每天都要处理海量数据同步和变更表的开发者来说,这种改善会非常直接。 可以预见,围绕 OrioleDB 的招聘只是一个开始。Supabase 已经从一个以开箱即用为核心的 BaaS 平台,逐步变成了一个更加面向基础设施和数据库核心的科技公司。它也许还会继续发布更多关于存储引擎性能的数据,公开一些基准测试,甚至邀请社区一起参与设计。
未来如果 OrioleDB 真的成为 PostgreSQL 生态中一个重要的存储选项,那么 Supabase 在这个时间点的决定,将会被看作是一次非常具有前瞻性的卡位。 从企业战略出发,做存储引擎不是效率最高的选择,但这恰恰能构成长期的竞争壁垒。Supabase 一直强调自己"不只是又一个 Firebase 开源替代品",而是要成为开发者真正可以依赖的数据库云。OrioleDB 所代表的数据库底层能力,正是这个目标不可或缺的一块拼图。Supabase 的愿景能不能实现,现在下结论还太早,但它愿意走这条更难的路,愿意为这项底层技术持续投入,本身就值得关注。 数据库行业不缺新的概念,缺的是愿意踏实打磨底层技术的人。
Supabase 的这次 OrioleDB 招聘,看起来是一个职位信息,实际上是一种表态:它相信 Postgres 在未来很多年里仍会是应用开发者的核心选择,同时它也相信,Postgres 自身必须进化。OrioleDB 是进化的方向之一,而 Supabase 想成为那个推动进化发生的力量。对于开发者来说,这无疑是一个值得持续关注的趋势。毕竟,下一代的数据库基础设施,也许就藏在像 OrioleDB 这样不可思议但极具突破性的项目里。 。
