# 收尾 · PostgreSQL 的护城河与选型建议

> 把 19 个特性收拢成一张「PostgreSQL 到底强在哪」的总表，提炼出它区别于其它库的三条本质，并给出务实的选型建议——什么场景该上 PG，什么场景别硬上。

- 作者：David（道雾轩）
- 专栏：PostgreSQL 特性详解（https://daiw.org/manual/postgresql.md）
- 最后更新：2026-07-13
- 原文：https://daiw.org/manual/postgresql/recap
- 转载与引用：请注明出处并附原文链接（https://daiw.org/about/copyright）

# 收尾 · PostgreSQL 的护城河与选型建议

我们在一台 PostgreSQL 18.4 上，把 19 个特性一个个跑通、拆开、讲透。现在退一步，把它们收拢成一张全景图，回答两个问题：**PostgreSQL 到底强在哪？什么时候该用它、什么时候别硬上？**

## 一张总表：19 个特性，各自的护城河

| 特性 | PostgreSQL 的独特之处 | 别家通常怎么办 |
| --- | --- | --- |
| [丰富数据类型](https://daiw.org/manual/postgresql/rich-types) | `uuid`/`inet`/`interval` 等都是一等公民 | 塞进字符串，应用层解析 |
| [数组](https://daiw.org/manual/postgresql/arrays) | 原生数组 + GIN，免中间表 | JSON 数组模拟 |
| [JSONB](https://daiw.org/manual/postgresql/jsonb) | 关系 + 文档混合，`@>` 走 GIN | 有 JSON，但索引 / 成熟度稍逊 |
| [范围 + EXCLUDE](https://daiw.org/manual/postgresql/range-generated) | 数据库强制「区间不重叠」 | 应用层加锁查重，有并发漏判风险 |
| [生成列](https://daiw.org/manual/postgresql/range-generated) | 派生字段数据库自动维护 | 多数库也有 |
| [CTE / 递归](https://daiw.org/manual/postgresql/cte) | 改写型 CTE（`DELETE ... RETURNING` 链式） | MySQL 做不到链式改写 |
| [窗口函数](https://daiw.org/manual/postgresql/window-functions) | 8.4 起完整支持 | MySQL 8.0 才有 |
| [LATERAL / GROUPING SETS](https://daiw.org/manual/postgresql/lateral-grouping) | 每组 Top-N、多维透视一句写完 | MySQL 无 `GROUPING SETS`/`CUBE` |
| [全文检索](https://daiw.org/manual/postgresql/full-text-search) | 内置分词 / 排序 / 高亮，免 ES | MySQL `FULLTEXT` 较弱 |
| [索引类型](https://daiw.org/manual/postgresql/indexes) | 6 种 + 部分 / 表达式 / 覆盖 | 多数只有 B-tree 一族 |
| [表分区](https://daiw.org/manual/postgresql/partitioning) | 声明式分区 + 秒级 DETACH | MySQL 分区不支持外键 |
| [物化视图](https://daiw.org/manual/postgresql/materialized-views) | `REFRESH CONCURRENTLY` 不锁读 | MySQL 干脆没有 |
| [EXPLAIN](https://daiw.org/manual/postgresql/explain) | 信息密度高、生态工具好 | 各家都有，思路一致 |
| [PL/pgSQL + 触发器](https://daiw.org/manual/postgresql/plpgsql-triggers) | 多语言过程 + 可复用触发器函数 | MySQL 过程 / 触发器较弱 |
| [LISTEN/NOTIFY](https://daiw.org/manual/postgresql/listen-notify) | 随事务一致的轻量 Pub/Sub | 多数库无内置 |
| [锁与并发](https://daiw.org/manual/postgresql/locks) | 咨询锁当分布式锁，`SKIP LOCKED` 当队列 | MySQL 8.0 才有 `SKIP LOCKED` |
| [扩展生态](https://daiw.org/manual/postgresql/extensions) | 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 几乎总能第一时间靠扩展跟上。二十多年过去，它非但没老，反而越来越像一个「数据平台」。

<Callout type="info">
  这也解释了为什么近些年 PostgreSQL 的采用率一路走高：当「多存储引擎」的复杂度越来越让人头疼，「一个够强、够开放的库把大部分活都干了」的吸引力就越来越大。「Just use Postgres（能用 PG 就用 PG）」这句话，不是没有道理。
</Callout>

## 什么时候该上 PostgreSQL

- **需要复杂查询 / 强一致 / 丰富类型的业务系统** —— 这是 PG 的主场，几乎闭眼选。
- **想少养组件** —— 搜索、队列、缓存失效通知、地理 / 时序 / 向量，能用 PG 内置或扩展搞定的，就别急着上一堆中间件。
- **数据模型复杂或多变** —— 关系 + JSONB 混合建模，严格与灵活兼得。
- **中小到中大规模** —— 单机 PostgreSQL（加只读副本）能扛的量，比很多人以为的大得多。

## 什么时候别硬上

诚实地说，PostgreSQL 不是万能的：

<Callout type="warn">
  几种「别硬上 PG」的场景：**① 需要海量水平扩展、天然分片的超大规模写入**——原生 PG 是单主架构，超出单机 + 副本的量级要靠 Citus 等分布式方案或换型。**② 纯缓存 / 极高 QPS 的简单 KV**——Redis 这类内存库更合适，别拿 PG 当缓存使。**③ 超大规模、需复杂相关性调优的搜索**——专业的 Elasticsearch 仍更强。**④ 海量时序且要极致压缩比**——TimescaleDB（仍是 PG 扩展）或专用时序库更对路。**判断标准很简单：PG 内置 / 扩展能覆盖到、且规模在单机 + 副本能扛的范围内，就用 PG；明显超出这个边界，再考虑专用系统。**
</Callout>

## 结语

回到开头那句话：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。