PostgreSQL 一个打十个：从搜索、队列到向量库，砍掉半个中间件栈

2024 年 2 月 14 日，一位叫 Raphael Bauer 的柏林 CTO 在个人博客上发了篇《PostgreSQL for Everything》。主张用一句话就能说完：你架构图里那些全文搜索、文档数据库、消息队列、时序数据库、向量库、缓存——大部分都可以砍掉，留一个 PostgreSQL 就够了。

这篇文章多次登上 Hacker News 首页。就在写这篇稿子的今天（2026 年 8 月 20 日），它又冲上去了一次：315 分、195 条讨论。一篇两年半前的选型文至今还在被反复争论，本身就说明它戳中了什么。

同一份业务，两套架构：专用中间件各司其职，还是一个 PostgreSQL 包打天下

更有意思的是，用今天的眼光回看，这篇文章不但没过时，还被整个数据库生态用真金白银验证了一遍：Databricks 花 10 亿美元收购了 Neon，Snowflake 收购了 Crunchy Data，Supabase 两年内估值从 20 亿美元涨到约 100 亿，Stack Overflow 开发者调查里 PostgreSQL 使用率冲到 58.2%。

这篇文章在 Bauer 原文的基础上做三件事：盘点「PG 替代专用系统」的每一项主张如今的成色；划清这条路线的边界——哪些场景确实不该硬上；最后给一份可以直接抄走的决策矩阵。英文原文全文附在文末。

💡 核心逻辑：复杂度是速度的敌人

Bauer 的论点从来不是「PostgreSQL 性能碾压谁」——单点跑分上 PG 往往并不是最快的。他的论点是一个朴素的运维常识：每引入一个独立系统，你就多了一份部署、监控、升级、容灾、备份和值班。对绝大多数团队，多维护一个系统的真实成本，远大于它在跑分上的优势。

更要命的是数据同步。应用库和搜索集群之间要双写、要对账；业务库和消息队列之间，永远有「写库成功了、消息发丢了」的裂缝要打补丁。这些胶水代码不会出现在任何架构图上，但它们是凌晨三点告警的主要来源。

PostgreSQL 的诱人之处在于：砍掉中间件之后，这些同步问题直接消失——数据只有一份，事务天生一致。原文里有句很朴素的话，值得贴在这里：

You need simplicity if you want to move fast.（想快，先把事情变简单。）

🗺️ 能力地图：中间件 → PostgreSQL 对应物

先把原文的十个「替代」主张压缩成一张表：

下面挑重点展开，每一项都是「原文观点 + 这两年半的新进展」。

🔍 全文搜索：先问 PG，再谈 Elastic

原文最推崇的案例是 Contentful：这家 headless CMS 直接用 PostgreSQL 给用户提供全文搜索，原文称其为「一个关于简洁如何支撑增长的寓言」。Instacart 也走了同一条路——把现代搜索基础设施建在 Postgres 上，而不是维护一个独立搜索集群。

机制上，PG 把文本转成 tsvector、用 GIN 索引加速匹配，pg_trgm 扩展负责模糊和相似度搜索，从 PG 16 开始哈希连接还能并行构建索引。最大的收益不在性能，而在架构：数据天然同步，永远不会出现「商品已下架、搜索结果还在卖」的尴尬。

中文场景有个额外注意点：PG 默认解析器不理解中文分词，需要加 zhparser 或 pg_jieba 扩展，效果才能达到可用水平。

边界也很清晰：亿级文档、需要精细的相关性调优、召回实验体系，Elastic 仍然是更好的工具。Contentful 的场景是结构化内容的站内搜索，不是全网搜索引擎。

📄 文档存储：jsonb 顺手拿走了 MongoDB 的饭碗

jsonb 让 PG 同时拥有了文档存储和查询能力，GIN 索引可以加速 JSON 字段内部的查询。原文引用的经典案例是《卫报》：2018 年他们把 25 年积累的内容数据从 MongoDB 整体迁到 PostgreSQL on RDS，并公开写了迁移复盘。

这两年还有个容易被忽略的背景：开源数据库的许可证反复摇摆——MongoDB 2018 年改 SSPL，Redis 2024 年跟进换协议逼出 Valkey 分叉。对比之下，PostgreSQL 那份类 BSD 的许可证三十年没变过。对做技术选型的人来说，「这家会不会哪天改协议」本身就是风险项。

边界：如果写入量需要水平分片扩展，文档数据库的分片方案依然更成熟。

📬 消息队列：SKIP LOCKED 是被低估的宝藏

这是全文技术含量最高的一节。PG 的行锁语法里藏着一个天然的队列原语：

