PostgreSQL 深度入门：事务、MVCC、索引、JSONB、全文检索与备份恢复（横纵综合报告） 未开始

题记与说明

撰写日期：2026-10-31
修订日期：2026-11-01（按独立审读意见逐条修订为最终稿）
报告性质：本报告由同日完成的两份章节稿综合修订而成——纵轴章节《课题纵向研究报告》（发展脉络）与横轴章节《横向对比报告（2026-10-31 截面）》（横向对比）。合并时消除了两稿之间的重复与口径差异（统一说明见文末附录 A），并保留全部来源链接。
核验说明：正文事实绝大多数来自 2026-10-31 当日网络检索与直接抓取的一手来源（官方文档、各版本发布说明、排名页、GitHub 仓库），链接见文末"参考来源"；凡标注 ★ 的条目为社区公认的版本归属或常识性技术事实（两份原稿分别以 ★ 与【模型知识】标注，本稿统一为 ★），未在本次会话逐条核验，引用时请注意复核。正文反复使用的技术术语统一在下方"术语速查"一句话定义，正文不再展开。

术语速查（正文反复使用、首次出现不展开的概念在此定义；运维细节见"四、延伸阅读与常见追问"）：

TL;DR

PostgreSQL 五十年遵循「学术原型给思想、社区给工程、外部压力给时机」：MVCC、WAL、PITR、全文检索进核心、jsonb、增量备份与 AIO 相继落地（1999–2025），每次跃迁都是对外部冲击的回应。2026 年 10 月，它居 DB-Engines 第 4，是前四名中唯一正增长的数据库；在 Stack Overflow 2025 年调查中是最常用数据库。五个能力子专题（事务/MVCC、索引、JSONB、全文检索、备份恢复；事务与 MVCC 合为一项分析，口径见 1.1）恰是护城河：堆内多版本 + VACUUM、六种索引、GIN 同服 JSONB 与全文检索、WAL 一等公民的备份。建议默认选 PostgreSQL：半结构化字段用 JSONB，中小搜索留在库内，文档优先或超大规模搜索再选 MongoDB / ES；学习按 MVCC → 索引 → JSONB → 全文 → 备份推进，步步相承（每个专题的动手入口见"四、延伸阅读与常见追问"）。

一、纵轴：发展脉络（1972–2026）

1.1 一句话总脉络

PostgreSQL 的五十年是一条从伯克利实验室走向全球基础设施的线：Ingres 验证关系模型 → POSTGRES 实验对象关系与多版本雏形 → Postgres95 SQL 化并被社区接管 → 6.x/7.x 打下 MVCC、WAL 的地基 → 8.x 借 PITR、Windows 移植、核心全文检索走向生产级 → 9.x 用流复制和 jsonb 回应互联网与 NoSQL 浪潮 → 10–12 完成逻辑复制、声明式分区与并行化 → 13–18 用增量备份、异步 I/O、B-tree skip scan 保持年更节奏。

子专题口径（全文统一）：标题所列"事务、MVCC、索引、JSONB、全文检索与备份恢复"为六个子专题；由于事务与 MVCC 在 PostgreSQL 中互为一体（MVCC 是事务的实现机制，见 §2.2），后文将二者合为一项分析，因此编年小结（1.11）与交叉洞察（3.1）实际覆盖五个能力子专题——事务/MVCC、索引、JSONB、全文检索、备份恢复；另有并行化一条贯穿性辅线（并行查询 → 并行建索引 → 并行 VACUUM → 异步 I/O），它不是子专题，但因跨越多个子专题而在编年表中单列一行。这五个能力子专题各自都能在这条时间线上找到清晰的落点。

1.2 阶段一：史前与母体（1972–1985）——Ingres 与关系模型的验证

E.F. Codd 1970 年提出关系模型之后，约 1972–1973 年，加州大学伯克利分校的 Michael Stonebraker 与 Eugene Wong 教授启动了 Ingres（INteractive Graphics and REtrieval System）项目，Gerald Held 随后加入、Larry Rowe 后来参与，目的是用可运行的系统验证 Codd 的理论。其奠基论文《The Design and Implementation of INGRES》发表于 1976 年 ACM TODS（华盛顿大学数据库史、论文原文 PDF（CMU 存档））。Ingres 后来被商业化（Relational Technology Inc.，几经易手至 ASK、Computer Associates）。

驱动因素：关系模型在纸面上提出后，学界需要第一个"能跑起来的"多用户关系数据库来证明其可行性；Ingres 与 IBM 的 System R 一起完成了这场验证。Stonebraker 也因包括 Ingres 与 POSTGRES 在内的系列工作获得 2014 年图灵奖。

1.3 阶段二：POSTGRES（1986–1994）——对象关系实验与多版本思想的胚胎

Ingres 之后，Stonebraker 在伯克利启动了"Post-Ingres"——POSTGRES。据官方历史页（A Brief History of PostgreSQL）：

• 项目由 Stonebraker 领导，受 DARPA、陆军研究办公室（ARO）、NSF 与 ESL, Inc. 资助；
• 1986 年开始实现，1987 年出第一个演示版，并在 1988 年 ACM SIGMOD 会议上演示；
• 1989 年 6 月发布 Version 1（向少量外部用户开放）；第一代规则系统遭批评后重设计，1990 年 6 月发布 Version 2；1991 年的 Version 3 加入多存储管理器、改进的查询执行器并重写了规则系统；
• 应用涵盖金融数据分析、喷气发动机监控、小行星追踪、医学数据库与 GIS；商业衍生公司 Illustra（后被 Informix 收购，Informix 现属 IBM）；
• 1992 年底成为 Sequoia 2000 项目的主要数据管理器；最终因支持负担，项目以 Version 4.2 收官。

对课题最关键的一点：POSTGRES 早期以"时间旅行（time travel）"方式保留行的历史版本来实现多版本可见性 ★——这正是后来 MVCC 与 VACUUM 的思想胚胎。课题中"为什么需要 VACUUM、为什么有 xmin/xmax"的历史根源都在这里（横向意义见 3.3 节）。

1.4 阶段三：Postgres95 与更名（1994–1996）——SQL 化与社区接管

伯克利放手后，1994 年两名学生 Andrew Yu 与 Jolly Chen 为 POSTGRES 加上了 SQL 解释器，替换掉 POSTQUEL，以 Postgres95 的名义开源发布到网络。官方历史页记载了这次改动的分量：代码改写为全 ANSI C 并精简 25%，在 Wisconsin Benchmark 上比 POSTGRES 4.2 快 30–50%，新增 GROUP BY、重写聚合函数、带来带 GNU Readline 的 psql、libpgtcl 客户端库、重做的大对象接口，并移除实例级规则系统（保留重写规则）。

1996 年，项目更名为 PostgreSQL，版本号重置为 6.0 以延续伯克利的编号序列，"Postgres" 保留为官方昵称；开发重心从"修补旧问题"转向"增加新能力"（官方历史页）。6.0 于 1997 年 1 月正式发布（版本策略页自 6.3 起有完整日期表）。主要参与者从伯克利课题组变为互联网上的松散黑客社区（Marc G. Fournier、Thomas G. Lockhart、Vadim Mikheev 等组成早期核心组 ★）；驱动因素是开源协作模式与 SQL 标准的普及。

