如何选择数据库？从真实案例看 PostgreSQL 与 MySQL 的优劣权衡

关系型数据库是几乎所有互联网应用的基础。在众多开源选项中，PostgreSQL 和 MySQL 是最常被拿来对比的一对“老对手”。

虽然它们都讲 SQL，但在设计哲学、性能表现和功能特性上差异明显。本篇文章结合了包括 Uber 在内的实际案例、AI 辅助建模的开发经验，并推荐一些实际工具，帮助开发者更清晰地做出技术选型。

---

为什么数据库选型至关重要？

数据库并不是“越强越好”，关键在于是否匹配你项目的业务模型、数据访问模式、团队习惯和未来扩展预期。

错误的选型可能导致性能瓶颈、开发难度上升，甚至影响后续系统的可维护性和迁移成本。

---

PostgreSQL：面向复杂业务的现代数据库

PostgreSQL 一直被视为开源世界中最接近企业级数据库的存在，很多开发者称它是“工程上的优等生”。

• 支持 JSONB 存储与索引，适合处理半结构化数据

• 提供 递归 CTE、窗口函数、自定义数据类型

• 拥有成熟的 MVCC（多版本并发控制），高并发读写表现优异

• 内置 全文检索 和 PostGIS 地理空间扩展

• 社区驱动，无商业授权限制，创新速度快

它尤其适合需要执行复杂查询、多维分析、数据清洗的系统，比如中台、报表、金融风控、内容平台等。

真实场景： Instagram、Netflix、GitLab、Discourse 等企业都在生产环境使用 PostgreSQL。

---

MySQL：轻量灵活，生态成熟

MySQL 更注重性能和部署的灵活性。InnoDB 引擎默认支持事务，近年来也持续引入现代功能。

• 支持多种存储引擎（InnoDB、MyISAM、RocksDB、MariaDB等）

• 性能优异，特别适合写多读多的场景

• JSON、递归 CTE 等特性逐步补齐

• 可借助 Vitess 等工具构建大规模分布式架构

• 类型设计上灵活，比如支持 TinyINT、MediumINT，可精细控制存储成本

使用建议： 如果你需要更轻量、易部署，或已有大批 MySQL 运维经验的团队，MySQL 是稳妥选择。

---

案例分析：为什么 Uber 放弃了 PostgreSQL？

Uber 在 2016 年发布了一篇广为流传的技术博客，描述了他们为何从 PostgreSQL 迁移至 MySQL。主要原因包括：

• 索引膨胀（Index Bloat）严重影响查询性能

• MVCC 在主从复制下存在一致性问题

• 写放大导致复制链路压力大

• PostgreSQL 的 VACUUM 机制让大表维护成本高

• 升级路径复杂，无法快速响应新版本功能

这些问题在 Uber 的极端高写入、高可用场景下被放大，不得不做出切换。

不过这并不是 PostgreSQL 的通病，而是其架构设计在特定条件下的挑战。到了 2025 年，PostgreSQL v17 已对上述问题进行了大量优化。

✅ 关键 takeaway：数据库选型一定是场景驱动的，不能简单复制别人的决策。

---

AI辅助建模：PostgreSQL vs MySQL 的类型设计对比

在一篇使用 AI 设计数据库的案例文章中，作者指出 PostgreSQL 虽然强大，但类型设计对性能的影响比想象中大。

例如：

• AI 默认推荐 ENUM，虽然节省空间，但 PostgreSQL 中 ENUM 实际存储成本并不低，索引表现不佳

• 使用 SMALLINT + lookup table 更容易维护，也利于迁移

• JSONB 推荐用于非定长字段，避免字段扩张问题

而 MySQL 在类型控制方面更灵活，比如支持 TINYINT、MEDIUMINT 等多种整数类型，可根据业务精细化配置存储效率。

结论：AI 是工具，真正的性能优化还需靠开发者自己把关。

---

️ 多数据库本地开发环境的工具推荐：ServBay

如果你正在开发支持多种数据库的应用，推荐使用 ServBay 作为本地环境工具。

• 支持同时运行 PostgreSQL 与 MySQL

• 一键启动，内置多版本管理，适合快速测试

• 支持 PHP、Redis、Mailhog 等常见服务

• 无需 Docker，适合 Mac 本地开发者

ServBay 能在项目初期测试不同数据库策略，为后期架构设计提供真实依据。

---

✅ 最后的建议：选择之前先问自己几个问题

1. 你的数据复杂吗？ 是否需要 JSON、地理空间、多维分析？

2. 读写比例如何？ 是高写入还是复杂查询为主？

3. 团队熟悉哪个栈？ 现有能力与工具链支持谁？

4. 未来是否会扩展到分布式？ 是否考虑跨区域复制、多主同步？

选数据库，别迷信哪个“更好”，关键是选对“适合自己”的。

---

总结

对比维度	PostgreSQL	MySQL
复杂查询能力	✅ 强	一般
并发处理	✅ 稳定	✅ 优秀
JSON/CTE/窗口函数	✅ 全支持	部分支持
生态工具	✅ 多样	✅ 成熟
存储灵活性	限定	✅ 多类型支持
运维复杂度	相对高	✅ 更轻量

选型的终极建议是：技术没有银弹，但理解你的系统，才是做对决策的开始。