数据库 on Zampo Blog

我用 PostgreSQL 替换了整个技术栈，省了 6 个微服务

Fri, 17 Apr 2026 20:00:00 +0800

现代软件工程已经基本变成了"订阅管理模拟器"。

我们被云厂商洗脑了，以为即使构建一个基础应用，也需要拼凑一个脆弱的分布式网络：

Redis 做缓存
Confluent Kafka 集群做后台任务
Elasticsearch 只是为了一个简单的搜索框
再搞个专用向量数据库为了那个临时加上的 AI 功能

等你终于把应用部署给你那"要求极高"的用户群（你自己和你妈）时，你已经欠了十几家 Y Combinator 支持的 SaaS 初创公司的钱，就为了让灯亮着。

这是一个过度工程化、价格离谱的陷阱。

但如果我告诉你，你可以把那些闪亮的云依赖全部扔进焚化炉，用一个经过 30 年验证的开源软件替换它们呢？

科技行业不想让你知道的秘密：一个久经考验的工具可以吞噬你的整个架构。

我刚刚用 PostgreSQL 替换了整个技术栈。

一、PostgreSQL 为什么能吞噬整个栈

PostgreSQL 是一个开源对象关系数据库系统，已经活跃开发了 30 多年。

开箱即用的能力：

坚如磐石的 ACID 合规性——当你的廉价云服务器崩溃时，用户数据不会损坏
可扩展性——这才是它能吞噬整个栈的真正原因

PostgreSQL 不只是行列存储。

它还能存储：

JSONB（半结构化数据）
向量（AI 嵌入）
全文搜索索引
地理空间数据（PostGIS）
图数据（关系遍历）
时间序列数据
键值对（作为 Redis 替代）

PostgreSQL 不是数据库，是一个数据平台。

二、实战替换：Redis（缓存 + 键值存储）

传统架构

应用 → Redis（缓存） → PostgreSQL（持久化）

问题：

两个服务要运维
缓存和数据库数据可能不一致
Redis 挂了要处理降级

PostgreSQL 方案

使用 UNLOGGED 表做高速缓存：

你以为自己会用 PostgreSQL，其实你只是会写 SQL

Mon, 13 Apr 2026 17:18:00 +0800

很多开发者天天在用 PostgreSQL，但只要你追问三个问题，场面就会立刻安静下来：它为什么并发强？为什么崩了还能恢复？为什么 JSONB、大文本这些大字段没把系统拖死？

如果这些问题你平时很少认真想过，那你多半还停留在“会用 PostgreSQL”的表层。说得再狠一点：很多人其实不是理解 PostgreSQL，只是会写 SQL。

PostgreSQL 入门：为什么说它能装下世间万物？

Tue, 07 Apr 2026 12:16:00 +0800

这是世界上最先进的开源关系型数据库。

PostgreSQL 的能力早已超越了传统关系型数据库的范围。现代开发中，为了解决各种问题，各类花哨的工具层出不穷——缓存用 Redis、全文检索用 Elasticsearch、文档存储用 MongoDB、向量数据库用专门的方案、定时任务跑在 K8s 上。

但有时候，仅仅一个 PostgreSQL，就能覆盖大部分后端开发需求。

为什么数据库的挑战者们都没好下场

Thu, 02 Apr 2026 21:30:00 +0800

1974 年，IBM 捣鼓出了世界上第一个关系数据库。

50 年过去了，Oracle、MySQL、PostgreSQL 这些 RDB 依然霸榜。年轻程序员嘴上喊着 “SQL 太土”，项目里该用还是用。

有意思的是，每隔几年就冒出一堆"未来数据库"来挑战 RDB 的地位：Key-Value Store、MapReduce、Hadoop、图数据库、向量数据库……

我都用过。所以我知道为什么它们最后都凉了。

Redis：我踩过最贵的坑

Redis 是 KVS 的典型代表，用 Key 找 Value，简单粗暴。

缓存用它，完美。问题是做开发的总有点执念，非要把缓存以外的事情也塞给它。

我当年做物联网项目就载过这个跟头。

当时选 Redis 考虑两个因素：一是物联网系统里大部分是文件，数据库只管组件状态；二是终端用 SD 卡，磁盘 IO 寿命短，想省着用。

结果第三个月就开始出问题了。

物联网环境里，网络和电源都不可靠，随时可能断电断网。每一个组件的状态管理变得极其复杂——在 Redis 上，你要用 Array、Set、HashMap 来描述一个简单的"任务运行状态"，换成 SQLite 的话，一个表加几条 SQL 就搞定了。

最后项目里一半以上的 Bug 都跟这个定制 Redis 数据结构有关。就在写这篇文章的时候，我们还在修一个诡异的 Bug：终端下载视频时遇到网络问题，紧接着又断电，Redis 里的任务信息不完整，视频永远下不下来。

你说这值不值？

为了省 SD 卡那点读写寿命，被折腾了好几年。

第一个 KVS 是 AT&T 在 1979 年发布的，叫 DBM。发明者？又是那个男人。

Hadoop：我学了个寂寞

MapReduce 不是数据库，是 Google 提出的一种分布式数据处理思路。

Map 对应 SQL 里的 WHERE + ORDER BY，Reduce 对应 GROUP BY。说白了就是把 SQL 的逻辑拆到多台服务器上跑。

为什么 PostgreSQL 能超越 MySQL？这是我见过最全面的对比

Thu, 02 Apr 2026 15:47:00 +0800

用了 MySQL 好几年，最近深入研究 PostgreSQL，才发现自己一直在将就。

不是 MySQL 不好，而是 PostgreSQL 在太多地方更胜一筹。这篇文章从四个维度把它说清楚：索引、数据一致性、性能、扩展性。

一、索引：PostgreSQL 的玩法更多

两者的基础索引都是 B+ 树，但 PostgreSQL 的花样也太多了。

聚簇 vs 非聚簇

MySQL（InnoDB）是聚簇索引：数据按主键顺序存在叶子节点上，查主键很快，但非主键字段要先查二级索引再回表查一遍。

PostgreSQL 的所有索引都是非聚簇索引：数据单独存放在堆表里，索引只存指针。主键和普通索引没区别，插入数据直接追加到末尾，不用担心页分裂。

GIN 索引：倒排索引

PostgreSQL 的 GIN 索引简直是 JSON 数据的克星：

1
2


CREATE INDEX idx_attr ON products USING GIN (attributes);
SELECT * FROM products WHERE attributes @> '{"color": "red"}';

一句 @> 操作符就能查包含特定键值对的记录。MySQL 根本不支持。

GiST 索引：什么都能索引

GiST 是一个索引框架，任何数据类型实现了接口就能用。

地理坐标、时间范围、IP 区间……这些用 PostgreSQL 原生的 daterange 加上 GiST 索引，查询重叠和距离效率极高。

1

SELECT * FROM reservations WHERE daterange '[2026-01-08,2026-01-13]' @> '2026-01-10'::date;

MySQL 也不行。