别为 Redis 和 RabbitMQ 付费了！Postgres 几乎能处理它们的一切……

一些独立开发者和创业公司创始人疯狂地拼凑技术栈，用Redis做缓存，RabbitMQ做队列，Elasticsearch做搜索，还有MongoDB，为什么呢？

我也犯过同样的错误。当初开发 UserJot（我的反馈和路线图工具）时，我的第一反应是设计一个“规范”的架构，把所有功能都拆分成独立服务。后来我停下来问自己：如果直接用Postgres来处理所有事情呢？

事实证明，大家一直对这个显而易见的问题避而不谈：

Postgres几乎可以做到这一切。

它的效果比你想象的还要好。

你肯定听说过 Postgres“只是个关系型数据库”，需要专门的工具来完成特定的任务。我以前也是这么想的，直到我发现Instagram仅用一个Postgres实例就能支持1400万用户；Discord可以处理数十亿条消息；Notion整个产品都是基于 Postgres开发的。

但关键在于：他们使用Postgres的方式已经和2005年不一样了。

别再为Redis和RabbitMQ付费了。Postgres原生支持 LISTEN/NOTIFY，而且比大多数专用解决方案更能处理消息队列：

-- Simple job queue in pure Postgres
CREATE TABLE job_queue (
    id SERIAL PRIMARY KEY,
    job_type VARCHAR(50),
    payload JSONB,
    status VARCHAR(20) DEFAULT 'pending',
    created_at TIMESTAMP DEFAULT NOW(),
    processed_at TIMESTAMP
);


-- ACID-compliant job processing
BEGIN;
UPDATE job_queue
SET status = 'processing', processed_at = NOW()
WHERE id = (
    SELECT id FROM job_queue
    WHERE status = 'pending'
    ORDER BY created_at
    FOR UPDATE SKIP LOCKED
    LIMIT 1
)
RETURNING *;
COMMIT;

这样就能实现精确一次处理，而且无需任何额外的基础设施。如果试着用Redis实现这一点，你会抓狂的。

在 UserJot 中，我正是使用这种模式来处理反馈提交、发送通知和更新路线图项目。只需一次事务，就能保证数据一致性，而且无需消息代理，也能降低复杂性。

Redis在大多数平台上最低每月收费 20 美元。Postgres的JSONB功能已包含在现有的数据库中，可以满足大部分需求：

-- Your Redis alternative
CREATE TABLE kv_store (
    key VARCHAR(255) PRIMARY KEY,
    value JSONB,
    expires_at TIMESTAMP
);


-- GIN index for blazing fast JSON queries
CREATE INDEX idx_kv_value ON kv_store USING GIN (value);


-- Query nested JSON faster than most NoSQL databases
SELECT * FROM kv_store
WHERE value @> '{"user_id": 12345}';

该@>操作符是 Postgres 的秘密武器。它比大多数 NoSQL 查询速度更快，而且能保持数据一致性。

Elasticsearch 集群成本高昂且复杂，而Postgres内置的全文搜索功能非常出色：

-- Add search to any table
ALTER TABLE posts ADD COLUMN search_vector tsvector;


-- Auto-update search index
CREATE OR REPLACE FUNCTION update_search_vector() RETURNS trigger AS $$
BEGIN
    NEW.search_vector := to_tsvector('english', COALESCE(NEW.title, '') || ' ' || COALESCE(NEW.content, ''));
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;


-- Ranked search results
SELECT title, ts_rank(search_vector, query) as rank
FROM posts, to_tsquery('startup & postgres') query
WHERE search_vector @@ query
ORDER BY rank DESC;

它开箱即用，支持模糊匹配、词干提取和相关性排序。

在UserJot的反馈搜索功能中，用户可立即通过标题、描述和评论中找到所需的功能请求，无需Elasticsearch集群，纯粹依靠Postgres发挥其核心优势即可实现。

抛开复杂的 WebSocket 架构，Postgres 的 LISTEN/NOTIFY机制可为你提供实时更新，无需任何额外服务：

-- Notify clients of changes
CREATE OR REPLACE FUNCTION notify_changes() RETURNS trigger AS $$
BEGIN
    PERFORM pg_notify('table_changes', json_build_object(
        'table', TG_TABLE_NAME,
        'action', TG_OP,
        'data', row_to_json(NEW)
    )::text);
    RETURN NEW;
END;
LANGUAGE plpgsql;

你的应用程序会监听这些通知，并将更新推送给用户，不需要使用Redis发布或者订阅模式。

我们来算笔账，一个典型的“现代”堆栈的成本是：

• Redis：每月20美元

• 消息队列：每月25美元

• 搜索服务：每月50美元

• 3项服务的监控费用：每月30美元

• 总计：每月125美元

但这只是主机托管费用，真正的痛点在于：

• 三项不同的服务需监控、更新和调试

• 不同的扩展模式和故障模式

• 维护多种配置

• 独立的备份和灾难恢复程序

• 每项服务的安全考虑因素各不相同

• 不同的客户端库和连接模式

• 协调跨多个服务的部署

• 系统间数据不一致

• 复杂的测试场景

• 不同的性能调优方法

