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 或云平台的认证。

TimescaleDB 快速上手与版本边界

先满足上文的采用边界：只有当 hypertable、压缩或连续聚合对应已测量的需求时才评估 TimescaleDB。TimescaleDB 2.x 上的最小评估序列：

CREATE EXTENSION IF NOT EXISTS timescaledb;

CREATE TABLE metrics (
  time   timestamptz NOT NULL,
  device text NOT NULL,
  value  double precision
);

SELECT create_hypertable('metrics', by_range('time'));

CREATE MATERIALIZED VIEW metrics_hourly
WITH (timescaledb.continuous) AS
SELECT time_bucket('1 hour', time) AS hour,
       device, avg(value), max(value)
FROM metrics
GROUP BY hour, device;

ALTER TABLE metrics SET (timescaledb.compress);
SELECT add_compression_policy('metrics', INTERVAL '7 days');
SELECT add_retention_policy('metrics', INTERVAL '90 days');

按已安装的 extversion 核实

by_range 维度构造器要求 TimescaleDB 2.13 及以上；更早版本使用 create_hypertable('metrics', 'time')。
ALTER TABLE ... SET (timescaledb.compress) 是旧版压缩 API。近期 2.x 版本将压缩收敛到 hypercore，reloption 与 policy 名称不同 —— 以已安装版本和 TimescaleDB 官方文档为准。
连续聚合在附加 add_continuous_aggregate_policy 之前不会按调度刷新。
TimescaleDB 采用 Timescale License（TSL），不是 PostgreSQL License。生产使用前逐项核对功能边界。

维护与数据治理

工具	作用	不应误解为
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 文档与自己的恢复副本演练为准。

PostgreSQL 19 计划建议模块

PostgreSQL 19 Beta 新增两个面向计划稳定化的 contrib 模块。pg_plan_advice 允许把关键 planner 决策描述、复现并通过附加在查询上的 advice 改写；pg_stash_advice 把 advice 字符串按 query identifier 存入动态共享内存并自动应用。

两者都应定位为实验通道，而不是生产级计划管理契约：advice 格式与覆盖范围在 GA 前仍可能变化，而且用这种方式固定计划绕开了重新 ANALYZE 或 HypoPG 这类验证手段。把它们放进 Beta 测试通道与计划对比 benchmark 一起评估，而不是用来替代这些验证。

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 血缘与兼容数据库。