Egres：单进程数千租户，Postgres生态的隔离革命？

背景与核心承诺：一个二进制替代Postgres生态？

Egres 的主页第一句话抛出了一个不太客气的问题：如果今天重新设计 Postgres，它会是什么样子？来源：egresql.io 我见过太多数据库项目把"重新设计"挂在嘴上，最后做出来还是那套 buffer pool 加 B-tree。Egres 至少在设计思路上没含糊。它只发一个二进制，却直接声称兼容 PostgreSQL wire 协议，psql 和现有驱动不用改一行代码就能连上。来源：egresql.io

这背后的关键决策是彻底换掉存储引擎。Egres 的新引擎叫 ZDB，是一个 LSM forest，不是传统的堆存储。每张表、每个索引都是独立的 LSM 树，有自己的 SSTables，一个数据库就是一片森林。数据在磁盘上不做交叉交错，扫描只碰自己表对应的文件，一个租户的树和另一个租户的树永远不会重叠。来源：egresql.io 复制走 Raft，支持从任意副本读到自己刚写的数据。分支是即时的，瞬间复制出一个新的数据库森林。整个项目开源，Apache 2.0。来源：egresql.io

我第一遍读的时候觉得这有点激进。wire 兼容意味着客户端生态白捡，但引擎重写意味着所有 Postgres 运维层的假设都要推倒重来。这个取舍是不是划算，要看后面量化指标怎么落地。

多租户架构与量化指标：数千租户，8线程，硬上限

多租户是 Egres 想解决的核心场景。它承诺单个进程承载数千个租户，每个租户都有资源计量和封顶。来源：egresql.io 实现方式不是靠容器，而是靠自己的协程系统。每个查询是一个 fiber，由 Egres 的调度器在进程的多个线程之间调度，不交给操作系统。来源：egresql.io

调度器每秒统计每个租户消耗的 CPU ticks、内存和磁盘 IOPS。一旦某个租户用完了它的配额，调度器直接把这个租户"park"起来，同一批线程上的其他租户继续跑。来源：egresql.io 官网给出的示例配置是一个 8 线程进程扛数千租户，没有 VM、没有容器、没有 sidecar。来源：egresql.io 这组数字很具体。传统多租户方案是每个租户一个 VM，每个 VM 里塞一个 kernel 加一个数据库进程，租户要为 kernel、内存下限和启动时间付固定成本。来源：egresql.io

这个对比很刺眼。VM 方案的隔离逻辑是把责任外包给 hypervisor，数据库自己根本分不清查询属于谁。Egres 的逻辑是数据库自己知道，所以自己执行硬上限，不让 hypervisor 参与。来源：egresql.io 我不确定 8 线程这个数字是不是有硬性物理上限，但官网明确把它作为示例写出来，说明至少内部测试跑通过这个配置。

与传统Postgres生态的对比：VM隔离 vs 应用内调度

传统 Postgres 的进程模型是每连接一个进程，这让多租户隔离通常只能靠外部的 VM 或容器。来源：PostgreSQL 官方文档 Egres 直接把这个假设拆了。数据库知道每个查询属于哪个租户，在进程内执行资源上限，不需要 hypervisor 在中间转一道。来源：egresql.io

这个范式转移的代价是整套 Postgres 运维工具都要重新审视。Egres 官网页面上直接点名了这些工具：PgBouncer、pg_repack、Patroni、pg_dump、VACUUM xid wraparound、pageservers，这些在传统 Postgres 里几乎是运维标配。来源：egresql.io 在 Egres 的架构里，它们要么被原生功能替代，要么需要彻底重新适配。

HN 上的讨论目前还不太热，帖子只有 1 分、0 条评论。来源：HN 但项目本身的立意很清楚。传统方式解决 noisy neighbor 靠的是过度配置，多给资源，用成本换隔离。Egres 的反直觉之处在于，单进程就能实现硬隔离，资源利用率反而更高。来源：egresql.io 这个判断我倾向于相信，前提是调度器确实能做到精确计量。

潜在挑战与开放问题

最需要验证的是生态兼容性。wire 协议兼容不等于整个生态兼容。扩展、存储过程、复制工具这些依赖 Postgres 内部行为的组件，Egres 没有给出完整的适配清单。Patroni 这类工具依赖的复制机制在 Raft 架构下是不是还能原样工作，我持保留态度。来源：egresql.io

单进程故障域是另一个绕不开的问题。数千个租户共享一个进程，进程崩溃意味着所有租户同时不可用。VM 隔离的租户至少不会互相传染，Egres 的模型把这种风险集中了。官网没有回避这一点，但没有给出崩溃恢复的详细方案。来源：egresql.io

调度器公平性也有细节要抠。CPU ticks 的计量方式写得比较清楚，但内存和 IOPS 的计量粒度没有展开。内存是进程级还是租户级？IOPS 算的是读还是写？这些不明确，硬上限的"硬"字就要打个折扣。来源：egresql.io 还有 ZDB 自身的成熟度。LSM 引擎的 compaction 和 WAL 处理，加上和 Raft 的集成，是存储系统里最难做对的部分。来源：egresql.io

最后是商业模式的悬而未决。Apache 2.0 允许企业自由使用，但商业支持、企业级特性怎么走，项目方还没给路线图。我不确定这是不是故意的克制，但开源协议之下，运维和调优责任会落在使用者自己身上。来源：egresql.io 目前我只能说，Egres 的技术方向值得跟踪，能不能替代 Postgres 生态里的某个角落实用，要等它跑过真实的多租户负载再下结论。

原文：

Egresql · 来源：Hacker News

作者：itfan123 值班编辑 · 发布于 2026年11月1日