如果你选择自建服务器，那么还需进行服务器管理、安全补丁，以及在Redis占用全部内存时不得不在凌晨3点进行调试。

但Postgres通过单一服务即可处理所有这些事务，该服务本就在你的管理范围内。

大多数人可能没有意识到：单个Postgres实例就能处理海量数据。我们说的是每天数百万笔交易、数 TB 的数据以及数千个并发连接。

实际案例：

• Airbnb：单个Postgres集群处理数百万笔预订

• Robinhood：数十亿笔金融交易

• GitLab：基于Postgres的完整DevOps平台

Postgres的魅力在于其架构，它具备极强的垂直扩展能力，而当你最终需要水平扩展时，也有很多成熟的方案可选择，例如：

• 读取副本以进行查询扩展

• 分区处理大型表

• 连接池实现并发

• 分布式架构的逻辑复制

大多数企业永远不会遇到这些限制。除非你需要处理数百万用户或复杂的分析工作负载，否则单个实例可能就足够了。

相比之下，管理那些扩展能力不一的独立服务则截然不同：你的Redis可能内存已达上限，消息队列可能吞吐量不足，而搜索服务则需要完全不同的硬件配置。

现代开发的最大陷阱，莫过于架构空想。我们总在为尚未出现的问题设计系统，针对从未遇到的流量做方案，为可能永远达不到的规模做准备。

1）“我们或许有一天需要扩大规模”；

2）添加 Redis、队列、微服务和多个数据库；

3）花费数月时间调试集成问题；

4）面向47位用户发布；

5）每月支付200美元购买的基础设施，其实只需一台5美元的VPS就能运行；

与此同时，你的竞争对手交付速度更快。因为他们不会在真正需要分布式系统之前，就盲目投入精力去搭建和维护它。

1）从Postgres开始，简单起步；

2）监控实际存在的瓶颈，而不是臆想出来的瓶颈；

3）当达到实际限制时，调整特定组件的规模；

4）仅在方案能解决实际问题时，才引入复杂设计。

你的用户并不关心你的架构，他们只关心你的产品是否好用，能否解决他们的问题。

专用工具自有其用处，但可能只有出现以下情况才用到它们：

• 每分钟处理超过10万个作业；

• 需要亚毫秒级的缓存响应；

• 正在对TB级的数据进行复杂的分析；

• 拥有数百万并发用户；

• 需要满足特定一致性要求的全球数据分发。

最让我震惊的是：Postgres 可以同时作为主数据库、缓存、队列、搜索引擎和实时系统，而且还能在所有组件间保持ACID事务。

-- One transaction, multiple operations
BEGIN;
INSERT INTO users (email) VALUES ('user@example.com');
INSERT INTO job_queue (job_type, payload) VALUES ('send_welcome_email', '{"user_id": 123}');
UPDATE kv_store SET value = '{"last_signup": "2024-01-15"}' WHERE key = 'stats';
COMMIT;

试试在 Redis、RabbitMQ 和 Elasticsearch 之间执行这样的操作，看你能不能不崩溃。

Postgres 并不引人注目，它既没有花里胡哨的官网，也没有像TikTok那样爆红的平台。但数十年来，当其他数据库不断迭代更替时，它始终在背后默默支撑着互联网的运转。

选择这类朴实可靠、能稳定落地的技术，本身就很有讲究。

1. 先只使用 Postgres开始：不要急于添加其他数据库；

2. 使用 JSONB 实现灵活性：既能享受无模式的优势，又能拥有SQL的强大功能；

3. 在 Postgres 中实现队列：节省成本并降低复杂性；

4. 真正遇到瓶颈时才添加专用工具：注意，不是想象中的瓶颈。

UserJot 的开发正是对这一理念的完美检验。作为一款反馈与路线图工具，它需要：

• 提交反馈后实时更新；

• 对数千个功能请求进行全文搜索；

• 用于发送通知的后台任务；

• 为频繁访问的路线图提供缓存；

• 存储用户偏好和设置的键值存储。

我的整个后端仅由单个Postgres数据库构成。没有Redis，没有Elasticsearch，也没有消息队列。从用户身份验证到实时WebSocket通知，一切都由Postgres处理。

结果如何？我可以更快地发布功能，需要调试的组件更少，基础设施成本也降到了最低。所有底层工作都由Postgres完成：用户提交反馈、搜索功能或获取路线图变更的实时更新。

这早已不是纸上谈兵，而是承载着真实用户与业务数据，稳定运行于生产和环境。

Postgres或许过于优秀反而成了负担。它功能如此强大，以至于让其他数据库在90%的应用场景中显得多余。行业惯例让我们相信每件事都需要专用工具，但或许我们只是把事情搞得比实际更复杂。

初创公司不需要成为分布式系统的展示平台，它需要解决真实用户面临的实际问题。Postgres让你能够专注于此，而不是一直在维护基础设施。

所以下次如果有人提议添加Redis"提升性能"或添加MongoDB"增强灵活性"时，不妨反问："你是否尝试过先用Postgres实现？"

答案或许会让你惊讶。当我将UserJot完全构建在Postgres之上时也感到非常意外，而它至今运行得无比顺畅。