你们在用MySQL还是PostgreSQL？-编程阁

大家好，我是地鼠哥，最近和我们就业陪跑训练营学员日常答疑的时候聊到一个有趣的话题，就像标题中说的，你们正在用什么DB呢？为什么呢？也欢迎在文末留言区交流。

最近几年，关注国内信创产业或数据库领域的人会发现一个现象：虽然MySQL在互联网公司的业务开发中依然占据主导地位，但那些主打“自主可控”、“高性能分布式”的国产数据库，绝大部分都是基于PostgreSQL深度开发的。

这并不是巧合。我们先来看看这几家头部厂商的选择：

腾讯云 TDSQL PG版（TBase）
github.com/Tencent/TBa…
他们引入了GTM全局事务管理器，实现了跨分片的事务支持。
阿里云 PolarDB for PostgreSQL
他们重构了存储层，做到了“一写多读共享存储”，解决了传统数据库扩容慢的问题。
华为云 GaussDB(for openGauss)
opengauss.org
华为在PG的基础上加入了列存储引擎和AI优化器，主要面向HTAP（混合事务/分析处理）场景。
杭州易景数通 openHalo
github.com/HaloTech-Co…

为什么这些架构师和厂商，在研发底层系统时，都不约而同地选择了PostgreSQL？今天我们就从实战和架构的角度来聊聊这背后的原因。

1. 开源协议与自主可控

这一点是国产数据库厂商最看重的。

MySQL虽然开源，但它的版权属于Oracle公司。MySQL采用的是GPL协议，而且存在商业版和社区版的区别。这意味着如果要基于MySQL修改内核并发布商业产品，会面临法律和商业上的限制。更重要的是，核心开发路线图是由Oracle控制的。

PostgreSQL则完全不同。它采用的是类BSD协议，这是一种非常宽松的协议。可以随意修改代码、重新分发，甚至闭源商业化，而不需要受制于任何一家商业公司。PostgreSQL的控制权在社区手里，由全球开发者共同维护。对于想要打造“自主知识产权”产品的国产厂商来说，PostgreSQL显然是更安全、更可控的基础。

2. 数据库的可扩展性

在使用MySQL时，我们通常只把它当作一个存储数据的仓库：存进去，取出来。如果需要额外的功能，比如分词、时序数据处理，通常会引入Elasticsearch或InfluxDB等其他组件。

但PostgreSQL的设计理念不同。它支持极其强大的插件机制（Extension），允许开发者深入内核去扩展功能，而不是仅仅停留在应用层。

看看这些常用的扩展，每一个都具备独立处理特定场景的能力：

TimescaleDB：直接把PG扩展为专业的时序数据库，支持自动分区、压缩。
pg_trgm：在数据库内就能做高效的模糊匹配和相似度搜索。
Citus：通过插件就能把单机PG扩展为分布式数据库。
pg_stat_statements：详细的SQL执行统计，排查性能问题非常方便。

在MySQL中，想要实现类似级别的扩展，难度要大得多。

3. 数据处理能力的差异

在实际开发复杂业务系统时，MySQL的一些设计细节常常会让开发者感到受限，而PostgreSQL则提供了更严谨的解决方案。

关于序列（Sequence）

在MySQL中，通常使用AUTO_INCREMENT。但如果需要一个全局唯一的ID生成器，或者需要在多个表之间共享同一个序列，MySQL就难以直接实现。可能需要专门建一张表来维护ID，或者依赖Redis。

PostgreSQL原生支持独立的序列对象，它不依赖于任何表：

-- PostgreSQL 中创建独立序列CREATESEQUENCE order_seqSTARTWITH1INCREMENTBY1;-- 使用序列生成 ID，完全独立于表结构INSERTINTOorders(id,name)VALUES(nextval('order_seq'),'test');

对比一下MySQL的处理方式，需要模拟实现：

-- MySQL 必须绑定到某张表的 AUTO_INCREMENT ALTER TABLE orders AUTO_INCREMENT = 1000; -- 或者用复杂的变量计算模拟 SET @next_id = 3088413 + 1;

关于数据类型

MySQL的数据类型比较基础。虽然现在也支持了JSON，但性能和灵活性上依然有限。

PostgreSQL在这方面支持得更全面：

数组类型（Array）：可以直接在一个字段里存一串标签，不需要关联表。
JSONB：这是二进制格式的JSON，支持索引，查询速度非常快，很多时候甚至可以替代MongoDB。
范围类型：比如时间段、价格区间，系统能自动处理区间的重叠判断。

4. 数据的可靠性与复制

对于金融级或企业级的应用，数据的完整性至关重要。

MySQL的主从复制主要依赖binlog。虽然现在也有了GTID和半同步复制，但在默认配置下，它是异步的，且在高并发下可能会有延迟。如果主库突然宕机，从库是有可能丢失数据的。

PostgreSQL的流复制（Streaming Replication）是基于WAL（预写式日志）的物理复制。它不仅效率高，而且非常稳定。更关键的是，PG原生支持同步复制（Synchronous Replication），可以确保事务在提交前，数据至少已经写入了一个备库。这对于追求“零数据丢失”的国产数据库来说，是一个现成的、极其重要的特性。