PlanetScale 对决 Supabase，谁将成为分布式 Postgres 之王？

PlanetScale 正式发布 Neki，Supabase 团队主导开源 Multigres，一场 Postgres 分布式战争即将上演。

目录

Postgres 垂直扩展的瓶颈与分布式浪潮

长期以来，PostgreSQL 凭借其强大的 SQL 语法支持、极佳的扩展性以及丰富的插件生态（如 PostGIS、pgvector），成为了现代软件开发的首选开源关系型数据库。然而，随着业务数据的爆炸式增长，许多团队不可避免地碰到了单机 Postgre 垂直扩展（Scale-up）的物理天花板。即使采购最顶级的硬件配置，随着核心表数据量突破数百 GB 甚至数 TB，运维痛点层出不穷：大表 VACUUM 阻塞正常流量、索引创建与重建耗费数小时、备份恢复周期漫长、高并发连接数爆表，以及不可避免的事务号回卷隐患。

在 MySQL 世界中，由 Google 孵化、PlanetScale 商业化推行的 Vitess 已经成为了海量数据水平分片（Sharding）的标准答案。但在 PostgreSQL 生态中，多年来一直缺乏一个既能保持 100% Postgres 原生兼容性、又能提供无缝水平扩展的统治级方案。

2026年9月，这一格局迎来了历史性的爆发：

• PlanetScale 正式发布 Neki：汲取 Vitess 八年大规模分片运营经验，为 Postgres 量身打造的原生 Sharding 架构（已进入 Platform Preview）。
• Supabase 团队主导开源 Multigres：明确打出“Postgres 版 Vitess”的旗号，发布最新分布式架构设计，聚焦高可用共识与多地域（Multi-cell）部署。
• Hacker News 爆发世纪辩论：关于两者的架构设计、数据一致性保障乃至“闭源托管 vs 开源社区”的商业道德讨论迅速登上热榜。

下面，我们来剖析下 Neki 与 Multigres 的技术异同、架构哲学与商业博弈，探讨谁能最终登顶分布式 Postgres 之王。

Neki：PlanetScale 将 Vitess 基因注入 PostgreSQL

PlanetScale 正式推出了 Neki（目前处于 Platform Preview 阶段）。PlanetScale 在过去八年中运行了全球规模最大的分片 MySQL 集群（基于 Vitess）。在推出 PlanetScale Postgres 后，他们发现大量客户迅速触及了单机 Postgres 的极限，于是决定将 Vitess 的分片经验移植到 Postgres 上，打造了 Neki。

  flowchart TD
    Client["客户端 / ORM"]
    Router["Neki Router\n(解析 SQL / 分布式执行计划 / 结果聚合)"]

    Client -- Postgres Wire Protocol --> Router

    subgraph ShardGroups ["分片集群"]
        direction LR
        
        subgraph SG1 ["Shard Group 1"]
            direction TB
            Sidecar1["Sidecar (动态连接池)"]
            PG1[("原生 Postgres")]
            Sidecar1 --> PG1
        end

        subgraph SG2 ["Shard Group 2"]
            direction TB
            Sidecar2["Sidecar (动态连接池)"]
            PG2[("原生 Postgres")]
            Sidecar2 --> PG2
        end
    end

    Router --> SG1
    Router --> SG2

1. 核心架构设计

Neki 遵循一个核心原则：坚持使用原生 PostgreSQL，不修改数据库本身。其架构由四个主要部分组成：

• Neki Router：作为应用的接入入口，兼容标准 Postgres 传输协议。Router 内置完整的 PG 查询解析器与分布式查询计划器，能够分析 SQL、确定目标分片、下发任务并聚合结果流。
• Shard 与 Shard Groups：每一个分片（Shard）都是一个完整的原生 PostgreSQL 集群（1 主 2 备，跨 3 个可用区部署）。由于运行的是未修改的 PG Engine，所有 PG 插件、扩展和 SQL 特性均保持原汁原味。
• Sidecar 连接池：运行在每个 Postgres 实例旁。相比传统的 PgBouncer，Neki 同时控制 Router 端与 PG 端，能够根据实例实际负载精准调节连接池大小。
• Control Plane & Data Topology：控制平面负责监控节点健康状态、自动故障转移（Failover）以及执行无缝在线 Resharding。数据拓扑（Data Topology）通过 JSON 配置映射逻辑表与物理分片。

2. 核心优势

• 平滑演进：无需在第一天就进行分片。应用可以先以单主多副本方式运行 Neki，当容量不足时，再直接发起在线 Resharding 工作流升为分片集群。
• 在线无感运维：版本升级、Schema 变更（Online DDL）、主从切换等需要停机维护的操作，在 Neki 中均通过内置的在线工作流完成。