1.5 阶段四：社区化与技术地基（1997–2001）——MVCC 与 WAL 落地

这是对课题核心概念（事务、MVCC、事务日志）最要紧的一段：

• 6.5（1999-06-09）：引入 MVCC（多版本并发控制），由 Vadim Mikheev 实现，以快照式多版本取代旧的表级锁并发模型（6.5 文档 MVCC 章）。
• 7.1（2001-04-13）：WAL（预写日志） 在本版引入并默认启用（7.1.0 发布说明将 WAL 列为首要新特性，并指出 "previous releases of PostgreSQL have forced all data modifications to disk before each transaction commit"——即 7.0 及更早版本尚无 WAL），由 Mikheev 主导（7.1 文档 WAL 章由 Vadim Mikheev 与 Oliver Elphick 撰写，7.1 WAL 文档、7.1.0 发布说明）。7.1 同时引入 TOAST（The Oversized-Attribute Storage Technique），移除约 8KB 的行大小限制、支持约 1GB 大字段，并补上外连接。
• 驱动因素：老式恢复机制与行大小限制成为生产使用的最大障碍；WAL 换来了真正的崩溃安全，也为日后所有复制与备份能力（PITR、流复制、逻辑解码——本质都是"把 WAL 流给出去"）埋下伏笔。

1.6 阶段五：走向生产级（2002–2009）——PITR、Windows、全文检索进核心

这一阶段 PostgreSQL 从"学者与极客的数据库"变成"企业敢用的数据库"：

• 7.3（2002-11-27）：schema 支持、预编译语句 ★；7.4（2003-11-17）：查询规划器大重写 ★。
• 8.0（2005-01-19）：三大里程碑——原生 Windows 服务端（此前只能靠 Cygwin）、SAVEPOINT 嵌套事务、PITR（基于 WAL 连续归档的时间点恢复）。PITR 是课题"备份恢复"主线的制度性起点（8.0 发布说明、版本策略页）。
• 8.1（2005-11-08）：两阶段提交（2PC）、角色（ROLE）体系、autovacuum 后台进程进核心 ★——autovacuum 把 MVCC 产生的死元组清理从"人肉定时任务"变成默认自治。
• 8.2（2006-12-05）：引入 GIN（Generalized Inverted Index），由 Teodor Sigaev 与 Oleg Bartunov 设计，为"值内含元素"的组合值（全文检索、hstore、pg_trgm）提供倒排索引；同版还有在线建索引（CONCURRENTLY）与约 20% 的 OLTP 性能提升（8.2 发布公告、8.2 发布说明）。
• 8.3（2008-02-04）：课题另一主线的高光——全文检索（tsearch2）整合进核心数据库，默认安装（发布说明署名 "Teodor, Oleg"）；同时引入 HOT（Heap-Only Tuples） 更新（Pavan Deolasee），当 UPDATE 不触及索引列时可免写新索引项并即时回收死元组，显著缓解 MVCC 的膨胀痛点；还有 异步提交（Simon Riggs）与 hstore/pg_trgm 的 GIN 支持（8.3 发布说明）。
• 8.4（2009-07-01）：窗口函数、公共表表达式（CTE）、列级权限 ★。

驱动因素：企业市场要求高可用与可恢复性（PITR）、异构桌面环境（Windows）、以及"数据库能不能当搜索引擎用"（GIN + 核心化全文检索）。

1.7 阶段六：复制与 NoSQL 应对（2010–2014）——流复制与 jsonb

互联网爆发期，PostgreSQL 回答了两个生死问题：高可用与半结构化数据。

• 9.0（2010-09-20）：流复制（streaming replication） 与 热备（hot standby）——主库把 WAL 直接流给备库，备库在恢复中可受理只读查询，"主备"时代开始（9.0 发布说明）。
• 9.1（2011-09-12）：基于复制协议的 pg_basebackup 取代 pg_start_backup + rsync/tar 的手工基准备份流程；同版还有同步复制、扩展基础设施（CREATE EXTENSION）★（9.1 发布说明）。
• 9.2（2012-09-10）：引入 json 类型（原样存文本）、仅索引扫描（index-only scans）、SP-GiST、级联复制 ★——PostgreSQL 开始正视 NoSQL。
• 9.3（2013-09-09）：物化视图、LATERAL 连接、initdb --data-checksums 数据页校验和、json 构造函数族 ★。
• 9.4（2014-12-18）：课题主线级事件——jsonb 类型发布。官方发布说明原文：新增 "a more capable and efficient data type for storing JSON data"，署名 Oleg Bartunov, Teodor Sigaev, Alexander Korotkov, Peter Geoghegan, Andrew Dunstan；jsonb 预解析存储（非文本原文），"allows faster access to values within a JSON document, and faster and more useful indexing of JSON columns"；同版 GIN 索引体积缩减、多键查找提速，另引入 逻辑解码（logical decoding，为后来的逻辑复制铺路）、复制槽（Andres Freund, Robert Haas）、ALTER SYSTEM、物化视图无阻塞刷新（9.4 发布说明）。

驱动因素：MongoDB 等文档数据库的冲击，让 PostgreSQL 选择"把文档模型吃进来"而不是丢掉关系内核；云时代的高可用则由流复制 + 复制槽组合回应。

1.8 阶段七：规模化（2015–2019）——并行查询、逻辑复制与 SQL/JSON

• 9.5（2016-01-07）：INSERT ... ON CONFLICT（UPSERT）——社区呼唤了十年的原子 upsert；BRIN（Block Range Index）为超大表提供极小的块区间索引；行级安全（RLS）（9.5 发布说明）。
• 9.6（2016-09-29）：并行查询（并行顺序扫描、并行连接、并行聚合）；全文检索新增词组搜索（<-> 与 <N> 距离算子），官方新闻直言这让 PostgreSQL 更像专用搜索引擎的替代品（9.6 Released!、9.6 发布说明）。
• 10（2017-10-05）：版本号去小数点。内置逻辑复制（基于 9.4 的逻辑解码）、声明式分区、哈希索引可写 WAL（崩溃安全）、SCRAM-SHA-256 认证 ★。
• 11（2018-10-18）：并行创建索引、CREATE PROCEDURE（过程中可做事务控制）、JIT 编译、加列不再重写表 ★。
• 12（2019-10-03）：SQL/JSON Path 语言（SQL:2016 标准，jsonb_path_query 等，带索引支持）、SQL 标准生成列、CTE 物化行为可控（NOT MATERIALIZED）、可插拔表存储接口（12 发布说明）。

驱动因素：多核硬件普及倒逼并行化（9.6–11 一条完整的并行化弧线）；JSON 业务从"存进去"进化到"按标准查出来"。

1.9 阶段八：成熟与当代（2020–2025）——13 到 18

