PostgreSQL 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 真正厉害的，不是性能，而是它把最后一道权限判断留在了数据库里

Fri, 17 Apr 2026 09:33:20 +0800

我越来越觉得，很多团队的安全问题，不是前面没做，而是最后收得不够。

浏览器有隔离，接口有鉴权，服务上了 HTTPS，机器放在内网里，日志和审计也配了。可等请求真的落到 PostgreSQL，后端连过去的，还是一个几乎什么都能做的高权限角色。

前面一层一层都像样，最后这一跳却像没上锁。

这也是我最近看 PostgreSQL 安全这条视频时，最有感触的一点：PostgreSQL 真正厉害的，不是它默认很安全，也不只是它功能多，而是它把最后一道权限判断留在了数据库里。

你以为自己会用 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，就能覆盖大部分后端开发需求。

为什么 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 也不行。