PostgreSQL 与其他数据库的优缺点对比

一、一句话定义

PostgreSQL 是一个功能最接近「全能」的开源关系型数据库。它既是 SQL 标准最忠实的实现者，又通过扩展生态把触角伸到了 JSON 文档、全文搜索、地理空间、时序数据、向量搜索等传统上属于 NoSQL 和专用数据库的领域。

二、纵向分析：从伯克利实验室到「数据库界的 Linux」

2.1 起源：三个人的学术接力

1986 年，加州大学伯克利分校的 Michael Stonebraker 带着 Ingres 项目的经验，启动了一个叫 POSTGRES 的研究项目。Ingres 是关系数据库的早期奠基者之一，但 Stonebraker 发现关系模型在处理一些复杂数据类型时力不从心，他想做一个「后 Ingres」系统，POSTGRES 的名字就是这么来的。

真正让 POSTGRES 与众不同的，是 Stonebraker 的三个核心设计信念：

1. 数据不只是行和列：系统应该内置支持用户自定义类型和复杂查询
2. 规则才是核心：他搞了一套基于规则的生产/推理系统，想让数据库能自动做出响应（后来演变为触发器和规则系统）
3. 开源学者基因：项目从一开始就是学术开放源码，代码公开，任何人都可以修改

1989 年，POSTGRES 发布了第一个可用版本，跑在当时的 BSD Unix 上。1993 年，外部用户数量已经超过伯克利内部的预期，Stonebraker 决定停止学术开发，把项目交给了社区。他跑去创办了 Illustra（后来被 Informix 收购，再后来被 IBM 吞掉），自己则继续在学术界深耕，最终在 2014 年拿到了图灵奖。

这段历史埋下了两个关键基因：

• 学术基因意味着 PostgreSQL 对 SQL 标准的遵循和对正确性的偏执，是刻在骨子里的
• 开源社区治理模式意味着它不可能被任何一家公司控制，但也意味着早期发展缓慢

2.2 SQL 化与改名：1994-1996 年的生死转折

1994 年，伯克利的两名研究生 Andrew Yu 和 Jolly Chen 做了一个在当时看来极其激进的决定：把 POSTGRES 的查询语言从 QUEL 换成 SQL。

这件事在今天看来理所当然，但在 1994 年，SQL 虽然已经是 ANSI 标准，但商业数据库市场被 Oracle、DB2、Sybase 瓜分，开源数据库还是一片荒地。QUEL 是 Ingres 时代的遗产，理论上比 SQL 更优雅，但 SQL 已经是事实标准。换掉查询语言，等于把整个查询引擎重写一遍。

他们做到了。1995 年，新系统以 PostgreSQL95 的名字发布。1996 年，正式更名为 PostgreSQL。

这个决策锁定了 PostgreSQL 的命运。 如果当时坚持 QUEL，PostgreSQL 会像 Ingres 一样成为历史名词。选择 SQL，它才活了下来。

2.3 MySQL 的崛起与 PostgreSQL 的「黑暗时代」（1995-2005）

几乎在同一年（1995 年），瑞典的 MySQL AB 发布了 MySQL。两个数据库接下来的十年，走上了完全不同的路。

MySQL 的路线是「够用就好，快最重要」。默认存储引擎 MyISAM 不支持事务，没有外键约束，但读写极快，适合 LAMP 架构（Linux + Apache + MySQL + PHP）。创始团队清楚 MySQL 缺什么，但他们的哲学是：先让用户用起来，再慢慢补。

PostgreSQL 的路线是「正确性优先，功能完整」：完整的事务支持（ACID）、外键、视图、触发器、自定义函数、MVCC（多版本并发控制）。性能上不如 MySQL，但能做 MySQL 做不了的事。

这十年 PostgreSQL 的处境非常尴尬：

• LAMP 浪潮席卷全球，MySQL 是 Web 开发的默认数据库
• PostgreSQL 被互联网创业公司视为「学术玩具」「太重了」「跑不动 Web」
• 维护 PostgreSQL 数据库需要比 MySQL 更懂原理的 DBA
• 社区治理虽然开放但决策缓慢，发版节奏跟不上需求

2005 年，DB-Engines 上 MySQL 的排名长期在第 2 位（仅次于 Oracle），而 PostgreSQL 排名在第 5-6 位徘徊。

2.4 从 Windows 到 JSON：关键的两次版本拐点

2005 年，PostgreSQL 8.0 原生支持 Windows