• 13（2020-09-24）：并行 VACUUM（可并行清理索引）、B-tree 去重（deduplication）压缩索引体积、pg_verifybackup 校验工具 ★。
• 14（2021-09-30）：multirange 类型、LZ4/ZSTD 压缩（TOAST 与 pg_basebackup）★。
• 15（2022-10-13）：MERGE 语句、逻辑复制的行/列过滤、public schema 默认不再对所有人可写 ★。
• 16（2023-09-14）：备库上的逻辑解码、pg_stat_io 观测视图、SIMD 加速 ★。
• 17（2024-09-26）：课题"备份恢复"主线十二年一跃——原生增量备份：pg_basebackup --incremental 与配套的 pg_combinebackup，可基于上一次备份只存变化；VACUUM 重写后内存占用最多降 20 倍；JSON_TABLE（SQL/JSON 查询）、MERGE 增强、逻辑复制支持大版本升级（17 发布说明）。
• 18（2025-09-25）：两大性能里程碑——异步 I/O（AIO）子系统（顺序扫描、位图堆扫描、VACUUM 等场景可并行发起多个读请求，社区实测有 2–3 倍顺序扫描提速的报告，且显著缩短崩溃后恢复时间）与多列 B-tree 上的 skip scan（前导列无等值条件也能高效用索引）；另有 UUIDv7、OAuth 2.0 认证、虚拟生成列、时间维度约束 WITHOUT OVERLAPS、支持从备库做逻辑复制、统计信息在重启/升级后保留（PostgreSQL 18 Released!、18.0 发布说明、Bytebase 解读）。

1.10 生态与当下（2025–2026）——写作时点的最新状态

• 版本现状：最新大版本线为 PostgreSQL 18（2025-09-25 发布，当前稳定 minor 为 18.6，另有 17.11、16.15 在支持期内，当日自官网直接抓取）；PostgreSQL 19 已进入收官测试——Beta 1 于 2026-06-04 发布，RC 1 于 2026-10-15 发布，正式版计划 2026-11-19 GA（官方 Beta 信息页、19 RC 1 公告）。官方节奏为每年一个大版本、minor 版本至少每季度一发、每个大版本支持 5 年（版本策略页）。
• 行业地位：PostgreSQL 获评 DB-Engines "DBMS of the Year 2024"，是其第五次夺得该年度桂冠（此前为 2017、2018、2020、2023），为所有数据库之最（OptimaData 报道）；2026 年 10 月排名见横轴 2.1 节。
• 生态外溢：2025 年 8 月，微软宣布将 MongoDB 兼容的 DocumentDB（构建于 PostgreSQL 之上）捐赠给 Linux 基金会，AWS、Google、Microsoft 共同背书，PostgreSQL 成为文档数据库事实底座之争的裁判（2025-08-25 宣布；来源见参考来源 24）。云原生分支（AWS Aurora、Azure、Supabase、Neon 等）与备份恢复第三方工具（pgBackRest、Barman、WAL-G 等）构成繁荣的外围。
• 治理：社区以 PostgreSQL Global Development Group（PGDG） 及各国协会自治运作，无单一母公司——这与商业化数据库形成鲜明对比，也是其"年更、五载支持"节奏能持续的组织基础。

1.11 五个能力子专题编年小结（课题视角，另附并行化贯穿辅线）

1.12 贯穿五十年的一条规律

回看全程，PostgreSQL 的每次跃迁几乎都遵循同一模式：学术原型给思想，社区给工程，外部压力给时机。MVCC 与 WAL 来自伯克利多版本思想与 Mikheev 的工程化；Windows 移植与 PITR 回应企业市场；jsonb 回应 NoSQL；并行查询与 AIO 回应硬件；增量备份与 skip scan 回应云规模数据。而本课题选取的五个能力子专题——事务/MVCC、索引、JSONB、全文检索、备份恢复（口径见 1.1）——恰好各占一个时代的关键落子：1999（MVCC）、2001（WAL）、2005（PITR）、2008（全文检索进核心）、2014（jsonb）、2016（BRIN/并行/词组搜索）、2017（逻辑复制）、2024（增量备份/JSON_TABLE）、2025（AIO/skip scan）。理解这串年份，比记住任何一个语法细节都更接近"深度入门"。

二、横轴：横向对比（2026-10-31 截面）

2.0 对比对象与维度的定义

本课题是"通用关系型数据库深度学习"课题，横轴对手分四组选取：

对比维度与正文小节的对位如下（成熟度作为截面背景放在 2.1 最先呈现，不占用"维度 N"编号；"生态"维度对应水平扩展与兼容生态一节；"适用场景"以 2.9 速查表收束）：

2.1 位置与势能：排名、开发者心智与版本节奏

DB-Engines 排名（2026 年 10 月，当日从 db-engines.com/en/ranking 直接抓取）：

逐项解读：

• 前四名里只有 PostgreSQL 在涨。三大传统巨头同比全部为负，PostgreSQL 一家 +45.56。按这个斜率做线性外推（外推仅供参考）：它与 SQL Server 的差距为 5.72 分（694.47 − 688.75），双方同比动量合计约 66 分/年（+45.56 与 −20.58），照此收窄速度，反超的交叉点落在 2026 年底之前——比此前粗略所写的"2027 年内"更早；考虑到 DB-Engines 分数的月度波动很大（Oracle 单年 −92.98 即为例证），本文只将其作为量级示意，不构成预测。这与纵轴的"DBMS of the Year 2024（第五次夺冠）"构成完整的势能叙事：奖项证明长期势头，当月排名证明势头仍在延续。
• Elasticsearch 同比 −22.55，而 OpenSearch 同比 +3.42、SQLite/DuckDB 等轻量方案在涨——这与"全文检索"子专题的选型结论（很多规模的应用可以留在 PostgreSQL 内部解决，见 2.5 节）方向一致，但人气分变化不等于市场份额转移，此处仅作关注度信号。
• 开发者调查交叉验证：Stack Overflow 2025 调查（约 4.9 万受访者）中 PostgreSQL 是最常用数据库（约 55.6% 的职业开发者使用），且同时是"最受喜爱/最想要"第一名（来源：survey.stackoverflow.co/2025/technology）。
• 版本节奏对照（当日从官网直接抓取）：PostgreSQL 当前稳定版本为 18.6（另有 17.11、16.15 在支持期内），"年度大版本 + 5 年支持"单轨制。MySQL 侧：官网当前提供 26.10.0（Innovation 版 GA）与 26.7.0（LTS 版 GA）两个版本——Oracle 已把 Innovation 轨道改用年份版本号；MySQL 8.0 已于 2026 年 4 月生命周期终止（EOL），8.4 LTS 分支仍在维护（据检索到的 2026 年 10 月 8.4.13 发布记录；来源：MySQL Innovation/LTS 说明、Oracle 官方博客）。学习层面的含义：MySQL 的版本碎片化（8.0 EOL、8.4 LTS、26.x 并存）抬高了学习者的择路成本，而 PostgreSQL 的单轨制更简单。

2.2 维度一：事务与 MVCC——"堆内多版本" vs "undo 派"

这是本课题最核心的子专题，也是 PostgreSQL 与所有主要对手实现差异最大的地方。

关键事实与来源：

