PostgreSQL 社区周报（第 3 期）：PG 真的赢了吗？

2026 年 11 月，Postgres 社区周报 第 3 期，本周新闻速递。

目录

PostgreSQL 真的赢了吗？

• 人气确实在上升：DB-Engines 显示 PostgreSQL 从 2013 年约 200 分升至如今近 700 分，前三大数据库则缓慢下滑；但该分数衡量的是搜索、招聘、Stack Overflow、社交媒体等“人气”，不等于装机量、营收或生产负载。
• 迁移主因很现实：许可费与审计压力、云上托管 PostgreSQL、避免厂商锁定、功能“够用且常更好”（JSONB、复制、分区、PostGIS/pgvector/TimescaleDB/Citus 等扩展）、开发者人才与创业公司默认选择、AI 向量检索需求。
• “免费小狗”有隐性成本：省下许可费，但要投入 DBA、工具集成（Patroni、pgBackRest、PgBouncer 等）、支持合同，以及从 Oracle/SQL Server 迁移时的重写、测试和培训成本。
• PostgreSQL 19 暴露社区模式压力：版本延期至 2026 年 11 月 19 日，beta 期间撤回头条功能如 SQL/PGQ 图查询；作者认为质量优先是负责任的，但对企业客户可能显得不可预测。
• 继续攀升面临挑战：Oracle/SQL Server 存量应用巨大、社区决策慢、提交者带宽有限、生态碎片化、高可用/大版本升级/超大库工具等运维缺口仍在，且排名具有相对性。
• 竞争对手仍可反击：Oracle 可简化许可、提供免费层或降价并强调企业级能力；MySQL 可加强开源版和路线图；SQL Server 可打 Azure/Fabric/Power BI/Copilot 集成与捆绑牌。
• 若价格归零：PostgreSQL 的成本优势会减弱，新迁移动机下降，企业功能差距更明显；但它仍保有许可证不可撤销、无单一厂商锁定、扩展生态、开发者心智和信任优势。
• 结论：PostgreSQL 赢的是趋势，不是胜局；可能很快升至第三。关键观察点是它何时在排名上超过 SQL Server、PG19 是否按期干净发布，以及被撤功能是否在 PG20 回归。

深入阅读

确立 PostgreSQL 标准：PGConf.dev 2026 第二部分

• 作者与 Hettie Dombrovskaya 在 PGConf.dev 2026 温哥华站社区讨论环节，分享了“什么才算 PostgreSQL 兼容”的工作坊成果，延续 PGConf.EU 2025 里加工作会议和 FOSDEM 讨论。
• 介绍了参考实现 postgres-compat：运行三类测试引擎并生成统一报告，主要复用 PostgreSQL 自带的 pg_regress 和 pg_isolation_regress 测试套件，逐字节比对输出。
• 测试覆盖 200 个回归测试和 117 个隔离测试；对于上游套件无法表达的兼容性问题，用 YAML 探针补充，包括静默失败、运行时配置和 contrib 扩展行为。
• 关键规则包括：测试分为 Core 和 Optional，只有 Core 失败才导致运行失败，跳过不计为失败；遵循“功能兼容，而非逐 bug 复刻”，但必须匹配上游回归输出。
• 静默失败也算失败：语句返回成功但未实际生效即判失败；测试工具必须适用于托管服务，不在目标上创建/删除数据库，权限拒绝与功能缺失分开报告。
• 厂商自行发布兼容性报告，社区可复现和验证，但不充当把关者。
• 当前项目以 PostgreSQL Licence 公开，支持 PostgreSQL 14 至 18，已有 74 个 YAML 探针（55 个 Core、19 个 Optional）；尚无正式发布，且仅连接单一目标，暂未覆盖双向逻辑复制、混合集群、Patroni/repmgr 等场景。
• 作者还与多种编程语言 PostgreSQL 驱动维护者讨论了纳入驱动回归测试；项目暂被搁置但未放弃，后续将发布 PGConf.EU 2026 瓦伦西亚参会总结等文章。

深入阅读

PGConf.EU 2026 上的自主 Postgres：从脚本到自动驾驶，以及其间的原语