这是 PostgreSQL 发展史上最重要的版本之一。在那之前，Windows 用户只能用 Cygwin 模拟，体验极差。8.0 版本让 PostgreSQL 进入了 Windows 服务器市场，虽然当时 Windows 上的 MySQL 已经铺得很广，但这条路打开了。

2010 年，PostgreSQL 9.0 流复制与热备

9.0 版本引入了 Streaming Replication（流复制）和 Hot Standby（热备），解决了长期被诟病的「高可用太难」问题。企业级用户开始认真考虑 PostgreSQL。

2012 年，PostgreSQL 9.2 JSON 支持

这个版本埋下了未来十年最重要的伏笔。PostgreSQL 9.2 引入了一个简单的 JSON 数据类型，当时只是「能存 JSON 字符串」。没人想到，这会在两年后彻底改变数据库格局。

2014 年，PostgreSQL 9.4 JSONB

JSONB（Binary JSON）是真正的大杀器。它比普通 JSON 存储效率更高、支持索引（GIN 索引）、可以在 JSON 字段内做查询优化。这是 PostgreSQL 第一次对 MongoDB 发出正式挑战。

2.5 临界点：2015-2018，为什么 PostgreSQL 开始反超

2015-2018 年，PostgreSQL 的几个关键变化叠加在一起，在开发者社区里引发了质变：

1. JSONB 生态成熟（2015-2016）

越来越多的开发者发现：「我可以用 Postgres 存 JSON，同时还能做 JOIN 和事务，为什么还要 MongoDB？」前端团队尤其喜欢这种「一个数据库搞定所有」的体验。

2. 并行查询（PostgreSQL 9.6，2016）

长期被诟病的单查询性能短板终于补上了。9.6 的并行查询虽然不完美，但方向对了。

3. 逻辑复制与声明式分区（PostgreSQL 10，2017）

10 版本是 PostgreSQL 的成年礼。逻辑复制解决了之前基于 WAL 流复制的很多限制，表分区从通过继承模拟变成了标准 SQL 语法。

4. 云厂商的拥抱

2015 年，Amazon RDS for PostgreSQL 正式上线。Heroku 从诞生就在用 Postgres。2017 年，Google Cloud SQL 和 Azure Database for PostgreSQL 相继支持。云厂商集体压注 PostgreSQL，让开发者不需要自己折腾运维就能用上 PG。

5. 开发者调查的关键数据

Stack Overflow 年度开发者调查中，PostgreSQL 的使用率逐年攀升：

• 2017 年：32.4%（首次超过 MySQL 的单年使用率，虽然后者仍是总量第一）
• 2019 年：36.5%（成为最受开发者喜爱的数据库）
• 2022 年：46.5%（断崖式领先）
• 2024 年：达到 49.0%，SQLite 紧随其后（45.8%），MySQL 降到 38.9%

DB-Engines 排名变化更能说明问题：

• 2015 年：PostgreSQL 排名第 4（Oracle、MySQL、SQL Server 前三）
• 2018 年：PostgreSQL 超过 SQL Server 成为第 3 名
• 2020 年：超过 MySQL 成为第 2 名（仅次于 Oracle）
• 2023-2025 年：保持在 Oracle 之后，但差距持续缩小

2.6 AI 时代：2023-2026 的第二次爆发

2023 年，AI 浪潮把 PostgreSQL 推到了一个意想不到的位置。

pgvector 的爆发

pgvector 是一个简单的扩展，给 PostgreSQL 加上向量相似度搜索能力。2023 年之前它几乎无人知晓，但随着 LLM 应用爆炸式增长，RAG（检索增强生成）成为标配，pgvector 的下载量从 2023 年初的每月几万次飙升至 2024 年底的每月数百万次。

2024 年 Stack Overflow 调查中，pgvector 成为增长最快的数据库扩展。PostgreSQL 在 AI 领域的最大优势，是它让开发者不需要在「向量数据库」和「业务数据库」之间做数据同步：一个 PG 实例，存向量，也存业务数据，JOIN 一下就行。

Supabase 的杠杆效应

2020 年成立、2022 年 $30M A 轮、2024 年 $80M B 轮、2025 年估值超过 20 亿美元。Supabase 的起飞速度远超同类产品。它的定位是「Firebase 的开源替代」，但底层用 PostgreSQL 而不是 NoSQL。Supabase 对 PostgreSQL 社区的最大贡献，是把 PG 的开发者体验（DX）提升到了 Firebase 级别：实时订阅、自动生成 REST API、可视化表编辑器、Row Level Security 集成。