Multigres：Supabase 打造的开源“Postgres 版 Vitess”

几乎在同一战场上，Supabase 推出了 Multigres。其目标极为明确：为 PostgreSQL 打造一个如同 Vitess 之于 MySQL 级别的开源分布式扩展架构。

  flowchart TD
    Client["客户端 / 应用"]
    Gateway["Multigateway"]

    Client -- Postgres Protocol --> Gateway

    subgraph Pod ["同一个 Pod / Host"]
        direction TB
        Pooler["Multipooler\n(连接池管理)"]
        PG[("原生 Postgres")]
        Pooler --> PG
    end

    Gateway -- 单条多路复用 gRPC 连接 --> Pooler

    Orch["Multiorch\n(基于 Raft / 广义共识协议监控 HA & 共识)"]
    Orch -->|监控复制状态与自动故障转移| PG

1. 核心架构设计

Multigres 采用了模块化的云原生设计，深度契合 Kubernetes 生态：

• Multigateway：对外提供标准 Postgres 协议接入，对内通过单条多路复用的 gRPC 连接将查询路由至后端的 Multipooler。
• Multipooler：连接池管理组件，与每一个 Postgres 数据库服务器运行在同一个宿主机（或 K8s Pod）中。
• Multiorch：高可用与集群编排大脑。它监控复制状态，自动修复断开的流，并基于 Raft 或广义共识协议（Generalized Consensus） 协调故障转移（Failover），确保数据写入在多数派确认前不丢失。
• Topo Server & Provisioner：基于 etcd 实现全局（Global）与区域（Cell-local）拓扑注册。Provisioner 负责根据 CREATE DATABASE 等指令动态创建与编排资源。
• TableGroups 与独立分片：Multigres 将表划分为不同的 TableGroup，每个 TableGroup 可以独立进行水平分片，兼顾了多租户隔离与特定大表的弹性扩展。

2. 核心优势

• 多区域/多 Cell 架构：内置 Cell 概念，本地 Local Topo Server 与 Multiorch 保证即使某个区域发生网络分区，局部 Cell 仍能正常提供服务。
• 强一致性保障：支持全同步复制与两阶段同步插件，在底层共识机制下提供强一致性保障。

Neki vs Multigres：核心维度对比

Hacker News 社区焦点与商业路线论战

在 HN 讨论帖中，关于 Neki 和 Multigres 的论战呈现出极度戏剧化的张力：

“PlanetScale 靠开源的 Vitess 起家，如今为 Postgres 打造了一个类似 Vitess 的产品，却把它做成了闭源专有软件……这太具讽刺意味了。” —— HN 开发者讨论

针对开源争议，PlanetScale CEO Sam Lambert 在讨论区进行了激烈的正面回应。他强调：“Amazon 等云厂商一直在无偿剥削商业开源公司，我们不能再给他们提供便利。”但社区开发者对此并不完全买账，指责 PlanetScale 正在背离开源承诺。

而在技术层面，开发者们普遍关注分布式一致性（CAP 理论取舍）：

• 对于跨分片事务（Cross-shard transactions），Neki 依赖应用层合理选择 Shard Key 避免跨分片写；如果涉及跨分片，两阶段提交（2PC）开销巨大。
• Multigres 则试图在底层存储拓扑中通过多节点共识和 2PC 复制插件来解一致性难题，但也面临着网路延迟对写入吞吐量的考验。

总结与展望：谁将问鼎分布式 Postgres 之王？

Neki 与 Multigres 代表了分布式 PostgreSQL 的两条截然不同的终局路线：

1. Neki 是“极致体验与平台赋能”的代表： 适合不愿意折腾基础设施、追求零运维停机、依赖 PlanetScale 分支（Branching）与 Insights 现代化工作流的企业级客户。
2. Multigres 是“云原生与开源自由”的代表： 适合坚守开源阵营、希望在 Kubernetes 上自主掌控基础设施、或者需要多地域/多 Cloud 混合部署的大型技术团队。

结论： 谁将成为分布式 Postgres 之王？短期看，拥有成熟 Vitess 经验与全托管平台的 PlanetScale Neki 在商业落地速度上略胜一筹；但长期来看，秉承彻底开源、由 Supabase 强力推动的 Multigres 拥有无限的社区生命力。这场技术与商业的双重对决，才刚刚拉开序幕！

参考来源：

1. Hacker News 社区讨论
2. PlanetScale: Introducing Neki
3. Multigres Architecture Overview