PostgreSQL 能持续演进三十年，靠的并不是频繁推翻旧设计，而是几项长期有效的工程取舍：用独立进程降低并发代码的复杂度，用 WAL 把事务提交和数据页落盘解耦，用 MVCC 将清理工作移到后台，再通过扩展机制控制核心代码的体积。
Tom Lane 对这些设计的评价并非“旧架构永远正确”。更准确的说法是：它们曾经用可接受的成本换来了可靠性、可维护性和开放协作；面对数百核服务器、海量连接和 AI 生成补丁时，这些取舍正在被重新审视，但改变仍然必须建立在可解释、可验证的工程基础上。
一连接一进程：简单性比表面开销更重要
PostgreSQL 的经典模型是每个客户端连接对应一个后端操作系统进程。每个后端拥有自己的地址空间、执行器状态和会话级缓存，同时通过共享内存访问 shared buffers、锁表和事务状态。
这个模型最直接的收益是代码简单。开发者处理大多数局部数据结构时，不必担心另一个线程在执行到一半时修改它。真正需要同步的状态集中在相对有限的共享区域中，这降低了并发错误扩散到整个代码库的概率。
不过，“一个会话崩溃，其他会话完全不受影响”并不准确。如果某个后端异常退出，PostgreSQL 无法绝对排除共享内存已被破坏的可能，因此 postmaster 会终止其他子进程、重建共享状态并执行恢复。进程隔离仍然保护了 postmaster 本身，但数据库实例可能经历一次整体重启。
现代硬件让这一模型的成本更加明显：
- 每个后端都需要私有内存和会话缓存。
- 大量可运行进程会带来上下文切换成本。
- 不同地址空间的数据需要反复进入 CPU 缓存。
- 新连接必须逐步填充 catalog cache，不能被视为廉价的一次性对象。
这也解释了为什么 PgBouncer 之类的连接池如此重要。连接池复用已经“热起来”的后端，把应用侧数千个逻辑连接压缩成数据库侧数量可控的物理连接。
线程化可能减少上下文切换和地址空间切换，但它绝不是把 fork() 换成 pthread_create()。真正困难的是重新定义全局变量、错误处理、会话状态以及 catalog cache 的所有权。不同事务还可能看到不同版本的目录元数据，共享缓存必须继续满足这种可见性规则。
WAL、Checkpoint 与恢复：先保存承诺，再慢慢整理现场
事务修改表页或索引页时，PostgreSQL 会先生成描述该修改的 WAL 记录。提交事务需要确保相关 WAL 已持久化，却不要求所有被修改的数据页立即写回对应的数据文件。
这项设计把原本散落在多个表和索引中的随机写，转换成更容易顺序持久化的日志流。脏数据页可以留在 shared buffers 中，随后由后台写入机制和 checkpoint 推进到磁盘。系统发生崩溃后，再从 WAL 重放尚未体现在数据文件中的修改。
因此，调优 checkpoint 不能只盯着“提交延迟是否下降”。间隔过短可能制造密集的数据页写入；间隔过长则会积累更多 WAL，并可能拉长恢复时间。这里始终存在三个相互牵制的目标：前台延迟、后台 I/O 平滑度和可接受的恢复时间。
WAL 重放仍强调简单和确定性。并行恢复理论上可能提升速度，但恢复路径首先要保证数据库一定能回到一致状态。对于基础设施软件，容易证明正确往往比跑分更重要。
MVCC 的代价不是消失，而是被移到了后台
PostgreSQL 更新一行时通常会创建新的行版本，而不是原地覆盖旧版本。读取事务根据自己的快照选择可见版本，因此读写操作可以在许多场景下并发进行，而不必让读者等待写者完成。
代价是旧版本会留下来，形成需要 VACUUM 回收的 dead tuples。Tom Lane 的判断是，这仍是一项合理的架构选择，因为维护成本被推迟到后台，而不是强制放进每次提交或回滚的关键路径。
这并不意味着用户可以忽略 VACUUM。长事务会长期保留旧快照，阻止旧行版本被回收；高频更新表可能快速膨胀；临时表使用会话私有缓冲区，也不能依赖常规后台 autovacuum 替当前会话处理全部维护工作。
可以在本机用下面的实验观察长事务如何影响清理。运行前需要安装 Docker；示例会创建名为 pg-architecture-demo 的临时容器，并占用本机 55432 端口。
docker run --rm --name pg-architecture-demo \
-e POSTGRES_PASSWORD=postgres \
-p 55432:5432 \
-d postgres:17
until docker exec pg-architecture-demo pg_isready -U postgres >/dev/null 2>&1; do
sleep 1
done
docker exec -i pg-architecture-demo psql -U postgres <<'SQL'
CREATE TABLE account_balance (
account_id bigint PRIMARY KEY,
balance numeric(12,2) NOT NULL
);
INSERT INTO account_balance
SELECT id, 100.00
FROM generate_series(1, 10000) AS id;
UPDATE account_balance
SET balance = balance + 1;
SELECT n_live_tup, n_dead_tup
FROM pg_stat_user_tables
WHERE relname = 'account_balance';
VACUUM (VERBOSE, ANALYZE) account_balance;
EXPLAIN (ANALYZE, BUFFERS)
SELECT *
FROM account_balance
WHERE account_id = 5000;
SQL
docker stop pg-architecture-demo
统计信息更新不是严格实时的，因此 n_dead_tup 是估算值。要观察长事务的影响，可以打开两个 psql 会话：在会话 A 中开始事务并读取表，在会话 B 中反复更新和执行 VACUUM，然后比较会话 A 提交前后的 dead tuple 估算值及表大小。生产环境不要为了“测试效果”对业务大表执行无约束的批量更新。
扩展优先，核心保持克制
可扩展性从项目早期就是 PostgreSQL 的基本方向。扩展可以增加数据类型、操作符、函数、过程语言和索引访问能力。社区评审核心功能时，也会关注它是否只适用于内置类型，还是为扩展类型保留了同等能力。
这种边界直接影响项目的长期维护成本。核心开发人力有限，把所有有价值的功能都放入核心，只会扩大测试矩阵和兼容负担。如果一个能力能够合理地作为扩展交付，保留在扩展中通常更可持续。
但扩展不是无限制的插件系统。SQL 解析器由 Flex 和 Bison 根据静态语法生成，扩展不能在运行时随意加入新关键字或语法分支。这看似保守，却换来了重要保证：Bison 能在构建阶段发现语法冲突，避免某段扩展语法在运行时被另一条规则遮蔽。解析器若要变得可扩展，就必须提供同等级别的歧义检测和跨平台可维护性。
同样，LISTEN/NOTIFY 适合作为简单信号通道，却不是高吞吐消息队列。工程团队可以坚持“先用 PostgreSQL”，但应同时定义迁移阈值：消息速率、积压容量、消费确认、重放需求或故障隔离一旦超出它的能力，就应引入专门系统。
内存上下文：用生命周期管理 C 内存
PostgreSQL 仍然是大型 C 工程，但它并非在每个调用点机械地配对 malloc 和 free。代码会把对象分配到具有明确生命周期的 memory context 中：有些上下文持续整个会话，有些只持续一条查询，还有些会按处理行反复重置。
关键原则是把对象放入尽可能短命、但足以覆盖其使用期的上下文。工作结束后可以批量释放整个上下文，这通常比逐个释放对象更高效，也降低了异常路径遗漏清理的风险。
边界同样清晰：在长生命周期上下文中忘记释放依然会泄漏；长命对象如果持有指向短命上下文的指针，依然会产生悬空引用。内存上下文缓解了一类内存管理问题，却没有提供编译器级内存安全，也不能自动证明对象所有权正确。
没有路线图，为什么项目仍能稳定前进
PostgreSQL 没有由单一公司制定的产品路线图。贡献者可能受雇于不同组织，但代码要进入社区版本，仍然需要说服评审者其设计、接口和维护成本是合理的。大型补丁耗时多年并不罕见，这会降低变化速度，却也减少了单家公司或单个开发者突然改写核心方向的可能。
宽松许可证同样是成功条件之一。它允许企业托管 PostgreSQL、构建商业产品或维护专有分支，同时继续从稳定的社区核心受益并回馈修复。libjpeg 的经历也强化了 Tom Lane 的判断：优秀标准若有任何人都能采用的自由实现，其传播能力会发生质变。
AI 给这套治理增加了新的压力。社区已经看到更多 AI 生成的缺陷和安全报告，其中既有有效问题，也有因工具不理解架构而产生的噪声。访谈中形成的倾向并非禁止 AI，而是要求人类贡献者为提交内容负责，并能解释每项设计决定；这在当时还不是正式项目政策。
面向生产环境的采用清单
使用 PostgreSQL 时，不要把历史架构简单归类为“保守”或“过时”。更有效的做法是把它们转换成可监控的边界：
- 用连接池约束数据库物理连接数，并分别设置应用并发和池容量。
- 监控 checkpoint 时长、WAL 生成速率、恢复目标和存储写入峰值。
- 跟踪长事务、dead tuples、表膨胀及 autovacuum 是否持续落后。
- 优先通过成熟扩展增加能力，但评估升级兼容性、崩溃边界和维护者活跃度。
- 把
LISTEN/NOTIFY、临时表和 PostgreSQL 内任务队列限定在适合的规模内。 - 接受 AI 辅助代码或报告前，要求提交者复现问题、解释机制并提供针对性测试。
PostgreSQL 的三十年经验并不是“架构一旦正确就不必改变”，而是每次改变都要尊重数据系统的首要承诺：写进去的数据明天仍然能够正确读出来。进程模型可能走向线程化，表访问方法可能支持列式存储，解析器也可能出现新的扩展机制，但可靠性、可解释性和核心克制仍会决定这些变化能否真正落地。