Neon 的 Serverless PG 革命

2022 年成立的 Neon，主打计算-存储分离的 Serverless PostgreSQL。2025 年 5 月，Databricks 以约 10 亿美元收购 Neon，引发社区震动。争议在于：Databricks 是数据湖仓公司，收购 Serverless PG 公司做什么？最流行的解读是，Databricks 需要 PostgreSQL 的 OLTP 能力来补充其极端 OLAP 定位，走「湖仓一体 + 事务」路线。

2024-2026 的新扩展潮

• pgai（2024）：让 PostgreSQL 可以直接调用 LLM API（OpenAI、Anthropic）
• pgvectorscale（2024）：微软开源，基于 pgvector 的规模化向量搜索
• pg_duckdb（2024-2025）：让 PostgreSQL 内部能跑 DuckDB 的分析引擎
• PostgreSQL 17（2024）：增量备份、WAL 改进
• PostgreSQL 18（2025 年 9 月发布）：异步 I/O 支持、OAuth 认证、merge 命令增强

2.7 中国市场的特殊路径

在中国，PostgreSQL 的传播路径和西方不太一样。

信创与去 O 化： 2019 年之后，国产数据库成为信创政策重点。PostgreSQL 的 BSD 许可证（允许修改后闭源再发布）比 MySQL 的 GPL 更友好，国内大厂纷纷基于 PG 改造：

• 阿里 PolarDB-P（基于 PostgreSQL 的云原生数据库）
• 华为 openGauss（开源，基于 PostgreSQL，但经过大量修改，2020 年开源）
• 腾讯 TDSQL-P（基于 PostgreSQL 的分布式数据库）
• 人大金仓 KingbaseES（国产数据库老牌玩家，基于 PostgreSQL）

openGauss 的处境比较特殊：它本质上是 PostgreSQL 11.x 的硬分叉，源码中大量修改了内核代码（如线程模型替换了进程模型）。但 openGauss 社区和 PG 上游社区之间的关系一度比较紧张：2020 年时 openGauss 被批评「只取不还」，2023 年之后情况有所改善，但贡献量仍然微弱。

三、横向分析：竞品对比

3.1 竞品格局总览

PostgreSQL 的竞品图谱非常复杂，因为它横跨了多个数据库细分赛道：

3.2 MySQL / MariaDB：最老牌的对手

MySQL 的来时路

MySQL 是 Web 2.0 时代的最大受益者。2008 年，Sun Microsystems 以 10 亿美元收购 MySQL AB。2010 年，Oracle 收购 Sun，MySQL 归属 Oracle 旗下。Michael Widenius（MySQL 创始人）因为担心 Oracle 会搞死 MySQL，分叉了 MariaDB。

MySQL 到今天仍然活得很好的原因有三：

1. 庞大的存量基础 微信、支付宝、淘宝、Facebook、Twitter（早期）、GitHub，这些互联网巨头的核心业务大量跑在 MySQL 上。迁移成本太高，大部分不会动。

2. 运维成熟度 MySQL 的复制（binlog-based）历史悠久，主从、半同步、GTID、组复制等方案经过了十几年的生产验证。PostgreSQL 的逻辑复制直到 2017 年（10 版本）才成熟，在此之前的高可用方案（Patroni、repmgr、slony）配置复杂度远高于 MySQL。

3. 云厂商的深度优化 阿里云 RDS MySQL、AWS Aurora、Google Cloud SQL for MySQL 都经过了大量内核优化，性能指标亮眼。

但 MySQL 正在失去开发者心智

Stack Overflow 2024 调查中，MySQL 的「被使用率」是 38.9%，被 PostgreSQL（49.0%）和 SQLite（45.8%）双双超过。更致命的是，在「最喜爱数据库」排名中，MySQL 已跌出前五。

核心技术差距：

用户口碑：为什么还有人坚持 MySQL？

在 Reddit 和 V2EX 上，坚持 MySQL 的声音集中在几个点：

• 团队十年经验，全部是 MySQL 技能栈，迁移成本难以承受
• 云厂商 RDS MySQL 优化极好，实际性能差距不大
• 对于简单的 CRUD 业务，哪个数据库都一样，没必要换
• PostgreSQL 的 VACUUM 调优太可怕了

2025-2026 的 MySQL 现状

