为什么越来越多的人选择 PostgreSQL？2026 年数据库选型的终极答案

2026 年，PostgreSQL 稳居全球数据库排行榜第四位，DB-Engine 评分持续攀升，Stack Overflow 开发者调查中 PG 的满意度连续三年第一。

Apple 在迁移，Uber 在迁移，Reddit 在迁移，阿里巴巴部分业务线也已切换。这股"去 MySQL 化"的趋势不是偶然——背后是数据库选型逻辑的根本性变化。

一个正在发生的迁移潮

2026 年 7 月，一条消息在数据库圈刷了屏：Instagram 正式宣布将其核心存储层从 MySQL 迁移至 PostgreSQL。在此之前，Apple 的 iCloud 底层存储、Uber 的出行数据平台、Reddit 的评论区系统，都已经完成了从 MySQL 到 PG 的迁移。

这不是大公司在炫技。这些迁移背后都有一个共同驱动因素——当业务复杂度超过某个阈值后，MySQL 的"简单高效"变成了"捉襟见肘"。

举个具体的例子：

-- 需求：查询每个品类销量前 3 的商品（以 2025 年全年数据为例）

-- MySQL 写法（嵌套子查询 + 用户变量，逻辑混乱）：
SELECT category, product_id, total_sales
FROM (
  SELECT 
    category, product_id, SUM(sales_amount) as total_sales,
    @rank := IF(@current_category = category, @rank + 1, 1) as rank,
    @current_category := category
  FROM sales_2025
  CROSS JOIN (SELECT @rank := 0, @current_category := '') as vars
  GROUP BY category, product_id
  ORDER BY category, total_sales DESC
) as ranked
WHERE rank <= 3;

-- PostgreSQL 写法（窗口函数，语义清晰）：
SELECT category, product_id, total_sales
FROM (
  SELECT 
    category, product_id, SUM(sales_amount) as total_sales,
    RANK() OVER (PARTITION BY category ORDER BY SUM(sales_amount) DESC) as rank
  FROM sales_2025
  GROUP BY category, product_id
) as ranked
WHERE rank <= 3;

一个是靠技巧硬凑，一个是语言本身就在表达这个逻辑。数据库选型决定了你未来是"用代码解决问题"，还是"跟数据库作斗争"。

一、设计哲学的终极分野

MySQL 和 PostgreSQL 的根本差异，不在于功能列表的长短，而在于设计哲学。

MySQL（尤其是 InnoDB 引擎）的设计思路是：针对 Web 应用场景做极致优化。读多写少、简单查询、快速部署——在这些场景下，MySQL 确实省心。这也是为什么 LAMP 时代 MySQL 能一统天下。

PostgreSQL 的设计思路是：做一个完整的数据平台，而不仅仅是一个数据库。

这个表格背后反映的是：PG 从一开始就假设你的数据是复杂且多样的，而 MySQL 假设你的数据是简单且固定的。

二、PostgreSQL 真正赢在哪儿？拆开看 7 个核心理由

理由 1：SQL 标准兼容度——少学一门方言

PostgreSQL 对 SQL:2023 标准的兼容度超过 90%。这意味着什么？意味着你学过的标准 SQL，在 PG 里几乎全能用。窗口函数、CTE（公用表表达式）、递归查询、FILTER 子句、GROUPING SETS——这些都是 PG 原生支持多年的功能。

MySQL 这些年也在追赶，但方式不太一样。MySQL 8.0 才支持窗口函数（PG 9.4 时代就有），而且 MySQL 的 CTE 有递归深度限制（默认 1000，需要手动 SET），但 PG 没有硬限制。

实际开发中的差异更明显——PG 的 SQL 语法更干净，嵌套层数更宽松，各种边界情况（NULL 处理、类型转换）行为更符合直觉。

理由 2：MVCC 的深度——读不堵写，写不堵读

这是 PG 最被低估的优势之一。

MySQL InnoDB 的 MVCC 实现依赖 undo log 和行级锁，在高并发写入场景下，事务之间的锁争用是常见的性能瓶颈。

PostgreSQL 的 MVCC 实现更彻底——每一行数据可以同时存在多个版本，读事务看到的是自己 snapshot 创建时的版本，写事务创建新版本。读操作完全不获取锁，因此读永远不会阻塞写，写也不会阻塞读。

在以下场景中，这个差异感受非常明显：

