在数据库的漫长演进史中，PostgreSQL往往被描绘成一位“老者”——它诞生于上世纪80年代，却始终位居开源数据库的第二名，被MySQL的光芒所掩盖。然而，过去五年间，PostgreSQL的采用率飙升，不仅超越了传统关系型数据库的边界，还在时序、地理空间、全文检索乃至向量检索等新兴领域频频现身。这并非偶然，而是其架构设计从一开始就选择了“后发优势”的路线——以高度的可扩展性换取长期的生命力，而非为单一场景做极致优化。本文不打算再罗列PostgreSQL与MySQL的功能对照表，而是聚焦于一个核心分歧：两者面对复杂变化的数据需求时，其底层哲学如何分道扬镳，并最终决定了谁更适合成为未来数据基础设施的基石。
先看并发控制。PostgreSQL的MVCC实现比MySQL更为激进——它通过将多个版本的行直接存储在主表（堆表）中，让读操作完全无锁，写操作也不会阻塞读。这种“多版本快照”虽提供了业界最强的事务隔离能力，却带来了清晰的代价：旧版本必须通过VACUUM定期清理，否则表膨胀会拖垮性能。反观MySQL的InnoDB，它采用回滚段+当前读的方式，将旧版本存储在独立区域，后台清理压力较低，但这也意味着事务隔离在可重复读级别下容易出现幻读且需要通过当前读和锁来限制。这两种设计的取舍，直接反映了两个社区对“一致性”和“性能”的不同权重：PostgreSQL更信任应用逻辑并给予其完备的快照语义，而MySQL更倾向于让数据库引擎保持轻量，把某些一致性责任推给开发人员。
再看扩展机制，这或许是两者最本质的分水岭。MySQL的存储引擎插件架构虽然成功，但功能扩展被严格限制在引擎层面，用户无法轻松地为数据库增加新的数据类型、索引方法或函数。而PostgreSQL的CREATE EXTENSION机制，使得任何第三方模块都能像系统内置功能一样无缝接入——TiDB生态中的向量索引、时序压缩、甚至机器学习推理都可以作为扩展加载。这带来的质变是：PostgreSQL不再只是一个数据库，而是一个“数据库操作系统”——你可以在其上组合出图数据库、文档数据库、时序数据库、地理空间数据库，而无需迁移数据。这种组合式创新，让PostgreSQL得以在每一个细分场景的数据库尚未成熟之前，就提前成为“够用且可用”的替代品。正是这种底层能力，让它在技术选型时成为覆盖风险的最佳默认选项。
我的独立观点是：PostgreSQL的“瑞士军刀”模式并非没有代价，它导致了参数配置极其复杂、调优门槛远高于MySQL；但恰恰因为现代数据需求的碎片化和不确定性，企业不再愿意为每个新品类（向量、时序、Graph）去承担运维新技术栈的风险。PostgreSQL用“一个核心+无数扩展”的方式，将运维复杂度集中化，同时提供了与专有数据库接近的能力，这种“后发优势”在技术债务的管理上具有极强的现实吸引力。未来十年，数据基础设施的方向不会是越来越多的数据库品类，而是不断收敛到少数具备强大扩展能力的通用底座上——PostgreSQL已经占据了这个生态位。如果你想在数据的洪流中保持选择权，不妨现在就把它作为数据栈的“内核”，而不是等到为时已晚。
