PostgreSQL避坑指南：这些场景千万别用

虽然 PostgreSQL 功能强大且通用性强，但在特定场景下可能并非最优选择。以下是应避免使用 PostgreSQL 的核心场景及替代方案建议：

---

一、绝对避免场景

1. 超大规模写入密集型 OLTP（如物联网高频写入）

• 问题：尽管 PostgreSQL 支持高并发，但单节点写入性能存在物理上限（通常 <10 万 TPS）。
• 替代方案：
  • 时序数据 → TimescaleDB（基于 PG 的时序扩展）
  • 分布式写入 → Cassandra / ScyllaDB
  • 日志类数据 → ClickHouse

2. PB 级分析型 OLAP（复杂聚合查询）

• 问题：即使使用列存储扩展（cstore_fdw），其 MPP 分布式能力弱于专用 OLAP 数据库。
• 替代方案：
  • Snowflake / BigQuery（云原生数仓）
  • ClickHouse（高性能列式存储）
  • Greenplum（基于 PG 但专注分布式 OLAP）

3. 简单键值存储（低延迟读/写）

• 问题：使用 WHERE key = ? 查询效率远低于内存数据库。
• 替代方案：
  • Redis（内存 KV，支持持久化）
  • DynamoDB（Serverless NoSQL）

---

二、需要谨慎评估的场景

1. 高可用性要求超过 99.99%（金融级容灾）

• PG 短板：原生集群方案（如流复制）主从切换存在秒级延迟，脑裂防护需人工介入。
• 更优方案：
  • 云托管服务（AWS RDS/Aurora, Google Cloud SQL）
  • Patroni + etcd（自动化故障转移方案）

2. 非结构化文档数据库需求（如深度 JSON 查询）

• 问题：虽然支持 JSONB，但嵌套字段检索性能低于文档数据库。
• 替代方案：
  • MongoDB（原生文档模型）
  • Elasticsearch（全文检索 + JSON 分析）

3. 纯内存计算场景（实时排行榜/计数器）

• 问题：即使使用内存表（UNLOGGED Table），仍存在 I/O 开销。
• 替代方案：
  • Redis Sorted Sets / Memcached

---

三、架构设计警示

场景	PostgreSQL 风险	缓解方案
缺乏专业 DBA 维护	MVCC 导致死元组堆积（表膨胀）	必须配置自动 AUTOVACUUM
复杂地理空间分析	PostGIS 计算密集型操作拖慢整体库	分离计算层 → 用 GeoSpark
多租户 SaaS 架构	跨租户查询易引发锁竞争	分库分表或改用 Citus 扩展

---

四、何时可坚持使用 PostgreSQL？

✅ 强 ACID 事务需求（如订单/支付系统）
✅ 复杂 SQL 查询（CTE/窗口函数/多表 JOIN）
✅ GIS 数据处理（PostGIS 生态成熟）
✅ 中等数据规模（单表 < 10 亿行）

---

决策树：是否选用 PostgreSQL？

结论：当场景涉及 分布式写入、PB级分析、纯内存操作 时优先考虑替代方案；对于 关系型事务、GIS、复杂查询 等场景，PostgreSQL 仍是首选。