第一时间捕获有价值的信号
本文译自 It’s 2026, Just Use Postgres,作者 Raja Rao DV

摘要:别再管理多个数据库了。Postgres 扩展可以用 BM25、向量、JSONB 替代 Elasticsearch、Pinecone、Redis、MongoDB 和 InfluxDB。
把你的数据库想象成你的家。家里有客厅、卧室、浴室、厨房和车库。每个房间都有不同的用途。但它们都在同一个屋檐下,通过走廊和门相连。你不会因为需要做饭就单独建一栋餐厅建筑。你也不会因为要停车就在城市对面建一个商业车库。
这就是 Postgres。 一个有很多房间的家。搜索、向量、时序、队列——都在一个屋檐下。
但这正是专业数据库厂商不想让你听到的。他们的营销团队花了多年时间说服你”为正确的工作使用正确的工具”。听起来很合理,听起来很明智,而且卖出了很多数据库。
让我告诉你为什么这是一个陷阱,以及为什么在 99% 的情况下 Postgres 是更好的选择。
“使用正确工具”的陷阱
你听过这样的建议:“为正确的工作使用正确的工具。”
听起来很明智。于是你最后用上了:
- Elasticsearch 用于搜索
- Pinecone 用于向量
- Redis 用于缓存
- MongoDB 用于文档
- Kafka 用于队列
- InfluxDB 用于时序
- PostgreSQL 用于…剩下的东西
恭喜。你现在有七个数据库要管理。七种查询语言要学习。七种备份策略要维护。七个安全模型要审计。六组凭证要轮换。七个监控仪表板要看。还有七个可能在凌晨 3 点出问题的东西。
当某个东西真的出问题了?祝你好运启动一个测试环境来调试它。
这里有一个不同的想法:就用 Postgres。
为什么这在当下很重要:AI 时代
这不仅仅是关于简单性。AI 代理已经让数据库蔓延成为一场噩梦。
想想代理需要做什么:
- 快速启动一个带有生产数据的测试数据库
- 尝试修复或实验
- 验证它是否有效
- 拆除它
用一个数据库?这是一个命令。派生它,测试它,完成。
用七个数据库?现在你需要:
- 协调 Postgres、Elasticsearch、Pinecone、Redis、MongoDB 和 Kafka 的快照
- 确保它们都处于同一时间点
- 启动七个不同的服务
- 配置七个不同的连接字符串
- 希望测试期间没有任何东西漂移
- 完成后拆除七个服务
如果没有大量研发工作,这几乎是不可能的。
而且不仅仅是代理。每次凌晨 3 点有东西出问题,你都需要启动一个测试环境来调试。用六个数据库,这是一场协调噩梦。用一个数据库,这是一个命令。
在 AI 时代,简单性不仅仅是优雅。它是必需的。
“但专业数据库更好!”
让我们直接解决这个问题。
神话: 专业数据库在其特定任务上要优越得多。
现实: 有时它们在狭窄任务上略微更好。但它们也带来了不必要的复杂性。这就像为每顿饭聘请私人厨师。听起来很奢华,但它增加了费用、协调开销,并制造了你以前没有的问题。
关键是:99% 的公司不需要它们。那 1% 的公司有数千万用户和相应的大型工程团队。你读过他们的博客文章,讲的是专业数据库 X 对他们来说有多棒。但那是他们的规模、他们的团队、他们的问题。对于其他所有人,Postgres 已经足够了。
大多数人没有意识到的是:Postgres 扩展使用与专业数据库相同或更好的算法(在很多情况下)。
“专业数据库”的溢价?主要是营销。
| 你需要什么 | 专业工具 | Postgres 扩展 | 相同算法? |
|---|---|---|---|
| 全文搜索 | Elasticsearch | pg_textsearch | ✅ 都使用 BM25 |
| 向量搜索 | Pinecone | pgvector + pgvectorscale | ✅ 都使用 HNSW/DiskANN |
| 时序数据 | InfluxDB | TimescaleDB | ✅ 都使用时间分区 |
| 缓存 | Redis | UNLOGGED tables | ✅ 都使用内存存储 |
| 文档 | MongoDB | JSONB | ✅ 都使用文档索引 |
| 地理空间 | 专业 GIS | PostGIS | ✅ 2001 年以来的行业标准 |
这些不是简化版本。它们是相同/更好的算法,经过实战检验,开源,而且通常由同一批研究人员开发。
基准测试也支持这一点:
- pgvectorscale:比 Pinecone 延迟低 28 倍,成本低 75%
- TimescaleDB:在提供完整 SQL 的同时匹配或优于 InfluxDB
- pg_textsearch:正是驱动 Elasticsearch 的 BM25 排名
除了 AI/代理问题之外,数据库蔓延还有复合成本:
| 任务 | 一个数据库 | 七个数据库 |
|---|---|---|
| 备份策略 | 1 | 7 |
| 监控仪表板 | 1 | 7 |
| 安全补丁 | 1 | 7 |
| 运维手册 | 1 | 7 |
| 故障转移测试 | 1 | 7 |
认知负担: 你的团队需要 SQL、Redis 命令、Elasticsearch 查询 DSL、MongoDB 聚合、Kafka 模式和 InfluxDB 的非原生 SQL 变通方案。那不是专业化。那是碎片化。
数据一致性: 让 Elasticsearch 与 Postgres 保持同步?你构建同步作业。它们失败了。数据漂移了。你添加对账。那也失败了。现在你在维护基础设施而不是构建功能。
SLA 数学: 三个系统,每个 99.9% 的正常运行时间 = 99.7% 的组合正常运行时间。那是每年 26 小时的停机时间,而不是 8.7 小时。每个系统都会成倍增加你的故障模式。
现代 Postgres 技术栈
这些扩展不是新的。它们已经生产就绪多年了:
- PostGIS:自 2001 年(24 年)。驱动 OpenStreetMap 和 Uber。
- 全文搜索:自 2008 年(17 年)。内置于 Postgres 核心。
- JSONB:自 2014 年(11 年)。与 MongoDB 一样快,还有 ACID。
- TimescaleDB:自 2017 年(8 年)。21K+ GitHub 星标。
- pgvector:自 2021 年(4 年)。19K+ GitHub 星标。
超过 48,000 家公司使用 PostgreSQL,包括 Netflix、Spotify、Uber、Reddit、Instagram 和 Discord。
AI 时代的扩展
AI 时代带来了新一代:
| 扩展 | 替代 | 亮点 |
|---|---|---|
| pgvectorscale | Pinecone, Qdrant | DiskANN 算法。延迟低 28 倍,成本低 75%。 |
| pg_textsearch | Elasticsearch | Postgres 原生的真正 BM25 排名。 |
| pgai | 外部 AI 管道 | 数据变化时自动同步嵌入。 |
这意味着什么: 构建 RAG 应用曾经需要 Postgres + Pinecone + Elasticsearch + 粘合代码。
现在?就用 Postgres。 一个数据库。一种查询语言。一个备份。一个派生命令让你的 AI 代理启动测试环境。
快速开始:添加这些扩展
这就是你需要的全部:
-- 带有 BM25 的全文搜索
CREATE EXTENSION pg_textsearch;
-- AI 向量搜索
CREATE EXTENSION vector;
CREATE EXTENSION vectorscale;
-- AI 嵌入和 RAG 工作流
CREATE EXTENSION ai;
-- 时序数据
CREATE EXTENSION timescaledb;
-- 消息队列
CREATE EXTENSION pgmq;
-- 定时任务
CREATE EXTENSION pg_cron;
-- 地理空间
CREATE EXTENSION postgis;
就这些。
看代码
下面是每个用例的工作示例。跳转到你需要的内容。
全文搜索(替代 Elasticsearch)
扩展: pg_textsearch(真正的 BM25 排名)
你正在替换的东西:
- Elasticsearch:单独的 JVM 集群、复杂的映射、同步管道、Java 堆调优
- Solr:同样的故事,不同的包装
- Algolia:每 1000 次搜索 1 美元,外部 API 依赖
你得到的:驱动 Elasticsearch 的完全相同的 BM25 算法,直接在 Postgres 中。
-- 创建表
CREATE TABLE articles (
id SERIAL PRIMARY KEY,
title TEXT,
content TEXT
);
-- 创建 BM25 索引
CREATE INDEX idx_articles_bm25 ON articles USING bm25(content)
WITH (text_config = 'english');
-- 使用 BM25 评分搜索
SELECT title, -(content <@> 'database optimization') as score
FROM articles
ORDER BY content <@> 'database optimization'
LIMIT 10;
混合搜索:一个查询中同时使用 BM25 + 向量
SELECT
title,
-(content <@> 'database optimization') as bm25_score,
embedding <=> query_embedding as vector_distance,
0.7 * (-(content <@> 'database optimization')) +
0.3 * (1 - (embedding <=> query_embedding)) as hybrid_score
FROM articles
ORDER BY hybrid_score DESC
LIMIT 10;
这在 Elasticsearch 中需要单独的插件。在 Postgres 中,这就是 SQL。
向量搜索(替代 Pinecone)
扩展: pgvector + pgvectorscale
你正在替换的东西:
- Pinecone:最低 70 美元/月,单独的基础设施,数据同步噩梦
- Qdrant, Milvus, Weaviate:更多要管理的基础设施
你得到的:pgvectorscale 使用 DiskANN 算法(来自微软研究院),在 99% 召回率下比 Pinecone 实现了 28 倍更低的 p95 延迟 和 16 倍更高的吞吐量。
-- 启用扩展
CREATE EXTENSION vector;
CREATE EXTENSION vectorscale CASCADE;
-- 带有嵌入的表
CREATE TABLE documents (
id SERIAL PRIMARY KEY,
content TEXT,
embedding vector(1536)
);
-- 高性能索引(DiskANN)
CREATE INDEX idx_docs_embedding ON documents USING diskann(embedding);
-- 查找相似文档
SELECT content, embedding <=> '[0.1, 0.2, ...]'::vector as distance
FROM documents
ORDER BY embedding <=> '[0.1, 0.2, ...]'::vector
LIMIT 10;
使用 pgai 自动同步嵌入:
SELECT ai.create_vectorizer(
'documents'::regclass,
loading => ai.loading_column(column_name=>'content'),
embedding => ai.embedding_openai(model=>'text-embedding-3-small', dimensions=>'1536')
);
现在每次 INSERT/UPDATE 都会自动重新生成嵌入。没有同步作业。没有漂移。没有凌晨 3 点的告警。
时序数据(替代 InfluxDB)
扩展: TimescaleDB(21K+ GitHub 星标)
你正在替换的东西:
- InfluxDB:单独的数据库,Flux 查询语言或非原生 SQL,有限的 SQL 支持
- Prometheus:对指标很棒,但不是你的应用数据
你得到的:自动时间分区、高达 90% 的压缩、连续聚合。完整的 SQL。
-- 启用 TimescaleDB
CREATE EXTENSION timescaledb;
-- 创建表
CREATE TABLE metrics (
time TIMESTAMPTZ NOT NULL,
device_id TEXT,
temperature DOUBLE PRECISION
);
-- 转换为超表
SELECT create_hypertable('metrics', 'time');
-- 使用时间桶查询
SELECT time_bucket('1 hour', time) as hour,
AVG(temperature)
FROM metrics
WHERE time > NOW() - INTERVAL '24 hours'
GROUP BY hour;
-- 自动删除旧数据
SELECT add_retention_policy('metrics', INTERVAL '30 days');
-- 压缩(90% 存储减少)
ALTER TABLE metrics SET (timescaledb.compress);
SELECT add_compression_policy('metrics', INTERVAL '7 days');
缓存(替代 Redis)
特性: UNLOGGED 表 + JSONB
-- UNLOGGED = 无 WAL 开销,更快的写入
CREATE UNLOGGED TABLE cache (
key TEXT PRIMARY KEY,
value JSONB,
expires_at TIMESTAMPTZ
);
-- 设置并带有过期时间
INSERT INTO cache (key, value, expires_at)
VALUES ('user:123', '{"name": "Alice"}', NOW() + INTERVAL '1 hour')
ON CONFLICT (key) DO UPDATE SET value = EXCLUDED.value;
-- 获取
SELECT value FROM cache WHERE key = 'user:123' AND expires_at > NOW();
-- 清理(用 pg_cron 调度)
DELETE FROM cache WHERE expires_at < NOW();
消息队列(替代 Kafka)
扩展: pgmq
CREATE EXTENSION pgmq;
SELECT pgmq.create('my_queue');
-- 发送
SELECT pgmq.send('my_queue', '{"event": "signup", "user_id": 123}');
-- 接收(带可见性超时)
SELECT * FROM pgmq.read('my_queue', 30, 5);
-- 处理后删除
SELECT pgmq.delete('my_queue', msg_id);
或者原生 SKIP LOCKED 模式:
CREATE TABLE jobs (
id SERIAL PRIMARY KEY,
payload JSONB,
status TEXT DEFAULT 'pending'
);
-- 工作器原子性地认领任务
UPDATE jobs SET status = 'processing'
WHERE id = (
SELECT id FROM jobs WHERE status = 'pending'
FOR UPDATE SKIP LOCKED LIMIT 1
) RETURNING *;
文档(替代 MongoDB)
特性: 原生 JSONB
CREATE TABLE users (
id SERIAL PRIMARY KEY,
data JSONB
);
-- 插入嵌套文档
INSERT INTO users (data) VALUES ('{
"name": "Alice",
"profile": {"bio": "Developer", "links": ["github.com/alice"]}
}');
-- 查询嵌套字段
SELECT data->>'name', data->'profile'->>'bio'
FROM users
WHERE data->'profile'->>'bio' LIKE '%Developer%';
-- 索引 JSON 字段
CREATE INDEX idx_users_email ON users ((data->>'email'));
地理空间(替代专业 GIS)
扩展: PostGIS
CREATE EXTENSION postgis;
CREATE TABLE stores (
id SERIAL PRIMARY KEY,
name TEXT,
location GEOGRAPHY(POINT, 4326)
);
-- 查找 5 公里内的商店
SELECT name, ST_Distance(location, ST_MakePoint(-122.4, 37.78)::geography) as meters
FROM stores
WHERE ST_DWithin(location, ST_MakePoint(-122.4, 37.78)::geography, 5000);
定时任务(替代 Cron)
扩展: pg_cron
CREATE EXTENSION pg_cron;
-- 每小时运行
SELECT cron.schedule('cleanup', '0 * * * *',
$$DELETE FROM cache WHERE expires_at < NOW()$$);
-- 夜间汇总
SELECT cron.schedule('rollup', '0 2 * * *',
$$REFRESH MATERIALIZED VIEW CONCURRENTLY daily_stats$$);
混合搜索(BM25 + 向量)
对于 AI 应用,你经常需要同时进行关键词搜索和语义搜索:
-- 倒数排名融合:结合关键词 + 语义搜索
WITH bm25 AS (
SELECT id, ROW_NUMBER() OVER (ORDER BY content <@> $1) as rank
FROM documents LIMIT 20
),
vectors AS (
SELECT id, ROW_NUMBER() OVER (ORDER BY embedding <=> $2) as rank
FROM documents LIMIT 20
)
SELECT d.*,
1.0/(60 + COALESCE(b.rank, 1000)) +
1.0/(60 + COALESCE(v.rank, 1000)) as score
FROM documents d
LEFT JOIN bm25 b ON d.id = b.id
LEFT JOIN vectors v ON d.id = v.id
WHERE b.id IS NOT NULL OR v.id IS NOT NULL
ORDER BY score DESC LIMIT 10;
用 Elasticsearch + Pinecone 试试这个。你需要两次 API 调用、结果合并、失败处理和双倍延迟。
在 Postgres 中:一个查询、一个事务、一个结果。
模糊搜索(拼写错误容忍)
扩展: pg_trgm(内置于 Postgres)
CREATE EXTENSION pg_trgm;
CREATE INDEX idx_name_trgm ON products USING GIN (name gin_trgm_ops);
-- 即使有拼写错误也能找到 "PostgreSQL"
SELECT name FROM products
WHERE name % 'posgresql'
ORDER BY similarity(name, 'posgresql') DESC;
图遍历(替代图数据库)
特性: 递归 CTE
-- 查找经理下的所有汇报(组织架构图)
WITH RECURSIVE org_tree AS (
SELECT id, name, manager_id, 1 as depth
FROM employees WHERE id = 42
UNION ALL
SELECT e.id, e.name, e.manager_id, t.depth + 1
FROM employees e
JOIN org_tree t ON e.manager_id = t.id
WHERE t.depth < 10
)
SELECT * FROM org_tree;
总结
还记得那个家的比喻吗?你不会为了做晚餐就单独建一个餐厅。你不会为了停车就在城市对面建一个商业车库。你用家里的房间。
这就是我们在这里向你展示的。搜索、向量、时序、文档、队列、缓存——它们都是 Postgres 家里的房间。与专业数据库相同的算法。经过多年实战检验。被 Netflix、Uber、Discord 和 48,000 家其他公司使用。
那么那 99% 呢?
对于 99% 的公司,Postgres 处理你需要的一切。那 1% 呢?那是当你在数百个节点上处理 PB 级别的日志,或者你需要 Kibana 的特定仪表板,或者你有真正超出 Postgres 能力的奇特需求。
但关键是:当你处于那 1% 时你会知道。 你不需要厂商的营销团队来告诉你。你会自己进行基准测试并碰到真正的墙。
在那之前,不要因为有人告诉你”为正确的工作使用正确的工具”就把你的数据分散在七栋建筑里。那个建议卖数据库。它不为你服务。
从 Postgres 开始。坚持用 Postgres。只有当你真的需要复杂性时才添加它。
2026 年了,就用 Postgres 吧。
开始使用
所有这些扩展都可以在 Tiger Data 上获得。几分钟内创建一个免费数据库:
psql "postgresql://user:[email protected]:5432/tsdb"
CREATE EXTENSION pg_textsearch; -- BM25 搜索
CREATE EXTENSION vector; -- 向量搜索
不需要专业数据库,就用 Postgres。