1
2
3
4
5

SELECT * FROM jobs
WHERE status = 'pending'
ORDER BY created_at
FOR UPDATE SKIP LOCKED
LIMIT 1;

SKIP LOCKED 的语义是：已经被别的消费者锁住的行直接跳过。多个 worker 并发抢任务，互不阻塞、互不重复。更妙的是任务表和业务表在同一个数据库里——「扣库存」和「记任务」在同一个事务里提交，分布式事务问题根本不存在。

这两年生态走得更远：Tembo 开源的 PGMQ 给 PG 包了一层 SQS 语义（可见性超时、消息归档、FIFO），Supabase 直接把它做成内置扩展。今天 HN 评论区的高赞补充也很能说明问题：Revolut 这家英国金融科技独角兽，把全部事件持久化和流处理跑在 Postgres 上，没有用传统消息代理。

原文给的建议非常工程化：从 PostgreSQL 开始做队列，等它真的撑不住再换 Kafka 或 SQS——你会惊讶它能撑多久。反过来说，百万级消息每秒、长时间回溯重放、多消费者组，这些 Kafka 的主场，PG 确实不该硬扛。

⏱️ 时序与向量：AI 把 PG 推上了新位置

时序方面，作者自己就在用 TimescaleDB 扛高流量的 Web 分析产品（Privatracker），原生 BRIN 索引 + 分区也能应付多数时序场景。

变化最大的是向量。原文写作时 pgvector 还只是 Timescale 生态里的一个扩展，今天它已经是 AI 应用事实上的默认向量库。资本市场的动作最能说明问题：Databricks 2025 年 5 月以约 10 亿美元收购 Neon 时披露，Neon 平台上 80% 的数据库是由 AI agent 创建的；紧接着 Snowflake 以约 2.5 亿美元收购 Crunchy Data；Supabase 的估值两年内从 20 亿美元一路涨到约 100 亿。PG 本身的引擎也在变强：2025 年 9 月发布的 PostgreSQL 18 引入异步 I/O，读密集负载吞吐最高翻倍——一个库扛更多角色，底牌更厚了。

原文发表后的两年半：生态用真金白银投票

🧊 缓存、文件、图数据库：能，但要想清楚

缓存的核心洞察是语义而非性能：缓存本来就可以丢了重建，而 UNLOGGED 表（不写 WAL 日志）恰好就是这个语义，TTL 过期用触发器模拟即可。会话、低频热点数据够用；但亚毫秒延迟、几十万 QPS 的纯内存场景，Redis/Valkey 依然是对的。

文件系统那节是原文最反直觉的案例：作者客户的项目要高频读写海量二进制小对象，实测 PG 比直接写文件系统还快——PG 的缓存和读写调度比自己随手写文件 I/O 高效，数据用 Flatbuffers 序列化后存进 bytea 列。当然，海量文件的归宿依然是 S3/R2 这类对象存储。

层级数据用 ltree 类型比递归 CTE 可读得多；想跑 openCypher 图查询还有 Apache AGE 扩展。这几项原文自己也带着「能，但酌情」的分寸感。

🏗️ 顺手干掉中间层

原文的半开玩笑之作：大量「微服务」干的事，就是从数据库取数、拼成 JSON 返回。而 PG 的 row_to_json 可以让 SQL 直接吐 JSON——中间层薄到只剩鉴权和权限。这和这两年「modular monolith」的回潮是同一个方向：拆分应该被规模逼出来，而不是作为起点。

📈 两年半后的成绩单

⚠️ 边界：什么时候必须上专用系统

这篇文章最值得学的不是结论，而是姿态——原文一边列「PG 替代一切」，一边毫不吝啬地夸 ClickHouse amazing。诚实的边界大概在这五条：

1. 写入水平扩展：PG 是单机写 + 异步复制，写吞吐到顶之后的路（分库分表、Citus）都不轻松。天生多写的业务一开始就要想清楚。
2. 海量分析：列存碾压行存是物理规律。大宽表的实时聚合、PB 级分析，ClickHouse / DuckDB 快出一个量级。
3. 亚毫秒缓存：极高 QPS 的纯内存 + 丰富数据结构，Redis/Valkey 还是正解。
4. 高吞吐流处理：百万级 msg/s、按时间回溯重放、多消费者组，是 Kafka 的主场。
5. 组织因素：团队会不会、运维扛不扛得住、已有投资沉没多少——这些和技术同样真实。

原文结尾那句话分寸感极好：PostgreSQL might not be the answer to everything - but it is the answer to a lot more than you might think!（PostgreSQL 也许不是一切的答案，但它能回答的，比你以为的多得多。）