• PostgreSQL 不做物理 undo：事务回滚是即时的，因为旧行版本一直留在表里，废弃版本靠 VACUUM 回收；Oracle 与 MySQL 采用独立 undo 存储，PostgreSQL 在表内做多版本（来源：Amit Kapila《Different Approaches for MVCC》）。InnoDB 每条记录保存 TRX_ID 与 ROLL_PTR 指向 undo 链，连 INSERT 都要写 undo 记录（来源：MySQL vs PostgreSQL Internals 系列，见 Reddit 讨论汇总）。
• VACUUM vs purge 的对照：Robert Haas 的经典系列文章对比了两者（MySQL vs. PostgreSQL, Part 2: VACUUM vs. Purge，2011-02，收录于参考来源 26）——两者最终都回收废弃版本，但 PostgreSQL 在堆里做（VACUUM），InnoDB 对 undo 段做（purge 线程）；长事务在两边都是大敌（PostgreSQL 阻塞 vacuum，MySQL 阻塞 undo 清理）。
• 对学习者的含义：PostgreSQL 的 MVCC 代价被"前置"到日常运维（autovacuum 调优、监控死元组、防 XID 回卷），这是 PG DBA 最核心的手艺；MySQL 的代价被"前置"到写入路径（每条 DML 写 undo）和回滚时刻。理解这一点，横向读任何数据库的多版本实现都能举一反三。
• PostgreSQL 18 的 AIO（异步 I/O）显著缩短崩溃后的恢复时间，让"事务持久性"这一课有了新版本的实证素材（来源：PostgreSQL 18 发布说明）。

2.3 维度二：索引——类型数量与表达力的代差

关键事实与来源：

• PostgreSQL 18 为多列 B-tree 索引引入 skip scan，非前导列上的过滤条件也能利用索引（来源：PostgreSQL 18 发布）。
• ★ PostgreSQL 内置 6 种索引访问方法（B-tree、Hash、GiST、SP-GiST、GIN、BRIN），另可经扩展增加（如 bloom），类型数量在主流关系库中最多；MySQL InnoDB 实质只有 B+tree 一族加 FULLTEXT/空间索引。这决定了 PostgreSQL 能用一套引擎覆盖更多工作负载（GIN 同时服务 JSONB 和全文检索是典型例证）。
• ★ 架构差异也影响索引认知：InnoDB 是聚簇索引组织表（二级索引存主键、回表廉价但主键过宽会"传染"所有二级索引）；PostgreSQL 是堆表 + 全部二级索引指向堆元组，HOT 更新可绕开索引维护。这是两派在"索引即一切"与"堆表为中心"哲学上的分野。

2.4 维度三：JSONB——"关系为主、文档为辅"的最强答案

关键事实与来源：

• 三者的本质定位差异：MongoDB 的 JSON 是"原生传输格式与核心模型"，PostgreSQL/MySQL 中 JSON 只是关系表的一种列类型（来源：SolarWinds：JSON Support in PostgreSQL, MySQL, MongoDB and SQL Server）。
• PostgreSQL json 类型存原文文本（写入校验、查询需重解析），jsonb 存解析后的二进制（查询更快、写入略慢）——9.2 与 9.4 两步演进的历史见纵轴 1.7 节（来源：dev.to：JSON vs JSONB）。
• GIN 索引是 JSONB 的胜负手：它为文档内每个键值建立独立索引项，使"JSON 里某个键包含某值"这类文档型查询可用索引完成；MongoDB 则只索引显式声明的字段（来源：Working with JSON Data in PostgreSQL vs. MongoDB）。
• 性能横向看：有实测认为现代 PostgreSQL 的 JSON 能力在查询型负载下不输甚至优于 MongoDB（来源：Medium：MongoDB vs PostgreSQL JSONB）；也有 2026 年基准显示 MongoDB 批量插入吞吐更高（115/s vs 81/s）、延迟差距更明显（来源：Reddit：JSON Documents Performance, Storage and Search，注：单一基准测试，工作负载敏感，不能外推为普适结论）。
• 结论：需要"关系骨架 + 半自由字段"时，JSONB 几乎是当前最优解；只有"文档优先 + 写入水平扩展"才真正需要 MongoDB。

2.5 维度四：全文检索——内置 FTS、ES 与中间路线的三方博弈

关键事实与来源：

• PostgreSQL 自 8.3（2008 年）起将全文检索做进核心，无需任何扩展即可使用（来源：Stack Overflow：Postgres Full-Text Search Instead of Elasticsearch）；词组搜索等后续增强见纵轴 1.8 节。
• 一位开发者连续六个月双跑两者的实测结论：Elasticsearch 在多数查询类型上快 3–10 倍，但 PostgreSQL 简单关键词检索 P95 约 89ms，对大量应用完全够用（来源：Medium：PostgreSQL Full-Text Search vs Elasticsearch — I Ran Both for 6 Months，注：个案实测）。
• 官方生态给出的中庸路线：当内置 FTS 达到极限时，可先用 ParadeDB 的 pg_search（BM25 via Tantivy）扩展过渡，再考虑上 ES（来源：Neon：Comparing Native Postgres, ElasticSearch, and pg_search）。
• 排名数据只能作弱信号，不作因果：Elasticsearch 在 DB-Engines 上同比 −22.55（第 12 名），OpenSearch 同比 +3.42（DB-Engines 2026-10，当日抓取）。需要明确：DB-Engines 的人气分变化≠搜索市场份额转移，本文没有份额数据；该信号与"中小规模搜索内化到 PostgreSQL"（FTS + pg_search + pgvector）的路线方向一致，但两者之间的因果本文不予断言。
• 选型规则（综合上述来源）：数据已在 PG、检索需求中等 → 留在 PG；需要高吞吐、复杂相关性调优、模糊容错、聚合分析、亚百毫秒@高并发 → ES/OpenSearch；中间态 → pg_search。

2.6 维度五：备份恢复——WAL 一等公民 vs 工具链外挂

关键事实与来源：

• PostgreSQL 17 的原生增量备份是近年备份子专题最大的变化：pg_basebackup --incremental 基于上一次备份的 manifest 只拷贝变更块，新增 pg_combinebackup 工具把全量 + 增量链合并为可用数据目录；增量备份不能直接用，必须先合并（来源：PostgreSQL 官方文档 pg_basebackup、PgDash 解读、MyDBOPS 实操）。
• pgBackRest 现状（当日从 GitHub 直接抓取验证）：当前稳定版 v2.59.2，2026-09-27 发布（8 月发 2.59.1），项目活跃维护，MIT 许可。能力清单：并行备份/恢复（lz4/zstd）、文件级与块级全/差/增量备份、多仓库、逐文件校验和与页校验、备份断点续传、流式压缩、Delta Restore、异步并行 WAL push/get、S3/Azure/GCS、仓库加密、基于版本化对象存储的勒索软件防护（来源：github.com/pgbackrest/pgbackrest）。
• 一个被证伪的传闻：本次检索中曾有摘要声称"pgBackRest 自 2026 年 4 月起不再维护"。经当日直接访问其 GitHub 仓库核实，该说法不成立（2026 年 7/8/9 月均有发布记录）。引用工具状态时应以仓库为准。
• 三大工具的分工（来自 Percona / Severalnines / 社区对比）：pgBackRest——C 语言、大库性能与并行压缩见长、通用首选；Barman（EDB）——服务器式架构、适合多实例机队与长期保留策略管理；WAL-G——Go 编写、云对象存储适配最顺（来源：Percona：PostgreSQL Backup Strategies for Enterprise-Grade Environments、Severalnines：Top Backup Tools for PostgreSQL、Cybertec 对比文档、dev.to 四工具对比）。
• 与 MySQL 对照的结论：两边的"PITR 思想"同源（预写日志 + 基础备份 + 重放到时间点），但 PostgreSQL 的物理备份与增量能力进入发行版本身（pg_basebackup / PG17 增量），MySQL 的高性能物理备份长期依赖第三方 XtraBackup。对学习者而言，PG 这套链路（WAL 归档 → base backup → restore_command → recovery_target_time）是所有数据库 PITR 概念的最佳教学样本。

