Supabase 最近释放出一个明确的信号:它不想只是用 Postgres 做点表层服务,而是要深入数据库内核,为未来的产品打地基。这家从 Y Combinator S20 走出来的公司,正在为 OrioleDB 招聘工程师。消息一出,很多数据库圈的人都在讨论:为什么是 OrioleDB?为什么在这个时候?这个动作对 Supabase、对 Postgres 生态,乃至对普通开发者到底意味着什么? 要理解这一切,得先从 Supabase 的底色说起。Supabase 是云原生时代最受关注的开发者工具公司之一,它提供的是一套基于 PostgreSQL 的即开即用后端服务,包括认证、实时订阅、对象存储、边缘函数和数据库。过去几年,它借着"开源 Firebase 替代品"的定位迅速崛起,吸引了很多前端开发者、独立开发者和中小企业团队。但 Supabase 真正的护城河,从来不是某个具体功能,而是它站在了 PostgreSQL 的肩膀上。
这个拥有数十年积累的关系型数据库,有着稳定的事务处理能力、强大的扩展生态和忠实的核心开发者社区。不过,PostgreSQL 也并非完美。它传统的堆存储模型在长时间、高并发的写入场景下,会出现索引膨胀、表膨胀和垃圾元组堆积的问题。这个问题由来已久,而 OrioleDB,就是近些年来 Postgres 社区为解决它而出现的最有野心的方案之一。 传统 PostgreSQL 的存储引擎之所以在更新频繁的工作负载下表现不佳,核心在于多版本并发控制机制。当一个事务更新一行数据时,旧版本不会立刻消失,而是会留存在数据页中,等待 VACUUM 进程在之后某个时刻清理。
如果更新非常频繁,旧版本会不断累积,造成表和索引的膨胀。统计信息会失真,查询计划可能走错,索引扫描的效率变差,最终整个数据库的性能都会受到影响。对于需要处理大量写入的 SaaS 应用、金融系统、物联网场景来说,这种问题几乎是不可避免的。管理员要么选择定时做 VACUUM,要么用工具重建表,要么增加硬件资源。这些办法治标不治本。而 OrioleDB 的设计理念,就是要从存储层本身的架构上去解决这一类问题。
OrioleDB 是一个全新的 PostgreSQL 存储引擎,它最重要的特点之一,是使用 undo log 来代替完全依赖死元组的旧版本管理方式。在传统堆表中,每个版本都会在数据页里留下痕迹,而 OrioleDB 把旧版本信息放到独立的 undo 区域,表主体不再需要承担大量垃圾数据的清理压力。这意味着数据库可以在更高的并发写入下保持更稳定的性能,同时大大降低 VACUUM 的频率。除此之外,OrioleDB 在行级锁、缓冲池、页组织和 WAL 日志方面都做了针对现代硬件的优化。它的目标是让 PostgreSQL 在 NVMe、Optane 等新一代存储介质上表现出更低的延迟和更高的吞吐量。更关键的是,OrioleDB 并不仅仅是一个理论产品,它已经通过 PostgreSQL 的扩展接口实现了对普通用户来说足够透明的接入方式。
开发者可以在建表时指定使用 OrioleDB,而不必对 PostgreSQL 内核做复杂的改造,这给了很多希望用 Postgres 应对更大规模业务的人一个非常实际的选择。 Supabase 选择在这个时间点加码 OrioleDB,背后有着清晰的战略逻辑。首先,Supabase 是一个平台公司,它的核心价值建立在 Postgres 生态的稳定性和可扩展性之上。如果 OrioleDB 可以显著降低云数据库的存储膨胀,减少运维复杂度,提升写密集型工作负载的性能,那么 Supabase 在基础设施层面就能获得真实的竞争力。其次,今天的开发者对数据库的要求越来越高,已经不再满足于"能跑 SQL"或者"支持事务"。大家关心的是,一个数据库在持续增长的大数据量下,是否还能保持可预测的延迟?在业务快速增长时,是否需要停机扩容?在频繁插入更新时,是否需要人工介入清理?这些问题的答案,很多都藏在存储引擎的深处。
Supabase 通过招聘 OrioleDB 相关的工程师,就是在发出一个确认:它有意愿、也有能力去掌握这些底层技术,而不是继续把关键的数据库能力外包给系统自带的默认实现。 这个招聘动作所体现出的技术方向,对整个 PostgreSQL 社区也有深远影响。长期以来,PostgreSQL 的存储引擎扩展能力虽然被写进设计中,但真正愿意去深入开发存储引擎的团队少之又少。原因很简单,存储引擎不仅是代码问题,更是事务模型、恢复机制、锁管理、索引组织、并发控制、内存管理等多个模块交织在一起的复杂体系。就算团队拥有丰富的数据库内核经验,也需要投入大量时间才能把一个新引擎打磨到生产级。OrioleDB 背后的团队已经在这个方向上走了很远,现在如果 Supabase 能以商业化公司的方式为它提供持续的人力、资金和产品场景,那么 OrioleDB 就有机会从一个较前沿的实验性项目,成长为真正可依赖的生产级存储引擎。
这对于那些希望在不离开 Postgres 的前提下获得更高性能的开发者来说,显然是一个巨大的利好。 从商业角度看,Supabase 做这件事的时机也非常耐人寻味。云计算发展到今天,数据库已经是竞争最为激烈的基础软件赛道之一。每一家云厂商都有自己的托管数据库,甚至很多公司在尝试用新的技术栈挑战 Postgres 的统治地位。但 Supabase 没有选择另起炉灶,而是选择把宝押在 Postgres 生态上,并且主动去推动生态底层的进化。这是一种聪明的策略,因为 Postgres 的兼容性和可迁移性本身就有极大的网络效应。
开发者在 Supabase 上写下的每一行 SQL、每一个数据模型,本质上都是 Postgres 生态的一部分。如果 OrioleDB 能够在 Supabase 平台内提供更优秀的能力,那这些能力同样可以复用到其他基于 Postgres 的工具和数据库服务中。这样的开放生态,才是 Supabase 最强大的壁垒。 对于普通开发者来说,Supabase 招聘 OrioleDB 工程师这件事可能看起来很遥远,但它带来的影响会和每一个人相关。想象一下,当你正在构建的产品用户规模快速增长,数据库写入压力越来越大,你不再需要急着去分库分表,不需要换一个与 Postgres 兼容性存疑的替代品,也不需要为了一条已经堆积了千万垃圾版本的数据表而焦虑。你只需要把存储引擎切换到 OrioleDB,或者等待平台自动完成底层的优化,就能让数据库继续平稳运行。
这听起来可能有些理想化,但正是 OrioleDB 所追求的方向。更低的存储膨胀、更稳定的锁行为、更高效的并发控制,这些词听起来像是数据库内核专家才会研究的术语,但它们的最终效果,会是普通开发者写出的应用加载更快、响应更稳定、维护成本更低。 当然,存储引擎的替换不会是一件轻而易举的事。PostgreSQL 的生态系统中,还有许多底层组件与存储引擎的交互需要仔细验证。比如逻辑复制、物理复制、备份恢复、扩展插件、全局临时表、外部表、DDL 重建等,这些功能的健壮性都需要新引擎在真实的分布式场景中去证明。OrioleDB 虽然已经取得了很多进展,但它仍然需要更多来自社区和企业用户的反馈,需要在不同场景下的压力测试、故障注入和性能调优。
而 Supabase 的加入,能够为它提供一个极其宝贵的练习场。Supabase 平台上有大量真实的生产流量,如果 OrioleDB 能够在这样一个多租户、全球分布式的环境中稳定运行,它就会迅速积累起足够的可信度,进而被更广泛地接受和采用。 从人才市场的角度来看,Supabase 的这次招聘也反映了当下数据库行业对底层技术人才的需求正在升温。过去很多高级工程师更愿意去研究 AIGC、推荐系统或者大规模分布式框架,参与数据库内核开发的人才相对有限。但数据库是每一个应用都离不开的基础设施,尤其在开源数据库不断吞噬传统商业数据库市场份额的今天,深耕数据库内核的开发者反而拥有更长期的价值。Supabase 为 OrioleDB 招聘,意味着它可以给候选人提供从操作系统、网络、存储到 SQL 解析执行这样一个完整的数据库工程栈的挑战。
这样的机会在市面上并不常见,因为它既需要你理解理论,又要你能沉浸在 C 语言和复杂并发编程中,还要有足够的工程素养去维护一个面向海量用户的数据库产品。对于享受底层技术的开发者来说,这几乎是一个理想型的团队角色。 再进一步看,Supabase 对 OrioleDB 的投入,也可能引发其他 Postgres 生态中的公司跟进。PostgreSQL 的存储引擎接口一直存在,但过去大多数贡献者关注的是优化器、执行器、分区表、索引类型等外围功能。真正愿意在存储引擎层面做基础创新的项目很少。如果 OrioleDB 被证明有效,后续可能会有更多开发者或商业公司投入到 Postgres 的另一种存储形态中,比如列存储、时序专用存储、文档优先存储等。
这样的多样化,最终会让 Postgres 生态变得更加丰富,也能让这个已经三十多岁的数据库,继续在新时代保持年轻的活力。 还有一点值得注意,Supabase 是一家开源商业化公司,它非常清楚社区信任的重要性。OrioleDB 本身是开源项目,Supabase 不可能把它的代码锁进私有产品里,也无法通过闭源的方式形成垄断。相反,只有把 OrioleDB 真正做好、做稳定、做通用,让所有 Postgres 用户都受益,Supabase 的商业价值才会随之提升。这是一种非常顺畅的价值闭环:工程师为开源存储引擎贡献代码,存储引擎提升 Postgres 能力,Postgres 能力反哺 Supabase 平台,平台再把成果分享给所有开发者。每一个环节都在创造增量,而增量最终会转化为生态的深度和粘性。
从更实际的角度看,Supabase 如果真的能通过 OrioleDB 改变 Postgres 在写入负载下的表现,它实际上就打通了一条从应用层到底层存储的全链路优化路径。在这个路径中,Supabase 可以更好地理解每个数据库表的使用模式,可以更智能地管理数据生命周期,可以在后台自动完成索引推荐、存储压缩、分区清理等繁琐工作。最终交付给开发者的,就不再只是一个数据库管理面板,而是一个懂业务、懂数据、能自我调优的数据平台。这种体验正是下一代开发者工具的趋势。开发者不需要也不需要关心垃圾元组是怎么产生的,不需要关心 WAL 日志应该如何配置,只需要把注意力放在业务逻辑上。而那些最难的数据库问题,会被 Supabase 和在它身后支持它的社区解决。
所以,Supabase 为 OrioleDB 招聘,绝不仅仅是一个公司招聘新闻,它是开源数据库发展史上的一个重要注脚。它标志着拥有成熟产品线的云原生平台,正在从追求功能堆叠转向追求底层技术创新。它也标志着 Postgres 这个老牌数据库,在面对云原生、AI 和实时计算等新趋势时,正在以自己的方式完成进化。对于开发者来说,这是一件值得长期关注的事情。因为今天的存储引擎,很可能就是明天大家使用的默认数据基础设施。而我们能看到这个演进从哪里开始,是现阶段参与技术社区最有意思的地方。
未来几年,Postgres 会不会因为 OrioleDB 而迈上一个新台阶,也许答案就在 Supabase 接下来的招聘和产品路线图中。 。
