云数据库的竞争,正在从产品功能、开源协议和生态渠道,悄悄延伸到最底层、最难被取代的存储引擎。作为Y Combinator 2020年夏季营走出来的代表性项目,Supabase从第一天起就选择了PostgreSQL作为根基,将Firebase式的开发体验与开源精神结合在一起。如今,这家公司开始围绕OrioleDB进行招聘,释放出一个不可忽视的信号:它不满足于做一层封装,而是要深入数据库内核,真正解决PostgreSQL在存储与性能端面临的长期问题。 Supabase的成长轨迹,几乎就是开发者基础设施向更底层演进的缩影。最初,它给开发者的印象是一个可以快速接入的BaaS平台,提供数据库、认证、行级安全、实时订阅、对象存储和边缘函数。但它最核心的资产,从来都不是这些API本身,而是背后那套PostgreSQL数据库。
PostgreSQL拥有强大的SQL能力、复杂查询规划器、事务机制、扩展生态,以及极高的可靠性。Supabase的价值主张,本质上是围绕PostgreSQL建立一条完整的开发流水线,让应用团队不必从零维护数据库。可这样一来,数据库底层的性能上限,就直接决定了整个平台的上限。 PostgreSQL默认的存储引擎建立在堆表结构之上,配合多版本并发控制来保证读写不互相阻塞。这个设计经过了几十年大规模验证,成熟度非常高,但它并不是全无代价。传统堆表在更新一行记录时,并不会马上覆写旧数据,而是先生成一个新的行版本,然后通过可见性机制让对应事务决定该看哪个版本。
行版本在经历提交、回滚、清理和回收之后,才有一部分可以被系统复用。问题是,高并发写入场景下,死元组的产生速度常常超过VACUUM进程的回收速度。于是表膨胀、索引膨胀、存储放大和写放大接踵而来,数据库越来越慢,运维团队只能一次次调高清理频率,协调停机窗口,甚至用临时表重建数据。 OrioleDB要解决的,正是这些由传统存储格式带来的痛点。它不是一个简单的性能补丁,也不是对现有存储引擎的小修小补,而是重新设计了一种面向PostgreSQL的存储方案。它的思路是尽量在存储引擎内部消解旧版本带来的碎片化风险,用更紧凑的页结构、更智能的版本链机制,以及更细粒度的行级锁管理,来减少无意义的拷贝和写放大。
在写入高频、更新频繁的业务中,这种方式可以显著降低表的膨胀速度,让数据库在长时间运行后依然保持相对稳定的查询计划与访问路径。 更值得注意的是,OrioleDB并没有选择分叉PostgreSQL。它利用PostgreSQL提供的表访问方法机制,以扩展的方式来实现新的存储引擎。这意味着,应用可以在现有PostgreSQL环境中使用OrioleDB,而不必牺牲SQL兼容性,也不必抛弃整个Postgres生态。很多PostgreSQL的特性仍然保留,比如索引、触发器、外键、复制,以及大量扩展模块。对于开发者来说,这种设计意味着可以用更低的迁移成本来享受到存储层升级带来的好处。
对于PostgreSQL社区来说,这也是一种更健康的演进方式:并不需要重写整个数据库,而是通过标准化接口,让存储层能够出现更多创新。 Supabase选择招聘OrioleDB相关的工程人才,首先是因为它本身就是一个重度PostgreSQL使用者。作为一个多租户平台,Supabase的每一个底层数据库实例都承载着大量应用请求。有的应用做实时消息推送,有的应用做IoT数据采集,有的应用做订单处理和后台管理。这些应用的写入模式各不相同,但对数据库的要求高度一致:希望延迟足够稳定,资源利用率足够高,运维负担足够轻。传统存储引擎在这种场景下的表现,往往受到许多因素干扰。
比如某个大事务长时间打开,使得旧版本无法及时清理,进而影响整个实例的可见性扫描;又比如某个表在频繁更新后出现严重索引膨胀,导致查询优化器选择了不理想的执行计划。OrioleDB从存储引擎层面减少这类波动,实际上就是为上层可靠性提供了更好的底座。 另一个原因在于,Supabase的很多核心能力,都建立在数据库的强一致性之上。实时订阅需要监听数据库逻辑变更,认证系统需要维护用户会话和权限,行级安全策略需要在查询执行时被高效应用。如果存储引擎需要频繁清理、在大量读写下产生锁竞争,那么这些看起来非常优雅的能力,在高并发下就很容易退化成性能瓶颈。OrioleDB的锁管理采用更接近行级粒度、更轻量的事务状态维护方式,让高并发场景下的连接与事务调度可以有更大的伸缩空间。
对于一个面向开发者的数据库平台来说,这种可预测性比盲目追求极限单机性能更有价值。 从技术人才角度来说,数据库存储引擎开发是最难招、也最难培养的岗位之一。大多数应用层工程师并不需要了解WAL和LSN,也不一定理解缓冲区淘汰算法、页面回收机制和崩溃恢复协议。但要把OrioleDB真正打磨到生产级,恰恰需要这些经验。Supabase的招聘并非普通意义上的团队扩充,而是向市场传递了一个信息:它愿意投资那些需要长期才能见效的基础设施。存储引擎不会因为几轮市场营销就迅速爆发,它需要反复进行故障注入测试、性能回归测试、极端场景测试,需要有人耐心地阅读源码、编写测试工具、分析IO路径、优化内存布局。
这样的人才,不只在Supabase内部稀缺,在整个数据库行业都是被争抢的资产。 对于PostgreSQL生态而言,OrioleDB进入视野的时机也很关键。过去几年,PostgreSQL在云数据库市场获得了巨大成功,越来越多的公司和云厂商提供兼容Postgres的托管数据库服务。但与此同时,针对默认存储引擎的批评也一直存在。有人说VACUUM太复杂,有人说写放大太厉害,有人说在大规模更新场景下需要更多人工调优。OrioleDB的出现,让社区看到了一个解决这些问题的可能性:它仍然是一套PostgreSQL,仍然兼容SQL,但在存储格式上更接近现代OLTP数据库的实践。
如果OrioleDB能够在真实的云环境中稳定运行,它就有可能成为PostgreSQL生态中最重要的一块实验田。 当然,新存储引擎的成熟远不止写代码那么简单。OrioleDB还需要面对很多现实问题:如何与现有的备份工具协同工作,如何在逻辑复制和物理复制环境下保持一致,如何迁移默认堆表中的数据,如何监控undo log的增长,如何对表进行扩容和重组,如何处理Paralle Query和分区表的兼容性,如何在异常宕机之后快速恢复。这些问题看起来不如日TPS之类的指标吸引眼球,却决定了存储引擎能否真正进入生产系统。Supabase作为一家以数据库为根基的云公司,有义务也有能力去做这些吃力不讨好的工作。 从商业角度看,云数据库的竞争已经进入深水区。
AWS有Aurora,Google有Cloud Spanner,Azure有Cosmos DB。这些产品虽然技术路线各不相同,但都在强调一件事:只有掌握存储层的核心能力,才能提供高弹性、高性能和高可用的数据库服务。作为一家创业公司,Supabase很难在所有维度上与云巨头正面竞争,但它可以通过PostgreSQL这个拥有巨大开发者的生态,走出一条不同的路。OrioleDB可能成为Supabase的差异化技术底座,让PostgreSQL在默认状态下就拥有更好的IO表现,甚至减少企业自建数据库时最常见的运维痛点。如果这条路走通,Supabase就不再只是一个Firebase替代品,而是会成为PostgreSQL云化的新范本。 对普通应用开发者来说,存储引擎听起来再遥远不过。
但人们很快就发现,应用的速度往往取决于数据库的延迟,数据库的稳定性往往取决于存储引擎的行为。当数据库因为膨胀而变慢,开发者不得不使用分页、缓存、读写分离等外挂方案来延缓问题。而这些方案又会让业务逻辑变得更复杂,让团队陷入性能优化的无底洞。如果OrioleDB能够让一个普通的PostgreSQL实例在长时间高负载运行后依然维持较好的性能,那么开发者就不需要一开始就设计复杂的架构,也不需要花费大量时间调优VACUUM参数。这种化繁为简的能力,才是OrioleDB对于普通开发者的最大价值。 Supabase的这次招聘策略,也在某种程度上反映了开源数据库商业化的趋势:把最难的底层问题交给专门研究它的人。
传统开源项目往往依靠志愿者和公司内部软件工程师的双重驱动,但存储引擎这种工作,需要足够的资金支持、长期规划和技术深度。Supabase通过将自己定位成OrioleDB的推动方,实际上承担起了为开源社区搭建一个可持续发展环境的责任。它不只是雇佣了一批会写C或Rust的工程师,更是邀请整个社区参与一场关于PostgreSQL存储层如何进化的讨论。 从更长远的视角来看,数据库领域的每一次突破,最终都会回到几个朴素的问题:一条记录在磁盘上如何存在,一个事务如何知道哪个版本对它是可见的,一次崩溃之后数据还能不能重新变成一致的状态。这些问题的答案,决定了数据库的极限。OrioleDB尝试给出新的答案:是否可以让热数据保留在更近的地方,让陈旧版本进入更高效的撤销日志,让行级锁不再成为高并发瓶颈,让空间的回收不再需要全面扫描。
这些设计如果最终被证明可靠,那它带来的影响将远超Supabase这一家公司。 当然,也不能回避风险。数据库存储引擎是容错要求最高的软件之一。即使有了极其合理的理论设计,在真实环境中依然可能遇到ABI不兼容、扩展接口变化、第三方工具不兼容、异常恢复路径覆盖不足等问题。OrioleDB要想普及,还需要建立完整的测试体系,包括模糊测试、随机化并发测试、持续故障注入、性能基准、长期稳定性测试。Supabase的招聘,不只是为了开发新功能,也需要组建一支能够持续进行质量验证和可靠性加固的团队。
只有这样,OrioleDB才有机会从实验阶段走向生产环境。 在云基础设施越来越便宜的今天,数据库的价值正在从存放数据这一基本功能,转向对数据进行快速处理与智能访问的能力。PostgreSQL能够成为全球最受欢迎的开源关系型数据库之一,靠的正是它强大的扩展性和忠实于标准的设计哲学。Supabase选择在这个时间点加码OrioleDB,实际上是在为PostgreSQL打开一扇新的大门。未来,也许会有更多存储引擎出现在PostgreSQL生态中,也许会出现更多像表访问方法这样的抽象层,让数据库能够适应不同类型的负载。而OrioleDB就是那条通向未来的起跑线。
真正重要的,往往不是某一次产品迭代所能展示的新UI,也不是某一场发布会上的基准数字。而是有一群人,愿意在一个被公认为极难攻克的领域里,投入大量时间和脑力,让一个开源数据库在底层变得更加强大。Supabase围绕OrioleDB的招聘,正是这样一次投入。它让外界看到,PostgreSQL的价值不止于功能齐全和生态丰富,更在于它拥有持续进化的能力。只要这种能力仍然存在,PostgreSQL就不会沦为过去时代的遗产,而会成为未来云数据库体系中不可替代的中坚力量。 当开发者们在新闻中看到Supabase招聘OrioleDB工程师时,他们看到的也许不是一个职位,而是一个关于数据库的想象:不用成天为表膨胀焦虑,不用在深夜手动运行VACUUM,不需要在项目初期就为数据库架构搭建出复杂的索引策略。
那是一个更安静、更稳定、更可预测的数据库世界。而Supabase和OrioleDB团队,正是迈向那个世界的探路人。这不是一次普通的工作人员扩招,而是一场关于PostgreSQL未来的长期押注。 未来几年,数据库市场的关键词不会只是云原生成红海、Serverless或者AI驱动的查询优化,而会更具体地指向存储引擎本身。谁能在保留SQL兼容性和事务能力的条件下,让磁盘更快、空间更省、并发更稳,谁就握住了下一代开发者基础设施的入口。Supabase先于很多人意识到了这一点,并用一场围绕着OrioleDB的招聘行动,把这种意识写进了自己的企业战略里。
无论这条路最终走得多远,它都已经给PostgreSQL社区带来了一种新的可能:一个开源数据库,并不需要永远固守几十年前的设计,它完全可以用一种渐进的方式,在现代硬件和现代负载之间,找到自己的新位置。 。