2.7 维度六：水平扩展与"PostgreSQL 兼容"生态

• PostgreSQL 原生：物理流复制 + 逻辑复制（PG 18 支持从备库做逻辑复制）解决读扩展与零停机升级；写扩展依赖 Citus 分片扩展或应用层分库（★ + PG 18 发布说明）。
• NewSQL 对手（均兼容 PostgreSQL 或 MySQL 协议）：CockroachDB（PostgreSQL 线协议兼容，DB-Engines 第 70 名）、YugabyteDB（PG 兼容，第 117 名）、TiDB（MySQL 兼容，第 80 名）——排名均低（DB-Engines 2026-10 当日抓取），说明分布式 SQL 仍是小众选择，但它选择"寄生"在 PostgreSQL 语法生态上这一事实本身，就是 PostgreSQL 作为行业标准接口的证明。
• 云原生托管层：AWS RDS/Aurora（Aurora 第 43 名）、Google Cloud SQL/AlloyDB、Azure Database for PostgreSQL，以及面向 AI 时代的 Serverless 派（Neon、Supabase）全部以 PostgreSQL 为核心引擎；pgBackRest 的官方赞助商名单（AWS、Supabase、pgEdge、Tiger Data、Percona、Eon、Xata、Dalibo 等）从侧面勾勒出这条 PostgreSQL 产业链（来源：pgbackrest GitHub，当日抓取）。
• 对本课题学习者的含义：学 PostgreSQL 得到的不只是一个数据库的技能，而是进入整个"PostgreSQL 兼容生态"的门票——托管云、Serverless、分布式 NewSQL、向量数据库（pgvector，本系列另有专文）都讲同一门语言。

2.8 维度七：许可、成本与治理

关键事实与来源：

• 许可差异是真实的商业差异：PostgreSQL 允许嵌入商业/专有产品、修改与分发而不要求开源（来源：runxbuild：PostgreSQL License、dev.to：MySQL vs PostgreSQL in 2026）；MySQL 社区版为 GPLv2，闭源分发衍生品需 GPL 义务或 Oracle 商业许可（来源：acemq 对比、PostgreSQL 功能矩阵）。
• 定价维度（云实例小时价）因厂商、区域、存储类型变化频繁，本报告不做具体数字引用，仅做定性对比——这是本报告中少数刻意不给数字的维度，如实说明。
• 治理维度与纵轴 1.10 节呼应：PGDG 社区自治、无单一母公司，是其许可宽松与年更节奏的组织基础。

2.9 选型结论速查表

一句话总结横轴结论：在 2026 年 10 月这个截面，PostgreSQL 是"默认应当学习并首选"的通用数据库——不是因为它在每个单项上都赢，而是因为它在每个单项上都没有明显短板，并且整个行业正在向它的接口收敛。

三、交叉洞察：两轴结合说明了什么

3.1 洞察一：时间线与竞争面是同一条线

把纵轴的编年与横轴的对比放在一起看，会发现本课题的五个能力子专题（事务与 MVCC 合为一项；并行化为贯穿辅线，不单列）每个都同时是历史上的"外部冲击回应点"和横向上的"差异化边界"：

这张表是全报告的核心：PostgreSQL 的长期主义，就是把每一次竞争压力都变成内置能力。NoSQL 来了，它把文档模型吃进来；搜索引擎火了，它把倒排索引放进核心；云时代到了，它把增量备份做成原生功能。时间线上每一次"回应外部压力"，都转化为横轴上的一块护城河。这一机制与它在 DB-Engines 前四名中独享正增长的表现趋势一致——对手要么被它吸收（MongoDB/ES 的传统场景），要么选择兼容它（CockroachDB/YugabyteDB/云托管层）。需要如实说明：这是一个与数据相容的解释，不是已证因果——第 5 名 MongoDB 同比同样为正（+6.63），本文也没有将排名增长量化归因于这一机制的数据。

3.2 洞察二：两个枢纽概念——GIN 与 WAL

五个能力子专题并非并列关系，内部有两个枢纽：

• GIN 是"索引 × JSONB × 全文检索"三条线的枢纽。2006 年为全文检索设计的倒排索引（8.2），八年后成为 jsonb 的查询基础设施（9.4 同版还专门缩减了 GIN 体积）；今天 tsvector + GIN 与 jsonb + GIN 两个组合，分别把 Elasticsearch 与 MongoDB 的传统主场压缩进了 PostgreSQL（§2.4、§2.5）。学习时先吃透 GIN 的倒排原理，JSONB 与 FTS 两章就只剩语法问题。
• WAL 是"事务 × 备份 × 复制 × 逻辑解码"四条线的枢纽。2001 年为崩溃安全设计的预写日志（7.1），后来成为 PITR（8.0，把 WAL 归档重放）、流复制（9.0，把 WAL 流给备库）、逻辑解码（9.4，把 WAL 解析成逻辑变更流）的共同源头——本质都是"把 WAL 流给出去"（§1.5）。理解了 WAL，备份恢复就不再是一堆工具选项，而是一条清晰的因果链：WAL 归档 → base backup → restore_command → recovery_target_time。

对学习者的推论：这两个概念的投入产出比最高，值得花双倍时间；其余章节都可以沿着它们向下展开。

3.3 洞察三：MVCC 是资产也是债务——历史决定运维

纵轴的起点（1989 年 POSTGRES 的"时间旅行"设计）决定了横轴上最深的架构分野：因为选择了"旧版本留在堆内"，PostgreSQL 换来了即时回滚、读写不互斥；也因此背上了表膨胀、autovacuum 调优、XID 回卷三座运维大山（§2.2）。POSTGRES 时代的"时间旅行"功能后来被移除，但它的存储遗产（xmin/xmax + VACUUM）服务到了今天——17 版本重写 VACUUM（内存最多降 20 倍）、18 版本用 AIO 加速它，都是在对 1989 年的设计决策还债与增值。

对用户的实际含义：选 PostgreSQL 就是选一种运维手艺。日常要盯死元组率、长事务、XID 余量；收益是不需要为回滚和高并发读写付 undo 成本。MySQL 用户则相反——写入路径永远背着 undo，但日常没有 vacuum 负担。没有绝对优劣，只有代价放在哪里的差别；但你的 DBA 技能投资会长期锁定在这套机制上，这也是"深度入门"课题选择 MVCC 作为第一课的原因。