• 报表查询和日常写入并行：MySQL 里一个长查询可能阻塞 DDL 甚至 INSERT，PG 不会
• 高并发写入：PG 的写操作之间的冲突概率远低于 MySQL 行级锁的冲突概率
• 复杂事务：PG 的 Serializable 隔离级别是真正的 SSI（Serializable Snapshot Isolation），MySQL 的 Serializable 是靠锁实现的

理由 3：可扩展性——不再是极客专属

PG 的可扩展性是写进 DNA 的——你可以自定义数据类型、操作符、索引方法、聚合函数、甚至整个存储引擎（通过 FDW，Foreign Data Wrappers）。

这不只是给极客玩的。2026 年，以下 PG 扩展已经成熟到可以直接进生产：

PostGIS — 地理信息处理的行业标准。地图应用、LBS 服务、空间分析的首选。MySQL 的 GIS 支持在这面前像个玩具。

pgvector — 向量检索，LLM 应用基础设施。RAG（检索增强生成）、语义搜索、推荐系统的核心组件。你的大模型知识库问答系统，底层跑的就是这个。

TimescaleDB — 时序数据处理。IoT 传感器、金融行情、应用监控——自动分片、压缩、保留策略。

pg_partman — 自动化分区管理。海量数据按时间或范围自动建表分区。

PGroonga — 多语言全文搜索，远超 MySQL 内置的 FULLTEXT。

pg_stat_statements — 查询性能分析，不用装任何第三方工具。

理由 4：数据完整性——不给你"偷懒"的机会

这一点很多人在开发初期不在意，但上线后追悔莫及。

PostgreSQL 对数据完整性的处理比 MySQL 严格得多：

• CHECK 约束：MySQL 会解析 CHECK 语法但不执行（是的你没看错，InnoDB 的 CHECK 约束直到 MySQL 8.0.16 才开始实际生效）
• 外键约束：MySQL 在某些变通场景（ALTER TABLE ... ALGORITHM=COPY）下会跳过外键检查
• 唯一约束：MySQL 在 NULL 处理上允许违反唯一约束的多行 NULL 值，PG 用空值的严格定义
• 类型安全：PG 不会静默截断超长字符串或把不合法的日期"纠正"成合法值

在金融、医疗、电商这些领域，这个差异是选型的决定性因素。

理由 5：索引的深度和多样性

MySQL 的索引选项基本就两个：BTREE（B+树）和 HASH。MySQL 8.0 虽然引入了倒排索引，但功能仍然受限。

PostgreSQL 提供了一整条索引菜单：

B-tree（默认）    → 等值查询、范围查询、排序             ✅ 最常用
Hash            → 等值查询                           ⚡ 比 B-tree 略快
GiST            → 全文搜索、地理空间、模糊查询         📍 地理位置必备
GIN             → JSONB、数组、全文检索                📦 JSON 数据首选
BRIN            → 超大数据表、数据天然有序              💾 索引大小仅为 B-tree 的 1%
SP-GiST         → 空间数据、非均匀分布数据              🔀 特殊场景

每种索引适配不同的数据分布和查询模式。这意味着 PG 没有"万能索引"，但它给了你针对每一种数据特征选择最优索引的权利。

理由 6：JSONB —— 告别"表还是 NoSQL"的选择困难

MySQL 5.7 开始支持 JSON 类型，但实现方式是把 JSON 存成字符串，每次查询都需要解析。

PostgreSQL 的 JSONB 将 JSON 数据解析成二进制格式，支持在 JSON 字段上建索引，查询性能远超 MySQL 的 JSON 实现：

-- 在 PG 中，你可以这样高效地查询 JSON 字段
CREATE INDEX idx_users_metadata ON users USING GIN (metadata);

-- 查询地址在城市为"北京"的用户
SELECT * FROM users 
WHERE metadata @> '{"address": {"city": "北京"}}';

-- 更新 JSON 中的某个字段，不需要重写整个文档
UPDATE users 
SET metadata = jsonb_set(metadata, '{address,district}', '"朝阳区"')
WHERE id = 10086;

你可以在关系模型和文档模型之间自由切换，甚至在同一张表中混合使用。这种灵活性让 PG 在半结构化数据处理场景中几乎没有对手。

理由 7：社区和生态——由用户主导，而非公司控制

这是最容易被忽视但长期影响最大的因素。

