收尾 · PostgreSQL 的护城河与选型建议
把 19 个特性收拢成一张「PostgreSQL 到底强在哪」的总表，提炼出它区别于其它库的三条本质，并给出务实的选型建议——什么场景该上 PG，什么场景别硬上。
收尾 · PostgreSQL 的护城河与选型建议
我们在一台 PostgreSQL 18.4 上，把 19 个特性一个个跑通、拆开、讲透。现在退一步，把它们收拢成一张全景图，回答两个问题：PostgreSQL 到底强在哪？什么时候该用它、什么时候别硬上？
一张总表：19 个特性，各自的护城河
| 特性 | PostgreSQL 的独特之处 | 别家通常怎么办 |
|---|---|---|
| 丰富数据类型 | uuid/inet/interval 等都是一等公民 | 塞进字符串，应用层解析 |
| 数组 | 原生数组 + GIN，免中间表 | JSON 数组模拟 |
| JSONB | 关系 + 文档混合，@> 走 GIN | 有 JSON，但索引 / 成熟度稍逊 |
| 范围 + EXCLUDE | 数据库强制「区间不重叠」 | 应用层加锁查重，有并发漏判风险 |
| 生成列 | 派生字段数据库自动维护 | 多数库也有 |
| CTE / 递归 | 改写型 CTE（DELETE ... RETURNING 链式） | MySQL 做不到链式改写 |
| 窗口函数 | 8.4 起完整支持 | MySQL 8.0 才有 |
| LATERAL / GROUPING SETS | 每组 Top-N、多维透视一句写完 | MySQL 无 GROUPING SETS/CUBE |
| 全文检索 | 内置分词 / 排序 / 高亮，免 ES | MySQL FULLTEXT 较弱 |
| 索引类型 | 6 种 + 部分 / 表达式 / 覆盖 | 多数只有 B-tree 一族 |
| 表分区 | 声明式分区 + 秒级 DETACH | MySQL 分区不支持外键 |
| 物化视图 | REFRESH CONCURRENTLY 不锁读 | MySQL 干脆没有 |
| EXPLAIN | 信息密度高、生态工具好 | 各家都有，思路一致 |
| PL/pgSQL + 触发器 | 多语言过程 + 可复用触发器函数 | MySQL 过程 / 触发器较弱 |
| LISTEN/NOTIFY | 随事务一致的轻量 Pub/Sub | 多数库无内置 |
| 锁与并发 | 咨询锁当分布式锁，SKIP LOCKED 当队列 | MySQL 8.0 才有 SKIP LOCKED |
| 扩展生态 | PostGIS / pgvector / TimescaleDB… | 生态封闭或有限 |
看完这张表，一个规律很清楚：别家有的，PG 基本都有；PG 有的，别家常常没有，或者得靠外部组件凑。
三条本质：PostgreSQL 为什么不一样
把 19 个特性抽象一下，PostgreSQL 的与众不同，落在三条根上：
① 类型系统是可扩展的，不是固定清单。 从 inet、tsvector 到 PostGIS 的 geometry、pgvector 的 vector——新类型能像内置类型一样索引、运算、加约束。别的数据库的类型是「厂商定死的一张表」，PostgreSQL 的类型是「可以往上长的一棵树」。这是最深的一条。
② 能力做进内核，而不是外挂。 全文检索、发布订阅、分布式锁、任务队列——这些在别处需要 Elasticsearch、Redis、MQ 的能力，PostgreSQL 做成了内置特性。少一个外部系统，就少一处数据同步、少一处一致性裂缝、少一份运维成本。「一个 PG 顶好几个组件」不是口号，是很多中小系统的真实架构简化。
③ 开放生态带来持续的生命力。 CREATE EXTENSION 这套机制，让社区能不断给 PostgreSQL 加新能力。每一波技术浪潮——空间数据、时序、如今的 AI 向量检索——PG 几乎总能第一时间靠扩展跟上。二十多年过去，它非但没老，反而越来越像一个「数据平台」。
这也解释了为什么近些年 PostgreSQL 的采用率一路走高：当「多存储引擎」的复杂度越来越让人头疼，「一个够强、够开放的库把大部分活都干了」的吸引力就越来越大。「Just use Postgres（能用 PG 就用 PG）」这句话，不是没有道理。
什么时候该上 PostgreSQL
- 需要复杂查询 / 强一致 / 丰富类型的业务系统 —— 这是 PG 的主场，几乎闭眼选。
- 想少养组件 —— 搜索、队列、缓存失效通知、地理 / 时序 / 向量，能用 PG 内置或扩展搞定的，就别急着上一堆中间件。
- 数据模型复杂或多变 —— 关系 + JSONB 混合建模，严格与灵活兼得。
- 中小到中大规模 —— 单机 PostgreSQL（加只读副本）能扛的量，比很多人以为的大得多。
什么时候别硬上
诚实地说，PostgreSQL 不是万能的：
几种「别硬上 PG」的场景：① 需要海量水平扩展、天然分片的超大规模写入——原生 PG 是单主架构，超出单机 + 副本的量级要靠 Citus 等分布式方案或换型。② 纯缓存 / 极高 QPS 的简单 KV——Redis 这类内存库更合适，别拿 PG 当缓存使。③ 超大规模、需复杂相关性调优的搜索——专业的 Elasticsearch 仍更强。④ 海量时序且要极致压缩比——TimescaleDB（仍是 PG 扩展）或专用时序库更对路。判断标准很简单：PG 内置 / 扩展能覆盖到、且规模在单机 + 副本能扛的范围内，就用 PG；明显超出这个边界，再考虑专用系统。
结语
回到开头那句话：PostgreSQL 被称作「最先进的开源数据库」。走完这 19 站，你应该能体会到，这个称号不是营销——它来自类型系统的可扩展、来自把一个个本需外挂的能力做进内核、来自一个持续给它输血二十多年的开放生态。
这个专栏挑的是「知道就是赚到」的特性：很多你可能听过名字，但未必知道它底下怎么实现、比别家强在哪、什么时候该掏出来用。希望读完之后，下次遇到「这个需求要不要再引一个组件」时，你会先问一句：PostgreSQL 是不是自己就能干？ 很多时候，答案是能。
想继续深挖数据库与后端主题，可以看看本站其它专栏。也欢迎在遇到具体问题时，把这里的特性当成一份「PostgreSQL 能力清单」随时回查。
参考文献
- [1] PostgreSQL 官方文档.https://www.postgresql.org/docs/current/ —— 本专栏所有特性的权威依据，PG 18 版。
- [2] PostgreSQL 官方站.「Feature Matrix.」https://www.postgresql.org/about/featurematrix/ —— 各版本特性引入时间线。
- [3] 本专栏全部 SQL 与输出，来自一套在 PostgreSQL 18.4（Neon 托管）实例上跑通的 19 项特性测试（19/19 通过），测试时间 2026-06-25。