PostgreSQL
功能最全的开源关系库，SQL 标准与扩展最强
PostgreSQL 常被叫作“开源 Oracle”：SQL 标准支持最完整，JSONB、数组、全文检索、GIS、向量检索都能开箱用，还能装扩展改内核行为。它的 MVCC 不用 UNDO，靠行上的版本信息和 VACUUM 回收，所以表会“膨胀”——这是用 PG 必须理解的第一件事。
它解决什么问题
MySQL 在复杂查询、JSON 处理、地理数据、窗口函数上越来越吃力；业务又不想上商业库，需要一个功能更全、许可更宽松的开源选择。
真实场景：典型场景：SaaS 产品用 PG 存业务数据，同时用 JSONB 存自定义字段、用 PostGIS 算门店距离、用 pgvector 做语义检索，一个库全搞定。
核心概念
每个概念一句话 + 一个类比。点击卡片看更详细的解释。
进程模型
每个连接 fork 一个独立进程，而不是线程池
类比：一个客户配一个专属柜员，不用排队等公共窗口
看概念详情VACUUM
回收被旧版本占用的空间，否则表会一直膨胀
类比：定期整理房间，把不要的东西清出去
看概念详情WAL
先写日志再改数据页，崩溃后靠它重放恢复
类比：先记账再动钱，账本在就不怕断电
看概念详情堆表与 MVCC
更新等于插入新版本，旧版本留在表里等 VACUUM 清
类比：改合同不涂改原件，而是新打一份，旧的那份先留着
看概念详情扩展
CREATE EXTENSION 就能加能力，PostGIS、pgvector 都是这么来的
类比：手机装 App，不用换手机就能加功能
看概念详情数据流转动画
跟着步骤看一条数据从进入系统到被处理完的完整路径，可以暂停、重播和调速。
一次 UPDATE 在 PostgreSQL 里发生了什么
← 左右滑动查看完整流程图 →
客户端连到 5432，postmaster 收到后 fork 一个 backend 进程专门服务这条连接。
提示：关键差异：PG 不原地改行，而是写一个新版本，旧版本靠 VACUUM 回收。 悬停图中的节点可以看概念解释。
优劣势
短句说清适合什么、不适合什么，选型时先看这一栏。
- SQL 标准和高级特性最完整：窗口函数、CTE、JSONB、数组、范围类型
- 扩展生态强：PostGIS、pgvector、TimescaleDB、Citus 都能直接装
- 并发控制更细，DDL 大多不锁表（CREATE INDEX CONCURRENTLY）
- 许可宽松（类 BSD），商业化没有法律风险
- 流复制、逻辑复制、PITR 都很成熟
- 更新是写新版本，表和索引容易膨胀，必须管好 VACUUM
- 每连接一个进程，高并发短连接场景需要连接池（pgbouncer）
- 默认参数偏保守，不做调优性能发挥不出来
- 国内运维人才和现成方案比 MySQL 少一些
常见使用场景
每个场景都配一句「为什么用它」。
SaaS 与复杂业务系统
多租户业务表、自定义字段（JSONB）、复杂报表查询。
为什么用它：表达力强，一个库能覆盖关系、文档、检索多种需求。
地理与位置服务
PostGIS 算距离、找范围内门店、做路径规划。
为什么用它：空间索引和空间函数是内建扩展，别的库要额外组件。
AI 应用的向量存储
pgvector 存 embedding，做相似度检索，和业务表放一起。
为什么用它：不用再引一套向量数据库，事务和 join 都还在。
同类对比
和同赛道的组件并排看，差异一目了然。
选型顺序应该是：先看是不是单机嵌入式（是就 SQLite），再看预算和合规（要商业兜底就 Oracle），最后在 MySQL 和 PostgreSQL 之间按“功能复杂度 vs 生态成熟度”取舍。三者都能存好数据，差别在边界。
常见问题
上手第一个月最容易卡住的地方。
Q1PostgreSQL 和 MySQL 怎么选？
要复杂查询、JSON、GIS、向量检索、严格 SQL 标准，选 PG；要极简运维、海量读、成熟分库分表方案和大量现成人才，选 MySQL。新项目如果团队没有强偏好，PG 的功能上限更高；已有 MySQL 体系且跑得好，没必要迁。
Q2表膨胀是怎么回事？
PG 的 UPDATE 不是原地改，而是写一条新记录、把旧的标记为死元组。死元组不清理就一直占着页空间，表和索引越来越大，扫描变慢。autovacuum 负责回收，但大批量更新、长事务会拖住它，所以要么调参数、要么定期手动 VACUUM FULL（会锁表）。
Q3为什么连接数一多就卡？
每个连接是一个操作系统进程，几百个连接就有几百个进程，上下文切换和内存开销都上来了。标准做法是前面挂 pgbouncer 做连接池，把上千个客户端连接收敛成几十个真实连接。
Q4PG 能做分库分表吗？
能，但方式不同：原生有声明式分区（按范围/列表/哈希），跨库可以用 Citus 扩展做分布式。相比 MySQL 生态的 ShardingSphere，PG 的分片方案更“库内”，运维模型不一样，选之前先评估团队熟悉度。