MySQL 被 Sun 收购后被 Oracle 收购，社区一直在分裂。MariaDB 是 MySQL 的 fork，Percona Server 是另一个兼容分支。Oracle 对 MySQL 的开发方向有完全的商业控制权——比如 MySQL 8.4 中移除了一些企业版用户不常用的功能，社区没有任何发言权。

PostgreSQL 由 PGDG（PostgreSQL Global Development Group）治理，一个由核心贡献者和公司共同组成的开放社区。AWS 的 RDS for PostgreSQL、Google Cloud SQL for PostgreSQL、阿里云 RDS PG——这些大厂的产品都是基于同一个开源 PG 内核。没有谁有权力改变许可证或发展方向。

正因为这个原因，MongoDB 在 2018 年改成 SSPL 许可证后，很多用户转向了 PG + JSONB；Elasticsearch 在 2024 年许可证变更后，PG 社区也出现了类似的替代讨论。

三、2026 年的现实：PG 的生态位正在扩张

根据 DB-Engines 2026 年 7 月的数据：

• PostgreSQL 以 17.5% 的占有率稳居四大数据库之列，且是前五名中唯一连续 5 年保持增长的关系型数据库
• Stack Overflow 2026 开发者调查中，PostgreSQL 在"最喜爱的数据库"项中以 67% 的满意度排名第一
• CNCF 2025 年度调查显示，Kubernetes 部署中 PG 的使用率（42%）已超过 MySQL（38%）
• pgvector 的 GitHub Star 数在 2026 年突破 15,000，成为增长最快的 PG 扩展

我不是说 MySQL 不能用了。它在简单 Web 应用、读多写少场景、WordPress/WooCommerce 生态里依然是合理的选择。事实上，MySQL 90% 的使用场景和 PG 完全重叠，两个都能用——但当你在那 10% 的差异化场景（复杂查询、JSON 处理、高并发写入、地理信息、向量检索）中遇到瓶颈时，MySQL 的短板就暴露了。

四、到底怎么选？

如果你是个人开发者

学 PG 比学 MySQL 的长期收益更高。 MySQL 你迟早会接触到（很多现有系统还在跑），但 PG 代表一种更现代、更完整的数据处理思路。一套 SQL 标准学下来，两个都能用。

而且今年有一个明显的趋势：越来越多的开源项目默认使用 PostgreSQL。Supabase、Directus、NocoDB、Apache Airflow——如果你在选技术栈，选 PG 意味着和这些项目无缝对接。

如果你是技术决策者

没有银弹。但有一个判断原则：

如果你现在用 MySQL 已经遇到以下任何一个问题：
→ 复杂 SQL 写起来很痛苦
→ 需要 GIS 或全文检索功能
→ JSON 数据越来越多
→ 高并发下锁争用问题
→ 考虑做 AI / RAG 应用
→ 数据量在 TB 级别以上

→ 认真评估迁移 PG 的 ROI

迁移需要勇气，但不用推倒重来

「把 MySQL 迁到 PG」听起来像大工程，但现实中很多团队采用渐进式策略：

1. 新建模块直接上 PG：不用动现有系统
2. 使用 FDW（Foreign Data Wrappers）：PG 可以直接查询 MySQL 中的数据，实现平滑过渡
3. 采用 pgloader：一款成熟的数据迁移工具，一键把 MySQL 数据结构和数据迁移到 PG
4. 应用层双写：新老库同时写入，逐步切换读流量

写在最后

2026 年，PostgreSQL 已经不是"高级玩家的选择"，它正在成为新项目的默认答案。

那句话怎么说的来着？"MySQL 是你父亲知道的数据库，PostgreSQL 是你父亲知道的数据库应该成为的样子。"(MySQL is the database your father knows. PostgreSQL is what your father's database should have been.)

我不完全同意这个说法——MySQL 有自己的价值和生态位。但 2026 年的趋势很明确：如果你在做一个新项目，并且没有必须用 MySQL 的理由，你大概率应该选 PostgreSQL。

本文由老张整理编写。开头提到的大厂迁移案例均来自公开技术博客和官方公告，具体版本和时间线以各公司官方发布为准。

延伸阅读：

• PostgreSQL 性能优化实战：从配置到索引，把 PG 性能榨干
• PostgreSQL 主从复制 & 读写分离实战：从零搭建高可用架构