🧭 决策矩阵：抄走就能用

一句话总结：**「PG for Everything」不是信仰，是默认值。**每一个专用系统都应该是被真实需要逼出来的，而不是被简历驱动加进来的。

延伸阅读：建设期的 schema 设计、索引与查询优化，可以看本博客的《创业公司的 Postgres 生存指南》；线上诊断连接池、膨胀、锁等待，可以看《Postgres 生产运维实战》。

附上原文

以下为 Raphael Bauer 的英文原文全文，发表于 2024 年 2 月 14 日，原文地址：PostgreSQL for Everything。

PostgreSQL for Everything

Contrary to popular belief - the answer to everything is NOT 42 - it’s PostgreSQL. (ok. It might also be Postgres).

Intro

I started using PostgreSQL roughly in 2003 for a research project called ColumbaDB. Columba is no more, but PostgreSQL is still alive and kicking more than ever.

In 2003, MySQL was much more widely used than PostgreSQL. MySQL was also potentially faster as it did not implement all features of the SQL standard. At the same time MySQL was lacking many features that we needed (full-text search, powerful indexes, SQL standard compliance etc). PostgreSQL felt more like a “real” database in comparison to MySQL - like a tiny version of Oracle - but in open source clothes.

During that research project I learned a lot about databases, indexes and the power of PostgreSQL.
One important use-case was full-text search. We could have used MySQL in conjunction with another system like Lucene / Solr to make our database searchable. But that would have meant running and maintaining two such systems. Complicated.

PostgreSQL allowed us to use a fulltext search plugin to do everything in one system. No need to sync any data. No need to maintain and run two systems. It just worked and made us smile (after some tweaks of course). Simplicity.

Since then I used PostgreSQL for many use-cases throughout my career as CTO / Interim Manager. Most recently I used PostgreSQL to store very high volume web analytics time series data via its TimescaleDB plugin. Check out Privatracker - the best way to do web analytics and respect the privacy of your visitors - to see it in action.

Many others discussed the topic from different angles. And each article is really worth your time (SQL is Agile, Stephan Schmidt on Using SQL for Everything). Also check out my Linkedin post.

And if you are using PostgreSQL I can highly recommend reading Hazel Bachrach’s nice post on “What I Wish Someone Told Me About Postgres”.

In my humble opinion the power of PostgreSQL comes from three sources:

• It is rock-solid and stable.
• It is easy to run, install and scale.
• It massively simplifies your IT setup by being not only a RDBMS, but also a full-text search engine, a document storage and much much more…

Let’s have a closer look…

Rock Solid and Stable

PostgreSQL is boring old technology. The first PostgreSQL release dates back to 1996. PostgreSQL is also very widely used - for a very long amount of time. Ironing out bugs - especially in database systems - takes time. PostgreSQL had that time.

It also has a very active community that diligently adds more and more features without breaking any old parts of it. In recent years PostgreSQL got many amazing features like json document storage, partitioning support, common table expressions and much much more. Each new release of PostgreSQL is exciting and brings new nice features.

True - PostgreSQL is old - but the features are very very modern - and PostgreSQL becomes better with every release.

Easy to Run, Install and Scale

PostgreSQL can be installed very easily locally. It is bundled with all major Linux distributions, part of Mac brew, but can also be installed with applications like PostgresApp.

When running tests, it comes in handy using Testcontainers with PostgreSQL. It was never easier running your tests against a real PostgreSQL database that is 100% similar to the production thing.

If you want to run PostgreSQL on a server then you can simply apt-get install it. Or run it in a docker container.

All cloud providers allow you to run (and scale!) PostgreSQL by clicking a single button. You got ample of choice at your fingertips:

• Amazon AWS
• Google GCP
• Microsoft Azure
• ElephantSQL
• CrunchyData
• Timescale
• … and many more …

That makes PostgreSQL one of the most widely supported software systems in the market. And for you this means less maintenance and more time for creating new features for clients.

Simplifies Your IT Setup

Running PostgreSQL in the cloud is already just one click. But it gets even better. PostgreSQL can replace many systems that youd’d have to run otherwise.

PostgreSQL Replaces Solr and Elastic: Full-Text Search

PostgreSQL allows you to turn your text data into user-searchable data. Without a separate system. It’s also language agnostic and you’ll never have any sync problems between your data and your fulltext search system.

The most impressive article on the topic is how Contentful used PostgreSQL to enable fulltext search for their users. It’s a tale in simplicity that enables growth.

Instacart did something very similar: They built their modern search infrastructure on Postgres instead of running a separate search cluster. Same story, different company.

More on the topic: https://www.postgresql.org/docs/current/textsearch.html

