最近，技术圈里刮起了一股“反简化”的风潮，其中最响亮的口号之一就是：“你其实不需要 Redis，一个 PostgreSQL 就够了。”

作为一个习惯了 MySQL + Redis 黄金搭档的开发者，听到这话的第一反应通常是：“疯了吧？Redis 是内存数据库，PostgreSQL 是关系型数据库，这俩能是一回事？”

但当你深入了解 PostgreSQL（简称 PG）之后，你会发现它早已不是一个简单的“关系型数据库”了。它更像是一个无所不能的数据库平台。

今天我们就来聊聊这位“全能选手”，以及它是否真的有底气取代 Redis。

为什么大家都在谈论 PostgreSQL？

在 MySQL 称霸 Web 开发的年代，PostgreSQL 常被贴上“学院派”、“配置复杂”的标签。但随着版本迭代，PG 凭借其强大的扩展能力（Extensions）和先进的特性，逐渐成为了架构师的心头好。

它支持：

  • 关系型数据（标准的 SQL，比 MySQL 更严格更强大）。
  • JSON 文档（JSONB 类型，查询性能甚至超越 MongoDB）。
  • 地理空间数据（PostGIS，地图应用的行业标准）。
  • 全文检索（自带分词，很多时候不需要 ElasticSearch）。
  • 向量搜索（pgvector，完美适配现在的 AI 浪潮）。

这时候有人就想了：既然它这么强，能不能把 Redis 的活儿也干了？

PG 凭什么挑战 Redis？

Redis 的核心应用场景通常有三个：缓存、消息队列、分布式锁。PostgreSQL 在这些领域竟然都有对应的解决方案。

1. 缓存：Unlogged Tables（不记录日志表）

Redis 快是因为它在内存里。PG 虽然是磁盘数据库，但它有一个大杀器：UNLOGGED Tables。

1
2
3
4
5
CREATE UNLOGGED TABLE cache_items (
    key TEXT PRIMARY KEY,
    value JSONB,
    expires_at TIMESTAMP
);
  • 原理：普通的 PG 表为了保证数据不丢，写入时要写两份（一份数据文件，一份 WAL 日志）。UNLOGGED 表不写 WAL 日志。
  • 效果：写入速度提升数倍。虽然崩了会丢数据，但这不就是缓存的特性吗？而且配合现代操作系统的 Page Cache 和 NVMe SSD，它的读取速度对于 99% 的应用来说已经足够快了。

2. 消息队列：LISTEN / NOTIFY

Redis 常被用作简单的 Pub/Sub（发布订阅）。PG 竟然原生支持这个功能：

1
2
3
4
5
-- 消费者监听
LISTEN my_channel;

-- 生产者发送
NOTIFY my_channel, 'Hello World';

对于任务队列，PG 还有 FOR UPDATE SKIP LOCKED 特性，可以实现多消费者不冲突地抢任务，可靠性比 Redis 还要高（因为数据是持久化的）。

3. 分布式锁：Advisory Locks

Redis 做分布式锁很常见（SetNX），但处理超时和原子性比较麻烦。PG 提供了 Advisory Locks（咨询锁）：

1
2
3
4
5
-- 获取锁（快速，不存磁盘，纯内存操作）
SELECT pg_try_advisory_lock(12345);

-- 释放锁
SELECT pg_advisory_unlock(12345);

这完全是内存级的操作，性能极高，而且连接断开自动释放，不用担心死锁。

真的能取代吗？冷静分析

虽然 PG 能干这些活，但能干不代表最擅长。

✅ 支持取代的理由（Just Use Postgres）

  1. 架构极简：以前你需要维护 App + MySQL + Redis + ES + Kafka。现在可能只需要 App + PostgreSQL。少一个组件，就少一份运维成本，少一类网络故障风险。
  2. 事务一致性：你的缓存、队列和主数据都在同一个数据库里，你可以用事务来保证原子性！“写入数据库同时写入队列”这种难题瞬间消失。
  3. 成本：Redis 需要昂贵的内存，PG 可以利用廉价的 SSD。

❌ 不建议取代的理由

  1. 极致性能：Redis 是亚毫秒级（<1ms）响应，单机轻松 10w QPS。PG 即使再优化，网络协议和 SQL 解析的开销也摆在那，通常是毫秒级（1-10ms）。对于高频计数器、实时抢购等场景，Redis 是不可替代的。
  2. 数据结构：Redis 有 Set, ZSet, List, Hash 等丰富的数据结构，操作极其方便。虽然 PG 可以用 JSONB 模拟，但复杂度高且效率不如 Redis 原生结构。
  3. 连接消耗：PG 的连接（Connection）是比较重的资源。如果把 PG 当缓存用，大量的并发请求可能会把数据库连接池打满，影响主业务。

总结：如何选择？

PostgreSQL 就像一把瑞士军刀，它能锯木头、剪指甲、开红酒。
Redis 就像一把专业的手术刀，它专注于极致的切割。

  • 如果你是初创团队 / 中小型项目：强力推荐 All-in PostgreSQL。在这个阶段，架构的简单性大于极致的性能。不用维护 Redis，不用处理缓存一致性问题，幸福感爆棚。
  • 如果你是高并发 / 复杂业务系统：请继续使用 PostgreSQL + Redis。让专业的工具做专业的事，PG 负责持久化和复杂查询，Redis 负责抗高并发流量。

PostgreSQL 也许不会完全“杀死” Redis，但它确实给了我们一个重新思考架构的机会：我们真的需要那么复杂的架构吗？