3.4 对用户的判断与建议

综合两轴证据，给出五条可执行建议：

1. 默认选择 PostgreSQL，把它作为"第一门深入学的数据库"。证据链：能力面最宽（§2.2–§2.6 无明显短板）、势能最强（前四名唯一正增长 + Stack Overflow 三项第一，§2.1）、许可最自由（可嵌入闭源产品，§2.8）、且整个行业正在向它的接口收敛（NewSQL/云托管/DocumentDB 兼容层，§1.10、§2.7）。学它得到的不是一门技能，而是一张生态门票。
2. 按"MVCC → 索引 → JSONB → 全文检索 → 备份恢复"的顺序学习。每一步都是前一步的下游消费者（VACUUM 依赖 MVCC、GIN 服务 JSONB/FTS、WAL 支撑备份），且每一步都能在 MySQL/MongoDB/ES 上找到对照实现（§2.2–§2.6 的对比表），形成"学一个、懂一类"的迁移结构。优先吃透 GIN 与 WAL 两个枢纽（§3.2）；每个专题的第一步动手命令见"四、延伸阅读与常见追问"。
3. 场景化选型不教条：关系骨架 + 半结构化字段用 JSONB，中小规模搜索留在库内（先试内置 FTS，极限时用 pg_search 过渡），文档优先 + 写入分片才上 MongoDB，大规模搜索/复杂相关性才上 ES，全球分布式强一致用 CockroachDB/YugabyteDB 这类"PG 兼容出口"（§2.9 速查表）。
4. 运维重心与版本策略：日常监控 autovacuum、长事务与 XID 余量（§3.3；具体指标、默认阈值与命令见"四、延伸阅读与常见追问"Q2）；跟随"年更大版本 + 最新 minor"节奏，PG 19 计划 2026-11-19 GA，升级前确认扩展同步适配；备份必须做恢复演练——PG17 增量备份不能直接用、必须先 pg_combinebackup 合并（§2.6），这类细节只有演练过才可靠。
5. 对数字保持工作负载敏感性：本报告引用的所有性能基准（ES 快 3–10 倍、Mongo 批量插入 115/s vs 81/s、AIO 顺序扫描 2–3 倍）都是特定负载下的个案，不可外推；云定价刻意不给具体数字；标注 ★ 的条目引用前请复核。同时保留一条方法学教训：本次写作中"pgBackRest 停止维护"的传闻经直接抓取 GitHub 证伪（§2.6）——工具状态类结论永远以官方仓库为准。

四、延伸阅读与常见追问

正文两处宣讲了「MVCC → 索引 → JSONB → 全文检索 → 备份恢复」的学习顺序（TL;DR 与 §3.4），本节把读者读完最自然会问的四个「下一步」逐条给出，全部指向官方文档与可直接执行的命令（本节引用的官方文档均于 2026-11-01 修订时访问核验，见参考来源 F 组）：

Q1：MVCC / xmin-xmax 到底怎么运作？

• 机制一句话：每行头部记录 xmin（创建该版本的事务 ID）与 xmax（删除/更新该版本的事务 ID）；每个事务依据自己的快照判断行版本可见性，UPDATE = 插入新版本 + 给旧版本打上 xmax，被废弃的旧版本即死元组，等待 VACUUM 回收（术语见文首速查）。
• 十分钟动手验证：开两个 psql 会话。A 会话：BEGIN; UPDATE t SET v = v + 1 WHERE id = 1;（先不提交）；B 会话：SELECT id, v, xmin, xmax FROM t WHERE id = 1; 观察新旧版本的 xmin/xmax 差异；A 会话提交或回滚后，执行 SELECT n_live_tup, n_dead_tup FROM pg_stat_user_tables WHERE relname = 't'; 观察死元组计数变化。
• 系统阅读：官方 MVCC 章（https://www.postgresql.org/docs/current/mvcc.html）。

Q2：autovacuum 日常盯哪些指标与阈值？

• 触发条件（默认值引自官方文档）：死元组数超过 autovacuum_vacuum_threshold（默认 50）+ autovacuum_vacuum_scale_factor × 表行数（默认 0.2，即 20%）时对表做 VACUUM；ANALYZE 对应 autovacuum_analyze_threshold（50）+ autovacuum_analyze_scale_factor（0.1）；PG 13 起另有仅插入触发：autovacuum_vacuum_insert_threshold（默认 1000）+ autovacuum_vacuum_insert_scale_factor（默认 0.2）。
• 监控三件事：① 死元组与清理进度——pg_stat_user_tables 的 n_dead_tup、n_live_tup、last_autovacuum、n_mod_since_analyze；② XID 余量——SELECT datname, age(datfrozenxid) FROM pg_database ORDER BY 2 DESC;，官方文档给出的保护梯级是：距回卷点还剩 4000 万事务时开始告警，剩量不足 300 万时拒绝分配新事务 ID（已开始的事务可继续，但只能只读）；autovacuum_freeze_max_age（默认 2 亿）会强制触发防回卷清理（即使 autovacuum 被关闭）；③ 长事务——SELECT pid, xact_start, state FROM pg_stat_activity WHERE xact_start IS NOT NULL ORDER BY xact_start;（长事务同时阻塞 PG 的 vacuum 与 MySQL 的 undo 清理，见 §2.2）。
• 系统阅读：Routine Vacuuming（https://www.postgresql.org/docs/current/routine-vacuuming.html）、autovacuum 参数（https://www.postgresql.org/docs/current/runtime-config-autovacuum.html）。

Q3：pg_basebackup --incremental + pg_combinebackup 怎么演练？

• 前置：服务器需产生 WAL 摘要（存于数据目录的 pg_wal/summaries），即 postgresql.conf 中设 summarize_wal = on 并重载——官方文档明言"如果所需的摘要文件不存在，做增量备份会失败"；--incremental 只支持服务器版本 17 及以上。
• 演练序列（命令为示意，参数含义以官方文档为准）：

# 1) 先做一次全量（-Fp 目录格式，便于查看 manifest 与后续合并）
pg_basebackup -D /backup/full -Fp -Xs -P

# 2) 数据变动后做增量：--incremental 指向上一次备份的 backup_manifest（须来自同一服务器）
pg_basebackup -D /backup/inc1 -Fp -Xs -P --incremental=/backup/full/backup_manifest

# 3) 校验全量备份
pg_verifybackup /backup/full

# 4) 合并：按"从旧到新"的顺序列出全部备份，合成一个"合成全量"，-o 指定输出目录
pg_combinebackup /backup/full /backup/inc1 -o /backup/restore

# 5) 恢复演练：把 /backup/restore 作为数据目录，配置 restore_command 与恢复目标后启动，
#    验证能否恢复到指定时间点（对应正文 §2.6 的 PITR 链路）

• 官方文档的两条关键提醒：增量备份不能直接用于恢复，必须先用 pg_combinebackup 把它直接或间接依赖的全部先前备份合并成合成全量；PostgreSQL 没有内置机制追踪"哪些旧备份仍是后续增量依赖的基础"，备份保留策略要自己管。
• 系统阅读：25.3.3 Making an Incremental Backup（https://www.postgresql.org/docs/current/continuous-archiving.html）、pg_basebackup（https://www.postgresql.org/docs/current/app-pgbasebackup.html）、pg_combinebackup（https://www.postgresql.org/docs/current/app-pgcombinebackup.html）。

