MySQL与PostgreSQL深度对比：从存储引擎到运维实战

作为一个常年跟数据库打交道的人，我经常被问到同一个问题：“新项目到底选 MySQL 还是 PostgreSQL？”说实话，这个问题没有标准答案，但你只要把两者的核心机制、运维习惯和生态差异摸透了，选型就变成了一道简单的算术题。这篇文章就从我实际使用的经验出发，把 MySQL 和 PostgreSQL 放在同一张工作台上做一次深度拆解，覆盖从安装部署、核心原理到常见故障排查的完整链路，希望能帮你少走一些弯路。

1. 整体设计思路：为什么要把两个数据库放在一起研究

1.1 核心定位差异决定了使用场景

很多人会把 MySQL 和 PostgreSQL 当成“二选一”的替代品，但实际上它们更像是两种不同思路的产物。MySQL 从诞生起就瞄准互联网场景，追求读写速度、简单部署和水平扩展，所以在 LAMP 时代它几乎是 Web 应用的事实标准。PostgreSQL 则走的是“最先进的开源数据库”路线，功能密度极高，擅长复杂查询、地理空间处理、自定义类型这类企业级需求。

这就导致了一个有意思的现象：两个数据库的“舒适区”几乎不重叠。我在实际项目中见过不少团队把 PostgreSQL 当成 MySQL 的平替来用，结果被它的 MVCC 膨胀机制搞得焦头烂额；也见过把 MySQL 硬扛 GIS 业务的团队，最后被空间索引的残缺功能逼到重写查询逻辑。与其在网上争论“谁更强”，不如把两者的差异拆开揉碎，搞清楚什么场景该选谁。

1.2 我从四个维度建立对比框架

这篇研究不是简单罗列功能清单，而是围绕四个核心维度展开：存储引擎与事务机制、SQL 能力与类型系统、部署运维与生态工具、数据迁移与同步方案。每个维度我都会给出实测对比和踩坑记录，而不是只停留在文档层面。

这里有一个底层原则：数据库选型是架构决策，不是技术偏好。如果团队里没有人深入理解 PostgreSQL 的 vacuum 机制，那它在高并发写入场景下很容易变成运维黑洞；反过来，如果业务全是复杂报表和递归查询，MySQL 的执行计划优化器会让你写到怀疑人生。所以选型之前，先对照自己的团队技术栈、业务特征和运维能力，再往下看对比内容会更有针对性。

2. 存储引擎与事务机制：MySQL 和 PostgreSQL 最本质的分水岭

2.1 InnoDB 与 MVCC：同样叫多版本，实现思路完全不同

MySQL 从 5.5 之后默认引擎基本就是 InnoDB，它的事务通过 undo log 实现 MVCC，也就是说每行记录上会保存多个版本，读操作通过版本链找到自己可见的快照。InnoDB 的索引是聚簇结构，主键顺序直接决定数据在磁盘上的物理排列顺序，这也是为什么 MySQL 强调“必须显式定义主键”的原因——没有主键它会偷偷建一个隐藏主键，白白浪费存储和性能。

PostgreSQL 的实现思路则完全不同，它的每个表都有一个系统列 xmin/xmax，用来记录插入和删除事务的 ID，旧版本数据不会原地覆盖，而是继续留在数据页里，由 vacuum 进程在后台清理。这套机制的好处是读操作永远不会被写操作阻塞，坏处是如果表频繁更新，表膨胀会非常严重，磁盘占用飙到实际数据量的十几倍都不奇怪。

我在生产环境见过一个典型的案例：一张日增 200 万行、频繁 update 状态的订单表，PostgreSQL 跑了两个月数据文件膨胀到 120GB，而真实数据只有 6GB。后来加了定时 vacuum full 才把空间收回来。这个坑如果你提前不了解，等磁盘告警的时候再排查会非常被动。

2.2 锁粒度与并发模型的实际影响

另一个容易踩坑的差异在锁机制。InnoDB 的锁是索引锁，也就是说如果 update 语句的 where 条件没有走索引，它会升级为表锁，严重影响并发。PostgreSQL 则支持行级锁、页级锁、表级锁的细粒度控制，还有多种锁模式可以组合，加上 SSI（可串行化快照隔离）的支持，在复杂事务场景下会更稳。

