PostgreSQL与MySQL比较
摘要
在当今数据驱动的时代，关系型数据库仍然是绝大多数应用系统的核心基础设施。开源数据库领域，PostgreSQL与MySQL长期占据主导地位，两者在发展哲学、架构设计、功能特性和许可模式上存在深刻差异。PostgreSQL以对SQL标准的严格遵循、丰富的功能扩展性和高度可定制的生态闻名，催生了众多基于其内核的衍生数据库产品；MySQL则以简单易用、高性能和成熟的Web生态见长。本报告从历史发展、系统架构、核心特性、事务与复制、性能优化等维度对两者进行深度解析与对比，并系统梳理了基于PostgreSQL开发的重要数据库产品——包括MPP数据仓库Greenplum、云原生Aurora/PolarDB、分布式Citus、时序TimescaleDB、国产openGauss/KingbaseES、兼容分布式YugabyteDB等，分析其技术路线与创新点，最后给出场景化选型建议，为数据库技术决策提供全景式参考。
1 引言
关系型数据库管理系统（RDBMS）自诞生以来，凭借其成熟的理论基础——关系模型与事务ACID保障，始终是企业信息系统的基石。在开源世界，PostgreSQL与MySQL是最具影响力的两个产品。根据DB-Engines 2026年的排名，MySQL位列榜首，PostgreSQL紧随其后且持续缩小差距。两者合计占据开源数据库市场绝大部分份额。
尽管同为SQL数据库，它们的设计取舍截然不同。PostgreSQL被设计为“世界上最先进的开源数据库”，着眼于可扩展性、标准兼容性以及对复杂查询场景的支持，其类BSD许可证极为宽松，允许自由的修改和商业化分发，这直接催生了一个庞大的衍生数据库生态系统。MySQL则更强调“快速、可靠、易用”，尤其在与LAMP（Linux+Apache+MySQL+PHP）栈深度绑定后，迅速征服了互联网应用市场。
进入云计算和数字化转型时代，用户面临的数据库选择已远不止原始社区版那么简单。理解PostgreSQL与MySQL的深层特性，以及基于PostgreSQL衍生的众多数据库产品（如分布式、时序、MPP分析、云原生等形态）的定位与能力，对于技术架构师做出正确选型至关重要。
本报告致力于提供一份深度、全面的技术研究报告。第二、三章分别解析PostgreSQL和MySQL的内核架构与核心特性；第四章进行系统的横向对比；第五章是特色内容，将详细介绍基于PostgreSQL开发的主要数据库产品，剖析其如何利用PostgreSQL的开放特性进行创新；最后给出应用场景与选型建议。
2 PostgreSQL深度解析
2.1 发展历史与社区治理
PostgreSQL的前身是加州大学伯克利分校Michael Stonebraker教授领导的Ingres项目。1986年启动的Postgres项目旨在突破传统关系模型的局限，支持更丰富的数据类型和对象关系模型。1996年，项目更名为PostgreSQL以强调SQL支持，并发布了第一个开源版本。
PostgreSQL使用自由的PostgreSQL License（类似于BSD许可证），允许任何人在不公开源代码的情况下修改并重新分发，这为其后续的商业衍生品繁荣奠定了法律基础。PostgreSQL由全球性的开源社区“PostgreSQL全球开发组”管理，不存在单一商业实体控制。社区采用核心团队与提交者（committer）的治理模式，发布节奏稳定——每年秋季发布一个大版本，每个版本获得5年的支持周期。截至2026年，当前主要活跃版本为PostgreSQL 16和17。
2.2 系统架构
PostgreSQL采用经典的多进程架构。主守护进程postmaster监听客户端连接，为每个新连接派生（fork）一个独立的服务进程postgres来处理该会话的所有操作。这种设计带来了良好的进程隔离性和稳定性——单个连接的崩溃不会影响其它连接，但同时也意味着高并发连接数下会产生较大的上下文切换与内存开销，实际场景中通常通过连接池（如PgBouncer）来优化。
内存管理方面，PostgreSQL使用共享内存作为核心缓冲区，包括共享缓冲池（shared_buffers）用于缓存数据页，WAL缓冲区用于缓存待写入的事务日志。各个后台进程，如后台写进程（bgwriter）、WAL写进程（walwriter）、检查点进程（checkpointer）、自动清理进程（autovacuum launcher）等，协同维护系统的持久化与清理任务。
存储层面，PostgreSQL只有一个内置的存储引擎（堆存储），不支持MySQL那样的可插拔引擎。堆表中每一行数据被存储为一个元组（tuple），表文件按8KB的页组织。这种单一引擎策略使得优化器、执行器可以与存储层深度耦合，实现更精细的优化，而扩展性则通过庞大的插件接口和索引访问方法API来实现。
MVCC实现是PostgreSQL的一大特色。它采用无覆盖的多版本元组机制：更新一行时，旧版本元组保留在原页面并被标记为无效，新版本作为全新元组插入。旧版本最终由VACUUM进程回收空间。这种设计避免了回滚段（undo log）机制，但需要持续进行VACUUM维护以防止表膨胀和事务ID回卷。没有undo日志也意味着回滚是即时的，不存在类似MySQL中长时间回滚大事务的痛苦。
WAL（Write-Ahead Logging）是事务持久性的保障。数据页的变更总是先记录到WAL，再写入数据文件。WAL是物理复制、逻辑复制和连续归档备份的基础。PostgreSQL 15引入了WAL压缩，进一步减少I/O。
2.3 核心特性
丰富的数据类型是PostgreSQL的标志性优势：
原生数组类型：
INTEGER[]，支持数组运算符与索引。JSON/JSONB：JSONB是二进制存储的高性能JSON，支持GIN索引，可进行嵌套查询，性能已与部分文档型数据库媲美。
范围类型：如
tsrange（时间戳范围），支持重叠、包含等运算符。几何类型：
point,polygon等。自定义复合类型、枚举类型。
通过扩展可加入如
hstore键值对、ltree树形结构等。
SQL标准支持方面，PostgreSQL长期被视为开源数据库的标杆。它很早便支持了窗口函数、公共表表达式（CTE，包括递归CTE）、LATERAL子查询、GROUPING SETS等分析特性。PostgreSQL 15实现了SQL标准的MERGE语句，支持复杂的条件插入/更新/删除。对SQL/JSON路径语言的支持也日臻完善。
索引体系堪称豪华，远超B-tree：
GiST（通用搜索树）：为几何数据、全文搜索等提供可扩展索引框架，是PostGIS的空间索引基础。
GIN（通用倒排索引）：尤其适合JSONB、数组和全文搜索向量，加速包含性查询。
BRIN（块范围索引）：针对海量自然顺序数据（如时间序列），牺牲精度换取极小索引体积，极大提高扫描效率。
SP-GiST：支持非平衡数据结构如四叉树。
此外，支持部分索引（带WHERE条件）、表达式索引（基于函数结果）、覆盖索引等，为查询优化提供了极大灵活性。
过程语言与函数：除了内置的PL/pgSQL，还可以安装PL/Python、PL/Perl、PL/Tcl、PL/Java等，甚至可以通过FDW实现跨数据库查询，几乎可以将PostgreSQL作为数据联邦中心。
扩展机制是PostgreSQL生命力的源泉。通过CREATE EXTENSION，可以动态加载新功能模块，如PostGIS（地理空间）、pg_stat_statements（查询性能分析）、pg_cron（定时任务）、pg_partman（分区管理）等。扩展可以定义新的数据类型、索引方法、后台工作进程，甚至改变查询规划过程。
2.4 事务与隔离级别
PostgreSQL支持SQL标准定义的全部四种隔离级别，但其中“未提交读”实际上表现为“已提交读”。它基于快照隔离（SI）实现多版本并发控制：
读已提交：每个语句看到的是语句开始时的快照，这是默认级别。
可重复读：每个事务看到的是事务开始时的快照，不会出现不可重复读，但幻读可能发生（在PostgreSQL的SI实现中，可重复读已经阻止了绝大多数幻读，因为同一事务内扫描同一范围返回相同的行集合，但不能完全阻止因谓词条件改变引起的写偏斜）。
可序列化：PostgreSQL 9.1起实现了基于可序列化快照隔离（SSI）的技术，通过跟踪读写依赖并动态检测序列化冲突来保证真正的可串行化，而非使用锁。它不使用MySQL InnoDB那样的间隙锁来阻止幻读，而是通过SI与冲突检测共同实现，这在高并发下能以较小开销提供最高隔离性。
2.5 复制与高可用
物理流复制自PostgreSQL 9.0引入，基于WAL传输。主库将WAL记录流式发送给备库，备库通过恢复模式持续应用，实现接近实时的同步。支持异步、同步（任一个或多个备库确认）以及级联复制模式。物理复制的优点是无延迟且强一致，缺点是要求主备大版本一致，且所有数据都会复制。
逻辑复制从PostgreSQL 10开始支持，基于发布/订阅模型。可以按表级别、甚至行过滤条件进行复制，支持跨大版本和部分跨平台。逻辑复制解耦了数据内容和物理存储格式，为数据分发、在线升级等场景提供极大灵活性。
在高可用方案上，社区工具Patroni已成为事实标准，它结合了etcd/Consul/ZooKeeper等分布式配置存储，提供自动故障切换、集群管理和VIP管理。其他方案如repmgr、PAF等也各有应用。
2.6 性能优化
PostgreSQL在复杂查询优化方面积累深厚。优化器使用基于成本的模型，支持遗传查询优化（GEQO）处理超多表连接。并行查询涵盖并行顺序扫描、并行索引扫描、并行哈希连接、并行聚合等多个方面。JIT（即时编译）在PostgreSQL 11中引入，使用LLVM将表达式计算和元组解析编译为机器码，尤其对CPU密集型分析查询效果显著。
分区表在PostgreSQL 10之后持续增强，采用声明式分区，支持范围、列表、哈希分区，并可将子分区置于不同表空间。通过分区裁剪，查询只需扫描相关分区。结合外部分区（FDW）还能构建简易分库方案。
3 MySQL深度解析
3.1 发展历史与许可
MySQL诞生于1995年，由瑞典MySQL AB公司开发，初期设计目标是成为轻量、快速的Web数据库。2008年被Sun Microsystems收购，2009年随Sun进入Oracle公司。其社区版使用GPLv2许可证，企业版需商业授权。由于Oracle的所有权以及开源社区的担忧，催生了两个重要的分支：MariaDB（由原MySQL创始人Monty Widenius领导）和Percona Server for MySQL（侧重于性能增强）。
3.2 架构设计
MySQL采用单进程多线程模型。一个mysqld进程负责处理所有连接请求，为每个连接分配线程（或通过线程池复用线程）。这种模型在大量短连接场景下线程创建销毁开销大，但线程间通信效率较高。与PostgreSQL的多进程模型形成鲜明对照。
最关键的架构特征是可插拔存储引擎。MySQL服务器层负责连接管理、查询解析、优化执行，而实际的数据存取由底层存储引擎完成。这种抽象层设计使得同一个数据库可以选择不同的存储引擎来存储表，为特定场景提供优化，但也带来了优化器必须对引擎功能“最小公分母化”的限制。
3.3 InnoDB存储引擎核心
自MySQL 5.5起，InnoDB已成为默认存储引擎，也是绝大多数场景下的首选。InnoDB的特性包括：
ACID事务，支持行级锁定，通过MVCC实现非锁定读。
聚簇索引：数据按照主键顺序组织在B+树叶子节点中，因此按主键查询非常快，二级索引叶子存储主键值，回表获取数据。这种设计对基于主键的OLTP查询十分高效。
MVCC实现：InnoDB在表空间的回滚段中存储旧版本数据（undo log）。更新操作会先写入undo log保留旧值，然后在数据页上执行修改。读取一致性快照时，需要通过undo日志还原到对应版本。因此，如果存在长时间运行的事务，undo log可能巨大，回滚大事务也代价高昂。
重做日志（redo log）和双写缓冲（doublewrite buffer）共同保证页写入的原子性，避免部分页写失败。
自适应哈希索引：对频繁访问的页面在内存中自动建立哈希索引，加速点查询。
缓冲池：缓存数据和索引，使用LRU变种算法管理。
3.4 核心特性演进
MySQL对SQL标准的支持在8.0版本有了飞跃：
窗口函数与公用表表达式（CTE）在MySQL 8.0中引入，极大增强了分析查询能力，但递归CTE的实现和优化相比PostgreSQL仍有差距。
JSON数据类型与一系列JSON函数，支持虚拟列上建索引来实现对JSON路径的快速查询（通过
JSON_EXTRACT生成列后索引）。但MySQL没有原生JSONB那种二进制存储和GIN索引，在大规模半结构化数据处理上弱于PostgreSQL。全文索引原生集成在InnoDB中，支持中文分词需要安装ngram解析器。
哈希连接在MySQL 8.0.18加入，优化了大数据集连接性能，此前长期依赖嵌套循环和块嵌套循环。
不可见索引允许在删除索引前先进行测试。
3.5 复制与高可用
MySQL的复制生态相当成熟且复杂，经历了从传统基于二进制日志位置到基于GTID的演进。
传统复制：主库将写入事件记录到binlog，从库I/O线程拉取并写入中继日志，SQL线程回放。可配置异步或半同步（需要至少一个从库确认接收到日志）复制。多源复制允许一个从库从多个主库汇聚数据。
GTID复制：每个事务拥有全局唯一标识，简化了故障转移和主从切换。
组复制（Group Replication）：基于Paxos协议，多个节点组成一致的多主或单主集群，提供自动故障检测和成员变更，是实现高可用的重要组件。
InnoDB Cluster：将组复制、MySQL Router（透明路由）和MySQL Shell组合在一起，提供完整的高可用与管理方案。
还有如NDB Cluster（分布式内存存储）用于电信级高可用场景。
3.6 性能与优化
MySQL的优化器主要基于成本估算，在简单OLTP查询上表现优异。索引合并、条件下推（ICP）、多范围读（MRR）等优化技术有效减少了数据访问量。企业版提供了线程池，Percona Server也实现了线程池以应对高并发。
4 PostgreSQL与MySQL详细对比
4.1 SQL标准兼容性与查询能力
PostgreSQL对SQL标准的支持历来显著领先。ANSI SQL中较新的特性，如窗口函数、CTE、递归CTE、LATERAL JOIN、FETCH FIRST WITH TIES等，PostgreSQL均较早实现。其执行复杂查询的优化器也更为成熟，支持多种并行执行与高级连接策略。MySQL 8.0虽然补齐了窗口函数和CTE，但在复杂SQL的优化深度、递归查询的处理能力、统计分析函数丰富度上尚有不足。例如，PostgreSQL的DISTINCT ON、GROUPING SETS、ROLLUP、CUBE等便捷语法在数据分析中很常用，MySQL则需通过多条语句或UNION模拟。
4.2 数据类型与索引丰富度
PostgreSQL的数据类型体系和索引远为丰富。原生数组、JSONB与GIN索引的组合使得PostgreSQL可直接承担一些文档存储或轻量搜索任务。范围类型对于日历、库存管理等场景提供了优雅的数据建模方式。而MySQL主要依赖标准的数值、字符串、日期类型，JSON支持依赖虚拟列索引，灵活性和性能表现均有限。索引方面，PostgreSQL的部分索引、表达式索引和BRIN/GiST/GIN等多类索引使得海量数据下的预聚合和特殊查询效率极高；MySQL的索引仅限于B-tree、全文和空间索引（基于R-tree），函数索引通过隐藏的虚拟列实现，无法做到部分索引。
4.3 MVCC与事务实现
两者都依赖MVCC提供一致性读，但实现方式不同。PostgreSQL将旧版本元组保留在原表，随VACUUM异步清理，更新操作立即产生新版本，回滚无代价，读不阻塞写。缺点是表膨胀需小心管理，长事务导致的写放大可能造成性能抖动。MySQL InnoDB将旧版本存入undo log，每次读取一致性视图均可能需要回溯undo链。优点是更新可能就地完成，表空间不会因旧版本而显著膨胀；缺点是大事务回滚耗时巨大，高并发下undo表空间可能成为瓶颈。两者默认隔离级别均为“读已提交”，但在“可重复读”下，MySQL通过间隙锁结合MVCC消除了幻读，而PostgreSQL依赖快照隔离基本消除幻读但写偏斜需要可序列化级别解决。
4.4 复制机制
PostgreSQL的物理流复制易于配置，数据强一致，特别适合同构集群；逻辑复制则提供了精细控制。其高可用需要借助外部工具如Patroni。MySQL的复制方案更多样化，GTID使运维更便捷，组复制原生实现了自动故障切换和一致性保障，InnoDB Cluster提供了开箱即用的高可用套件。但MySQL复制依赖binlog解析，在某些强校验场景下可能遇到一致性问题。总体而言，MySQL的高可用成熟度稍高于PostgreSQL原生，但PostgreSQL加Patroni的组合也已达到生产级。
4.5 性能对比
在传统的点查和主键范围扫描OLTP场景下，MySQL InnoDB凭借聚簇索引、优化良好的锁实现以及线程模型，通常表现出更低的延迟和更高的吞吐量（尤其是在高并发短事务下）。而PostgreSQL在复杂查询、分析型操作、并行处理和涉及大量计算的事务中优势明显，其JIT编译和丰富的索引类型能大幅加速特定工作负载。对于混合负载（HTAP），PostgreSQL更易于通过扩展（如Citus、TimescaleDB）平滑应对。读写混合场景下，PostgreSQL的MVCC无锁读提供了很好的读性能，但写压力的VACUUM影响需要留意。
4.6 扩展性与生态
这是PostgreSQL最核心的竞争力。其扩展框架不仅带来了功能模块，更催生了全新的数据库产品形态（见下一章）。MySQL虽有插件接口，但能力深度和广度远不及。从许可证角度看，PostgreSQL的类BSD协议意味着企业可以自由地基于它构建闭源的商业数据库系统（如EDB Postgres、许多国产数据库），而MySQL GPL要求衍生作品通常也必须开源，或需从Oracle购买商业许可。这一差异塑造了完全不同的产业生态：PostgreSQL衍生出大量独立产品的数据库产品，而MySQL更多以“分发版本”或“云服务”形式存在（如Amazon RDS for MySQL，Percona Server等），鲜有脱胎换骨的新形态。
4.7 安全性
PostgreSQL支持基于主机的认证（pg_hba.conf）、GSSAPI、LDAP、SCRAM-SHA-256等多种认证方式，行级安全策略（RLS）可以基于用户角色限制数据行可见性，列级权限和视图可以组合出细粒度控制。MySQL 8.0引入了角色管理，支持密码过期策略、双密码等，安全功能也在快速增强，但如RLS等高级特性仍然缺失。
4.8 运维与工具
MySQL有MySQL Workbench、Percona Toolkit、Orchestrator等丰富成熟的图形化和命令行工具，备份恢复（xtrabackup）高效便捷。PostgreSQL有pgAdmin、pgBackRest、Patroni等，运维自动化同样完善。两者在监控、备份和迁移方面都有成熟方案。
5 基于PostgreSQL的数据库产品
PostgreSQL宽松的许可证、卓越的扩展能力和优秀的SQL引擎，使其成为众多数据库产品开发的理想起点。这些产品或者直接基于PostgreSQL内核进行深度改造，或者利用其扩展框架构建专业化能力，或者采纳其SQL前端以兼容生态，形成了一支庞大的“PostgreSQL衍生家族”。
5.1 分析型MPP数据仓库：Greenplum
Greenplum数据库是最典型的基于PostgreSQL的MPP（大规模并行处理）分析型产品。最初基于PostgreSQL 8.2内核，后持续追并新版本特性。其架构为无共享（shared-nothing）集群：一个Master节点负责接收查询、生成并行执行计划并协调，多个Segment节点独立存储和处理数据，节点间通过高速Interconnect交换数据。
Greenplum在PostgreSQL引擎之上新增了列式存储、数据压缩、面向OLAP的优化器（GPORCA）、资源负载管理以及多态存储（行存与列存可选，支持外部表访问HDFS等）。它完整继承了PostgreSQL的SQL语法和扩展生态，用户可以直接安装PostGIS等扩展，对大规模地理数据分析尤为有用。
自2015年开源以来（Apache 2.0），Greenplum被广泛应用于企业数据仓库场景，与Teradata、Netezza等商业产品竞争。其基于PostgreSQL的特性使得熟悉PostgreSQL的团队可以快速上手。
5.2 云数据仓库：Amazon Redshift
Amazon Redshift是云计算时代的标志性数据仓库服务。它起初源自ParAccel分析数据库，而ParAccel正是基于PostgreSQL 8.0.2代码发展而来的闭源列存MPP引擎。因此，Redshift深层继承了PostgreSQL的SQL语法、目录表和驱动兼容性，用户可以使用标准的PostgreSQL JDBC/ODBC连接。
Redshift的存储完全采用列式，并结合AWS基础设施实现大规模并行扫描与自动负载管理，其管理控制台、快照、扩展等功能与云原生深度结合。尽管它已逐渐脱离PostgreSQL基础代码而独立演进，但其血缘关系仍表明，PostgreSQL作为分析数据库起始平台的可行性。在谈到基于PostgreSQL开发的数据库产品时，Redshift作为成功案例值得一书，它对SQL的支持和表现直接受益于PostgreSQL的遗产。
5.3 分布式扩展：Citus
Citus（现为Azure Cosmos DB for PostgreSQL 和 Azure Database for PostgreSQL – Hyperscale的基础）是一个将单机PostgreSQL转变为分布式数据库的扩展。它采用分片（sharding）架构：一个协调器节点持有元数据并路由查询，多个工作节点存储分片数据。Citus支持两种分发模式：按分布列哈希分片（append-distributed/range-distributed）和参考表（在每个节点完整复制），实现了分布式SQL、分布式JOIN和分布式事务。
Citus完全以PostgreSQL扩展形式运行，无需修改内核。这使得用户可以在分布式表上使用所有熟悉的PostgreSQL功能。它对HTAP场景很友好，既可支持高吞吐的实时分析，也可处理OLTP类工作负载。被微软收购后，Citus成为了Azure上极具吸引力的托管PostgreSQL横向扩展方案，同时开源版（AGPLv3）依然可用，充分体现了PostgreSQL扩展生态的商业价值。
5.4 时序数据库：TimescaleDB
TimescaleDB是专为时间序列、事件和度量数据优化的数据库，以PostgreSQL扩展形式存在。它在普通PostgreSQL表的基础上引入了超表（hypertable）概念：通过将表按时间列自动分区为多个内部块（chunk），每个块可以独立压缩、根据保留策略自动删除（数据生命周期管理）。
TimescaleDB允许使用标准SQL进行时序分析，支持窗口函数、连续聚合（物化视图的增量刷新）等，打破了专业时序数据库在SQL功能上的局限。其列式压缩算法和针对性的查询优化（如按时间分区的块裁剪、运行时聚合下推）使其在时序工作负载上大幅超越普通PostgreSQL。作为基于PostgreSQL的专用产品，它完美利用了PostgreSQL的可靠性和扩展点，降低了用户的采用门槛。
5.5 分布式SQL数据库：YugabyteDB与CockroachDB
这两个产品代表了所谓“NewSQL”分布式数据库的方向，它们都高度重视PostgreSQL兼容性。
YugabyteDB在架构上直接复用了PostgreSQL的上半部分代码（查询层），形成YSQL API。下层存储采用自研的分布式文档存储DocDB，结合RAFT共识算法和混合逻辑时钟，实现全球分布式事务。这意味着用户可以使用标准的PostgreSQL驱动和绝大部分语法来操作一个分布式的、高可用的数据库集群，真正算作“基于PostgreSQL开发的数据库产品”。它支持多区域复制、在线扩容和读取跟随。
CockroachDB虽然是用Go从零构建的，与PostgreSQL无共享代码，但它实现了PostgreSQL的连线协议和大量SQL语法，旨在成为分布式、生存力极强的全球数据库。因其与PostgreSQL生态的密切兼容（如ORM支持），常被一起讨论。严格来说它是一款“PostgreSQL兼容”产品，但其设计哲学同样彰显了PostgreSQL作为SQL标准实现标杆的影响力。
5.6 云原生数据库：Aurora、AlloyDB、PolarDB
云厂商对PostgreSQL进行了底层存储重构，创造出计算存储分离的云原生形态。
Amazon Aurora PostgreSQL是AWS旗舰的关系数据库服务。它与PostgreSQL查询引擎兼容，但核心创新在于存储层：Aurora将redo日志从计算层下推到分布式存储层，由存储层在多个可用区的多副本上自动修复和伸缩，避免了传统数据库将脏页写入存储的开销。计算与存储分离后，只读副本可以共享同一份存储，实现分钟级扩展。Aurora是云上最成功的PostgreSQL兼容服务之一。
Google Cloud AlloyDB for PostgreSQL是2022年推出的高性能PostgreSQL兼容服务，同样采用计算存储分离。它在PostgreSQL基础上植入了一层智能缓存和异步WAL处理，分析查询性能可达标准PostgreSQL的数十倍，同时保持了完全的兼容性，代表了下一代云原生PostgreSQL形态。
阿里云PolarDB for PostgreSQL采用共享存储架构，一主多读。自研的PolarFS分布式文件系统允许所有计算节点共享一份数据，结合只读节点的物理复制，实现快速扩容。PolarDB还集成了内存融合技术，进一步降低主备延迟，是国产云原生数据库的典型。
腾讯云TDSQL-C PostgreSQL版同样采用存算分离，提供按需扩展和高可用能力。这些云原生产品虽然基于PostgreSQL内核，但存储和复制机制已被彻底重写，专为云基础设施优化。
5.7 国产数据库阵营
在信创浪潮下，诞生了许多基于PostgreSQL的国产数据库。
openGauss是华为开源的关系型数据库，源自PostgreSQL 9.2.4内核，经过大规模重构。它引入了线程池模型、NUMA感知内存分配、列存引擎、MOT内存优化表、基于AI的自调优能力、全密态执行环境等创新。openGauss成为独立开源社区，衍生出商业版GaussDB，广泛应用在金融、运营商核心系统。它代表了从PostgreSQL起步并完全自研演进的路线。
KingbaseES（人大金仓）同样以PostgreSQL为基础，重点打造对Oracle、MySQL、SQL Server的深度兼容能力，提供数据迁移评估和自动化转换工具，极大降低从商业数据库迁移的门槛。其共享集群RWC支持多节点读写，在政务领域占据主导地位。
瀚高数据库（HighGo DB），基于PostgreSQL增强，专注于企业级安全特性，如国密算法支持、强制访问控制等。
神通数据库也兼容PostgreSQL协议。这些国产数据库几乎都选择了PostgreSQL作为技术基座，而非MySQL，这恰恰证明了PostgreSQL许可证的自由度和代码质量的吸引力。
5.8 企业级发行版：EDB Postgres Advanced Server
EnterpriseDB公司的Postgres Advanced Server是商业PostgreSQL的典范。它在社区版基础上增加Oracle兼容层（支持PL/SQL、数据库包、同义词、数据库链接），提供了企业级性能优化、安全管理、自动分区和原生审计等功能。EDB证明了基于PostgreSQL开源内核构建高价值商业产品的可行性，其授权收入证明了这条技术路线的成功。
5.9 其他重要衍生品
PostGIS：虽为扩展，但已构建起事实上的开源空间数据库标准，被众多商业GIS平台采纳，是PostgreSQL生态支柱之一。
PipelineDB（现为TimescaleDB的一部分）：流式计算扩展。
Vitess：Google开源的MySQL集群管理，但值得注意的是也有Citus这样的PostgreSQL方案。
各种DBaaS服务：如Crunchy Bridge，提供企业级高安全性的托管PostgreSQL。
6 应用场景与选型建议
适用PostgreSQL的场景
复杂查询与数据分析：需要窗口函数、递归查询、复杂统计报表的系统。
地理空间处理：搭配PostGIS承担LBS、GIS应用。
混合数据模型：需要同时处理关系型数据、JSON文档和数组的场景。
需要高度可定制性：希望利用扩展或FDW做数据联邦。
许可证敏感：希望闭源分发或构建自有数据库产品。
国产化替代：从Oracle迁移，可利用KingbaseES、openGauss的兼容能力。
适用MySQL的场景
典型Web应用与内容管理：如WordPress、Magento等现有生态深度绑定。
高并发简单OLTP：主键读写为主，查询相对简单，如用户会话、商品库存。
注重复制高可用开箱即用：需要组复制、InnoDB Cluster提供自动化集群管理。
团队有MySQL深厚经验，或公司已有大量MySQL资产。
混合与替代方案
如果数据量激增、查询复杂化，可考虑将MySQL与PostgreSQL分析扩展结合，或者直接迁移至基于PostgreSQL的专用产品。比如将日志分析负载迁移到TimescaleDB，将BI报表迁移到Greenplum。需要弹性伸缩时，评估PolarDB或Aurora等云原生PostgreSQL服务。
7 结论
PostgreSQL与MySQL并非简单地孰优孰劣，而是代表了两种成功的数据库哲学。MySQL以实用主义满足互联网对轻量、快速、简单的需求，形成了庞大的用户基础；PostgreSQL以学术的严谨、丰富的功能和极致的扩展性，成为技术深度的标杆，并孵化出一个生机勃勃的数据库产品家族。基于PostgreSQL开发的Greenplum、TimescaleDB、Citus、YugabyteDB、PolarDB以及众多国产数据库，证明了其作为技术基座的巨大价值。选择哪个数据库，本质上是对业务特征、团队技能和未来演进方向的权衡。理解这两大生态的深层差异，是每一位数据架构师的必修课。
参考文献
PostgreSQL Global Development Group. PostgreSQL Documentation. PostgreSQL: Documentation
Oracle Corporation. MySQL 8.0 Reference Manual. https://dev.mysql.com/doc/refman/8.0/en/
Greenplum Database Documentation. TechDocs
Citus Data. Citus Documentation. Citus Documentation — Citus 13.0.1 documentation
Timescale, Inc. TimescaleDB Docs. Tiger Data Documentation | Tiger Data Docs
Yugabyte, Inc. YugabyteDB Architecture. YugabyteDB Docs
Amazon Web Services. Amazon Aurora User Guide.
Alibaba Cloud. PolarDB for PostgreSQL Documentation.
openGauss社区. openGauss文档. openGauss社区官网 - 企业级开源关系型数据库 | openGauss社区官网
人大金仓. KingbaseES产品白皮书.
Stonebraker M., Rowe L.A. The Design of POSTGRES. ACM SIGMOD 1986.
