PostgreSQL扩展终极指南：504个扩展全景解析与32个新增硬核扩展详解
从一个化学扩展说起
一切始于两天前的一则GitHub Issue。一位用户在使用RDKit——化学信息学领域无可争议的标准库时遇到了难题。虽然该库能在PostgreSQL中实现分子结构存储、子结构检索和相似性计算等核心功能，但PGDG官方打包版本竟然缺失了关键的InChI功能。这位用户花费了大量时间折腾编译参数，最终虽勉强跑通，但仍希望Pigsty能提供原生支持。
RDKit确实是一块难啃的硬骨头。大约两年前我曾尝试将其纳入Pigsty的扩展仓库，目标是从Debian移植到EL系列系统。但现实很残酷：Boost、Eigen、RapidJSON、Cairo等依赖项环环相扣，再加上InChI、Avalon等可选模块，每个组件都有独立的编译开关和操作系统兼容性问题。几番尝试未果后，我只能暂时搁置。
然而这次情况截然不同——Coding Agent时代已经到来。
借助Codex / Claude Code处理这类"构建系统考古"任务堪称降维打击。过去需要反复试错数周的工作，如今只需一两轮对话就能自动完成。在最新版本中，我不仅解决了PGDG打包的InChI支持问题，更将编译参数优化做到了极致。整个流程顺畅得令人难以置信，用户反馈也极为满意。
这种来自开源社区的积极互动总能带来最大的成就感。
趁热打铁
既然构建流程已经跑通，我索性将积压已久的几个"历史遗留难题"一并解决。
plv8扩展首当其冲。这个V8引擎的PostgreSQL绑定之前在EL10上始终无法编译通过，此次通过打上多个补丁终于实现了稳定构建。
duckdb_fdw的兼容性难题也得到了优雅解决。该扩展允许从PG内部直接读写DuckDB文件，但此前会与DuckDB官方的pg_duckdb扩展发生共享库冲突，我不得不暂时将其隐藏。新版本通过将duckdb_fdw作为pg_duckdb的子扩展，共享同一份libduckdb库，彻底消除了冲突，两个扩展终于能够和平共处。
工具链已然成熟，我萌生了一个更大胆的想法：何不将PostgreSQL生态中那些值得收录但一直未能攻克的扩展全部纳入？于是催生了这次史诗级更新——新增32个扩展，更新22个扩展，Pigsty扩展仓库总量正式突破500大关，达到惊人的504个。
完整扩展目录: pigsty.cc/ext[2]
| 分类 | All | PGDG | PIGSTY | CONTRIB | MISS | PG18 | PG17 | PG16 | PG15 | PG14 |
|---|---|---|---|---|---|---|---|---|---|---|
| 全部 | 504 | 155 | 332 | 71 | 0 | 481 | 488 | 479 | 473 | 457 |
| EL | 499 | 150 | 332 | 71 | 5 | 472 | 482 | 474 | 468 | 452 |
| Debian | 489 | 107 | 311 | 71 | 15 | 466 | 474 | 464 | 458 | 442 |
这五百多个扩展的构成颇具深意：约70个是PostgreSQL自带的Contrib扩展，150个来自PGDG官方打包，剩下的330个全部由我个人维护构建。可以说，在PostgreSQL扩展生态这个赛道上，Pigsty已经做到了前所未有的深度和广度。
横向对比更能体现这一成就的分量。主流云服务商如Supabase，在去除PG自带的35个Contrib扩展后，实际提供的第三方PG扩展不足30个。这意味着Pigsty的扩展数量是商业产品的十倍以上。
新扩展全景扫描
本次新增的32个扩展技术密度极高，可归为四大类别：
数据域革命：将化学分子、RDF三元组、BSON、Protobuf、循环日程等复杂对象提升为数据库一等公民，彻底打破传统关系模型的边界。
查询能力跃升：涵盖稀疏线性代数与图算法、Datalog图查询引擎、全文检索增强、混合排序融合、递归SQL模板引擎等前沿能力。
生产工程化：提供深度可观测性、查询遥测实时导出、CDC到MQTT协议转换、COPY命令安全拦截、DDL逻辑复制补全、轻量级分布式锁、软告警式数据质量治理等企业级特性。
开发者体验革新：包括会话级变量管理、伪自治事务日志系统、自然语言时间解析，以及最具颠覆性的——在数据库内部直接运行TypeScript代码。
这些扩展共同指向一个明确的演进方向：PostgreSQL正通过其强大的扩展层，从单纯的数据库进化为连接应用层与数据平台的中间枢纽。越来越多的原本需要独立服务解决的复杂问题，如今可以在单条SQL事务边界内一站式完成。
这就是PostgreSQL极致可扩展性的终极魅力。
新扩展技术详解
本章节由Claude、Codex、Gemini三大AI助手协同完成，为读者快速掌握每个扩展的核心功能、技术实现与适用场景提供精准导航。
- rdkit —— 化学信息学的数据库原生革命
RDKit作为开源化学信息学的行业标准库，由Greg Landrum创立（前身为诺华制药项目，现归属T5 Informatics）。其PostgreSQL插件模块将分子结构存储、子结构检索与相似性计算直接融入关系型数据库，使制药企业和化学研究机构能够用标准SQL查询数百万级化合物库，彻底摆脱对外部工具链的依赖。
核心数据类型包括**mol（分子对象）和qmol（查询分子/SMARTS模式），以及bfp/sfp（位指纹/稀疏指纹）。运算符体系丰富：@>执行子结构匹配，%实现Tanimoto相似度判断，<%>作为距离运算符。所有操作均可通过GiST索引**加速——索引层基于指纹预过滤实现快速剪枝，再进行精确匹配。关键函数如mol_from_smiles()、morganbv_fp()（Morgan指纹生成）、tanimoto_sml()等，配合rdkit.tanimoto_threshold等GUC参数可精细调控检索灵敏度。
以ChEMBL数据库（187万化合物）为例：
-- 子结构检索：查找含特定骨架的分子SELECT count(*) FROM rdk.mols WHERE m @> 'c1cccc2c1nncc2';-- 返回：461个匹配，耗时约108ms
-- Tanimoto相似性搜索：基于Morgan指纹SELECT molregno, tanimoto_sml(morganbv_fp(mol_from_smiles('c1ccccc1C(=O)NC'::cstring)), mfp2) AS similarityFROM rdk.fps JOIN rdk.mols USING (molregno)WHERE morganbv_fp(mol_from_smiles('c1ccccc1C(=O)NC'::cstring)) % mfp2ORDER BY morganbv_fp(mol_from_smiles('c1ccccc1C(=O)NC'::cstring)) <%> mfp2;
-- SMARTS模式匹配：检索噁二唑或噻二唑类化合物SELECT * FROM rdk.mols WHERE m @> 'c1[o,s]ncn1'::qmol LIMIT 500;
应用场景覆盖药物研发全流程：先导化合物骨架搜索（百万级库的子结构匹配）、SAR分析（通过相似性查找活性类似物）、化合物注册系统（利用指纹进行重复性检查）、商业化合物目录检索（如eMolecules 600万+数据集）。
工程实践要点：cartridge的核心价值不在于"能否计算"，而在于"能否被索引、能否被查询规划器正确优化"。索引策略与查询模板需要预先固化，否则极易写出语义正确但性能灾难的结构过滤。在187万化合物规模上，子结构检索耗时88ms至1900ms不等，经充分优化可支撑600万+化合物的查询负载。项目采用BSD许可证，提供Docker镜像（如mcs07/postgres-rdkit）和conda安装方案。
- provsql —— 让查询结果可追溯的半环溯源引擎
ProvSQL由巴黎高等师范学校Pierre Senellart教授与INRIA Valda团队联合研发，发表于VLDB 2018。该扩展为PostgreSQL注入**(m-)半环溯源（semiring provenance）**与不确定性管理能力，能自动追踪每个查询结果由哪些基础元组推导而来，并支持在不同代数结构（布尔、安全等级、计数、概率）下对溯源信息进行求值。
技术核心是通过PostgreSQL hook拦截查询执行，为每张表自动注入隐藏的provsql列，存储指向溯源电路（provenance circuit）的UUID。支持的SQL子集极其广泛：SELECT-FROM-WHERE、JOIN、GROUP BY、DISTINCT、UNION/EXCEPT、聚合函数、HAVING，甚至在PG 14+支持INSERT/DELETE/UPDATE的溯源追踪。核心函数包括add_provenance()启用追踪、provenance_evaluate()对溯源求值、formula()输出布尔公式、probability_evaluate()计算概率。概率求值支持多种算法：从最朴素的直接求值到Monte-Carlo采样，再到借助d4、c2d等外部求解器进行d-DNNF编译。
-- 安全等级传播：查询结果自动继承最高安全级别SELECT create_provenance_mapping('personnel_level', 'personnel', 'classification');SELECT p1.city, security(provenance(), 'personnel_level')FROM personnel p1, personnel p2WHERE p1.city = p2.city AND p1.id < p2.idGROUP BY p1.city ORDER BY p1.city;
-- 布尔公式溯源：每行结果显示其推导公式SELECT *, formula(provenance(), 'witness_mapping') FROM s;
-- 概率查询：计算结果行可信度SELECT city, probability_evaluate(provenance()) FROM result;
适用场景四类：安全分级传播——查询结果自动继承源数据最高安全等级；概率数据库——基础数据带可信度评分时计算查询结果正确概率；数据血缘审计——精确追踪结果行来源元组，支持PROV-XML标准导出；可信度评估——如刑事调查场景，通过溯源加权评估目击者陈述可靠性。
ProvSQL的真正价值在于"可组合性"：溯源结果非字符串日志，而是可被函数持续处理的对象。建议部署于关键链路（核心报表/模型特征/合规计算），而非全库无差别开启。采用C/C++实现（依赖Boost库），溯源电路存储于共享内存。支持PG 10–18，MIT许可证。
- onesparse —— 十亿边级图算法的SQL原生方案
OneSparse将高性能稀疏线性代数库SuiteSparse:GraphBLAS引入PostgreSQL，由GraphBLAS C API委员会成员Michel Pelletier主导开发，技术顾问包括SuiteSparse作者Timothy A. Davis教授（SIAM/ACM/IEEE Fellow）。核心理念是将图表示为稀疏矩阵，通过矩阵乘法实现BFS、PageRank、三角中心性等图算法，且完全在SQL中完成。
扩展引入matrix（稀疏矩阵）、vector（稀疏向量）、scalar、semiring、monoid等数据类型，提供@（矩阵乘法/plus_times半环）等运算符。内置算法库来自LAGraph，包括BFS（层级与父节点双模式）、PageRank、三角中心性、度中心性、单源最短路径等。技术实现上，将GraphBLAS的不透明句柄封装于PostgreSQL的Expanded Object Header结构，小图（<1GB）采用TOAST存储，大图支持Large Object或文件系统。内置JIT编译器支持NVIDIA CUDA GPU加速。
-- 从Matrix Market文件加载图SELECT mmread('/home/postgres/onesparse/demo/karate.mtx') AS graph;
-- BFS遍历SELECT (bfs(graph, 1)).level FROM karate;
-- 度中心性（矩阵列归约）SELECT reduce_cols(cast_to(graph, 'int32')) AS degree FROM karate;
-- PageRank计算SELECT pagerank(graph) FROM karate;
在GAP benchmark中，对43亿边的图执行BFS达到每秒70亿+边的惊人吞吐量（48核AMD EPYC服务器）。应用场景覆盖金融反欺诈（交易网络环检测）、社交网络分析、Graph RAG等。实际落地需评估数据装载/序列化格式与现有管道兼容性，以及算子与SQL Planner/并行执行的协同效果——强烈建议先在小规模样例上跑通端到端链路。
OneSparse要求PG 18 Beta或更高版本，目前处于Alpha阶段。Apache 2.0许可证。
- pg_datasentinel —— 容器化时代的深度可观测性解决方案
pg_datasentinel由Datasentinel公司Christophe Reveillère开发，2026年4月10日发布1.0版本。该扩展为PostgreSQL注入四大可观测性能力，填补了原生监控在容器化环境与预警机制方面的关键空白。
第一，扩展活动监控：在pg_stat_activity基础上增加每个后端进程的内存使用量、实时临时文件字节数，PG 18+还支持当前执行计划ID显示。第二，容器资源透明化：报告CPU配额、内存限制、当前使用量和CPU压力，完美适配Docker、Kubernetes、OpenShift及所有cgroup管理环境。第三，事务回卷风险预测：实时追踪XID和MXID消耗速率，提供到aggressive-vacuum和回卷限制的实时ETA。第四，日志捕获视图：将vacuum、analyze、临时文件、checkpoint事件记录到共享内存环形缓冲区，解析为结构化计数与计时信息，支持实时SQL查询。
-- 查看各后端内存使用（增强版pg_stat_activity）SELECT pid, usename, query, backend_memory_bytes, temp_file_bytesFROM pg_datasentinel_activity;
-- 容器资源实时监控SELECT cpu_quota, memory_limit, memory_usage, cpu_pressureFROM pg_datasentinel_container_resources;
-- 事务回卷风险预估SELECT xid_current, xid_limit, xid_eta_aggressive_vacuum, xid_eta_wraparoundFROM pg_datasentinel_wraparound;
对于Kubernetes上运行PostgreSQL的团队，pg_datasentinel提供了无需外部监控代理的容器级资源可见性。XID回卷预警功能堪称运维神兵——众所周知，XID回卷会导致数据库强制关机，而pg_datasentinel通过追踪消耗速率提供预测性告警，将"被动救火"变为"主动防火"。采用3-Clause BSD许可证，要求PG 15+。
- datasketches —— Apache出品的亿级数据近似分析神器
Apache DataSketchse是Apache基金会顶级项目（源自Yahoo/Verizon Media），其PostgreSQL扩展将多种**近似分析数据结构（Sketch）**引入SQL世界。核心诉求非常明确：在海量数据上执行精确的COUNT(DISTINCT)、分位数计算和频繁项统计，要么太慢要么太耗内存。
扩展提供七种Sketch类型：cpc_sketch（Compressed Probabilistic Counting）、hll_sketch（HyperLogLog）、theta_sketch（支持集合交并差运算的去重计数）、aod_sketch（Tuple sketch）、kll_float_sketch/kll_double_sketch（分位数估算）、req_float_sketch（尾部高精度分位数）、frequent_strings_sketch（频繁项统计）。每种Sketch均提供*_sketch_build()、*_sketch_union()、*_sketch_get_estimate()等标准接口。
关键价值在于Sketch作为可序列化对象支持聚合合并，特别适合数据立方体式的近似指标构建：按维度切片预聚合Sketch，查询时按需union即可得到去重计数。Sketch在内存中保持亚线性空间复杂度，且跨语言（Java、C++、Python、Rust、Go）二进制兼容。
-- 近似去重计数：比精确COUNT(DISTINCT)快约6倍SELECT cpc_sketch_distinct(id) FROM random_ints_100m;-- 结果：63423695（精确值：63208457），耗时~20s vs 精确~2min
-- Theta Sketch集合运算：计算两用户群体交集SELECT theta_sketch_get_estimate( theta_sketch_intersection(sketch1, sketch2)) FROM theta_set_op_test;
-- KLL分位数估算：获取中位数SELECT kll_float_sketch_get_quantile(sketch, 0.5) FROM kll_float_sketch_test;
-- 多维度聚合+Sketch合并SELECT cpc_sketch_get_estimate(cpc_sketch_union(respondents_sketch)) AS num_respondents, flavorFROM ( SELECT cpc_sketch_build(respondent) AS respondents_sketch, flavor, country FROM (VALUES (1,'Vanilla','CH'),(1,'Chocolate','CH'), (2,'Chocolate','US'),(2,'Strawberry','US')) AS t(respondent, flavor, country) GROUP BY flavor, country) bar GROUP BY flavor;
典型用例：实时UV统计——不存储用户ID即可跨时间窗口合并去重；分布分析——在数十亿事件上计算p50/p95/p99延迟无需排序；受众重叠分析——用Theta Sketch交集运算计算"看过广告A且访问网站B"的用户数。在1亿行数据上，CPC Sketch去重计数约20秒完成（精确COUNT(DISTINCT)约2分钟），相对误差控制在个位数百分比内。
- pghydro —— 国家级水务系统的空间分析引擎
PgHydro由巴西国家水务卫生局（ANA）GIS专家Alexandre de Amorim Teixeira开发，构建于PostGIS之上，已被ANA采纳为全国水资源管理的官方工具，并在FOSS4G 2022大会展示。
核心能力覆盖水文网络全链路：从原始GIS数据导入与一致性校验，到流向计算、Otto Pfafstetter流域编码（国际通用分层流域分类系统）、上下游分析、汇水面积计算、Strahler河流分级等。架构采用模块化设计，包含五个子扩展：pghydro（核心）、pgh_raster（DEM栅格分析）、pgh_hgm（水文地貌特征）、pgh_consistency（拓扑一致性校验）和pgh_output（数据导出）。
-- 导入排水线数据SELECT pghydro.pghfn_input_data_drainage_line('public', 'input_drainage_line', 'geom', 'nome');
-- 计算流向并自动修正不一致河段SELECT pghydro.pghfn_CalculateFlowDirection();SELECT pghydro.pghfn_ReverseDrainageLine();
-- 计算Pfafstetter流域编码SELECT pghydro.pghfn_Calculate_Pfafstetter_Codification();
-- 计算上游汇水面积和入海距离SELECT pghydro.pghfn_CalculateUpstreamArea();SELECT pghydro.pghfn_CalculateDistanceToSea(0);
-- Strahler河流分级SELECT pghydro.pghfn_calculatestrahlernumber();
适用于国家级水文数据库管理、流域规划与编码、上下游污染影响分析（如定位污染源上游所有河段）、排水网络拓扑一致性验证。它本质上是一套专业领域的数据库内ETL/分析流水线——数据在PostGIS中统一管理，分析过程SQL自动化，当原始地形/河网数据更新时，按函数流水线重算比手工脚本可靠得多。配合QGIS的PgHydroTools插件实现可视化交互。完全用PL/pgSQL编写，GPLv2许可证。
- pg_stat_ch —— ClickHouse官方出品的查询遥测利器
pg_stat_ch由ClickHouse公司开发并开源（2025年2月"Postgres Week at ClickHouse"活动），作者Kaushik Iska。与pg_stat_statements在PostgreSQL内部做聚合统计不同，pg_stat_ch将每条查询的原始执行事件（包含45个字段、固定4.6KB）实时流式导出到ClickHouse，所有聚合分析（p50/p95/p99、Top查询、错误分析）交由ClickHouse强大的分析引擎完成。
数据管道架构：PostgreSQL Hooks（前台）→ 共享内存环形缓冲区 → 后台Worker → ClickHouse。45个遥测字段覆盖查询计时、行数、缓冲区使用、WAL写入、CPU时间、JIT指标（PG15+）、并行Worker统计（PG18+）、客户端上下文（应用名、IP）、错误捕获（SQLSTATE码）等。扩展采用ClickHouse原生二进制协议加LZ4压缩，静态链接clickhouse-cpp库。为避免对PostgreSQL造成背压，队列溢出时主动丢弃事件（记录丢弃计数器）而非拖慢数据库——与StatsD设计哲学一致。
-- PostgreSQL侧：监控扩展健康状态SELECT * FROM pg_stat_ch_stats();-- 返回：enqueued, exported, dropped计数，最后成功/失败时间戳
-- ClickHouse侧：过去1小时按应用统计p95/p99SELECT query_id, count() AS calls, quantile(0.95)(duration_us) / 1000 AS p95_ms, quantile(0.99)(duration_us) / 1000 AS p99_msFROM pg_stat_ch.events_rawWHERE app = 'myapp' AND ts_start > now() - INTERVAL 1 HOURGROUP BY query_id ORDER BY p99_ms DESC LIMIT 10;
ClickHouse侧预置四个物化视图：events_recent_1h（滚动1小时副本）、query_stats_5m（5分钟桶+TDigest分位数）、db_app_user_1m（按数据库/应用/用户归因负载）、errors_recent（7天滚动错误窗口）。
性能表现惊人：p99开销仅5μs/条，在pgbench 32客户端36.6K TPS场景下，30秒捕获770万事件零丢弃，对TPS影响**<1%**（36,658 vs 36,913基线）。三层锁争用最小化策略：原子溢出检查 → 非阻塞LWLock尝试 → 每后端本地缓冲区（每事务刷新，减少约5倍锁获取）。将PostgreSQL作为"事务系统"，ClickHouse作为"遥测仓库"，职责分离，比日志文件逆向解析稳定可靠得多。支持PG 16–18，Apache 2.0许可证。
- pg_rrf —— 混合检索排序融合的一行函数方案
pg_rrf由日本开发者yuiseki开发（2026年1月发布），Rust（pgrx）实现。它将**Reciprocal Rank Fusion（RRF）**算法封装为原生PostgreSQL函数，解决混合检索中"分数不可比"的工程痛点：不同检索器输出尺度各异，直接加权难以调优，而RRF仅依赖排名。公式为score(d) = Σ 1/(k + rank_i(d))，k默认60（Cormack et al., SIGIR 2009）。
扩展提供四个函数：rrf(rank_a, rank_b, k)计算两路融合分数、rrf3()三路融合、rrfn(ranks[], k)N路融合，最实用的是**rrf_fuse(ids_a bigint[], ids_b bigint[], k)**——接收两个排序ID数组，返回融合后的(id, score)表。NULL安全设计：仅在单路出现的ID使用该路排名计算得分。
-- 使用pg_rrf实现混合检索：pgvector + BM25WITH fused AS ( SELECT * FROM rrf_fuse( ARRAY(SELECT id FROM docs ORDER BY bm25_score DESC LIMIT 100), ARRAY(SELECT id FROM docs ORDER BY embedding <=> :qvec LIMIT 100), 60 ))SELECT d.*, fused.scoreFROM fused JOIN docs d USING (id)ORDER BY fused.score DESC LIMIT 20;
这将原本需要FULL OUTER JOIN + COALESCE链+手动评分公式的20+行CTE压缩为单行函数调用。应用场景覆盖RAG混合检索（语义+全文融合）、电商产品搜索、多信号文档排序等。将融合逻辑下推到数据库层，特别是当结果需继续JOIN业务表时，显著减少应用层拼接与排序开销。当前v0.0.3，MIT许可证。
- pg_kazsearch —— 哈萨克语全文检索的零突破
pg_kazsearch是PostgreSQL首个哈萨克语全文检索扩展。哈萨克语作为高度黏着语，单词如мектептерімізде承载复数、领属、位格等多重后缀，必须完全剥离才能到达词根мектеп。现有PostgreSQL或Elasticsearch分析器均无法处理此特性。
扩展采用Rust（pgrx）实现，提供kazakh_cfg文本搜索配置和pg_kazsearch_dict词典。词干提取算法基于BFS后缀剥离，配合元音和谐验证和源自Apertium-kaz的21,863个词性标注词根词典防止过度词干化。运行时可通过ALTER TEXT SEARCH DICTIONARY动态调整权重参数。
-- 词干提取演示SELECT ts_lexize('pg_kazsearch_dict', 'алмаларымыздағы');-- 返回：{алма}
-- 构建带权重tsvector并检索SELECT title FROM articlesWHERE fts @@ websearch_to_tsquery('kazakh_cfg', 'президенттің жарлығы')ORDER BY ts_rank_cd(fts, websearch_to_tsquery('kazakh_cfg', 'президенттің жарлығы')) DESCLIMIT 10;
在2,999篇文章基准测试中，查询延迟0.5ms（比pg_trgm快2.8倍），nDCG@10提升25%，Recall@10提升23%。适用于哈萨克语新闻/政府文档检索、电商搜索等场景——在多语种系统中补齐"低资源语言"检索能力，避免退化为粗糙的trigram模糊匹配。
- pg_liquid —— Datalog风格的声明式图查询
pg_liquid由Michael Golfi（西雅图）开发，将Liquid/Datalog风格的声明式图查询带入PostgreSQL。通过liquid.query(...)单次调用即可声明事实、定义规则并执行查询，无需部署独立图数据库。规则为query-local（仅单次liquid.query有效），支持事实断言、递归传递闭包、复合查询（compounds）和行规范化器。
SELECT targetFROM liquid.query($$ Edge("a", "path", "b"). Edge("b", "path", "c"). Edge("c", "path", "d").
Reach(x, y) :- Edge(x, "path", y). Reach(x, z) :- Reach(x, y), Reach(y, z).
Reach("a", target)?$$) AS t(target text)ORDER BY 1;
扩展支持本体谓词定义（如DefPred）与compound（如OntologyClaim@(...)）结合，通过compound携带溯源/置信信息，依靠规则实现subclass closure等推理。适用于知识图谱查询、层级数据遍历（组织架构、分类树）、基于规则的业务逻辑系统等场景——当不想引入重量级图引擎时，用扩展补齐最关键的递归查询能力。完全用PL/pgSQL实现，无外部依赖，项目处于早期阶段。
- logical_ddl —— 逻辑复制的DDL同步缺失拼图
PostgreSQL逻辑复制仅处理DML（INSERT/UPDATE/DELETE），不处理DDL（ALTER TABLE等），这是运维中的痛点——表结构不同步会直接中断复制。logical_ddl由Samed Yildirim开发，通过事件触发器拦截DDL命令，反解析后保存到可逻辑复制的表中，订阅端接收后生成等效SQL执行。
支持的DDL操作包括：ALTER TABLE RENAME TO/RENAME COLUMN/ADD COLUMN/ALTER COLUMN TYPE/DROP COLUMN。数据类型兼容性：内建类型、数组、复合/域/枚举类型可用，但这些类型的"定义复制"（如CREATE TYPE）不在覆盖范围。可通过logical_ddl.publish_tablelist实现表和命令级别的精细化捕获控制。
-- 发布端配置INSERT INTO logical_ddl.settings (publish, source) VALUES (true, 'publisher1');
-- 将逻辑复制所有表加入DDL追踪INSERT INTO logical_ddl.publish_tablelist (relid)SELECT prrelid FROM pg_catalog.pg_publication_rel;
-- 按表指定捕获DDL类型INSERT INTO logical_ddl.publish_tablelist (relid, cmd_list)VALUES ('my_table'::regclass, ARRAY['ADD COLUMN', 'DROP COLUMN']);
适用于逻辑复制环境的自动化DDL同步、零停机迁移、多数据中心PostgreSQL架构等。将"DDL同步"从流程管理变为可审计的数据流，显著降低复制事故概率。MIT许可证，PGXN可用。约束、索引、默认值等尚未实现。
- rdf_fdw —— 用SQL桥接语义网世界
rdf_fdw由Jim Jones开发，是通过SPARQL端点访问RDF三元组存储的Foreign Data Wrapper，架起关系型SQL世界与语义网/关联数据世界的桥梁。引入rdfnode数据类型处理RDF术语（IRI、语言标签、数据类型），支持WHERE/LIMIT/ORDER BY/DISTINCT等条件的SQL-to-SPARQL下推，以及通过SPARQL UPDATE端点执行INSERT/UPDATE/DELETE。
-- 创建指向DBpedia的外部服务器CREATE SERVER dbpedia FOREIGN DATA WRAPPER rdf_fdw OPTIONS (endpoint 'https://dbpedia.org/sparql');
-- 创建外部表映射SPARQL查询CREATE FOREIGN TABLE dbpedia_query ( p rdfnode OPTIONS (variable '?p'), o rdfnode OPTIONS (variable '?o')) SERVER dbpedia OPTIONS ( sparql 'SELECT ?p ?o WHERE {<http://dbpedia.org/resource/Berlin> ?p ?o}');
-- 用标准SQL查询RDF数据SELECT * FROM dbpedia_query WHERE o = 'some_value' LIMIT 10;
rdf_fdw_clone_table()存储过程支持将外部表数据分批克隆到本地表。实现层面会将拉取数据加载到内存再转换，面对大规模数据需谨慎评估内存与下推效果。适合关联数据集成（DBpedia、Wikidata）、用SQL/BI工具链直接消费SPARQL端点等场景。MIT许可证，支持PG 9.5–18。
- pgbson —— 比JSONB更精确的二进制文档存储
pgbson（postgresbson）由buzzmam开发，为PostgreSQL引入原生BSON（Binary JSON）数据类型。相比JSON，BSON提供一等公民的datetime、decimal128、int32/int64、binary等类型，解决分布式系统数据交换中的精度丢失和类型模糊问题，确保二进制完美往返（BSON in = BSON out）。
核心API分两类访问方式：高性能dotpath函数——bson_get_string(bson, 'd.recordId')、bson_get_datetime()、bson_get_decimal128()等，直接在底层结构行走，仅终点分配内存；类似JSON的->/->>链式操作符，但每一步构造中间子结构，深层路径成本放大。配合B-Tree和HASH索引，函数索引可实现10,000倍查询加速（vs顺序扫描）。输入端支持EJSON格式。
-- 插入带丰富类型的EJSON文档INSERT INTO data_collection (data) VALUES ( '{"d":{"recordId":"R1","amt":{"$numberDecimal":"77777809838.97"}, "ts":{"$date":"2022-03-03T12:13:14.789Z"}}}');
-- 函数索引 + dotpath查询（推荐模式）CREATE INDEX ON data_collection(bson_get_string(data, 'd.recordId'));SELECT bson_get_decimal128(data, 'd.amt')FROM data_collection WHERE bson_get_string(data, 'd.recordId') = 'R1';
-- 箭头链式访问（深层路径性能较差）SELECT (data->'d'->'amt'->>'$numberDecimal')::numeric FROM data_collection;
典型场景：跨语言事件/文档管道（Java→Kafka→Python→PostgreSQL）的精确类型保持、金融数据（decimal128精确到分）、数字签名（BSON的确定性二进制格式支持可靠哈希）等。MIT许可证，支持PG 14–18。
- pg_when —— 自然语言时间解析器
pg_when由frectonz开发，将自然语言时间表达解析为PostgreSQL的timestamptz或epoch时间戳。核心函数when_is(text)返回标准timestamp，语法由三部分组成：日期 + at + 时间 + in + 时区。未指定时区时默认为UTC。
SELECT when_is('5 days ago at this hour in Asia/Tokyo');SELECT when_is('next friday at 8:00 pm in America/New_York');SELECT when_is('in 2 months at midnight in UTC-8');SELECT when_is('December 31, 2026 at evening');
另有seconds_at()、millis_at()、micros_at()、nanos_at()返回不同精度的UNIX时间戳。这不是调度器，而是纯解析器。适用于运营/客服系统的"人类时间输入"落库、数据修复/回填脚本中的自然语言时间替代拼写函数、统一时区处理等场景。MIT许可证。
- pgmqtt —— 数据库变更直连MQTT消息总线
pgmqtt由RayElg开发（Rust实现），将PostgreSQL变更（INSERT/UPDATE/DELETE）通过CDC直接转换为MQTT消息推送给订阅者，同时支持MQTT入站消息按映射写回表。它不是通用MQTT客户端，而是将"变更流"与"消息broker"嵌入数据库侧，通过SQL配置topic映射与payload模板。
-- 出站：表变更 → MQTT topic（支持模板化topic和JSON payload）SELECT pgmqtt_add_outbound_mapping( 'public', 'my_table', 'topics/{{ op | lower }}', '{{ columns | tojson }}');
-- 入站：MQTT topic → 表（JSONPath规则映射到列）SELECT pgmqtt_add_inbound_mapping( 'sensor/{site_id}/temperature', 'sensor_readings', '{"site_id": "{site_id}", "value": "$.temperature"}'::jsonb);
IoT场景尤为适用——无需外部中间件即可将数据库状态变化推送至边缘设备，或将传感器数据直接写入表。也适用于事件驱动架构中的轻量级消息分发，减少应用层胶水代码。Elastic License 2.0。
- pg_query_rewrite —— 运行时SQL透明替换引擎
pg_query_rewrite由Pierre Forstmann开发，利用ProcessUtility hook实现SQL语句的运行时透明替换。规则基于精确字符串匹配（大小写和空格敏感）存储于共享内存。
-- 添加重写规则SELECT pgqr_add_rule('select 10;', 'select 11;');
-- 此后执行"select 10;"将返回11SELECT 10; -- 返回11
-- 查看所有规则及重写计数SELECT pgqr_rules();
这是一把"锋利双刃剑"：不支持参数化语句、最大长度约32KB、匹配对大小写/空格/分号敏感、规则不持久化（重启丢失，需借助启动SQL机制恢复）。适用于数据库迁移期间对遗留系统固定SQL做透明重定向、危险查询临时拦截、查询A/B测试等。默认最多10条规则，支持PG 9.5–18。
- pgclone —— 数据库对象一键克隆工具
pgclone由valehdba开发（PGXN发布2.0.0版），定位直白：无需pg_dump/pg_restore、无需shell脚本，直接通过SQL函数将表、schema、数据库、函数（甚至角色与权限）从源实例克隆到目标环境。
使用COPY协议实现高速数据传输，支持异步操作与进度跟踪，支持选择性克隆（列/行过滤），DDL全覆盖（索引、约束、触发器、视图、物化视图、序列等），还提供数据脱敏与敏感列自动发现能力。
-- 克隆远程表到本地（含数据）SELECT pgclone_table( 'host=source-server dbname=mydb user=postgres password=secret', 'public', 'customers', true);
-- 克隆整个远程数据库SELECT pgclone_database( 'host=source-server dbname=mydb user=postgres password=secret', true);
适用于开发/测试环境快速搭建（含DDL、索引）、生产到预发的"带脱敏克隆"、多库迁移与验证等。相比pg_dump/pg_restore，它完全在数据库内部完成，极大简化DevOps流程。
- pgproto —— Protocol Buffers原生支持
pgproto由Apaezmx开发，为PostgreSQL提供原生Protocol Buffers（proto3）存储、查询、修改和索引能力。核心机制是"运行时Schema注册 + 二进制遍历"：将FileDescriptorSet注册到pb_schemas后，protobuf类型列即可通过路径数组提取嵌套字段。引入->字段导航、#>嵌套路径访问、||消息合并等操作符，以及pb_set()/pb_insert()/pb_delete()/pb_to_json()等函数。
-- 嵌套字段提取SELECT data #> '{Outer, inner, id}'::text[] FROM items;
-- 局部更新（返回新protobuf值）UPDATE items SET data = pb_set(data, ARRAY['Outer', 'a'], '42');
-- B-Tree表达式索引CREATE INDEX idx_pb ON items ((data #> '{Outer, inner, id}'::text[]));
在10万行基准测试中，pgproto存储仅16 MB（JSONB 46 MB，原生关系表25 MB），全文档检索5.9ms（关系模型33.1ms需多表JOIN）。当需要保留Protobuf生态（RPC/消息）同时实现数据库侧索引与过滤时，这是极具吸引力的方案。适合IoT数据存储、微服务事件仓库、gRPC数据层等。PostgreSQL License。
- pg_fsql —— JSONB驱动的递归SQL模板引擎
pg_fsql由yurc开发，将"SQL模板渲染 + 安全参数化执行 + 模板树递归组合"封装为扩展。模板按dot-path组织成树，子模板产出片段或JSON后注入父模板。支持占位符语法（{d[key]}及不同转义!r/!j/!i）、SPI plan cache（按模板可选缓存）、多种命令类型（exec/ref/if/exec_tpl/map/NULL），以及fsql.run执行、fsql.render dry-run、fsql.tree、fsql.explain等公共API。无需superuser权限。
-- 定义模板INSERT INTO fsql.templates (path, cmd, body)VALUES ('user_count','exec', 'SELECT jsonb_build_object(''total'', count(*)) FROM users WHERE status = {d[status]!r}');
-- 执行模板SELECT fsql.run('user_count', '{"status":"active"}');
-- 渲染但不执行（dry-run）SELECT fsql.render('user_count', '{"status":"active"}');
这不是函数式SQL，而是层次化模板引擎：目标是用JSON请求体驱动SQL生成，减少应用层代码分支。适用于动态报表生成、ETL管道编排、多租户查询生成、将差异化SQL固化在模板表中配合权限管理等场景。
- pg_dispatch —— 基于pg_cron的异步SQL分发器
pg_dispatch由Snehil Shah开发，是异步任务分发器，定位为TLE兼容的pg_later替代品，底层依赖pg_cron。核心函数pgdispatch.fire(command)立即异步执行SQL，pgdispatch.snooze(command, delay)延迟执行。设计目标是解锁主事务——当AFTER INSERT触发器需执行重操作时，将其卸载为后台任务。
SELECT pgdispatch.fire('SELECT pg_sleep(40);');SELECT pgdispatch.snooze('SELECT pg_sleep(20);', '20 seconds');
TLE兼容（纯PL/pgSQL），可在Supabase、AWS RDS等沙盒环境使用。依赖pg_cron >= 1.5。适合触发器/函数内的异步副作用（通知、异步汇总、写审计表等），避免长事务占用连接。
- block_copy_command —— COPY命令安全加固防火墙
block_copy_command由rustwizard开发（Rust/pgrx），通过ProcessUtility hook集群级拦截COPY命令。在安全敏感环境（PCI-DSS、HIPAA合规）中防止通过COPY TO进行数据外泄，或通过COPY FROM执行未授权数据导入。
提供基于角色的blocklist、方向控制（block_to/block_from），对COPY ... TO PROGRAM强制阻断（默认拦截所有用户）。blocked_roles甚至可阻止superuser。支持完整审计日志。
COPY my_table TO STDOUT; -- 非superuser：ERRORCOPY (SELECT 1) TO PROGRAM 'cat'; -- 默认：对所有用户阻断
-- 查看审计日志SELECT ts, current_user_name, copy_direction, blocked, block_reasonFROM block_copy_command.audit_logWHERE ts > now() - interval '1 hour'ORDER BY ts DESC;
适用于托管/共享环境（防止租户用COPY导数据）、企业合规（统一拦截与审计）、ETL权限收敛（通过GUC/角色配置精确允许导入、阻断导出）。作者同时维护更全面的命令防火墙扩展pg_command_fw。
- pg_isok —— 数据质量的"软触发器"体系
pg_isok（Isok）由Karl O. Pinc开发，已在生产环境稳定运行超过十年。它不同于传统约束/触发器，而是"软触发器"式数据完整性管理：你编写SQL找出可疑数据模式，Isok负责记录/分类/延后这些发现，并报告"新增问题或已接受数据的变化"，避免反复审阅历史问题。
-- 典型Isok查询：找出"客户无订单"可疑模式INSERT INTO isok.isok_queries (query) VALUES ( 'SELECT customers.id::text, ''Customer '' || customers.id || '' has no related ORDERS'', NULL FROM customers WHERE NOT EXISTS ( SELECT 1 FROM orders WHERE orders.customerid = customers.id )');
与硬约束（拒绝数据）不同，它允许可疑数据存在但持续追踪——通过isok_queries和isok_results表组织工作流，run_isok_queries函数执行检查，逐行接受或延迟告警。适合"脏数据导入后逐步清理"“业务规则模糊需人工裁决"场景。能写SQL即可上线一套"告警+去重+延期"机制。
- external_file —— PostgreSQL版Oracle BFILE
external_file由Gilles Darold（HexaCluster Corp）维护，提供与Oracle BFILE等效功能：通过目录别名+文件名的EFILE类型引用服务器端外部文件，支持读取（readEfile()）、写入（writeEfile()）和复制（copyEfile()）。通过lo_*机制执行读写，用目录别名表与权限表控制访问范围。
-- 注册目录INSERT INTO directories(directory_name, directory_path) VALUES ('MY_DIR', '/data/files/');
-- 读取外部文件SELECT readEfile(efilename('MY_DIR', 'document.pdf'));
-- 将bytea列写入外部文件SELECT writeEfile(my_bytea_column, efilename('MY_DIR', 'output.bin')) FROM my_table;
为Ora2Pg迁移场景量身定制，也适合"文件在库外、元数据在库内"的遗留系统，以及数据库侧管理外部大对象的批处理导入导出。
- byteamagic —— bytea内容的文件类型侦探
byteamagic由Nico Mandery开发，封装libmagic（Unix file命令底层库），提供两个函数：byteamagic_mime(bytea)返回MIME类型，byteamagic_text(bytea)返回人类可读的文件描述。
SELECT byteamagic_mime(file_data) FROM file_storage WHERE id = 1;-- 'image/png'
SELECT byteamagic_mime(data) AS mime_type, count(*)FROM uploads GROUP BY 1 ORDER BY 2 DESC;
当不得不在表中存储bytea/BLOB时，可在SQL层面识别二进制真实类型（PDF、PNG等）。适合附件/上传内容治理（识别真实类型、防止伪装）、Content-Type自动识别、历史BLOB数据清理等。
- pg_text_semver —— 无限制的语义版本号类型
pg_text_semver由Rowan Rodrik van der Molen开发，基于text DOMAIN实现完全符合Semantic Versioning 2.0.0规范的版本类型。与C实现的semver扩展不同，它对版本号各部分无32位整数大小限制。
SELECT '0.9.3'::semver < '0.11.2'::semver; -- true（语义比较，非字典序）SELECT '1.0.0-alpha'::semver < '1.0.0'::semver; -- true（预发布 < 正式版）SELECT '8.8.8+bla'::semver = '8.8.8'::semver; -- true（构建元数据忽略）SELECT semver_parsed('1.0.0-a.1+commit-y');-- (1, 0, 0, 'a.1', 'commit-y')
纯SQL实现，支持min/max聚合和PGXN版本范围检查。适用于扩展/包版本管理、依赖约束校验、版本分布统计等。
- parray_gin —— text[]数组的子串匹配索引
parray_gin由Eugene Seliverstov开发，为text[]数组列提供基于GIN索引的部分匹配操作符。标准PostgreSQL GIN数组操作符仅支持精确元素匹配，parray_gin新增的@@>操作符支持子串包含判断，底层基于trigram分解（复用pg_trgm实现），通过recheck处理误报。
CREATE INDEX ON test_table USING gin (val parray_gin_ops);
-- 'post'子串匹配'postgresql'SELECT * FROM test_table WHERE val @@> array['post'];
-- 支持LIKE模式的部分包含SELECT * FROM test_table WHERE val @@> array['%ar%'];
适合标签系统自动补全、模糊标签搜索等场景——让数组模糊匹配进入索引路径，替代应用层扫描。支持PG 9.1–18。
- pg_slug_gen —— 加密安全的时间戳短标识生成器
pg_slug_gen由Fernando Olle开发，生成基于时间戳的加密安全唯一短标识。使用pg_strong_random()选择字符，slug长度决定时间戳精度：10字符（秒）、13（毫秒）、16（微秒，默认）、19（纳秒）。
SELECT gen_random_slug(); -- 微秒精度SELECT gen_random_slug(10); -- 秒精度SELECT gen_random_slug(19); -- 纳秒精度
注意这不是URL slug生成器（从标题转写），而是"安全短ID"方案。适合邀请码/短链接/公开资源ID（避免自增ID暴露业务规模）、分布式写入（时间戳维度提供可控无碰撞窗口）等。比base62(序列)更难预测。
- pglock —— PostgreSQL内的轻量级分布式锁
pglock由fraruiz开发，在PostgreSQL内部实现轻量级分布式锁服务。基于锁表和一组函数（pglock.lock/pglock.unlock/pglock.ttl/pglock.set_serializable）实现，支持TTL过期机制（默认5分钟），可选配合pg_cron定时执行pglock.ttl()清理过期锁。建议使用SERIALIZABLE隔离级别保证并发语义正确性。
-- 获取锁SELECT pglock.lock('b3d8a762-3a0e-495b-b6a1-dc8609839f7b', 'users');
-- 释放锁SELECT pglock.unlock('b3d8a762-3a0e-495b-b6a1-dc8609839f7b', 'users');
-- 清理过期锁SELECT pglock.ttl();
无需外部依赖（Redis、ZooKeeper等），适用于多实例应用抢占任务/资源（定时任务、幂等消费者）、Leader选举、防止重复任务执行等场景。锁行为与业务写入可在同一数据库生态中统一治理。纯SQL实现。
- regresql —— 语言无关的SQL回归测试框架
regresql由boringSQL（Radim Marek）开发，是独立CLI工具（Go编写），非PostgreSQL扩展。它扫描项目中的*.sql文件，运行并保存输出快照与EXPLAIN计划基线，后续运行时对比差异，在CI中捕获查询结果变化与性能回退。支持JUnit/GitHub Actions/pgTAP输出格式。
-- 在.sql文件中用注释标记查询名称-- name: get-user-by-idSELECT * FROM users WHERE id = :id;
-- name: list-active-usersSELECT * FROM users WHERE active = true;
工作流围绕discover/add/update/test/baseline/snapshot等命令组织。适合SQL快照测试（迁移/重构后快速发现结果差异）、EXPLAIN基线（CI中捕获plan flip或seq scan退化）、将"SQL确认过的输出"版本化管理。
- pgcalendar —— 无限投影的循环日程系统
pgcalendar由h4kbas开发，提供完整的循环事件日历系统：事件（events）是逻辑实体，日程（schedules）定义循环模式（每日/每周/每月/每年），投影（projections）生成实际发生时间，例外（exceptions）修改单个实例（取消、改期）。
-- 创建事件和日程INSERT INTO pgcalendar.events (name, description, category)VALUES ('Daily Standup', 'Team standup meeting', 'meeting');
INSERT INTO pgcalendar.schedules (event_id, start_date, end_date, recurrence_type, recurrence_interval)VALUES (1, '2024-01-01 09:00:00', '2024-12-31 23:59:59', 'daily', 1);
-- 投影：生成一周实际发生时间SELECT * FROM pgcalendar.get_event_projections(1, '2024-01-01', '2024-01-07');
-- 添加例外：取消某天INSERT INTO pgcalendar.exceptions (schedule_id, exception_date, exception_type, notes)VALUES (1, '2024-01-15', 'cancelled', 'Holiday');
-- 切换日程配置SELECT pgcalendar.transition_event_schedule( p_event_id := 1, p_new_start_date := '2024-02-01 09:00:00', p_new_end_date := '2024-06-30 23:59:59', p_recurrence_type := 'weekly', p_recurrence_interval := 2, p_recurrence_day_of_week := 1);
“无限投影"“多段schedule配置切换"“例外处理"这类能力在排班、会议、计费周期等场景极为常见，但应用层自行实现往往细节爆炸。将日程逻辑下沉到数据库后，权限、审计与一致性约束更容易统一管理。
- pg_variables —— 比临时表高效的会话变量
pg_variables由Postgres Professional开发，提供会话级变量支持，涵盖标量、数组和记录（集合）类型。变量按命名包（package）组织，“是否事务性"可配置：默认变量不随BEGIN/ROLLBACK回滚，但is_transactional = true时遵守ROLLBACK/SAVEPOINT语义。
SELECT pgv_set('vars', 'int1', 101);SELECT pgv_get('vars', 'int1', NULL::int); -- 返回101
-- 事务性变量：跟随SAVEPOINT回滚BEGIN;SELECT pgv_set('vars', 'tx_val', 101, true);SAVEPOINT sp1;SELECT pgv_set('vars', 'tx_val', 102, true);ROLLBACK TO sp1;COMMIT;SELECT pgv_get('vars', 'tx_val', NULL::int); -- 返回101
-- 记录集合操作SELECT pgv_insert('pack', 'employees', row(1, 'Alice'::text));SELECT * FROM pgv_select('pack', 'employees');
作为临时表的高性能替代，避免目录膨胀（catalog bloat）。适合复杂存储过程/批处理中的中间状态保存、连接级信息缓存，也作为其它扩展的基础设施（如pgelog用它缓存dblink连接）。
- pgelog —— 回滚不丢的自治事务日志
pgelog由anfiau开发，通过dblink实现伪自治事务，使日志记录在调用事务回滚时依然持久化。这解决了PL/pgSQL EXCEPTION块中日志在ROLLBACK后丢失的经典问题。dblink连接通过pg_variables做会话级缓存优化。
-- 即使外层事务回滚，日志依然保留DO $$BEGIN PERFORM 1/0; -- 触发除零错误EXCEPTION WHEN OTHERS THEN PERFORM pgelog_to_log('FAIL', 'my_func', 'division by zero', '1', SQLERRM, SQLSTATE); RAISE;END $$;
-- 查询日志SELECT log_stamp, log_info FROM pgelog_logs ORDER BY log_stamp DESC LIMIT 5;
-- 配置日志TTLSELECT pgelog_set_param('pgelog_ttl_minutes', '2880');
关键流程审计时，业务事务回滚不应丢失诊断线索。批处理/迁移脚本中，阶段性日志比单纯RAISE NOTICE更具查询价值。依赖dblink和pg_variables扩展，每个会话可能额外打开一个连接，需评估max_connections影响。
技术趋势总结
这32个新星扩展背后浮现出五条清晰的技术演进脉络。
第一，专业化对象的数据库原生内化。从化学分子、RDF三元组、BSON、Protobuf到循环日程，这些扩展将PostgreSQL从"结构化表存储"推向"可查询的复杂对象容器”。权限、审计、备份、事务语义等基础设施复用数据库原生能力，大幅削减数据搬运和外部服务依赖。
第二，查询能力向组合式API演进。RRF融合、SQL模板树、查询重写、稀疏计算、近似摘要结构等扩展的共同目标，是让复杂逻辑用更少、更稳定的SQL片段表达，同时保持可审计、可复跑和可优化。
第三，生产工程与平台化能力加速下沉。从pg_stat_ch的实时遥测外送、pg_datasentinel的容器资源洞察，到block_copy_command的安全钩子、pg_isok的软告警治理——扩展层正在承接越来越多"原本需外部系统"的能力。
第四，垂直领域渗透持续深化。从化学信息学（rdkit）、水文分析（pghydro）到哈萨克语NLP（pg_kazsearch），PostgreSQL正成为越来越多专业领域的计算底座。
第五，新语言运行时探索开启新篇章。pg_typescript将Deno/V8嵌入PostgreSQL的实验，可能预示存储过程开发体验的下一轮革新——数据库函数首次可用与应用层完全相同的语言和工具链编写。
PostgreSQL扩展生态正是如此：既有大教堂（Apache基金会项目），也有集市（个人周末项目），共同构建着世界上最先进的开源数据库。