PostgreSQL replaces MongoDB: Excellent Json Support

PostgreSQL has excellent support for storing and querying(!) json. It also features an index type (GIN) that makes these operations blazingly fast. Is there a need for MongoDB any more?.

The Guardian also wrote an excellent article how they switched from Mongo to PostgreSQL. Thanks for sharing Jan-Otto! Hazel also wrote a nice piece on jsonb and what to take into account when using it.

PostgreSQL replaces Kafka and RabbitMQ: PostgreSQL as a queue

Events, queues and persistent logs are getting more and more important in today’s software systems. Systems like Kafka, RabbitMQ, SQS and others provide that functionality. But maintaining them is annoying, custom and you need the skillset.

The good news: You can just use PostgreSQL. The magic comes from

• SELECT .. FOR UPDATE
• SELECT .. SKIP LOCKED

Using these SQL features you can effectively use a table as queue. Either in a persistent fashion with a cursor and many consumers, or in a read-once fashion.

The article at crunchydata explains this concept very well.

My tip: Start with PostgreSQL as a queueing system. Only when that does no longer perform well switch to other systems like Kafka, RabbitMQ or SQS. You’ll be surprised how well PostgreSQL works.

PostgreSQL Replaces Clickhouse: High Volume Time Series Data

Time series data is special. Often you get many data points in a very short amount of time. And then you have to aggregate the data frequently, doing some statistics on it and so on.

There are specialized software systems like Clickhouse (amazing by the way…). But you can also use a plugin for PostgreSQL that allows you to do (nearly) the same: Timescale.

I’ve used Timescale and can recommend it. The good news is that you can continue using PostgreSQL - even for high volume data easily. No need to learn and maintain something new.

PostgreSQL as Vector Database for AI Workflows

Timescale lately released the pgvector extension, that turns your PostgreSQL into a vector database.
This allows you to use the tech you already know for indexing and retrieval of relevant data. That’s an essential part of AI LLM workflows.

Timescale also recently announced pgai that includes pgvector, but also a lot of other nice extensions that make it super simple to index data, call LLM models and retrieve data based on similarity.

PostgreSQL Replaces Redis: Non-Persistent High Performance Caching

Caching is important. Most applications use something like Redis as a cache to get information like sessions and more quickly. A cache can by definition lose data and can be regenerated from the original source.

But. Why use Redis when PostgreSQL can be tuned to be as fast (in most usecases) as a Redis cache? The secret is using an UNLOGGED table. You can even emulate Redis’ automatic expire by a trigger. A lot has been written about this - I can just recommend trying it out.

PostgreSQL Replaces File System: For Raw Data

For one of my clients we had to read and write a huge amount of small pieces of binary encoded information. We initially thought that doing this via the file system was the fastest way to do so.

After some performance checks it became clear that PostgreSQL was even faster than reading from the file system for our use-case. PostgreSQL uses the file system very efficiently for its data - and it adds a lot of caching and efficient reading and writing strategies that can outperform writing and reading raw data on a file system.

We used Flatbuffers to store the data in a blob column. Data was then de-serialized on the client. You might want to try that approach as well.

PostgreSQL Replacing Your Graph Database

Hierarchical data can be managed in SQL via recursive queries. That’s ok, but also super-hard to read, maintain and debug. Not even speaking of performance.

The better way is the LTREE datatype of PostgreSQL. It helped me not only once to implement hierarchical tag structures. Easy to read, maintain and blazingly fast.

PostgreSQL Replacing Your Microservice

Most of the “microservices” these days are only about models, getting data from a database and returning json to the client.

But you know what? PostgreSQL can turn any query into a Json result. That effectively replaces your server middleware. There are Pros and Cons to this approach, but it shows the capabilities of PostgreSQL. The amazing Lukas Eder wrote about the topic - not PostgreSQL specific - but everything mentioned there is very well doable in PostgreSQL as well

PostgreSQL - Replacing your Playstation 5

Well. Some enthusiast implemented Tetris as Common Table Expressions in pure SQL. Crazy. And maybe not to be taken too seriously.

Conclusion

The list above is not very exhaustive. PostgreSQL is a very flexible piece of software. And it can be extended with plugins to do more and more.

You need simplicity if you want to move fast. If you come across a new requirement always ask: Can’t PostgreSQL do this? And do we really need that shiny new technology X?

PostgreSQL might not be the answer to everything - but it is the answer to a lot more than you might think!

原文：PostgreSQL for Everything by Raphael Bauer（2024-02-14）。本文由本号在原文基础上引申编写，中文部分引用请注明出处，英文原文版权归原作者所有。