Q4：JSONB 建索引，GIN 默认算子类与 jsonb_path_ops 怎么选？

• 默认 jsonb_ops：为文档内每个键和每个值各建独立索引项，支持键存在性 ? / ?| / ?&、包含 @> 与 JSONPath 匹配 @? / @@。
• jsonb_path_ops：只为「值 + 到达它的键路径」的哈希建索引项，索引通常小得多、查询选择性更好（尤其查询含高频键时）；不支持 ? 系键存在性操作符，只支持 @>、@?、@@（官方文档原文口径）。
• 经验法则：查询模式里有「这个键/路径存在吗」→ 必须用默认 jsonb_ops；只做包含与 JSONPath 查询、在意索引体积与速度 → jsonb_path_ops。
• 建索引用法：CREATE INDEX ON docs USING gin (j);（默认算子类）与 CREATE INDEX ON docs USING gin (j jsonb_path_ops);
• 系统阅读：JSON Types（https://www.postgresql.org/docs/current/datatype-json.html）。

五、参考来源

A. 当日直接抓取验证（2026-10-31）

1. DB-Engines Ranking（2026 年 10 月）：https://db-engines.com/en/ranking
2. PostgreSQL 官网版本信息（18.6 / 17.11 / 16.15）：https://www.postgresql.org/
3. MySQL 下载页（26.10.0 Innovation GA / 26.7.0 LTS GA）：https://dev.mysql.com/downloads/mysql/
4. pgBackRest GitHub 仓库（v2.59.2，2026-09-27；证伪"停止维护"传闻）：https://github.com/pgbackrest/pgbackrest

B. PostgreSQL 官方文档与发布说明

1. 官方历史页（POSTGRES/Postgres95/更名全过程）：https://www.postgresql.org/docs/current/history.html
2. 官方版本支持策略页（6.3–18 全部大版本发布日期、年更与 5 年支持节奏）：https://www.postgresql.org/support/versioning/
3. PostgreSQL 6.5 文档 MVCC 章（Vadim Mikheev）：https://pg.center/docs/6.5/mvcc.htm
4. PostgreSQL 7.1 文档 WAL 章（Mikheev & Elphick）：https://www.postgresql.org/docs/7.1/wal.html
5. PostgreSQL 7.1.0 发布说明（WAL、TOAST）：https://www.postgresql.org/docs/release/7.1.0
6. PostgreSQL 8.0 发布说明（Windows、SAVEPOINT、PITR）：https://www.postgresql.org/docs/8.0/release.html
7. PostgreSQL 8.2 发布公告（GIN、在线建索引）：https://www.postgresql.org/about/news/2006/12/05/ ；8.2 发布说明：https://www.postgresql.org/docs/8.2/release-8-2.html
8. PostgreSQL 8.3 发布说明（全文检索进核心、HOT、异步提交）：https://www.postgresql.org/docs/8.3/release-8-3.html
9. PostgreSQL 9.0 发布说明（流复制、热备）：https://www.postgresql.org/docs/9.0/release-9-0.html
10. PostgreSQL 9.1 发布说明（pg_basebackup、同步复制）：https://www.postgresql.org/docs/9.1/release-9-1.html
11. PostgreSQL 9.4 发布说明（jsonb 署名与原文表述、逻辑解码、复制槽）：https://www.postgresql.org/docs/9.4/release-9-4.html
12. PostgreSQL 9.6 发布新闻（并行查询、词组搜索）：https://www.postgresql.org/about/news/1693/ ；9.6 发布说明：https://www.postgresql.org/docs/9.6/release-9-6.html
13. PostgreSQL 12 发布说明（SQL/JSON Path、生成列）：https://www.postgresql.org/docs/12/release-12.html
14. PostgreSQL 17 发布说明（增量备份、pg_combinebackup、VACUUM 内存、JSON_TABLE）：https://www.postgresql.org/docs/17/release-17.html
15. PostgreSQL 18 发布新闻（AIO、skip scan、UUIDv7、OAuth）：https://www.postgresql.org/about/news/postgresql-18-released-3142 及 https://www.postgresql.org/docs/release/18.0
16. PostgreSQL 19 Beta 信息页与 RC1 公告（2026-06-04 Beta1、2026-10-15 RC1、计划 2026-11-19 GA）：https://www.postgresql.org/developer/beta 、https://www.postgresql.org/about/news/postgresql-19-rc-1-released-3409

C. 历史与行业地位

1. Ingres 历史（Stonebraker/Wong，1972–1973 启动、1976 TODS 论文）：https://homes.cs.washington.edu/~lazowska/cra/database.html 、https://www.cs.cmu.edu/~natassa/courses/15-721/papers/p189-stonebraker.pdf
2. DB-Engines "DBMS of the Year 2024"（第五次夺冠）：https://www.optimadata.nl/en/nieuws/postgresql-dbms-of-the-year-2024
3. Stack Overflow 2025 开发者调查（最常用/最受喜爱/最想要）：https://survey.stackoverflow.co/2025/technology
4. Microsoft DocumentDB 捐赠 Linux 基金会（2025-08-25 宣布）：Linux Foundation 新闻稿 https://www.linuxfoundation.org/press/linux-foundation-welcomes-documentdb-to-advance-open-developer-first-nosql-innovation 、Microsoft 开源博客 https://opensource.microsoft.com/blog/2025/08/25/documentdb-joins-the-linux-foundation 、The New Stack 报道 https://thenewstack.io/linux-foundation-opens-the-door-to-documentdb

D. 横向对比来源