但“更稳”并不代表“更快”。PostgreSQL 每次事务开始都要分配事务 ID，写多读少的场景下事务 ID 回卷问题甚至会触发强制 shutdown，这在 MySQL 里几乎没有存在感。所以我的经验法则是：以简单 CRUD 为主、读写比高的互联网业务用 MySQL 会更省心；包含复杂事务、报表分析、需要严格数据一致性的企业系统，PostgreSQL 的容错空间更大。

2.3 数据类型边界：别让“int+5”这种操作拖垮你的表结构设计

搜索热词里出现“mysql中int+5”不是没有原因的。MySQL 的 int 类型分多种长度，int(5) 其实只是显示宽度，并不限制存储范围，真正的上限由 int 本身决定（最大 2147483647），很多人在这里被文档误导过。PostgreSQL 则没有这种概念，int 就是 int，还能通过 smallint、bigint、serial、bigserial 精确控制取值范围，额外支持 numeric 这种任意精度的定点数。

这意味着如果你在 MySQL 里存金额，用 decimal(10,2) 是常规操作；但如果你用 float 或 double，高并发下出现 0.1+0.2 不等于 0.3 的问题就等着被业务投诉吧。PostgreSQL 的 numeric 类型则可以把精度控制到非常细的级别，但代价是运算速度远不如 float。设计表结构时我建议：整型主键用 bigint，金额用 decimal/numeric，经纬度之类的高精度浮点单独评估，不要盲目跟随 ORM 的自动类型映射。

3. SQL 功能与类型系统：谁更“能打”，谁更“难缠”

3.1 窗口函数、递归查询与 JSON 能力的实战对比

窗口函数方面，PostgreSQL 的支持远比 MySQL 成熟。MySQL 8.0 虽然补齐了 row_number()、rank() 这些基础窗口函数，但高级用法比如 frame 子句的精细控制、FILTER 子句仍然缺位。PostgreSQL 则从 9.4 开始就支持完整的 SQL:2011 窗口函数规范，尤其是 FILTER 配合聚合函数时能写出非常优雅的报表 SQL。

递归查询是另一个分水岭。PostgreSQL 的 WITH RECURSIVE 可以轻松实现组织架构树、BOM 展开、地铁换乘路线等场景，MySQL 8.0 虽然也支持 WITH RECURSIVE，但性能调优空间小很多，深层次递归容易出现临时表爆内存。我自己在 MySQL 里写过三层以上的递归 CTE，优化器直接给我选择了全表扫描，那次之后我就明白了，复杂树形查询还是交给 PostgreSQL 更靠谱。

JSON 能力上，PostgreSQL 的 jsonb 类型支持 GIN 索引、jsonpath 查询，还能通过 ->> 操作符直接提取路径，玩得非常花；MySQL 的 JSON 类型虽然 5.7 就有，但索引优化一直不够理想，实际用起来还是在跟文本搜索较劲。没有绝对的好坏，但如果你明确知道自己要做文档型业务，可能 MongoDB 更值得考虑，而不是硬拿关系库去扛。

3.2 存储过程、触发器与扩展机制：从“能用”到“好用”的距离

存储过程在 MySQL 里是个老大难，语法像拼凑出来的方言，调试工具又少，网上随便一搜全是“mysql 储存过程 + 错误信息”这类求助帖。PostgreSQL 的 PL/pgSQL 则是完整的过程化语言，支持变量声明、异常捕获、批量处理，写起来体验接近 Oracle 的 PL/SQL，有传统数据库经验的开发者上手非常快。

触发器方面，MySQL 的触发器 5.7 就支持了，但有明显的性能损耗，而且一个表上多个相同事件触发器会顺序执行，没法灵活控制优先级。PostgreSQL 支持行级、语句级触发器和 INSTEAD OF 触发器，还能通过 PL/Python、PL/Perl 扩展写非 SQL 逻辑，灵活度完全是另一个层级。更重要的是 PostgreSQL 的扩展生态，PostGIS 做地理空间分析、pgvector 做向量检索等应用，这些都不是靠几个插件就能在 MySQL 上复刻的。

3.3 面试中高频出现的功能对照表

之前整理过一份 MySQL 面试题的时候，发现面试官特别喜欢考察两个数据库的差异点，这里整理成一份对照表，方便新手快速建立认知：

这张表不建议死记硬背，重点理解最后一行，它决定了你的技术栈在什么业务里最顺手。

