2020年,Supabase以Y Combinator第20期学员身份亮相,当时外界最直接的评价是"Firebase的开源替代品"。然而今天,Supabase早已在实时数据库、身份认证、对象存储和边缘函数等多个领域建立起了自己的产品矩阵。更难得的是,这家公司始终没有偏离其最核心的信念:PostgreSQL可以成为整个互联网应用的后端。现在,Supabase正在为OrioleDB招聘工程师。这个动作释放出一个清晰信号:它要在数据库最底层,也就是存储引擎层面,掀起一场真正的变革。 对于大多数开发者和数据库管理员来说,PostgreSQL已经足够强大。
它的堆存储、MVCC机制和丰富的扩展生态帮助无数企业构建了关键应用。但任何数据库都有边界。传统PostgreSQL的堆表在写入密集型场景下会产生大量死元组。每一次更新都不是原地修改,而是生成一个新版本,然后通过VACUUM在后端不断清理。数据量小的时候,这没有问题;数据量大了,高并发更新频繁了,表膨胀、索引膨胀和写放大问题就会成倍放大。很多团队只能不断调整autovacuum参数,增加磁盘容量,甚至定期做重建。
这些运维负担本质上是因为存储引擎本身存在结构性的瓶颈。 OrioleDB的出现,正是为了改变这个局面。它不是一个独立的数据库,而是一个基于PostgreSQL的存储引擎扩展。它最初由Oriole Data团队设计,目的就是从底层重写PostgreSQL对数据页、事务日志和索引的处理方式。比如,OrioleDB用撤销日志来管理多版本并发控制,而不是依赖堆表里的死元组。这样做的好处是显而易见的:旧版本可以由事务系统统一回收,而不是让垃圾记录一直留在数据页中,最终导致表膨胀。
与此同时,OrioleDB在WAL架构上做了更为精细的设计,通过细粒度的日志记录减少磁盘写入放大。对于运行在高性能服务器上的PostgreSQL实例来说,这些变化能带来直接的性能提升。 除了减少膨胀和写放大,OrioleDB还针对现代多核处理器进行了优化。传统PostgreSQL在非常高的并发工作负载下,锁竞争和Buffer Pool访问会成为瓶颈。OrioleDB采用无锁或更细粒度锁定的内存结构,使得会话能够以近线性方式扩展。这意味着,如果应用有多个CPU核心,数据库可以利用这些核心处理更多事务。
对于需要低延迟、高吞吐的实时应用,这可能是比简单更换硬件更本质的解决路径。 Supabase选择在这个时间点投入OrioleDB,绝不仅仅是为了实现一两个性能指标。作为一家开源公司,Supabase的核心策略是在PostgreSQL之上构建体验极佳的应用平台,同时将底层的能力反哺给社区。过去几年,Supabase推出了PostgREST、Realtime、pg_graphql等工具,这些工具让开发者可以用更现代的方式使用Postgres。但它们大多是在SQL层或API层做文章。OrioleDB不同,它是一个真正意义上的数据库内核项目,需要接触事务管理、缓冲池、索引、预写日志这些最底层的模块。
愿意在这样一个项目上招聘,说明Supabase已经把自己的技术护城河挖到了存储引擎这一层。 从产品角度看,OrioleDB与Supabase的路线图高度吻合。Supabase的用户是大量互联网应用开发者,他们的应用往往需要承受不可预测的流量波动。数据库能否在膨胀和写放大发生之前就主动规避问题,直接影响应用的可用性和成本。假如OrioleDB在Supabase的托管平台上成为可选的存储引擎,用户可以享受更稳定的写入性能、更小的存储占用,以及更少的人工干预。对于实时数据、物联网设备、消息队列这类场景,这种优势非常有吸引力。
当然,把OrioleDB带到生产环境并不是一件容易的事。数据库存储引擎是系统软件中最难做的领域之一,任何细小的错误都可能导致数据损坏,而数据损坏意味着业务系统彻底不可用。OrioleDB目前仍然是Postgres生态中一个兼具潜力和挑战的扩展。它需要经历大规模测试、崩溃恢复验证、长时间运行稳定性测试,以及各种文件系统和硬件环境下兼容性验证。Supabase招聘工程师,说明它愿意承担这部分工作,也说明它有足够的资本和耐心来等待一个数据库内核走向成熟。 从招聘的角度来看,这是一个极其难得的职业机会。
在绝大多数公司,数据库工程师可能只是在管理运维层面做一些脚本,或者在一些现成引擎之上写业务代码。但在Supabase的OrioleDB团队,工程师要面对的是PostgreSQL源代码中最核心的部分。新成员会参与锁定协议、页淘汰策略、WAL格式、MVCC快照等课题。这些话题几乎不可能通过短期博客学习掌握,而是需要大量实践和系统思考。对于想成为真正的数据库内核开发者,这样的岗位就像是进入一个高强度的研究生实验室,同时还得确保代码最终能服务全球范围的用户。 这样的工作当然不轻松。
你需要对C语言有非常扎实的掌握,因为PostgreSQL和OrioleDB的底层都离不开C。你需要理解操作系统与磁盘之间如何交互,需要了解现代CPU的缓存与指令流水线,还要具备调试复杂崩溃问题的能力。除此之外,维护过开源数据库项目或者参与过PostgreSQL贡献会是极大的加分项。Supabase不会因为你没有数据库内核经验就把门关上,但你需要证明自己拥有深入底层系统后能够快速学习的能力。面试中很可能出现真实的PostgreSQL源代码问题,考查候选人如何分析问题、定位瓶颈,并且提出自己的修改思路。 Supabase的企业文化也为这种高度工程化的工作提供了支撑。
作为一家全远程公司,Supabase一直强调异步沟通、深度工作和文档文化。数据库工程师往往可以在自己的时区自由地工作,但需要在设计文档中留下清晰的决策记录。因为一旦某个设计被合并到OrioleDB中,全球世界各地的开发者和企业都会依赖这些代码。同样,Supabase重视开源的可信度。OrioleDB的代码是公开的,团队的每个PR、每个issue都透明可见,这种模式能够吸引更多志同道合的贡献者,也会让招聘决策变得更透明。 事实上,Supabase的这一招聘决定也反映出整个云计算行业正在发生深刻变化。
过去十年,云厂商的竞争焦点一直是托管数据库的易用性,而在内核层面真正有建树的公司并不多。随着数据规模持续增长,应用层可以做的优化越来越有限,很多问题只有回到数据库引擎才能根治。从Snowflake到Databricks,从Neon到Supabase,新一代数据库公司不再满足于给PostgreSQL包一层壳,而是愿意在事务系统、存储层和恢复机制上做真正的创新。OrioleDB是Postgres生态中少数有潜力改变游戏规则的项目之一。 可以想象,如果OrioleDB最终成熟并且成为PostgreSQL的新默认选项,整个Postgres生态都将受益。开发者不再需要因为更新频繁而担心表膨胀;云数据库用户可以节省大量存储成本;基础设施团队也不再需要花时间处理复杂的事情。
更重要的是,PostgreSQL的开发者社区会获得新的思想财富,包括如何重新设计MVCC、如何用顺序日志替代页级WAL、如何让数据库更好地利用多核硬件。这些思想会渗透到其他数据库系统中,最终推动整个行业向前走。 对于正在考虑申请这份工作的开发者,我想说的是,如果你曾经在晚上阅读PostgreSQL源码,曾经好奇数据库崩溃时到底发生了什么,或者又对自己说"我也想像参与一个真正底层的项目",那么Supabase的OrioleDB团队可能就是你正在寻找的地方。这里没有花哨的市场宣传,没有堆叠创业圈套话,只有一群人与世界上最复杂的软件之一战斗。你能拿出的证明,不是简历上的头衔,而是你对系统深层机制的敏感度和勇气。 当然,加入这样一个团队也意味着要承担远高于普通应用开发的压力。
数据库内核一旦释放错误,影响可能直接落在用户的身上。但这恰恰也是这份工作最迷人的地方。你在若干年后回望,会发现某个线上系统的稳定运行,正是源自你写的某段代码。这种长期主义,在今日以数据和速度衡量一切的世界里,显得格外珍贵。 Supabase与OrioleDB之间的故事,本质上是一段关于产品哲学与技术信仰的旅程。Supabase相信PostgreSQL有能力承载现代互联网的绝大多数应用,而OrioleDB则代表着这条路上最硬核的一站。
当越来越多优秀工程师被这种信仰吸引,Postgres就不再只是那个老牌数据库,而会成为一个充满活力的开放生态。招聘只是一个开始,更多关于存储引擎的革新,都在来的路上。 。
