Compare · 3 个对象
MySQL vs PostgreSQL vs Oracle
三个关系库，三种活法：互联网、全能开源、商业核心
从谁的角度看
| 对比维度 | MySQL 互联网业务默认选择 | PostgreSQL 功能最全的开源库 | Oracle 金融级商业库 |
|---|---|---|---|
| 定位与成本 | |||
| 许可与费用 | GPL / 商业双许可，社区版免费 | 类 BSD，完全免费无限制 | 商业授权，按 CPU / 用户计费，昂贵 |
| 典型用户 | 互联网、电商、SaaS 初创 | SaaS、GIS、AI 应用、金融科技 | 银行、保险、运营商、大型 ERP |
| 能力 | |||
| SQL 标准符合度 | 中，方言较多 | 高，最接近标准 | 高，但有 PL/SQL 方言 |
| JSON 支持 | JSON 类型 + 函数，索引受限 | JSONB + GIN 索引，可当文档库用 | JSON 类型（21c+），能力较新 |
| 扩展机制 | 插件式存储引擎，功能扩展弱 | Extension 生态最强（PostGIS / pgvector） | 内建功能全，但不可自由扩展 |
| 存储过程 | 支持，能力一般 | 支持多种语言（PL/pgSQL / Python） | PL/SQL 最成熟，企业逻辑常写在库里 |
| 性能与并发 | |||
| 并发模型 | 一进程多线程，连接开销小 | 一连接一进程，必须配连接池 | 多进程 + 共享内存（SGA） |
| MVCC 实现 | undo log + ReadView，原地更新 | 行版本 + VACUUM，写新版本 | UNDO 表空间 + SCN，原地更新 |
| 写放大 | 较小 | 较大（更新即新版本，索引全改） | 较小 |
| 扩展方式 | 主从 + 分库分表（ShardingSphere） | 流复制 + 分区 + Citus | RAC 多活 + Data Guard + 分区 |
| 运维 | |||
| 高可用方案 | MHA / Orchestrator / MGR | 流复制 + Patroni / repmgr | RAC + Data Guard（最成熟也最贵） |
| 运维门槛 | 低，资料最多 | 中，参数与 VACUUM 要理解 | 高，需要专职 DBA |
| 一句话选型 | |||
| 什么时候选它 | 互联网业务、读多写少、要成熟分库分表方案和现成人才 | 复杂查询、JSON / GIS / 向量、想一个库解决多种需求 | 金融核心、合规审计、要求 7×24 且预算充足 |
点某一行可以高亮该维度，方便逐条横向读；移动端左右滑动查看全部列。
选型建议
MySQL
大多数互联网业务的默认答案：生态最全、招人最容易、分库分表方案成熟。
PostgreSQL
新项目功能需求复杂（JSON、地理、向量、复杂报表），且团队愿意理解 VACUUM，选它上限更高。
Oracle
金融核心、运营商计费这类不能停机又必须有人兜底的场景，预算够就上。
SQLite
如果数据只属于“一个进程、一台机器”，别上服务端数据库，SQLite 就够了。
一句话结论
选型顺序应该是：先看是不是单机嵌入式（是就 SQLite），再看预算和合规（要商业兜底就 Oracle），最后在 MySQL 和 PostgreSQL 之间按“功能复杂度 vs 生态成熟度”取舍。三者都能存好数据，差别在边界。