4. 部署安装与运维排障：从“装好”到“跑稳”的全过程

4.1 环境准备与安装：Windows、Linux 与 Docker 三种姿势

先从最冗余的安装说起。MySQL 在 Windows 上建议直接下载官网的 MSI 安装包，一路 Next 就行，但要注意选择 Server Only 而不是默认的 Developer Default，否则会装入一堆用不上的组件。安装完成后需要做两件事：设置 root 密码、把 MySQL 服务改成手动启动（如果你不想开机就被它拖慢的话）。Linux 上则是用 yum 或 apt 装官方源，CentOS 7 用户尤其要注意，系统自带的源版本可能停留在 5.7，要装 8.0 就得先装 MySQL 官方的 yum repository。

PostgreSQL 的安装相比会更直接，Windows 用 EDB 的图形化安装包，Linux 用发行版对应的包管理器，比如 Ubuntu 下是 apt install postgresql，CentOS 下是 yum install postgresql-server。不过 CentOS 7 默认源里通常只有 PostgreSQL 9.2，想上 16 或 18 就得用 PostgreSQL 官方提供的 PGDG 源，搜索热词里那个“centos 7上编译安装postgresql 16”就是这个原因——很多人被旧版本源坑了以后，宁愿从头编译一遍。

Docker 则是现在最推荐的安装方式。一个 docker-compose.yml 就能把 MySQL 或 PostgreSQL 跑起来，例如 PostgreSQL 18 可以写成这样：

yaml复制services:
  postgres:
    image: postgres:18
    container_name: my-pg
    environment:
      POSTGRES_USER: admin
      POSTGRES_PASSWORD: admin123
      POSTGRES_DB: mydb
    ports:
      - "5432:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data
volumes:
  pgdata:

MySQL 的 Docker 部署也是同理，只需要改 env 变量名（MYSQL_ROOT_PASSWORD、MYSQL_DATABASE），并映射 3306 端口即可。用 Docker 最大的好处是可复现，本地开发、测试、生产环境的数据库版本可以完全一致，我甚至建议把初始化 SQL 脚本也挂载到 /docker-entrypoint-initdb.d/ 目录，容器首次启动时自动执行，省去手工导入的麻烦。

4.2 启动、连接与基础配置：别让端口和权限卡住你

装好之后第一个坑经常出在启动方式上。MySQL 的 Windows 服务默认启动是对的，但如果要用命令行 mysql 命令，需要把 C:\Program Files\MySQL\MySQL Server 8.0\bin 加到系统 PATH 里。PostgreSQL 则默认只监听 localhost，想远程连还得改 postgresql.conf 里的 listen_addresses 和 pg_hba.conf 的认证规则，这两个文件对新手来说都是纯文本配置，改错一个字母就连不上。

还有一个非常经典的报错，论坛上隔三差五就有人问：

text复制无法创建锁文件 "/var/run/postgresql/.s.pgsql.5432.lock": 权限不够

这个问题的根源是 /var/run/postgresql 目录的所有权不对。PostgreSQL 启动时默认以 postgres 用户身份运行，但锁文件目录被其他用户持有，就会报这个错。解决方法是给目录授权：

bash复制sudo mkdir -p /var/run/postgresql
sudo chown postgres:postgres /var/run/postgresql
sudo systemctl restart postgresql

如果再遇到 FATAL: data directory "/var/lib/postgresql/16/main" has invalid permissions，那就是数据目录的权限问题，同样用 chown 解决。这些所谓“报错”都不是什么深奥原理，纯粹是 Linux 权限模型在日常运维里的基本功。

MySQL 的经典问题则是端口被占用。默认 3306 被其他 MySQL 实例或者安全软件占用时，启动服务会一直失败。这时候先 netstat -ano | findstr 3306 看看是谁的锅，如果是旧的 mysqld 进程在跑，直接杀掉再启动新的就行。如果你换了端口，记住连接时一定要显式加 -P 端口号，否则客户端默认还是走 3306，踩过一次你就长记性了。

4.3 高可用部署与磁盘膨胀：PostgreSQL 运维的核心难题

搜索热词里“postgresql 高可用部署”和“postgresql wal-data占用磁盘过大”放在一起不是偶然，这两个问题经常同时出现。PostgreSQL 的高可用方案传统上是 Patroni + etcd + HAProxy，Patroni 负责自动故障切换，etcd 负责集群状态存储，HAProxy 做流量分发。

