Multigres：Vitess 之父在 Supabase 给 Postgres 造的集群层
阅读时间: 大约 9 分钟
Multigres：Vitess 之父在 Supabase 给 Postgres 造的集群层
MySQL 生态有 Vitess 解决水平扩展，Postgres 生态长期缺一个「对等物」。2025 年 6 月 10 日，Supabase 官方博客宣布：Vitess 联合创始人 Sugu（Sugu 离开其商业化公司 PlanetScale 后）加入 Supabase，主导构建 Multigres——「Vitess for Postgres」。「Koala 聊开源」点评说，这既体现了 Postgres 社区的热度，也意味着 Postgres 终于有人要系统性地补上分片这块短板。本文基于 Supabase 官方公告，拆解 Multigres 是什么、要走多远，以及它现在到底交付了什么。
一、背景：MySQL 有 Vitess，Postgres 缺什么
Vitess 最早在 YouTube 为扩展 MySQL 而生，后来成为 CNCF 毕业项目，为 MySQL 提供了：分片（Sharding）、连接池（Connection pooling）、查询路由（Query routing）、韧性与故障恢复（Resiliency/failover）、以及面向 Kubernetes 的云原生编排。它让 MySQL 能像云原生分布式数据库一样被运维和扩展。
但 Vitess 只支持 MySQL，不支持 Postgres。Postgres 虽然功能强大、社区火热，在「自动分片 + 连接池 + 查询路由 + K8s 编排」这条系统性扩展路线上，一直缺少一个由同一支团队、按同一种工程哲学做出来的方案。Multigres 要补的正是这个空位。
二、是什么：位于 Postgres 前面的新代理
官方定义：Multigres 是一个位于你 Postgres 数据库前面的新代理（proxy），与 Vitess 目标相同，但专注 Postgres 生态。它的终极目标是规模化（scale）——正如路线图所示，一个 MG 代理层在不同阶段后面挂着不同数量的 PG 实例：
- 单机（Single Node，GB 级）：MG 后面一个 PG；
- 高可用（High Availability，TB 级）：MG 后面两个 PG；
- 分片（Sharded，PB 级）：MG 后面挂多个 PG，做水平分片。
三、技术路线：渐进式上车，兼容性第一
官方反复强调两个原则：
- 渐进式 on-ramp（ gradual on-ramp）：开发者不必一开始就背上分片的复杂度。入门时先用它做简单的连接池；业务长大、需要可靠性时升级到高可用；真正进入 PB 级数据量时再走到分片。也就是说，同一个代理、同一套心智模型，覆盖从单机到分片的全过程。
- 兼容性优先：分片不可避免带来权衡，而 Postgres 社区「几乎把兼容性看得高于一切」。因此项目的首要任务不是炫技，而是不破坏 Postgres 的既有行为与生态——这与很多分布式 Postgres 项目「先做自己的方言」形成对比。
Sugu 本人在公告里的表述也很克制：他考虑给 Postgres 做一个 Vitess adapted 已有一段时间，Postgres 的爆发式流行把这种想法推成了「执念」；他考察各种环境后，认为 Supabase 最适合完成这件事。需要注意：公告发布时（2025-06）项目刚启动，分片与 PB 级是目标愿景，不是已交付能力——初期交付的是连接池，再逐步演进。
四、关键事实（官方口径）
| 维度 | 内容 |
|---|---|
| 发布方/主导 | Supabase；由 Vitess 联合创始人 Sugu 主导 |
| 发布时间 | 2025 年 6 月 10 日（公告） |
| 定位 | 位于 Postgres 前的代理，对标 Vitess |
| 对标 Vitess 能力 | 分片、连接池、查询路由、故障恢复、云原生（K8s）编排 |
| 路线 | 连接池（GB/单机）→ 高可用（TB）→ 分片（PB） |
| 首要原则 | Postgres 兼容性优先 |
| 历史注脚 | 旧 Vitess 演示称 3–5ms 延迟，那是机械硬盘时代；SSD 已达亚毫秒级 |
五、评测方法与口径批判
Multigres 目前是早期项目 + 路线图公告，几乎没有可独立复核的性能数据，读它要特别注意「愿景」与「现状」的区别：
- 「PB 级分片」是终极目标，不是当前可用功能。按官方渐进路线，最先落地的是连接池，高可用与分片是后续阶段；现在就按「已有 Vitess 等价物」去规划生产迁移，属于误读时间表；
- 「Vitess for Postgres」是定位类比，不等于在 Postgres 上 1:1 复刻 Vitess 的全部成熟组件。Postgres 与 MySQL 的存储引擎、复制机制差异很大，很多设计需要重新摸索；
- 公告里没有给出 TPS、延迟、分片路由开销等数字，唯一出现的「3–5ms」还是 Sugu 特意标注的历史 HDD 数据，不能当作 Multigres 的性能承诺；
- 兼容性优先是优点，但也意味着它早期不会提供太多「非 Postgres 标准」的魔法，选型者要接受它是慢工出细活。
六、适用与不适用场景（分阶段看）
现在（早期连接池阶段）适合：
- 想提前关注、未来随 Supabase 一同成长的 Postgres 用户；
- 有连接池需求、愿意跟踪并反馈早期项目的团队。
未来（分片阶段成熟后）适合：
- 数据量向 TB/PB 增长、需要自动分片与查询路由的 Postgres 业务；
- 喜欢 Vitess 那套 K8s 云原生运维哲学、但技术栈是 Postgres 的团队。
现在不适合：
- 立刻需要可投产分片方案的生产系统（该能力尚未交付，应评估 pgdog/Citus 等已有方案）；
- 对项目成熟度、SLA 有硬要求的核心业务。
七、客观分析：优势与局限
优势：
- 对的人 + 对的场景：由真正写过 Vitess 的人主导，路线有历史背书；
- 渐进兼容：从连接池到分片平滑升级，且以 Postgres 兼容性为第一优先；
- 生态红利：背靠 Supabase，有真实大规模 Postgres 生产环境打磨；
- 补位价值：Postgres 生态长期缺一个系统性的 Vitess 等价物。
局限：
- 尚在早期：分片/PB 能力是路线图，短期不能投产；
- 无公开性能基准：缺少可复核的吞吐/延迟数据；
- 移植难度：MySQL 到 Postgres 的引擎差异，决定了它不能简单照抄 Vitess；
- 时间表不确定：从连接池到 PB 分片需要相当长的演进周期。
八、它意味着什么
Multigres 的象征意义大于当下实用意义：它意味着 Postgres 在「好用、生态繁荣」之外，开始有人用最专业的团队系统性地攻「超大规模扩展」这块硬骨头。对今天的工程师，它是一个值得持续跟踪的路线图，而不是一个现在就能押注的分片产品；等到它真的走到高可用与分片阶段，Postgres 才能真正在 PB 级场景里与 MySQL+Vitess 正面竞争。