1. MySQL Innovation/LTS 模型与 8.0 EOL：https://dev.mysql.com/doc/refman/9.3/en/mysql-releases.html 、https://dev.mysql.com/blog-archive/introducing-mysql-innovation-and-long-term-support-lts-versions ；PG 18 解读：https://www.bytebase.com/blog/what-is-new-in-postgres-18
2. MVCC 实现对比（堆内多版本 vs undo）：http://amitkapila16.blogspot.com/2015/03/different-approaches-for-mvcc-used-in.html 、https://www.reddit.com/r/PostgreSQL/comments/te9za5/what_are_the_tradeoffs_between_postgresqls_and ；Robert Haas《MySQL vs. PostgreSQL, Part 2: VACUUM vs. Purge》（2011-02）：http://rhaas.blogspot.com/2011/02/mysql-vs-postgresql-part-2-vacuum-vs.html （2026-11-01 修订时经网络检索定位原文链接；blogspot 域在修订环境内无法直连复核全文，特此说明）
3. PG 17 增量备份实操：https://www.postgresql.org/docs/current/app-pgbasebackup.html 、https://pgdash.io/blog/incremental-backup-in-postgresql-17.html 、https://www.mydbops.com/blog/postgresql-17-incremental-backup-pg-basebackup-pg-combinebackup
4. 备份工具对比：https://www.percona.com/blog/postgresql-backup-strategy-enterprise-grade-environment 、https://severalnines.com/blog/top-backup-tools-postgresql 、https://github.com/cybertec-postgresql/pg_hardstorage/blob/main/docs/explanation/comparison-pgbackrest-walg-barman.md 、https://dev.to/piteradyson/postgresql-backup-tools-comparison-databasus-wal-g-pgbackrest-and-barman-2kg
5. 全文检索对比：https://neon.com/blog/postgres-full-text-search-vs-elasticsearch 、https://navanathjadhav.medium.com/postgresql-full-text-search-vs-elasticsearch-i-ran-both-for-6-months-a585f60c8a5d 、https://stackoverflow.com/questions/58812324/postgresqlfull-text-search-vs-elasticsearch
6. JSONB 对比：https://www.solarwinds.com/blog/json-support-in-postgresql-mysql-mongodb-and-sql-server 、https://www.slideshare.net/slideshow/working-with-json-data-in-postgresql-vs-mongodb/237002539 、https://dev.to/dbvismarketing/json-vs-jsonb-in-postgresql-for-database-development-1hbp 、https://www.reddit.com/r/programming/comments/1rjoo6e/json_documents_performance_storage_and_search 、https://medium.com/@krpsanthoshkumar/mongodb-vs-postgresql-jsonb-which-one-should-you-choose-for-storing-json-data-628aa21cf599
7. 许可对比：https://www.runxbuild.com/blog/postgresql-license 、https://dev.to/piteradyson/mysql-vs-postgresql-in-2026-7-key-differences-you-should-know-before-choosing-4l9d 、https://acemq.com/compare/postgresql-vs-mysql 、https://www.postgresql.org/about/feature/matrix/

E. 标注为 ★ 的条目（未在本次会话逐条核验）

1. 各数据库隔离级别默认值、SQL Server 版本存储、SQLite 串行写模型、PostgreSQL 索引访问方法清单与各版本归属（GiST 7.3、KNN-GiST 9.1、SP-GiST 9.2、哈希索引 10、并行建索引 11、B-tree 去重 13、pg_verifybackup 13、multirange/LZ4/ZSTD 14、MERGE 15、pg_stat_io 16、websearch_to_tsquery 11、jsonb_set 9.5、autovacuum 8.1、7.3/7.4/8.4 特性、早期核心组成员）、B-tree 继承自 POSTGRES、pg_dump 起于 Postgres95、contrib tsearch/tsearch2（Sigaev & Bartunov）、InnoDB 聚簇组织、BSON in-place 更新、MongoDB/Elasticsearch 许可演变、分片与复制架构描述等。引用时请注意复核。

F. 2026-11-01 修订时新增/核验的官方文档（"四、延伸阅读与常见追问"及修订处引用）

1. 官方 MVCC 章（xmin/xmax、快照与可见性）：https://www.postgresql.org/docs/current/mvcc.html
2. Routine Vacuuming（XID 回卷保护梯级：剩 4000 万事务告警、剩量不足 300 万拒绝分配新事务 ID；autovacuum_freeze_max_age 强制防回卷清理）：https://www.postgresql.org/docs/current/routine-vacuuming.html
3. autovacuum 参数默认值（vacuum 50/0.2、analyze 50/0.1、insert 1000/0.2、freeze_max_age 默认 2 亿）：https://www.postgresql.org/docs/current/runtime-config-autovacuum.html
4. 增量备份与合并：25.3.3 Making an Incremental Backup（https://www.postgresql.org/docs/current/continuous-archiving.html ，WAL 摘要存于 pg_wal/summaries、缺失则增量备份失败）、pg_basebackup --incremental（https://www.postgresql.org/docs/current/app-pgbasebackup.html ，--incremental 指向上一次备份的 manifest，仅服务器 17+）、pg_combinebackup（https://www.postgresql.org/docs/current/app-pgcombinebackup.html ，输入目录从旧到新排列，-o 指定输出目录）
5. JSON Types（jsonb GIN 算子类：jsonb_ops 支持 ?/?|/?& 与 @>/@?/@@；jsonb_path_ops 不支持键存在性操作符、索引通常更小）：https://www.postgresql.org/docs/current/datatype-json.html
6. PostgreSQL 9.5 发布说明（UPSERT、BRIN、RLS）：https://www.postgresql.org/docs/9.5/release-9-5.html

附录 A：两稿合并的口径统一说明

本节原为「三、交叉洞察」的首节（编辑性说明，不属洞察内容），按审读意见移至文末作为附录，不再占用洞察编号；正文"报告性质"处的引用已同步改指本附录。

两份章节稿在合并前存在少量口径差异与大量重复，本稿统一如下：

1. 版本口径：纵轴表述为"最新大版本为 PostgreSQL 18（2025-09-25）"，横轴表述为"当前稳定版本 18.6（另有 17.11、16.15）"。两者不矛盾，是同一事实的不同粒度。本稿统一为：最新大版本线为 18（2025-09-25 发布），当前稳定 minor 为 18.6；PostgreSQL 19 处于 RC 阶段（RC 1 于 2026-10-15 发布，计划 2026-11-19 GA）（见 1.10 节）。
2. 重复内容归并：PG 18 的旗舰特性（AIO、skip scan、UUIDv7、OAuth 2.0、WITHOUT OVERLAPS、备库逻辑复制）在两稿中各展开一次，本稿在纵轴 1.9 节一次讲透，横轴仅在 MVCC（恢复时间）与索引（skip scan）维度引用；PITR/pg_basebackup/PG17 增量备份在纵轴讲"何时出现"（编年），横轴讲"横向位置"（与 MySQL/XtraBackup 对比），两处互相引用而不重复展开。GIN/全文检索/jsonb 的版本日期统一以纵轴编年为准。
3. JSONB 性能口径：横轴两处性能结论（查询型负载 PG 不落下风；2026 年单一基准 MongoDB 批量插入更快，115/s vs 81/s）均保留，并统一标注"单一基准、负载敏感、不可外推为普适结论"。纵轴无此内容，无冲突。
4. 全文检索口径：横轴"ES 快 3–10 倍（六个月双跑个案）"与"PG 简单检索 P95 约 89ms 够用"不是矛盾而是互补，本稿统一为按规模分层的选型规则（见 2.5 节），不做二选一。
5. pgBackRest 维护状态：检索摘要曾声称"pgBackRest 自 2026 年 4 月起停止维护"，当日直接抓取其 GitHub 仓库证伪（v2.59.2，2026-09-27 发布，7/8/9 月均有发布记录）。本稿以仓库为准，并保留此核查记录作为方法示范（见 2.6 节）。
6. 标注体系统一：纵轴的 ★ 与横轴的【模型知识】统一为 ★，含义为"社区公认事实，未在本次会话逐条核验"；其余事实均附当日来源链接。
7. DB-Engines 双口径互补：纵轴引用"DBMS of the Year 2024（第五次夺冠）"，横轴引用"2026 年 10 月排名"，本稿合并为"奖项证明长期势头 + 当月排名证明势头延续"的完整叙事（见 1.10 与 2.1 节）。

（完。本报告为按独立审读意见修订后的最终稿；两稿合并的口径统一说明见附录 A，读者下一步的动手入口见"四、延伸阅读与常见追问"。）