配置 Patroni 时有一个细节很容易被忽略：每个节点的 cluster_name 必须一致，而且 postgresql.conf 里 wal_level 必须是 replica 或 logical，否则备库无法通过 WAL 日志接收主库的更改。我在一次演练中把主库的 wal_level 设成了 minimal，备库同步直接断开，日志里疯狂刷 could not receive data from WAL stream，折腾了半小时才定位到原因。

WAL 日志占满磁盘是另一个高频事故。PostgreSQL 在 archive_mode = on 时会把 WAL 文件持续归档到 pg_wal 目录，如果 archive 命令卡住或归档目录满了，旧 WAL 永远不清理，磁盘直接爆掉。处理步骤是先检查 pg_wal 目录大小：

bash复制du -sh /var/lib/postgresql/16/main/pg_wal

再检查归档是否正常：

sql复制SELECT * FROM pg_stat_archiver;

如果 failed_count 在持续增长，说明归档命令有问题，优先修复归档目标。如果只是单纯 WAL 膨胀，可以通过 pg_archivecleanup 清理已经归档的旧文件：

bash复制pg_archivecleanup /var/lib/postgresql/16/main/pg_wal 00000001000000000000000A

但要注意，这个命令只能手动执行，且仅在你确认对应 WAL 已经被安全归档后才能跑，否则会导致数据丢失。生产环境建议一定要配好 archive_command 的返回值判断和告警监控，不要指望靠手动清理救急。

4.4 数据库同步方案：DataX 与多库同步工具的选型

搜索词里反复出现“mysql/sqlserver/postgresql数据库同步软件”，说明跨库同步是很多团队的刚需。最常用的开源方案是阿里开源的 DataX，它通过插件机制支持多种数据源，并且针对 MySQL、PostgreSQL、SQLServer 都有独立的 reader/writer 插件。配置一个 MySQL 到 PostgreSQL 的同步任务，核心就是写 json 配置文件：

json复制{
  "job": {
    "content": [
      {
        "reader": {
          "name": "mysqlreader",
          "parameter": {
            "username": "root",
            "password": "123456",
            "column": ["id", "name", "created_at"],
            "connection": [
              {
                "table": ["user"],
                "jdbcUrl": ["jdbc:mysql://192.168.1.10:3306/test"]
              }
            ]
          }
        },
        "writer": {
          "name": "postgresqlwriter",
          "parameter": {
            "username": "admin",
            "password": "admin123",
            "column": ["id", "name", "created_at"],
            "preSql": ["delete from user"],
            "postSql": [],
            "connection": [
              {
                "table": ["user"],
                "jdbcUrl": "jdbc:postgresql://192.168.1.20:5432/test"
              }
            ]
          }
        }
      }
    ],
    "setting": {
      "speed": {
        "channel": 4
      }
    }
  }
}

这个配置里最值得关注的是 speed.channel，它决定并发度。设置太高，目标库容易扛不住锁竞争；太低，数据量大的时候又跑太慢。我的经验是先从 4 开始试，观察源库和目标库的 CPU 负载再逐步调整。DataX 的问题在于它做的是批式离线同步，不是 CDC（变更数据捕获），如果需要准实时同步，得额外引入 Canal（MySQL）或 Debezium（PostgreSQL）这类工具，配合 Kafka 做消息管道，架构复杂度会上升一个层级。

5. 生态工具链与常见问题排查：一张表解决 80% 的日常报错

5.1 必备客户端与可视化工具

MySQL 最常用的图形化工具是 MySQL Workbench 和 Navicat。Workbench 是官方出品，免费强大，但界面稍显老旧；Navicat 功能全面、颜值在线，不过收费且只支持 Windows 和 macOS。PostgreSQL 的标准选择是 pgAdmin，配套的 psql 命令行工具也是神器，写复杂 SQL 时体验比任何图形界面都流畅。

DBeaver 是我个人最推荐的跨数据库通用工具，同时支持 MySQL、PostgreSQL、SQLServer、Oracle 等，JDBC 驱动会自动下载，还能直接执行 DataX 同步任务里的 JDBC URL 做连接测试，排查问题非常方便。还有一个细节是 MySQL 8.0 默认使用 caching_sha2_password 认证，而 Navicat、Workbench 老版本或某些驱动可能只支持 mysql_native_password，就会报后面会提到的 Firedac phys mysql client does not support authentication protocol requested 这类错误。解决方案是改用户的认证插件：