• 核心问题：Postgres 正从“由 DBA 操作”走向“越来越能自我运维”，但真正缺口不是让数据库更聪明，而是让它可被智能体读懂：能描述自身结构、数据语义、正常行为、权限边界和可变更范围。
• “最小知识”原则：类似最小权限，给每个智能体只提供其任务所需的信息切片，既缩小上下文，也限制混乱或被攻破的智能体可能泄露/误用的范围。
• 三角框架：AI 服务分析师、AI 服务 DBA、AI 价值生成与治理。实际讨论中，治理不是独立一角，而是把另外两角维系在一起的力量。
• 库内还是库外是光谱，不是二选一：共同原则是“从内部观察、在策略下决策、通过窄门行动”；无论推理在哪里运行，证据和边界都应留在数据库中。
• 模型提出，系统裁决：模型可检测、解释、建议，但不应做最终裁判；最终决定应来自策略、规则或统计证据。
• 自主性应按可逆性、影响范围和时机逐级提升，而非只按动作类型判断。看似“便宜”的建索引也可能在高峰期造成高代价；应先模拟、限定范围、安排窗口，再执行。
• 语义层是分析师场景最薄弱处：真实私有 schema 上 Text-to-SQL 准确率远低于学术基准；应把语义、注释、连接提示和可信参数化查询存入 Postgres，并由数据所有者批准含义。
• 缺的是“连接组织”：roles、grants、COMMENT ON、pg_constraint、application_name、pg_stat_statements、事务等部件大多已有，但还缺让智能体可依赖、DBA 可推理的原语。
• 建议推进共享开放 MCP 契约：标准读工具、受控写工具，并把每个工具映射到角色、裁决和审计记录；后续可建工作组、收集失败案例，把治理从共识变成 Postgres 可提供的机制。

深入阅读

AI 能写 SQL 吗? — Bruce Momjian

核心结论：AI 能有效生成 SQL，但存在明确边界

• 能力已验证：AI 可以从纯英文描述生成可执行的 SQL 查询。演讲以 Pagila 示例数据库（视频租赁场景，15 张表，含外键）为测试环境，覆盖了从简单聚合到涉及 EXISTS、多表关联的业务查询。

• 方法：借助 MCP（模型上下文协议）而非传统 RAG。MCP 允许 AI 动态发现并调用外部数据源与工具，克服了 RAG 只能使用程序员预先设定内容、无法根据输出质量调整后续行为的局限。

• 复杂业务语义仍需要人类判断。例如，“2023 年从未被租过的视频”这一需求存在歧义——“视频”是指全部影片，还是仅指库存中存在的影片。最终输出被按库存状态排序，以对冲这种不确定性。

• 核心局限一：真实数据库远比示例复杂。对象和行数更多、命名一致性更差、数据质量更参差，且常常缺少约束。

• 核心局限二：演讲中的示例几乎全是只读查询，且未涉及安全控制。这意味着在写入型 DML 和生产环境的安全边界上，结论尚未得到验证。

• 底层原因：LLM 本身不擅长离散数据、动态数据和精确性。SQL 查询恰恰依赖这三者——表关系是离散的，业务数据是动态变化的，结果必须精确而非“统计上合理”。

深入阅读

在 PostgreSQL 中删除一张 4 TB 的表

• 背景：GitLab 有一张 4 TB 归档表，主库带 10 个副本，目标是“可控地删掉”。DROP TABLE 在主库上很快，真正风险在副本回放停顿和锁阻塞。
• DROP TABLE 不会通过 WAL 传输表数据，只传播元数据和待删除的文件编号；主库提交后由后台删除文件，副本也按 WAL 记录删除对应文件。
• DROP TABLE 需要 AccessExclusiveLock，会阻塞所有后续查询。即使只有一个长事务在读表，DROP 排在它后面，其他查询也不能插队，表会一直不可用。
• 建议用短 lock_timeout 加重试循环；外键要单独迁移先删，否则删子表会锁住父表，把锁队列问题扩散到核心表。
• 更稳妥的做法是先重命名表并等一个发布周期，让遗留读路径显式报错；TRUNCATE 是较软方案，只锁子表并换空文件，但副本仍有文件删除成本。
• 副本受影响分两部分：Standby/LOCK 记录会让备库回放进程获取排他锁，若有长查询会阻塞回放，超过 max_standby_streaming_delay（默认 30 秒）会取消查询；文件删除也由回放进程执行，期间回放暂停。
• 文件删除成本主要取决于文件系统、碎片/extent 数和 page cache：冷 ext4 约 17 ms/segment，缓存每 GB 约增加 34 ms；4 TB 在碎片化 ext4 上可能造成约 70 秒回放停顿，XFS 快得多，ZFS 居中。
• 操作建议：外键逐个迁移；先重命名观察；开启 log_recovery_conflict_waits；确认副本文件系统；在低峰执行，配合短锁超时和重试；提前清 page cache 对冷表帮助不大。
• 如果表仍有流量：不要用大 DELETE；按时间分区则用 DETACH PARTITION CONCURRENTLY 后再 DROP，可把停顿限制在单个分区。
• 必须原地删行时，分批 DELETE 比一次性删除温和，但 WAL 量很大，主要来自 full page images；删除后首次 count(*) 还会因 hint bits 产生大量 WAL 和延迟。
• 更优方案是把要保留的少量行复制到新表再切换，WAL 远小于批量删除；但需处理切换期间新写入、更新/删除、外键、权限、索引、统计信息和 prepared transactions 等问题。
• 结论：删除 4 TB 表的关键不是主库 DROP，而是副本回放停顿和锁队列；优先用重命名、分区、复制保留数据等策略拆分风险。