• MySQL 8.4 LTS 是当前的主流版本，MySQL 9.x 创新版本也发布了，但社区采用谨慎
• Oracle 加大了 HeatWave（MySQL 的 OLAP 引擎）的投入，试图把 MySQL 变成一个 HTAP 数据库
• MariaDB 经历了财务危机（2024 年 10 月私有化，估值暴跌）

3.3 SQLite：最被低估的竞争对手

SQLite 是全世界部署量最大的数据库：每台手机、每台电脑、每个浏览器，都在用。它是一个嵌入式数据库，没有服务器进程，数据存储在单个文件里。

为什么用 SQLite？

• 零配置，不需要安装、配置、启动服务
• 全世界上部署量（估计超过 1 万亿份）
• 读写极快（单机、单连接场景）
• 文件格式稳定，30 年兼容性承诺

2023-2025 的 SQLite 复兴

SQLite 这几年经历了一波让人意外的复兴：

• Turso（2023）：基于 SQLite 的分布边缘数据库，拿到 $10M+ 融资
• Cloudflare D1（2023-2024）：Cloudflare 的全球边缘数据库，底层是 SQLite，运行在 300+ 个数据中心
• libSQL（2023-2024）：Turso 维护的 SQLite 分叉，增加了向量搜索、主从同步、WASM 支持
• LiteFS（2023）：Fly.io 的 SQLite 分布式方案

SQLite 的致命短板

• 并发写入性能极差（一次只能有一个写入者）
• 不支持主从复制（需要上层方案绕）
• 数据量大时（> 100GB）不稳定
• 不支持网络访问（需要上层封装，如 Turso/libSQL）

PostgreSQL vs SQLite 的关系

它们不是竞争关系，而是互补关系。行业内越来越流行的模式是：

• 开发环境：SQLite（零配置，快速启动）
• 生产环境：PostgreSQL（并发、多连接、高可用）
• 边缘计算：SQLite（D1、Turso）

这个模式在 Prisma、Drizzle、Django 等 ORM/框架中得到了原生支持：切换数据库只需要改一行连接字符串。

3.4 MongoDB：从 NoSQL 旗手到「也想要 ACID」

MongoDB 是 NoSQL 运动中最成功的「文档数据库」。它诞生于 2009 年，在 2010-2015 年的 NoSQL 爆发期，MongoDB 的 slogan 一度是「You don't need a relational database」。

MongoDB 的故事：从不可一世到回归理性

2010 年代初，MongoDB 的快速增长堪称恐怖。它抓住了 Web 2.0 时代的一大痛点：关系型数据库的 schema 太僵化，每次改表结构都要做 migration，而对于快速迭代的创业公司来说，schema-less 的文档模型简直是天赐之物。

但 MongoDB 也吃了很多苦头。2013 年，Jepsen 测试发现 MongoDB 的「默认写入不确认」会导致数据丢失，引发了社区信任危机。2018 年之后，MongoDB 才逐步补上事务支持：4.0 版本引入了多文档 ACID 事务，但性能代价不低。

PG JSONB 对 MongoDB 的打击

2014 年 PostgreSQL 9.4 发布 JSONB 之后，MongoDB 的「文档优势」开始被侵蚀。JSONB 让 PostgreSQL 既能存 JSON、又能做 JOIN、又能做事务，而 MongoDB 直到 2018 年才有事务。

Reddit 和 Hacker News 上，越来越多的人说：「用一个 PG 就够了，为什么还要 Mongo？」

2025 年的 MongoDB：

• 市值仍然很大（虽然从 2021 年高点跌了 60%+，但 2024-2025 有所回升）
• 在「天然文档模型」场景（如目录、配置、内容管理系统）仍有优势
• 但「PG JSONB 对大多数场景够用」的共识已经形成
• MongoDB 8.0（2024）增加了更多关系型数据库特性

当人们在讨论 MongoDB vs PostgreSQL 时，本质是在讨论：

• 你愿意为 schema flexibility 放弃多少 transactional guarantee？
• 你的数据模型真的需要文档数据库吗？还是 JSONB 就够了？
• 你愿意为多维护一个数据库付出多少运维成本？

3.5 Redis：缓存的王者，但不止是缓存

Redis 严格来说不是 PostgreSQL 的竞品，它们是互补的。但在缓存层和 KV 存储场景，Redis 几乎是不可替代的。

Redis 的优势：

• 纯内存操作，读写延迟 1 毫秒以内
• 丰富的数据结构（String、Hash、List、Set、Sorted Set、Bitmap、HyperLogLog、Stream）
• 发布订阅、Lua 脚本、过期策略
• 集群模式成熟

