Postgres 就是你所需要的

当我开始开发我的第二个 SaaS 产品UserJot时，我决定简化有关技术堆栈的一切。

我的第一个 SaaS 产品LogSnag是一款基于相当复杂的基础架构构建的分析工具：Redis、Postgres、ClickHouse、Amazon SQS 等等。考虑到 LogSnag 的需求，这种复杂性很好地满足了它的需求。但对于UserJot 这个用户反馈平台，我挑战自己走上了完全相反的方向：简单至上。

问题是：我可以在 Postgres 上专门运行整个可投入生产的 SaaS 应用程序吗？

答案是肯定的。

复杂性并非你的朋友（初期）

早期产品很少会因为扩展性问题而夭折。它们往往受困于过早出现的复杂性和缺乏市场契合度。你添加的每一个外部服务——Redis、BullMQ、Pinecone、SQS——都会带来复杂性、维护成本以及潜在的故障点。

对于 UserJot，我专注于一个指导原则：

不要解决你没有的问题。

事实证明，Postgres 几乎解决了我遇到的所有与数据相关的挑战。

使用 Postgres 作为你的作业队列

事件驱动架构非常棒。副作用保持隔离，核心逻辑保持清晰。传统上，实现这一点意味着使用 Redis、BullMQ 或类似的服务。

但有一个更简单的方法：

进入pg-boss

pg-boss是一个基于 PostgreSQL 的轻量级作业队列，使用。它提供可靠的作业调度、重试、延迟作业和并发功能，无需任何外部依赖。我在这里SELECT FOR UPDATE SKIP LOCKED详细介绍了它。

这意味着：

• 没有 Redis。
• 更少的活动部件。
• 易于调试。

如果你的数据量急剧增加怎么办？你以后再添加 Redis 也无妨——等你真正遇到这个问题的时候。

使用 Postgres 进行向量搜索（再见 Pinecone）

UserJot 包含许多依赖于矢量搜索的功能。通常，你会使用像 Pinecone 或 Weaviate 这样的专业矢量数据库。

相反，我使用了pgvector——一个 PostgreSQL 扩展，它直接在数据库中添加了原生向量搜索功能。它允许你无缝地存储嵌入并执行相似性搜索：

SELECT id, title
FROM submissions
WHERE project_id = 'xyz'
ORDER BY embedding <-> $1
LIMIT 5;

好处：

• 单一事实来源：数据保持统一。
• 轻松连接和过滤：毫不费力地将向量相似性查询与标准 SQL 查询结合起来。
• 简化的基础设施：无需额外的数据同步或双重写入。

同样，如果规模需要，迁移到专用向量数据库很简单——但对于大多数 SaaS 企业来说可能没有必要。如果您有兴趣了解更多关于使用 Postgres 进行向量搜索的信息，我在这里写过详细的内容。

Postgres 作为键值存储

需要临时令牌、功能标志或配置值的键值存储吗？

通常情况下，你会选择 Redis。但 Postgres 也能满足你的需求：

CREATE TABLE kv_store (
  key TEXT PRIMARY KEY,
  value TEXT,
  expires_at TIMESTAMP WITH TIME ZONE
);

-- Retrieve keys that haven't expired yet
SELECT * FROM kv_store
WHERE key = 'feature_flag'
AND (expires_at IS NULL OR expires_at > NOW());

Postgres 可以轻松解决这个问题，并且还有额外的好处：

• 持久数据存储
• 轻松迁移和架构演变
• 丰富的查询功能

对于大多数独立或较小的 SaaS 产品（小意味着比 Netflix 规模的产品更小），Postgres 已经足够了。

但它真的能扩大规模吗？

绝对地。

Postgres 拥有卓越的垂直扩展能力。您可以轻松处理数百万行数据、每秒数千次查询以及复杂的查询。现代 Postgres 提供高级索引、缓存、分区和优化策略，以满足高性能需求。

当我说“小产品”足够时，我指的是相对于大规模的科技巨头而言的小型产品。实际上，99.9% 的 SaaS 企业（包括非常成功的独立产品）永远不会将 Postgres 推向极限。

如果你足够幸运，达到了这样的规模？恭喜你！你可以轻松地拆分出需要专用基础设施的部分。

UserJot 完全在 Postgres 上运行

目前，UserJot 后端仅在 PostgreSQL 上运行：

• 核心关系数据
• 作业队列（pg-boss）
• AI嵌入存储和向量搜索（pgvector）
• 键值数据存储
• 事件驱动的副作用（触发器）

这些只是冰山一角。Postgres 还有大量其他功能和扩展，可用于各种不同的用例。

最后的想法

您的基础设施应该反映您实际面临的问题的规模，而不是假设的未来问题的规模。

尽早选择简单意味着：

• 降低基础设施的复杂性和成本
• 更快的开发周期
• 更易于调试和维护
• 基础设施所有权
• 更容易设置本地开发环境
• 更容易扩展

复杂性最终总会找到你，但简单性一旦失去就不会轻易回来。

Postgres 不仅仅是一个数据库——它还是快速有效地构建优秀产品的理想基础。

如果您正在构建或考虑围绕 Postgres 构建一个简化的堆栈，我很乐意听听您的故事！如果您正在寻找客户反馈平台，我很乐意听听您对UserJot 的看法。

我偶尔会发送这样的帖子——加入列表吧。