深入阅读

他们如何从在线 PostgreSQL 数据库中迁出 4 TB 数据

• NexHealth 在真实生产流量下，用约三周时间将约 4 TB、覆盖 19,000+ 医疗机构的在线数据迁移到独立数据库，且没有产生客户可感知的事故。
• 迁移目标是把“治疗域”从主库中拆出：该域约 4 TB，其中 procedures 表达 3.3 TB、超过 30 亿条记录，主要是写入后以查询为主的“巨型查找表”，此前显著推高主库 IOPS。
• 关键前提是先做逻辑隔离：审计并消除跨域 join/关联，改为子查询或服务层查询，并通过独立数据库连接让跨域查询在测试和本地开发中直接失败。
• 例外是 procedure codes：最终采用 PostgreSQL FDW 作为参考模型，由主库作为事实来源并通过数据库触发器同步到治疗库，避免跨库查询耦合和易出错的双写。
• 物理迁移使用 PostgreSQL 逻辑复制，按客户规模从小到大分批推进，先内部测试机构、再早期客户、最后大型企业客户，以控制爆炸半径。
• 遇到的主要问题包括：REPLICA IDENTITY FULL 不会传播到范围分区；批次过大导致 WAL 累积和复制槽失效；逻辑复制回填会给主库磁盘带来隐藏 I/O 压力。对应做法是工具化补齐分区配置、缩小批次、避免并发回填，未来考虑从只读副本复制。
• 结果：主库 IOPS 消耗下降 30%，缓存未命中率从约 4% 降至约 3%，相当于约 30% 的网点容量余量；下一步是继续建设按工作负载拆分的目的性数据系统。

深入阅读

pg_duckdb 1.2.0 发布

• 版本状态：1.2.0 为“实验性”版本，尚不适合生产使用；仍有多项用户报告的严重问题待后续版本修复。
• DuckDB 升级：适配 DuckDB v2.0.0。
• 安装与兼容性：支持安装到非 public schema；支持在事务中创建 pg_duckdb 扩展；增加初始 PostgreSQL 19 支持并修复 PG19 兼容性；修复 macOS 信号处理。
• 功能增强：支持 read_text 和 read_blob；为 Vortex 核心扩展的 read_vortex 增加 Postgres 包装；支持对 Postgres 表执行 INSERT ... INTO ... SELECT ...。
• 修复与改进：自动根据 git describe 设置模块版本；修复视图中 ContainsPostgresTable 触发问题、错误信息措辞问题，以及加载 secrets 后恢复 top_level_statement 等问题。
• 构建与发布：支持有/无 vcpkg 依赖构建；静态构建使用 DuckDB 自带 LZ4；Docker 构建切换为 Clang；新增发布 CI 工作流。
• 新贡献者：本版本新增多位首次贡献者。

深入阅读

不分叉的 Greenplum：将 Apache Cloudberry 作为 PostgreSQL 19 扩展

• 这是作者的个人实验，并非 Apache Cloudberry 官方发布：目标是把 Cloudberry/Greenplum 的 MPP 能力改造成 PostgreSQL 19 的一组扩展，而不是继续维护 PostgreSQL 分叉。
• 动机是分叉长期落后于上游 PostgreSQL，合并升级成本高；扩展方案可直接使用最新 PostgreSQL 生态，如 PostGIS、pgvector 和现成二进制扩展，未来大版本升级也更轻量。
• 成果规模显著：12 天、629 次提交；新增 pg19/ 目录约 43.3 万行；Cloudberry 数据库代码按行约 93% 已移植，不计其 MPP planner “Route B” 约 97%；ORCA 优化器约 38 万行未改直接复用。
• PostgreSQL 核心改动很小：仅 22 个小补丁、47 个文件、+1,578/−41 行，主要新增 OID、事务状态、解析器、表访问方法等扩展点；未加载 Cloudberry 扩展时必须与原生 PostgreSQL 行为一致。
• 原生性经过严格验证：PostgreSQL 自带 371 项测试通过，ABI 仅新增符号无变更，catalog/设置/关键字/查询 ID 字节一致，性能开销约 -0.005% 到 +0.155%。
• 不是简单 FDW：具备 coordinator/segments 架构、查询计划切片下发、Motion 数据传输、分布式快照、两阶段提交、分布式死锁检测、FTS/镜像等 MPP 能力。
• 性能验证：TPC-H 22/22、TPC-DS 99/99 均由 ORCA 规划，答案与 DuckDB 一致；相对非 ORCA 的 gather 回退路线几何平均快 3.1× 和 4.0×。
• 测试覆盖仍不足：Cloudberry 原有 1,180 个测试文件仅 691 个（59%）跑通，后续需扩大 isolation2 和 greenplum_schedule 覆盖。
• 兼容与限制：支持 DISTRIBUTED BY、分区、gpfdist、gp_toolkit、gpMgmt 等；但迁移需逻辑 dump/restore，配置项改为 gp. 前缀，暂以操作系统卷加密替代 TDE，未移植 Route B，ORCA 拒绝的查询会走较慢 gather 路线，且因需要打补丁的核心，不太可能进入主流托管 PostgreSQL 服务。
• 定位对比：Citus 偏分片/多租户，pg_duckdb/pg_lake 偏单机分析，ClickHouse/StarRocks 在向量化扫描聚合上更快；Cloudberry 扩展更适合自托管、复杂大表 JOIN、事务、PL/pgSQL、PostGIS/pgvector 的数仓场景。
• 关键经验：LLM 写代码成功的关键不是“写得快”，而是工程化流程——精确代码研究、原型与测量、测试作为完成标准、并行 worktree，以及人类负责架构决策。

