在数据库技术不断被云厂商改写的今天,PostgreSQL 的位置似乎比以往任何时候都更加牢固。作为开源数据库世界里最活跃的社区之一,PostgreSQL 拥有丰富的数据类型、成熟的扩展机制、强大的 SQL 能力和极高的可扩展性。而 Supabase 的出现,赋予了 PostgreSQL 一种全新的呈现方式:让应用开发者无需管理后端,就能获得实时数据库、身份认证、存储和 API 能力。这家因为 Y Combinator 2020 年夏季批次而进入公众视野的公司,最近在数据库内核领域释放出新的信号:它正在为 OrioleDB 招聘相关工程师。这个动作让不少人开始重新审视 PostgreSQL 存储引擎的未来。 熟悉 Supabase 的人都知道,它并不是一个简单的数据库托管服务。
Supabase 的产品几乎全部构建在 PostgreSQL 之上,从实时订阅到 Row Level Security,从自动生成 REST API 到 PostgREST,Supabase 所做的一切,都是为了让开发者更高效地使用 PostgreSQL。然而,随着用户规模和数据规模的增长,数据库本身的底层能力逐渐成为瓶颈。传统 PostgreSQL 存储引擎在一些高并发、高频更新场景下暴露出不少问题,而这正是 OrioleDB 想要改变的。 那么,OrioleDB 到底有什么特别之处?简单来说,它是为 PostgreSQL 设计的一种替代性存储引擎。与当前默认的堆式存储不同,OrioleDB 旨在解决 PostgreSQL 在写放大、可见性信息存储和 VACUUM 负担上的历史性挑战。传统的 PostgreSQL 使用堆表加索引的结构,配合 MVCC 多版本并发控制机制。
当一个事务更新一行数据时,数据库并不会真正覆盖旧数据,而是产生一个新的元组版本。旧版本需要等所有早期事务结束后才能被清理。这个清理任务由 VACUUM 机制周期性地完成。随着修改频率升高,死元组越来越多,索引也可能产生膨胀,VACUUM 需要扫描大量页面,导致性能波动和运维负担。 OrioleDB 的设计思路更接近一些商业数据库。它把旧版本数据从堆页面中剥离出来,放入独立的 undo log 中。
每次更新不再在原始表页面上留下一堆等待清理的旧元组,而是用追加的方式记录修改前的数据版本。这样一来,数据页面的稳定性能大幅提高,由于死元组引起的碎片和膨胀问题也会得到缓解。更重要的是,这样的方式减少了不必要的数据搬运,降低了写放大,提升了全系统的整体吞吐。 OrioleDB 还改进了预写日志的粒度。传统 PostgreSQL 的物理 WAL 需要记录页面级的变化,这在某些高频写入场景下会产生不小的额外开销。OrioleDB 使用更接近行级语义的日志方式,允许系统在故障恢复时更快地定位需要重做的变更,同时减少日志落盘的数据量。
对于在生产环境中运行大量实例的团队来说,这既意味着更低的存储成本,也意味着更可预期的恢复时间。 另外,OrioleDB 对事务快照部分做了优化。比如在扩展的事务 ID 管理上使用更现代的方式,减少事务环绕等问题对系统的影响。它还能以更低的开销维护索引与表之间的同步,让变化较多的热数据不容易因为旧版本堆积而出现问题。 为了实现这样的目标,OrioleDB 在数据结构上采用了一些非传统选择。其索引基于一种写优化的 B 树变体,能够将随机写入转换为更有序的写入,从而降低随机 I/O 对性能的冲击。
在高并发场景中,这种设计可以显著提升写入吞吐,同时保持查询性能的稳定。 对于普通开发者来说,存储引擎的革新带来的最直接体验是:数据库更快、更稳、更少需要人工调优。过去,一到高峰时段,PostgreSQL 的高 CPU、高 IOPS 和小型表膨胀问题就会浮现。DBA 需要反复检查 autovacuum 配置和 dead tuple 数量。如果 OrioleDB 成熟并整合进 Supabase,这些内部问题有望大幅减少。开发者可以把精力放在业务逻辑上,而不是和 VACUUM 赛跑。
Supabase 为 OrioleDB 招聘工程师,显然是希望把这种底层能力内化为平台的核心优势。从招聘岗位来看,Supabase 需要的不是普通的应用工程师,而是能够深入 PostgreSQL 源码、理解数据库编译原理、熟悉缓存管理器和事务机制的人。他们需要面对 C 语言中的复杂宏、内存管理、锁冲突和持久化日志等非常底层的问题。这种岗位的开放,说明 Supabase 并不是把 OrioleDB 当作一个实验项目,而是当成一个严肃的、需要长期投入的技术方向。 Supabase 作为 YC S20 的一员,采用的打法一直带有鲜明的生命周期特征:先用开放工具和免费额度吸引开发者,再通过服务和云产品形成商业闭环。而头部创业公司的竞争力,往往取决于对核心依赖的技术栈的掌控力。
Supabase 的核心技术栈就是 PostgreSQL,OrioleDB 则是让 PostgreSQL 在高负载下依然能保持优秀表现的钥匙。因此,招聘 OrioleDB 工程师,在商业逻辑上是完全自洽的。 从更大的视野看,Supabase 对 OrioleDB 的投入会对整个 PostgreSQL 生态带来连锁效应。首先,这给了社区一个明确信号:存储引擎并不是不能革新的领域。过去很长一段时间,大家都默认 PostgreSQL 的堆存储是唯一选择。但是随着云原生应用对低延迟、高吞吐的追求,开发者越来越需要更灵活的存储层。
OrioleDB 的存在,让 PostgreSQL 可以去适应更多不同的 workload,而不是在传统架构上不停打补丁。 同时,这场变革也会影响云数据库市场的竞争格局。如今,云计算厂商大多通过托管 PostgreSQL 的方式吸引用户。可一旦 Supabase 凭借 OrioleDB 在性能和成本上建立起独特优势,它就可以避免与云厂商进行同质化竞争。尤其是在单机数据库和分布式数据库之间,PostgreSQL 需要一个兼顾 SQL 功能和可扩展性的中间形态。OrioleDB 对存储引擎进行的精简,让这个中间形态成为现实。
相比之下,其他仍未在存储层发力的平台,可能需要重新思考自己的技术路线。 当然,任何存储引擎的成熟都需要时间。OrioleDB 虽然前景广阔,但距离被大规模生产环境接纳,还有很长的路要走。数据库最核心的要求不是功能多,而是数据不丢、长期稳定。一个存储引擎从实验室到生产环境,需要经历无数次的故障注入测试、性能基准测试、备份恢复演练和跨版本兼容测试。Supabase 为 OrioleDB 招聘岗位,可以加快这一进程,但并不能一蹴而就。
对于已经依赖 Supabase 的企业来说,选择是否切换到 OrioleDB 也需要经过慎重评估。每个团队的负载不一样,有些应用收益明显,有些则可能需要等待新的功能成熟。 从招聘角度讲,OrioleDB 相关的职位可能包括数据库内核开发、SQL 查询优化、存储层以及 SRE 等方向。这些岗位对基础能力的要求非常高。一个合格的候选人不光要熟悉 PostgreSQL 的代码,还需要有扎实的操作系统知识,理解页缓存、磁盘调度和文件系统接口。同时,也要能接受在开源社区中与全球开发者协同工作,因为 OrioleDB 不仅仅是 Supabase 的项目,也是 PostgreSQL 社区的一部分。
Supabase 需要的人,应该有耐心啃最复杂的问题,也有能力把底层细节转化为普通开发者能感知的体验提升。 更重要的是,这一轮招聘并不意味着 Supabase 要闭门造车。Supabase 一直积极参与 PostgreSQL 社区的开源协作,OrioleDB 的目标同样是回归上游、让更多用户受益。如果 OrioleDB 的代码能被合并到未来 PostgreSQL 的发行版中,或者作为扩展被广泛采用,那么整个开源世界都会因此受益。Supabase 只是率先把这条路走通的公司。通过开放岗位招募和培养一代数据库内核工程师,它也在为社区存储长期的技术资产。
展望未来,PostgreSQL 的应用边界还会继续拓展。它在 OLTP 上早已不输任何商业数据库,在 OLAP 和扩展接口上也越来越多地被用在分析、向量检索和地理空间场景。OrioleDB 的加入,给 PostgreSQL 提供了更强大的底层支撑。在 Supabase 的产品矩阵中,Realtime 需要低延迟的订阅,Storage 需要可靠的对象存储接口,Auth 需要低延迟的 Token 校验,这些都离不开数据库的高效执行。一个经过深度优化的存储引擎,能够让所有上层功能受益。 总而言之,Supabase 为 OrioleDB 招聘工程师,绝不是一个孤立的人力需求。
它是开源数据库走向深水区的一个注脚,也是一家头部创业公司选择做难而正确之事的证明。对于开发者来说,这是一个值得持续关注的方向:谁掌握了数据库存储引擎,谁就掌握了未来云原生应用性能的关键。而现在,Supabase 正在以行动告诉世界,它准备把这场硬仗打下去。 。