sql复制ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'yourpassword';
FLUSH PRIVILEGES;

PostgreSQL 14 默认的密码加密方式改成了 scram-sha-256，如果你用老旧客户端连接，则会收到 password authentication failed 或者 fe_sendauth: no password supplied，这时候同样要考虑在 pg_hba.conf 里改成 md5，或者升级客户端。

5.2 常见报错与排查速查表

这些年积累的日常报错，我整理成了下面这张速查表，基本覆盖了搜索热词里 90% 的求助内容：

5.3 关于 pgvector 与扩展生态的一个补充

热词里“pgvector windows dll download postgresql 16”这条有代表性，很多人在 Windows 环境里想装向量扩展用来做 AI 应用，结果发现 PostgreSQL 的扩展机制在 Windows 上感觉体验特别逆天。

我的建议是：向量检索这类需求不要在生产环境执着于 Windows，直接在 Linux 上使用 PG 仓库安装 PostgreSQL 16，然后通过 apt 包管理器安装 postgresql-16-pgvector，比手动下载 DLL 可靠得多。如果必须用 Windows，务必确认你的 PostgreSQL 是哪个版本（32 位还是 64 位），下载对应的 pgvector DLL，放到 lib 目录，然后执行：

sql复制CREATE EXTENSION IF NOT EXISTS vector;

扩展的本质是给 PostgreSQL 安装“外挂能力”，这也是它和 MySQL 最大的生态差异之一。PostGIS、pgvector、timescaledb 这些扩展把 PostgreSQL 从一个关系数据库变成了地理空间分析、向量检索、时序数据平台，这种扩展性在 MySQL 里很难做到。

5.4 MySQL Workbench 与命令行：日常操作中容易被忽略的小事

MySQL Workbench 使用教程市面上有很多，但大多数只讲基础功能。我这里补充几个能让效率翻倍的小技巧：查询结果网格可以直接右键导出为 JSON、CSV、SQL 语句；ER 图可以一键反向生成物理外键，对理解老项目表结构帮助巨大；EXPLAIN 按钮加 FORMAT=JSON 能让你看到更详细的执行计划，定位慢查询时非常有价值。

另外，MySQL 数据库命令大全这类资料网上很多，但真正用得上的是 SHOW PROCESSLIST、EXPLAIN SELECT、SHOW INDEX FROM 和 SHOW TABLE STATUS 这几个。遇到慢查询先跑 EXPLAIN，观察 type 是否走索引，rows 是否估算过大，很多性能问题根本不用翻文档就能定位。而 PostgreSQL 的对应命令是 EXPLAIN ANALYZE，它比 MySQL 详细得多，还会真正执行 SQL 并统计执行时间和行数，排障思路基本一致——先看有没有走索引，再看有没有临时表排序，最后看有没有大表全扫描。

6. 数据迁移、备份恢复与面试知识点：从实战到提炼

6.1 从 MySQL 迁移到 PostgreSQL 的完整心法

如果团队决定从 MySQL 迁到 PostgreSQL，或者反过来，务必先梳理清楚类型映射关系。比如 MySQL 的 TINYINT(1) 常常被 ORM 映射为 boolean 类型，到了 PostgreSQL 就对应 boolean，但如果原表里存的是 2、3 这类数值，迁移后查询会出现类型转换错误。字符串类型上，MySQL 的 VARCHAR(255) 到了 PostgreSQL 里一般还是 VARCHAR(255)，但需要注意 MySQL 的 utf8mb4 对应 PostgreSQL 的 UTF8，乱码问题多半都是这里引起的。

迁移工具上，简单场景用 DataX 就够，复杂场景建议用 Percona 的 pg_chameleon 或者 ora2pg（虽然名字带 ora，但也支持 MySQL）。生产环境迁移我强烈建议先做一次全量同步，然后切到增量同步，最后在业务低峰期做切换，不要相信“一次性导入导出”就能搞定的话术，真实项目中数据量一上来，你会被各种主键冲突、外键约束、字符集乱码问题折磨一遍。

6.2 备份恢复策略：你用得上的三种姿势

