PostgreSQL 与其他数据库怎么选——对比 FAQ

一页回答那些反复出现的问题。每个回答先给结论，再给一句诚实的"什么时候反过来选对方"，有纵深页面的附上链接。

PostgreSQL 与 MySQL 怎么选？

两者都是成熟、久经生产验证的开源关系型数据库，普通的 CRUD 应用用哪个都能跑得很好。PostgreSQL 的优势在纵深：更丰富的 SQL（窗口函数、CTE、lateral join）、更严格的标准行为、更多的索引类型，以及把它变成平台的扩展生态（PostGIS、pgvector）。MySQL 的优势在覆盖面：庞大的托管与工具体系，以及在简单高读 Web 负载上的长期记录。反过来选 MySQL 的情形：你的技术栈、托管环境或团队经验本来就是 MySQL 形态的，且负载就是直白的读写。完整对比见 PostgreSQL 与 MySQL 选型。

PostgreSQL 与 MariaDB？

MariaDB 是 MySQL 的社区分叉，由 MySQL 原作者在 Oracle 收购 MySQL 之后发起，至今仍以 GPL 发布，并与 MySQL 保持广泛的协议兼容。因此这个对比的 PostgreSQL 一侧与 MySQL 基本是同一条轴线：关系纵深与可扩展性，对阵更轻量、兼容 MySQL 的生态。反过来选 MariaDB 的情形：你想要 MySQL 兼容性但偏好社区治理的项目，或者你现有的 MySQL 栈想迁离 Oracle 的掌控而不是更换数据模型。完整对比见 PostgreSQL 与 MariaDB 选型。

PostgreSQL 与 Redis / Valkey？

不同品类，通常搭配部署：Redis/Valkey 是内存键值与数据结构服务器，PostgreSQL 是持久化的关系型数据库。经典模式是 Redis 作为挡在 PostgreSQL 前面的缓存或队列层，而不是替代它。规模不大的 KV 需求 PostgreSQL 自己就能扛——见把 PostgreSQL 当键值存储用。许可证方面：Redis 7.2 及之前是 BSD；2024 年 3 月 Redis 7.4 起改为源码可见的 RSALv2/SSPLv1 双许可证；自 2025 年 Redis 8 起，用户也可以改选 OSI 认可的 AGPLv3——见 Redis 许可证页面。Valkey 是 Linux 基金会基于最后一个 BSD 版本（7.2）的分叉，在 2024 年变更后数日由来自阿里巴巴、亚马逊、爱立信、Google、华为、腾讯的贡献者发起，并保持 BSD 许可证。反过来选 Redis/Valkey 的情形：你需要亚毫秒延迟、TTL 自动过期与驱逐，或 Redis 的数据结构（sorted set、stream）——这些 PostgreSQL 没有对应物。

PostgreSQL 与 MongoDB？

文档数据库对阵"也能做文档"的关系型数据库。PostgreSQL 的 jsonb 覆盖了大多数"灵活 schema"需求——可索引、可查询，还能与关系表在同一个事务里 join 和提交——见 JSONB 存储与检索。MongoDB 则完全以文档为中心构建，水平分片是其原生能力。一条许可证提示：自 2018 年 10 月起，MongoDB 社区服务器采用 SSPL——一个未获 OSI 认可的源码可见许可证，如果你打算把它作为服务对外提供，这一点很关键。反过来选 MongoDB 的情形：数据模型端到端都是文档形态、团队以文档方式思考，并且希望不用扩展就获得内建分片。

PostgreSQL 与 SQLite / Turso？

SQLite 是嵌入式、无服务器、单文件的引擎——进程内的一个库，而不是你要连接的服务器——采用单写入者模型。PostgreSQL 恰好是相反的形态：为大量并发连接而生的客户端/服务器数据库。Turso 是 libSQL 背后的公司；libSQL 是 SQLite 的开源、开放贡献分叉，增加了嵌入式副本与远程访问的服务器模式；其新一代 Turso 数据库是用 Rust 从零重写的 SQLite 兼容实现（截至本文写作时处于 beta），面向多数据库与边缘部署。反过来选 SQLite/Turso 的情形：数据库就活在应用内部或边缘节点，实际上只有一个写入者，而"要运维一台服务器"正是你想避免的事情。

PostgreSQL 与 DuckDB？

DuckDB 是进程内的列存 OLAP 引擎；PostgreSQL 是行存 OLTP 服务器。一句话版本：单进程文件分析找 DuckDB，并发事务服务找 PostgreSQL——两者的关系是组合多于竞争。反过来选 DuckDB 的情形：不起任何服务器、直接对 Parquet/CSV 做交互式分析。完整对比及两者混用方式见 PostgreSQL 与 DuckDB 选型。

Oracle 能迁到 PostgreSQL 吗？

能——这是业界最常见的数据库迁移之一，工具链与方法论都已成熟。真正的工作很少是数据本身，而是 schema 与过程化代码：PL/SQL 包、存储过程和 Oracle 专有 SQL 需要转换成 PL/pgSQL，Ora2Pg 等开源工具可以自动化其中大部分评估与转换。哪些特性迁移得顺、哪些需要重新设计、切换如何排期，见 Oracle 迁移到 PostgreSQL。继续留在 Oracle 的情形：负载依赖 PostgreSQL 没有直接对应物的能力、且应用无法改动——这部分残留有多少，正是迁移指南帮你估算的。

PostgreSQL 与 Elasticsearch / ClickHouse？

两者都是专用引擎而非通用数据库。Elasticsearch 是分布式搜索引擎（基于 Lucene），面向大规模全文检索与日志分析；ClickHouse 是列存 OLAP 数据库，为大扫描上的快速聚合而生。PostgreSQL 自带够用的全文检索，并能通过扩展触达列存分析（见扩展生态），中等规模下这往往已经足够。反过来选 Elasticsearch 的情形：搜索相关性、模糊匹配或日志摄取是产品的核心界面；反过来选 ClickHouse 的情形：负载以大型分析扫描为主，PostgreSQL 的行存在结构性上更慢。

总览表

相关页面

• PostgreSQL 与 MySQL 选型 与 PostgreSQL 与 MariaDB 选型——关系型阵营的深度对比
• 把 PostgreSQL 当键值存储用——什么时候可以完全不上 Redis
• PostgreSQL 与 DuckDB 选型——OLTP 与 OLAP，以及两者并用
• Oracle 迁移到 PostgreSQL——迁移手册
• 云 PostgreSQL 服务版图——选定 PostgreSQL 之后，跑在哪里