2024 年的 Redis 许可证风波

2024 年 3 月，Redis 宣布将许可证从 BSD 切换到 RSALv2 和 SSPL，意味着云厂商不能再免费提供托管的 Redis 服务。这导致 Linux 基金会分叉了 Valkey，AWS、Google Cloud、Oracle 纷纷加入 Valkey 阵营。这是自 MongoDB 2018 年换许可证、Elasticsearch 2021 年换许可证之后，开源数据库领域又一次大规模分叉事件。

PostgreSQL 和 Redis 的互补关系

在典型的生产架构中，它们不是二选一的关系：

• PostgreSQL 是「真相来源」（Source of Truth），存所有持久化数据
• Redis 是「缓存层」（Cache Layer），存热点数据，降低数据库压力

但 PostgreSQL 18 的异步 I/O 改进和内存优化，正在缩小 PG 和 Redis 在「高性能 KV 读取」场景的差距。虽然不会取代 Redis，但「Redis 是不是必要的」这个问题在越来越多的架构讨论中被提起。

3.6 ClickHouse 与 DuckDB：分析型数据库的崛起

ClickHouse：列存的威力

ClickHouse 是俄罗斯 Yandex 在 2016 年开源的列式存储数据库，专为 OLAP（在线分析处理）而设计。它的核心哲学是「宽表、大扫描、聚合查询」：对亿级数据的 GROUP BY 查询，ClickHouse 可以比 PostgreSQL 快 10-100 倍。

ClickHouse 的典型场景：

• 用户行为分析（埋点、事件）
• 日志分析
• 实时 BI 报表
• 数据湖仓架构中的分析层

DuckDB：2023-2025 的现象级爆火

DuckDB 是 2019 年从荷兰 CWI 研究机构诞生的嵌入式分析型数据库，定位是「SQLite 的 OLAP 版本」。它不需要服务端，嵌入在 Python/R/Node.js 进程中运行，使用列式存储 + 向量化执行引擎，单机分析性能极强。

DuckDB 的爆火速度非常惊人：

• 2022 年：GitHub 5k stars
• 2023 年：20k stars
• 2024 年：40k stars
• 2025 年：超过 60k stars

PG 在分析场景的短板

PostgreSQL 是行存储，对于大表扫描和聚合查询，它的性能天然不如列存数据库。PostgreSQL 的 OLAP 改进（并行查询、JIT 编译、分区表）虽然一直在进步，但和 ClickHouse 这类专门为分析设计的系统相比，差距仍然很大。

两方的生态正在融合

有趣的是，2024-2025 年出现了 PG 和 DuckDB 杂交的趋势：

• pg_duckdb：在 PostgreSQL 内部运行 DuckDB 的分析引擎，让 PG 的 SQL 能自动利用 DuckDB 的列存和向量化执行
• DuckDB 的 PostgreSQL 连接器：让 DuckDB 可以查询 PG 的数据

这说明开发者想要的是「一个数据库 + 一个分析引擎」的协同工作，而不是「两个数据库」的运维负担。

3.7 分布式 NewSQL：Postgres 协议兼容军团

这些数据库的共同点是：SQL 接口兼容 PostgreSQL 协议，但底层存储和计算引擎是完全不同的分布式架构。

为什么它们都要兼容 PG 协议？

因为 PostgreSQL 的 SQL 方言和客户端库生态已经成了事实标准。如果一个新的分布式数据库需要从零设计查询语言和客户端驱动，没人会用。兼容 PG 协议意味着：

• 开发者可以直接用 psql、pgAdmin、Prisma、Drizzle 连接
• 现有的 PG 应用代码几乎不需要改动
• 生态红利（pgvector、PostGIS 等扩展）可以继承

PostgreSQL 自身在分布式场景的短板

PostgreSQL 不是分布式数据库。它的高可用方案（流复制 + Patroni + etcd）可以做到自动故障切换，但做不到「一个集群多个节点同时写入」：写扩展只能靠分层（读写分离、分库分表、Citus 扩展，或者换用 CockroachDB/TiDB）。

四、横纵交汇洞察

4.1 历史如何塑造了今天的竞争位置

PostgreSQL 今天的位置，不是一个「战略规划」的结果，而是三个关键历史选择叠加的产物：

选择一：1994 年把 QUEL 换成 SQL

