PostgreSQL 扩展生态全景解析（第五期）：分布式扩展 —— 从分片到存算分离的进化之路
引言：单机 PostgreSQL 的天花板
我们的系列走到了第五期。第一期我们讨论了扩展生态的宏观图景，第二期探了 GIS，第三期探了向量，第四期探了时序。它们回答的问题分别是“在哪里”“像什么”和“何时”。但还有一个更加基础的问题，在前面几期的讨论中悄然浮现——
当数据量增长到单机存不下时，怎么办？
想象一个多租户 SaaS 平台，每个租户的数据都在同一张表里。一年后，这张表突破数十亿行。PostgreSQL 的优良设计——MVCC、索引、查询优化器——在这个规模下依然能正常工作，但服务器的 CPU、内存、磁盘 I/O 终究有上限。单机 PostgreSQL 的吞吐量和存储容量有天花板。
这个天花板，正是本期要讨论的问题：分布式扩展。
如果说 PostGIS 让 PostgreSQL“看懂”了空间，pgvector 让它“理解”了语义，TimescaleDB 让它“拥抱”了时间，那么分布式扩展则要回答一个更底层的问题——如何让 PostgreSQL 超越单机边界，跨多台服务器协同工作？
一、分片的本质与挑战
1.1 什么是分片（Sharding）？
分片，也叫水平分区，是将一张大表按某种规则拆分成多个子集，每个子集放在不同的数据库节点上。分片使得水平扩展成为可能——随着数据量增长，加入更多节点，总容量和吞吐能力也随之线性扩展。
分片方案的根本在于“数据分布策略”。通常有两种主要方式：分片键（Sharding Key）分区（如按租户 ID 将数据打散到不同节点上），以及目录服务分割（使用一个中央映射表记录数据到节点的映射关系，支持更灵活的数据放置策略，但查询需先查目录再定位，引入额外一跳延迟）。
PostgreSQL 的分片方案主要分为三类：扩展插件（如 Citus）、原生技术组合（原生分区表 + FDW）、外部代理组件（如 PgDog）。
1.2 分布式查询的挑战：跨节点 JOIN 与分布式事务
分片后，查询变得复杂。一个关键问题是 Co-location（协同放置）：如果两张表都按租户 ID 分片，且分片规则一致，那么 JOIN 可以在单个节点上完成，性能最优。如果分片规则不一致，JOIN 就可能导致跨节点数据 shuffle，性能急剧下降。
另一个挑战是分布式事务与一致性。跨越多个 PostgreSQL 节点的事务，需要在所有参与节点上保持原子性。
1.3 分布式系统的权衡：CAP 定理与 PACELC
分布式系统必然面临权衡。CAP 定理指出，在一致性（Consistency）、可用性（Availability） 和网络分区容忍性（Partition Tolerance） 三者中，只能同时满足两个。PostgreSQL 原生复制模型倾向于保障 CP（一致性和分区容忍性），在网络分区时宁可暂停服务也不提供不一致的数据。
PACELC 定理则进一步指出，即便没有网络分区，系统也要在延迟（Latency） 和一致性（Consistency） 之间权衡。数据库具体做了何种取舍——选择了强一致性还是最终一致性——将直接影响应用架构设计和容错策略。
二、Citus：最成熟的云原生分布式扩展
2.1 基本架构：在无共享架构之上构建分布式集群
Citus 是 PostgreSQL 生态中应用最广泛的分片扩展，它将 PostgreSQL 从单节点转变为分布式集群。Citus 采用无共享架构，每个节点独立拥有自己的 CPU、内存和磁盘。集群由一个协调器节点和多个工作节点共同组成。应用连接协调器，协调器根据分布列的哈希值将数据路由到各工作节点，并负责并行化跨分片查询。
2.2 分布列的选择
Citus 的核心是分布列（Distributed Column）。创建分布式表时，用户需指定分布列，Citus 根据分布列哈希值决定数据落到哪个分片。
行级分片（Row-based Sharding）是最经典的方式，适用于多租户 SaaS 场景。选择分布列的关键原则是：查询必须包含分布列过滤条件。例如按 tenant_id 分片，查询 WHERE tenant_id = 123 会被路由到单个工作节点；若查询缺少分布列条件，协调器必须并行查询所有工作节点。
对于异构租户场景，Citus 自 12.0 版本引入了基于模式的分片（Schema-based Sharding）。此模式下，每个租户拥有独立的 Schema，减少应用改造量，但节点间共享资源的密度会有所降低。
2.3 协同性与参考表
协同放置是 Citus 的核心优化：如果两张分布式表具有相同的分布列和分片规则，JOIN 操作可以在各工作节点本地完成，无需数据 shuffle。
Citus 还提供参考表，将小表完整复制到每个工作节点，用于维度数据关联。例如“产品分类”表设置成参考表后，任意 JOIN 都无需跨节点数据传输，查询性能大幅提升。
2.4 Citus 14.0：将 PostgreSQL 18 的力量带到分布式集群
2026 年 2 月，Citus 14.0 发布，核心是完整适配 PostgreSQL 18。Citus 作为 PostgreSQL 扩展决定了其架构优势：PG 18 的性能增强在 Citus 集群中“自动生效”，无需额外开发。
PG 18 为 Citus 带来的关键能力包括：
- 异步 I/O（AIO，Asynchronous Input/Output）：分片密集的分布式集群中，顺序扫描和 VACUUM 操作从 AIO 获得显著加速。
- 跳跃扫描：多列 B-tree 索引可跳过前缀列直接使用后置列，对多租户应用中条件不包含
tenant_id的查询仍有性能收益。 - uuidv7()：时间有序的 UUID 在各分片间生成，减少跨分片索引的随机写入开销。
多数能力对用户免费，但部分复杂功能仍需 Citus 专项适配——如分布式查询中的 JSON_TABLE() 支持、DDL 传播验证、时态约束的分片一致性保证等。
2.5 列式存储：分析型负载的杀手锏
Citus 除了分片，还集成了列式存储。它利用了 PostgreSQL 的表访问方法 API，行为完全类似于普通的堆表——支持流复制、归档、pg_upgrade，弥补了早期 cstore_fdw 仅作为 FDW 的限制。压缩比高达 6-10 倍，对于数据量极大的分析场景，成本下降十分可观。
正是因为 Citus 列式存储的成熟，独立的 cstore_fdw 扩展已于 2026 年 3 月标记为弃用，官方建议现有用户迁移至 Citus 列式存储。
三、分布式生态的其他力量
3.1 PgDog：SQL 感知的自动分片代理
2026 年 2 月，PgDog 正式发布。它是一个用 Rust 编写的数据库代理，核心特点是无需修改应用代码，也无需使用数据库扩展即可实现分片。PgDog 理解 PostgreSQL 协议，可解析查询并判断应路由到哪个分片、负载均衡、拦截或重写不健康的查询（如缺少分片键的查询）。应用无侵入是其核心优势，但相比 Citus，其跨分片分布式查询能力较弱。
3.2 FDW + 原生分区表：原生路线的延续
不使用任何额外扩展，PostgreSQL 也可通过原生分区表 + FDW + 自定义路由逻辑搭建分布式方案。这种方法完全使用标准 PostgreSQL 组件，无第三方依赖，但运维成本高——每增加一个节点需手动创建 FOREIGN TABLE，跨节点查询完全依赖 FDW 下推能力。因此一般仅用于特定场景，如将冷数据归档到异地。
3.3 Apache ShardingSphere：Java 生态的分片中间件
Apache ShardingSphere 不是 PostgreSQL 扩展，是一款 Java 生态中的数据库中间件，提供分片、读写分离、数据加密等能力。核心竞争优势在已有 Java 技术栈的分布式场景下进行一体化数据库治理和多异构数据源联邦查询。
3.4 Greenplum（Apache Cloudberry）：原生分布式 MPP 数据仓库
Greenplum 是 PostgreSQL 历史上影响力最大的分布式分支之一。虽然它并非扩展，而是基于 PostgreSQL 的独立发行版，但其技术路线对 Citus 等扩展影响深远。2026 年 4 月，Apache Cloudberry（Greenplum 的后继项目）发布 2.1.0 版本，新增 UDP 互联协议、ORCA 优化器增强、PAX 列存格式 LZ4 压缩等能力，填补 PG 生态在分析型 MPP 数据仓库领域的空白。
四、从分片到存算分离：云原生时代的范式迁移
2026 年的 PostgreSQL 分布式生态，正在经历从“分片扩展”到“存算分离”的范式迁移。
分片和存算分离是两个相互补充而非对立的维度。分片解决的是数据量超出一台机器的物理限制的问题，通过将数据分布在不同节点上扩展容量和吞吐；存算分离解决的是计算和存储耦合导致弹性不足的问题，将计算节点变为无状态，存储统一沉降到共享存储池中。
两者的关系可以理解为：分片是横向扩展数据容量，存算分离是纵向提升资源弹性。方案可以选择其一，也可以组合使用——存算分离的节点仍可继续做分片，实现双层扩展。
4.1 存算分离的架构突破：阿里云 Serverless Pro
阿里云 Serverless Pro 将持久化数据统一沉降到 OSS 对象存储，本地 ESSD 仅用于缓存与临时数据，使计算层趋于无状态。计算与存储解耦后，算力可独立扩缩容——峰值快速拉起，低谷及时回收，存储按需付费。
基于共享存储底座，Serverless Pro 支持“主集群 + 多 Virtual Warehouse”架构。主集群处理写入，只读业务由独立 VW 承载，创建 VW 无需复制数据，读扩展从“天级”缩短为“分钟级”。
4.2 主动-主动架构：Google Cloud 的逻辑复制演进
Google Cloud 正在推动 PostgreSQL 逻辑复制从主-从模式走向主动-主动架构。其核心贡献是自动冲突检测——数据库可在复制过程中自动识别行级冲突，无需人工干预。其他关键贡献包括将逻辑复制扩展到序列、pg_upgrade 大对象管理优化等。
社区对此反响热烈，但需注意：双向逻辑复制解决的问题域（多活容灾）与分片方案解决的问题域（数据容量扩展）完全不同。企业级全局部署仍需组合使用多种技术。
4.3 CloudNativePG：Kubernetes 原生 PostgreSQL
CloudNativePG（CNPG）是 Kubernetes 上运行 PostgreSQL 的 Operator，已成为 Kubernetes 运行 PostgreSQL 的事实标准，拥有超过 8,000 GitHub 星标。
2026 年 3 月发布的 1.29.0 版本引入 Image Catalogs 机制，将 PostgreSQL 扩展以容器镜像形式抽象、分发和管理，使数据库引擎与扩展模块版本对齐，消除了手动构建维护复杂自定义 PG 镜像的需求。
五、多写架构：从主从到多活的探索
与分片解决“数据容量水平扩展”不同，多写架构试图解决“写入吞吐的水平扩展”以及“全局可用性”的问题。用户最常见的理解是多主复制——允许多个节点同时接受写入，彼此同步。
真正的多主复制必须解决两个核心难题：一是冲突检测与解决，二是分布式事务的一致性保证。
EDB Postgres Distributed（原名 BDR）是此领域最成熟的商业方案。它支持多主复制、分布式一致性（最后写入胜出，LWW）、DDL 复制等高级特性，并提供变更数据捕获能力。属于商业闭源，但技术成熟度在业界处于领先地位。
六、分布式场景下的列式存储演进
本期多次提到列式存储，因为分布式场景下分析型负载的优化逻辑已从单节点的列存储格式，升级为在分片基础上叠加列式存储以进一步提升压缩率和扫描效率。
Citus 列式存储早期源于 cstore_fdw，现已完全吸纳到 Citus 核心，利用 PostgreSQL 表访问方法 API 成为 HTAP 基础设施的关键一环。
TimescaleDB 2.26 也在列式存储方向深化：扩展列存储向量化路径覆盖更多查询模式（特别是 time_bucket() 聚合完全向量化，从 350 ms 降至 85 ms），利用 ColumnarIndexScan 直接回答 COUNT/MIN/MAX/FIRST/LAST 查询，以及使用复合布隆过滤器加速多列过滤查找。
七、分布式扩展的选择指南
7.1 选择分布式 PostgreSQL 方案的决策模型
以下是三个最重要的判断标准：
| 维度 | 考量 |
|---|---|
| 数据量级与吞吐 | 1TB 以下完全不需要分片；10TB-100TB 进入 Citus 适用区间；PB 级需分片 + 存算分离组合 |
| 应用程序敏态 | 能否改 Schema 植入分布列？应用代码能否全局按分布列查询？若为“否”，优先考虑 Schema-based Sharding 或 PgDog |
| 一致性 – 延迟的韧性 | 金融交易等强一致性场景不可接受最终一致性，直接选用分布式 PostgreSQL 而非分布式 MySQL |
7.1 决策路线图
选择分片方案时，可从四个关键问题入手：
Q1：数据量级与吞吐处于哪个区间？ 若数据量 < 1TB 或查询 QPS < 5000，优先考虑垂直扩容（升级单机规格）而非分布式。大多数中小型业务在优化索引和查询后，单机 PostgreSQL 足以支撑数年。分片会引入分布式事务、跨节点 JOIN 等新复杂度。
Q2：应用程序的改动接受度如何？ 若可以接受修改 Schema 和查询，Citus 行级分片是最成熟的选择。若无法修改应用且不想使用扩展，PgDog 提供零侵入的路由代理。若只需要将冷数据归档到异地，FDW + 原生分区已足够。
Q3：是否需要跨分片分布式 JOIN？ 若业务逻辑依赖多表关联且无法按相同分布列设计表结构，Citus 的 Co-location JOIN 是最成熟的方案。若仅按键查询（KV 查询）为主，PgDog 已足够。
Q4：是否需要分布式事务与强一致性？ 金融级场景需要强一致性分布式事务，则必须使用成熟的分布式数据库（YugabyteDB、CockroachDB 等）。Citus 分片无内置分布式事务，多分片写入依赖应用层补偿方案。
八、展望：分布式 PostgreSQL 的未来
8.1 扩展与内核的边界正在模糊
Citus 14.0 将 PG 18 能力带到分布式集群，CloudNativePG 1.29.0 通过 Image Catalogs 治理扩展分发，PGXN 正在研究扩展的可组合性——这一切都指向一个更宏大的趋势：分布式能力正在从“附加组件”向“原生特性”演进。
8.2 云原生时代的分布式数据库蓝图
2026 年的 PostgreSQL 分布式生态呈现清晰的四层分化：
- 分片扩展层：Citus、PgDog、ShardingSphere——在 PostgreSQL 之上提供分布式能力
- 云托管存算分离层：Amazon Aurora、阿里云 PolarDB——共享存储架构的 PaaS 形态
- Kubernetes 编排层：CloudNativePG、Stolon——容器化时代的 PostgreSQL 运维
- 原生分布式数据库层：CockroachDB、YugabyteDB、TiDB——分布式优先设计，兼容 PG 协议
这四层并非相互替代，而是覆盖不同规模、不同场景的完整光谱——这正是“一切皆数据”在分布式时代的落地形态。
写在最后
回到开篇的问题：当数据量增长超出单机承载时，PostgreSQL 怎么办？
这一期的答案是，PostgreSQL 生态给出了多种回答：Citus 说“把表拆开，放到多台机器上，透明分布式查询”；PgDog 说“不用动应用代码，代理帮你搞定路由”；存算分离方案说“计算无状态，存储共享池，弹性随心缩放”；CloudNativePG 说“在 Kubernetes 上，一切皆自动化”。
所有路径汇聚在一起，传递了一个信号：PostgreSQL 正在从一个单机数据库，演变为覆盖 OLTP、OLAP、HTAP、数据联邦的全场景数据平台。
本系列已接近终点。下一期将是系列的收官之作——回顾五期旅程，总结扩展生态的四条核心路径，展望“AI 原生数据库”在 Postgres 生态中的最终形态。
参考文献
[1] CERN PGDay 2026. Sharding Solutions for Postgres. 2026.
[2] Citus 14.0 Release Notes. PostgreSQL 18 Compatibility. 2026.
[3] Microsoft Learn. What is Citus？. 2026.
[4] Microsoft Tech Community Blog. Distribute PostgreSQL 18 with Citus 14. 2026.
[5] 博客园. 第四期：云原生PostgreSQL的分布式架构演进. 2026.
[6] PgDog Launch Announcement. Scaling PostgreSQL with automatic sharding. 2026.
[7] FreshPorts. cstore_fdw migration notice. 2026.
[8] Citus Columnar Documentation. Next generation of cstore_fdw. PGXN.
[9] Tiger Data Blog. TimescaleDB 2.26: 3.5x Faster time_bucket(). 2026.
[10] CloudNativePG 1.29 Release Notes. Image Catalogs. 2026.
[本系列下一期（第六期）：总结与展望——AI 原生数据库与 PostgreSQL 扩展生态的终局。]