备份恢复是运维的基本功，也是面试里最容易翻车的一环。MySQL 的日常备份我建议用 mysqldump 配合 --single-transaction 参数做逻辑备份，避免锁表；PostgreSQL 则用 pg_dump 做逻辑备份，或者用 pg_basebackup 做物理备份。对于大数据量库，logic 备份效率偏低，物理备份更合适，但物理备份的可移植性差，恢复时要求数据库版本必须一致。

热词里“postgresql 14 md5链接”也反映了一个很现实的问题：很多团队还在用 md5 做认证，但 PostgreSQL 14 默认改成 scram-sha-256 后，旧客户端全部连不上。安全合规的角度看，scram-sha-256 确实比 md5 强太多，如果确实有老系统依赖 md5，正确做法是把 pg_hba.conf 里的认证方式从 scram-sha-256 改成 md5，同时升级老客户端的驱动，不要为了兼容长期牺牲安全性。

6.3 MySQL 面试题里的高频考点

把搜索热词里的“mysql面试题”单独展开说下。面试官最喜欢问的 MySQL 题目基本集中在几个维度：索引失效场景（最左前缀、like %xx、or 条件）、事务隔离级别（默认 REPEATABLE READ，如何解决幻读）、MVCC 实现原理（undo log + 版本链 + ReadView）、存储过程与触发器的使用场景、EXPLAIN 执行计划的 type 字段含义等。

PostgreSQL 的考点则更偏重：MVCC 与 vacuum 机制、事务 ID 回卷、brin/gist/gin 索引的使用场景、jsonb 与行存储的差异、Patroni 高可用原理、流复制与逻辑复制的区别等。两份清单放在一起对比，你就会发现面试官其实不是要你背八股文，而是想确认你有没有在生产环境里真正踩过坑、理解过原理。这也是为什么我建议新人不要只会开着 MySQL Workbench 点点点，命令行里跑一遍 EXPLAIN，再用 pg_stat_statements 看看真实执行统计，比刷一百道面试题都管用。

6.4 数据库实践里的个人经验总结

数据库不是“装好就能跑”的软件，它需要你持续关注。我自己的做法是：每周固定检查一次慢查询日志（MySQL 的 slow_query_log 或 PostgreSQL 的 log_min_duration_statement），每月做一次表膨胀检查和索引使用率统计，每个季度做一次完整备份恢复演练。很多问题如果等到线上告警才发现，你已经失去了主动权。

7. 写在最后：个人坚持多年的几条选型与运维经验

7.1 选型决策树

如果你还在纠结“MySQL 还是 PostgreSQL”，可以对照这个极简决策树：

• 业务是典型的 Web CRUD、社区、电商、CMS，团队对 MySQL 更熟悉，选 MySQL；
• 业务涉及复杂查询、GIS、JSON 文档、递归树状结构、高速写入与事务一致性要求很高，选 PostgreSQL；
• 两者都合适时，优先考虑团队已有技术储备和运维习惯，不要为了“新技术”而换库；
• 如果只是学习研究，建议两个都装一遍，真实跑几个项目后再做判断。

7.2 运维真理：慢就是快，监控先行

我在踩过那么多次坑之后最大的体会是：数据库问题的核心不是“选谁”，而是“监控与预案”。无论 MySQL 还是 PostgreSQL，只要你把慢查询日志打开、把连接数监控补齐、把磁盘使用率和 WAL 目录纳入告警，至少能避免 80% 的生产事故。工具层面可以用 Prometheus + Grafana 搭配 node_exporter 和 mysqld_exporter / postgres_exporter 做全家桶监控，成本不高但收益巨大。

7.3 一个小技巧：让 Docker 成为你的实验室

最后分享一个务实的小技巧：如果你想短时间内把 MySQL 和 PostgreSQL 都玩明白，不要在自己电脑上傻乎乎地装两套本地服务，直接用 Docker 起两个容器，再配好数据卷和端口映射。这样测试完可以随时销毁重建，版本随便升，配置随便改，坏了也不影响宿主机。我自己研究 pgvector、Patroni 高可用、DataX 同步这些内容，都是在 Docker Compose 里反复实践才彻底理解的。

数据库没有银弹，只有适不适合。希望这篇研究能帮你建立自己的判断框架，少踩一些我已经替你踩过的坑。