这个决策让 PostgreSQL 活了下来。如果当时选择坚持 QUEL，PostgreSQL 会像 Ingres 一样成为历史名词。但代价是，SQL 化比 MySQL 晚了 6 年起步，错过了 Web 1.0 和 LAMP 浪潮。

选择二：JSONB 的豪赌（2014）

PostgreSQL 9.4 的 JSONB 是开源社区的一个「非常规操作」：关系型数据库不是因为 JSON 而存在的，但 PostgreSQL 选择在关系模型之上兼容文档模型。这个决定拉开了 PostgreSQL 从关系型数据库进化为全能型数据库的序幕，也是它反超 MySQL 的关键转折点。

选择三：BSD 许可证的长期主义

MySQL 是 GPL 双许可，商业使用需要购买许可或者开源自己的代码。PostgreSQL 选择 BSD/MIT 许可证：你可以修改它、闭源它、卖它，什么都不用给上游。这个选择在 2000 年代被批评为「太天真了，别人白嫖你的代码」，但在 2020 年代反而成了最大的竞争力：云厂商愿意深度集成 PostgreSQL，企业愿意在 PostgreSQL 上构建商业产品（Supabase、Neon、Timescale、Citus），因为没有任何许可风险。

4.2 优势的历史根源

今天 PostgreSQL 的每一个核心优势，都能追溯到某个历史节点：

4.3 劣势的历史根源

同样，每个劣势也都有历史原因：

最耐人寻味的一个问题是：VACUUM 这个「历史包袱」为什么一直没改？

MVCC（多版本并发控制）是所有主流数据库都在用的机制，但 PostgreSQL 实现 MVCC 的方式是「把旧版本留在数据页里，等 VACUUM 来清理」。MySQL 的 MVCC 用 undo log 实现，旧版本写入 undo log，数据页本身不用管。这两种方式各有优劣，但 VACUUM 的写放大和调优地狱确实是 PostgreSQL 最被诟病的地方。

为什么不改？因为 VACUUM 的机制已经渗透到 PostgreSQL 存储引擎的每个角落：从页面布局到索引格式到 WAL 日志。改它等于重写存储引擎，而 PostgreSQL 社区没有这个资源。相当于一栋老房子的地基砌法，上面住了 30 年，已经没法拆了重建。

4.4 未来推演：三个剧本

剧本一（最可能）：PostgreSQL 继续扩张，但每个赛道都有更专业的对手

PostgreSQL 会继续蚕食 MySQL 的份额，在 2026-2028 年之间可能超过 Oracle 成为 DB-Engines 排名第一。pgvector 和 AI 相关扩展会让 PG 在 RAG 场景成为默认选择。

但 PostgreSQL 不会消灭其他数据库。每个赛道都有更专业的选择：

• 需要极致分析性能：ClickHouse / DuckDB
• 需要极致缓存性能：Redis / Valkey
• 需要嵌入式部署：SQLite
• 需要全球分布式强一致：CockroachDB / Spanner

PostgreSQL 的定位是「覆盖面最广的通用数据库，但不是任何细分赛道的极致」，这恰恰是它最大的价值。

剧本二（最危险）：摩尔定律打破了 PG 的护城河

如果 DuckDB 类嵌入式分析引擎进步到可以做 OLTP 事务，或者 ClickHouse 增加了完整的事务支持，分析型数据库会侵蚀 PostgreSQL 的上层场景。同时，TypeScript 全栈生态（Prisma、Drizzle）的抽象层让换数据库的成本越来越低：如果应用层和数据库之间隔了一层 ORM，换数据库的迁移成本大幅降低，PostgreSQL 的生态锁定效应会减弱。

最危险的时间点是 2028-2030 年，如果 DuckDB 的写入性能和支持了并发，它可能成为「更好的 SQLite + 分析能力」，蚕食 PostgreSQL 的轻量级场景。

剧本三（最乐观）：PostgreSQL 成为「数据基础设施的 Linux」

就像 Linux 统治了服务器操作系统，PostgreSQL 可能统治数据库操作系统：

• 所有云厂商都提供 PG 兼容服务
• 新的分布式数据库都兼容 PG 协议
• 扩展生态足够丰富，可以覆盖 90% 的应用场景
• pg_duckdb 类扩展让 PG 内部也能跑分析引擎
• 一个 PG 实例 = 一个数据库平台

Supabase 的 slogan「PostgreSQL is the only database you need」从这个角度看，可能不是营销口号，而是未来趋势的预言。