在数据库世界里,人才流动的方向往往预示技术趋势的方向。当一家公司公开为某个存储引擎发布招聘信息,这不只是补一个岗位,而是在向市场传递战略信号。Supabase(YC S20)正是如此 - - 这家被称作 Firebase 开源替代者的公司,正在为 OrioleDB 招聘数据库工程人才。这个动作可能比许多融资消息更值得深读,因为它把战场从应用层拉到了数据库内核层。 Supabase 的成长路径本身就是一条围绕 PostgreSQL 展开的旅程。它出生在 Y Combinator 2020 年夏季批次,当时后端即服务赛道上已经有不少玩家,Firebase 也占据着大量开发者心智。
Supabase 选择了一条完全不同的路径:不做封闭云服务,而是把 PostgreSQL 这个成熟数据库变成产品核心,用开源的方式重新组织后端基础设施。Auth、REST API、Realtime、Storage、Edge Functions、数据库管理后台......这些能力最终都统一在一个 Postgres 之上。开发者可以把核心数据库完全掌握在自己手里,同时享受第三方服务带来的便利。这种"控制权"与"易用性"的结合,恰好是很多团队愿意选择 Supabase 的原因。 但这也让 Supabase 必须面对一个根本性问题:PostgreSQL 本身的天花板在哪里?传统的 PostgreSQL 存储引擎基于堆表设计,配合多版本并发控制来保证事务隔离。每次更新操作都会生成一个新版本行,旧版本行需要在不再被事务需要之后被清理。
这个清理工作由 VACUUM 完成,而 VACUUM 在高并发、大表单、频繁更新的场景下会带来额外的 IO 和排队成本。表膨胀和索引膨胀会继续消耗磁盘和内存,写放大问题也会在复制和备份中进一步放大。这些问题不是 bug,而是旧存储架构与现代硬件之间日益明显的错位。很多团队最终不得不凭借分区、分库、手工重建表、定期维护等手段来积极对抗膨胀,但这些方法都增加了运维负担。 OrioleDB 的切入点正是这里。它不是给 PostgreSQL 打补丁,而是作为一个新的存储引擎扩展,尝试解决堆表架构中的结构性问题。
最核心的变化是用索引组织表来存储数据,让表数据本身按照索引顺序组织,访问路径更短,也省去了一部分回表的开销。多版本信息从数据页中抽离出来,放进独立的撤销日志里。这样一来,旧版本不再无限堆积在需要被扫描和清理的表页中,VACUUM 的压力会大幅降低。写入路径上,OrioleDB 引入行级 WAL 的概念,让日志记录更接近语义化,减少不必要的物理页写入。锁粒度更细、并发控制更主动,这些设计目标都是为了更好地利用现代多核 CPU、大内存和 NVMe 磁盘的性能。 需要强调的是,OrioleDB 不是一个全新的数据库,也不要求应用重写代码。
它通过 PostgreSQL 的 Table Access Method 接口接入,让用户以在建表时指定存储引擎的方式使用。这意味着它具备极强的兼容性和可移植性。对 Supabase 这样的托管服务商来说,OrioleDB 代表了一种从底层改变用户体验的机会。只要存储引擎能更高效地处理写入和读取,上层 API 的所有能力都会同步受益。比如 Realtime 功能依赖数据库的订阅和逻辑解码,如果存储引擎变得更稳、更强,实时能力在流量增长时也能保持低延迟。再比如边缘函数和 REST API 背后往往是一次次短查询,这些查询在索引组织表上的执行效率,可能会更接近开发者期待中的速度。
Supabase 为什么选择在这个时间点招聘 OrioleDB 相关人才?答案可能藏在几个维度里。第一,数据库托管市场的竞争重点正在从"能不能跑"转向"跑得好不好"。很多云厂商都开始自研数据库内核,或者大力参与开源数据库的深度改造。Supabase 如果不能掌握关键技术能力,就会在性能、成本、企业级功能上受制于人。第二,PostgreSQL 社区在存储引擎层面的创新非常活跃,但要把一个实验性扩展变成生产环境可以稳定运行的组件,需要长时间投入专业资源。OrioleDB 背后有熟悉 PostgreSQL 内核的开发者,但这还远远不够。
Supabase 需要扩大团队,把核心引擎的维护、测试、调优、文档、发布等工作真正走完。第三,从商业角度看,这是一条差异化的护城河。 对于开发者来说,这场招聘背后可能隐藏着一个难得的职业机会。数据库内核是一个非常依赖于信任和积累的方向。能够参与 OrioleDB 开发,意味着你要处理的事务不只是业务逻辑,而是数据库最底层的事务模型、WAL 日志、崩溃恢复、锁管理、缓冲池调度、并行执行等系统性问题。这些问题复杂,但一旦解决,就会对整个生态产生持久影响。
Supabase 在这个阶段投入,说明它愿意接受长周期、慢变量的挑战。这种耐心,在创业公司身上其实不容易看到。 从开源社区的角度,Supabase 的加入也是对 PostgreSQL 生态的一次支持。许多云厂商在开源项目上是"吃水不忘挖井人"的态度,能够真正以公司身份长期投入社区开发的不多。Oracle、Google 等虽然也有 Postgres 相关产品,但它们的目标往往是服务自身云托管。Supabase 作为一个开源 BaaS,本身依赖 Postgres 的健康发展,因此更有动机持续贡献。
OrioleDB 的成熟将不局限于 Supabase 一家:任何使用 PostgreSQL 的人,未来都有可能在自己的数据库实例中启用新的存储引擎。也就是说,今天为 OrioleDB 写下的每一行代码,都是在降低未来所有 Postgres 应用面临存储瓶颈的概率。 数据库内核开发之所以罕见,是因为它需要同时驾驭理论模型与工程实现。一个简单的事务更新,涉及事务日志格式、页面布局、锁表、内存管理、操作系统的 page cache、文件系统语义、CPU cache。OrioleDB 的复杂度并不低于一个独立的数据库,但它又必须保持和 PostgreSQL 的接口完全兼容。这种"戴着镣铐跳舞"的升级方式,比从零写数据库更难,也更有价值。
Supabase 的招聘,大概率会聚焦在这类人身上:懂 PostgreSQL 的源码,理解数据库内部的 B-tree、WAL、MVCC,也习惯处理真实用户在大规模部署中遇到的边缘 case。 当然,技术上的未来并不只是一片坦途。OrioleDB 需要在极端条件下证明自己:崩溃恢复是否足够快?并发事务的隔离性是否真正达到生产标准?备份复制与现有工具链是否兼容?这些都需要经过一轮又一轮的压测、故障注入和线上验证。而在这些挑战背后,最难得的是团队愿意在数据库内核这条艰难道路上做长期主义的选择。Supabase 的招聘不是短期补人,而是为接下来两三年甚至更久的底层架构建设做准备。 可以想象,下一步 Supabase 会围绕 OrioleDB 建立起一套完整的工具链,从配置、迁移、监控,到与现有 PostgreSQL 生态的无缝兼容。
对于开发者而言,这意味着终有一天,在 Supabase 上创建一个数据库开始新应用时,可以一键选择一种更先进、性能更高的存储引擎。那个时刻,使用 PostgreSQL 的成本会更低,能力上限会更高,而 Supabase 作为开源服务的价值也会被进一步放大。 在数据库世界里,真正的竞争从来没有停留在 SQL 语法和 API 接口上。存储引擎就像是操作系统的内核,它决定了系统能承受多大吞吐、多低延迟、多高并发。Supabase 为 OrioleDB 招聘,本质上是在为 Postgres 的后十年投资。这轮投资的回报,可能要到几年后才会逐渐显现,但种下一棵树最好的时间是十年前,其次是现在。
对于整个 PostgreSQL 生态,对于关注数据基础设施的开发者,这都算得上一个值得继续观察的信号。 。