深入阅读

移除 pgrust：该条目存在作弊行为（按查询定制的内核与结果缓存）

• ClickBench 移除了 pgrust 条目，原因是其成绩并非来自通用数据库执行，而是专门为 43 个 ClickBench 查询编写的机制。
• 它存在“逐查询手写内核”：发布二进制中嵌入了 q00.rs 到 q36.rs 等按 ClickBench 查询编号命名的源码路径，并有大量以 clickbench ... 命名的计划匹配与拒绝信息。
• 公开的 v0.3 源码显示，包含“所有 43 个 ClickBench 查询的手工降级物理计划”，部分查询直接由元数据/统计信息回答，Q28 正则还被硬编码为单条目表。
• 热运行实际上是结果缓存：Q20、Q21、Q23 的计划说明称热运行是“对缓存判定结果的纯折叠，零列访问”；EXPLAIN 显示 windowreplay、metaanswer，扫描标记为从未执行。
• 实测显示冷运行与热运行差距异常：Q20 冷运行 10.8 秒，第二/三次仅 11 毫秒/5 毫秒；重启后又回到 11.2 秒，再降到 3 毫秒。
• 该缓存现在无法通过配置关闭；即使关闭 pgrust.gravity_entry 和 pgrust.condition_cache，重复 LIKE 仍只需 3 到 4 毫秒。
• 对 43 个基准查询之外的形状缺乏通用执行路径：轻微改写的查询会报错 statement over columnar relation "hits" is not served，且不支持 INSERT、UPDATE、DELETE。
• 43 个查询的答案本身大多正确，但问题在于它衡量的是“基准查询查找表/缓存回放”，而不是真实数据库能力。

深入阅读

基准测试过拟合之争

• 古德哈特定律在数据库基准测试中同样成立：一旦人们针对某个可量化指标过度优化，该指标就会失去参考价值。
• TPC-D 因过度缓存导致查询时间趋近于零而退役；TPC-H 通过定义为 ad-hoc 基准、禁止利用工作负载知识和缓存结果等方式缓解问题。
• ClickBench 正面临类似问题，且 AI 代码生成显著加剧了过拟合：AI 会逐条查询做微优化，即使这些优化在通用场景中不合理甚至可能产生错误结果。
• 文中以 pgrust 为例：对字符串列 group-by 时仅基于哈希值忽略字符串内容，可能算错；缓存重复谓词以消除第二次查询成本；Q17 利用数据按 userid 聚簇且无 order by 的 limit 特性，几乎不读大部分数据。
• 人类通常不会做这类微小且不具通用性的优化，但 AI 可以逐查询分析并针对性调优。
• ClickBench 自身也有问题：规则不明确、无更新流、查询简单、共享谓词、定义不充分等；但更根本的问题是：一旦针对特定基准激进优化，该基准就不再很有用。
• 历史上“系统还需对真实用户有用”的压力能部分抑制过拟合，但对“凭感觉/AI 生成”的执行引擎，这种约束不存在。
• SQLStorm 用数万条查询增加过拟合难度，但 AI 可逐条分析大量查询，因此并非真正防御。
• 作者认为有意义的基准应：a) 像 TPC-H 一样是 ad-hoc，禁止利用先验知识和任何中间结果缓存；b) 包含更新流，避免只读/读多写少系统不公平占优；c) 真正 ad-hoc，即被测系统早于基准存在。
• 对抗古德哈特定律的一种方式是定期自动生成新基准，并测量基准出现前已存在的系统；但缓存/预计算问题仍然存在。

深入阅读