文章探讨了使用PostgreSQL替代Redis作为缓存的可行性。作者通过搭建简单的HTTP服务器，在Kubernetes集群中分别测试Redis和PostgreSQL（使用非日志表）的性能表现。实验采用标准配置的PostgreSQL 17.6和Redis 8.2镜像，通过k6工具进行基准测试，比较两者在缓存应用场景下的差异。

标题：Redis确实快，但我选择用PostgreSQL做缓存

文章来源：https://dizzy.zone/2025/09/24/Redis-is-fast-Ill-cache-in-Postgres/

发布时间：2025年9月24日

核心内容：

作者通过实验对比了Redis和PostgreSQL在缓存场景下的性能表现。实验在家庭实验室的k8s集群中进行，限制两者使用相同的硬件资源（2核CPU和8GB内存）。

实验方法： 1. 构建简单的HTTP服务器，实现获取/设置缓存接口 2. 分别实现Redis和PostgreSQL缓存方案： - Redis使用标准客户端库 - PostgreSQL使用非日志表(unlogged table)优化写入性能 3. 预先插入3000万条测试数据 4. 进行三种测试场景： - 读取测试（80%命中率） - 写入测试（10%更新概率） - 混合测试（20%写入/80%读取）

测试结果： 1. 读取性能： - Redis每秒处理更多请求（HTTP服务器成为瓶颈） - PostgreSQL受限于CPU资源 - Redis延迟更低

2. 写入性能：

   • Redis仍保持优势
   • PostgreSQL持续处于CPU满载状态
   • Redis内存使用更稳定

3. 混合测试：

   • Redis综合表现更优
   • PostgreSQL内存使用增至约6GB

4. 非日志表优化：

   • 对写入性能提升显著
   • 对读取性能影响有限

结论： 虽然Redis在缓存场景确实更快，但作者仍倾向于使用PostgreSQL，原因包括： 1. 多数项目已使用PostgreSQL，减少额外依赖 2. PostgreSQL性能已足够（每秒7425次请求） 3. 可通过接口设计保持缓存实现的可替换性 4. 需要TTL功能时可通过额外字段和定时任务实现

最终建议： 对于大多数项目，使用PostgreSQL作为缓存是合理选择，既能满足性能需求，又能保持架构简洁。当项目规模扩大时，再考虑引入Redis也不迟。

（注：原文中具体的性能数据图表和代码实现细节在此摘要中做了简化处理，保留了核心对比结论和决策依据）

以下是评论内容的总结，平衡呈现不同观点：

1. 支持PostgreSQL替代Redis

   • 认为PostgreSQL性能足够，简化架构（评论3："1ms足够快，建议先用PostgreSQL"；评论6："被说服在新项目放弃Redis"）
   • 提到Redka项目实现Redis API兼容（评论1："Redka通过SQLite/Postgres支持Redis子集很巧妙"）

2. 质疑测试方法

   • 认为测试未反映真实场景（评论2："测试的是RTT而非吞吐量"；评论15："未调优配置的基准测试无意义"）
   • 指出硬件配置问题（评论8："未测试多核性能"；评论17："只给PG分配2核不公平"）

3. 强调Redis优势

   • 管道化提升性能（评论4："Redis最大优势是管道化"；评论2："用rueidis客户端可提升10倍性能"）
   • 关键功能不可替代（评论9："TTL是缓存核心功能"；评论7："UNLOGGED表重启会导致缓存雪崩"）

4. 其他技术建议

   • 推荐替代方案（评论12："可考虑nginx缓存或memcached"；评论10："需监控缓存清理任务"）
   • 数据规模影响（评论11："应测试更大数据量"；评论17："未考虑Redis内存限制"）

5. 对基准测试的批评

   • 学术严谨性不足（评论14："图表精美但方法不及格"；评论16："未讨论索引和配置是误导"）
   • 生产环境差异（评论17："家庭实验室场景不具代表性"；评论15："容器环境也需调优"）

争议焦点在于测试场景的适用性（评论3："应根据实际用例测试"；评论18："性能与简洁性的权衡标准是什么"）。