PostgreSQL 扩展与开源生态选型指南

按向量、GIS、时间序列、搜索、分析、维护与脱敏场景选择 PostgreSQL 扩展，并控制版本升级、许可证、备份和云兼容风险

PostgreSQL 扩展让类型、索引、planner hook、后台 worker 和存储能力进入数据库进程，也会进入备份、复制、故障恢复和 major upgrade 的关键路径。选型原则是：没有明确工作负载和退出方案，就不要安装。

安装前的六项门禁

目标 PostgreSQL major、操作系统和 CPU 架构有明确支持与 package。
许可证满足自托管、SaaS、分发和商业功能边界。
备份、PITR、standby、逻辑复制和恢复环境能够加载相同版本。
pg_upgrade、extension update 和需要重建的 index 有演练路径。
托管云的区域、SKU 与 allowlist 提供所需版本，不只提供同名扩展。
有不依赖该扩展的导出或迁移策略，避免无意中锁定平台。

记录 SELECT extname, extversion FROM pg_extension，并把扩展版本与数据库版本一起进入部署清单和 AI 上下文。

先检查 PostgreSQL 索引与存储访问方法中的原生 B-tree/GIN/GiST/SP-GiST/BRIN、全文检索、分区、FDW 与物化视图。只有原生能力无法满足已测量的 workload 时，再增加 extension。

按工作负载选择

场景	常见候选	采用边界
SQL 统计	`pg_stat_statements`	官方 contrib，生产可观测性基线；治理查询文本权限
向量检索 / RAG	pgvector	用真实过滤条件测 recall、latency、内存与索引构建
地理空间	PostGIS	GIS 标准选择；确认 extension 与数据格式升级路径
时间序列	TimescaleDB	需要 hypertable/压缩/连续聚合时评估；逐项核对许可证
分布式多租户	Citus	单机已被测量为瓶颈且 shard key 稳定后再引入
BM25 / 搜索	ParadeDB / pg_search	核对许可证、索引恢复、复制与云支持
PostgreSQL 内 BM25	pg_textsearch	上游目前声明 production ready；仍需按目标版本和语料独立验收
嵌入式分析 / Parquet	pg_duckdb	适合分析路径；验证事务边界、资源隔离和对象存储凭据
Iceberg columnstore mirror	pg_mooncake	通过 logical change capture 维护 columnstore mirror；验证一致性、对象存储、pg_duckdb 依赖与恢复
图查询	Apache AGE	只有图模型与 Cypher 带来可测收益时采用

“上游 production ready”是项目自己的状态声明，不是对你的 workload、SLA 或云平台的认证。

维护与数据治理

工具	作用	不应误解为
HypoPG	用 hypothetical index 评估 planner 选择	真实构建成本和生产收益证明
pg_repack	以较短排他锁窗口重组表和 index	日常 autovacuum 的替代品
pg_partman	管理原生时间/序列分区生命周期	自动修复错误 partition key
pg_cron	在数据库内调度简单 SQL 工作	通用业务队列和复杂 workflow 引擎
Greenmask	生成脱敏、子集化的测试数据	可以无审查复制生产敏感数据
PostgreSQL Anonymizer	声明式静态/动态掩码	自动满足全部合规要求

严重膨胀先找长事务、autovacuum、写入模式与 fillfactor 根因，再使用 pg_repack。分区只解决能按 partition key 剪枝和管理的数据生命周期问题。

PostgreSQL 19 REPACK 与 pg_repack 不是一回事

PostgreSQL 19 Beta 文档中的核心 REPACK 是新 SQL command，REPACK (CONCURRENTLY) 基于 logical decoding，并对主键/replica identity、unlogged/partitioned/system table、replication slot 和磁盘空间有约束。

第三方 pg_repack 是独立 extension 与命令行工具，具有自己的兼容矩阵、安装包和操作边界。不要因为名称相近，就把 pg_repack 的经验、监控或风险模型直接套到 PostgreSQL 19 核心 REPACK。

Beta 功能不可作为生产依赖

截至 2026-08-02，PostgreSQL 19 仍为 Beta 2。核心 REPACK 的语义和限制应以最终 GA 文档与自己的恢复副本演练为准。

AI、备份与升级清单

向 AI/Agent 提供：server_version_num、extname/extversion、允许使用的 operator/index method、目标云限制和禁止语法。不要仅告诉模型“这是 PostgreSQL”。

每次扩展升级前完成：

读取目标版本 release notes、SQL update script 和已知重建要求；
从真实备份恢复到隔离环境；
升级 PostgreSQL 与 extension，运行完整性、性能和 RLS 测试；
重建要求的 index，并比较 plan、recall 或业务结果；
重新生成备份并执行一次恢复，确认新版本链路成立。

Supabase、Neon、YugabyteDB、CockroachDB、Cloudberry、Gel 和 FerretDB 不应混进“扩展排行榜”：它们分别是平台、分支、独立数据库或协议转换层。分类见 PostgreSQL 血缘与兼容数据库。