
原文:https://www.tigerdata.com/blog/its-2026-just-use-postgres
作者:Raja Rao DV
把数据库想成你的房子。
房子里有客厅、卧室、卫生间、厨房和车库。
每个房间各有用途,但都在同一屋檐下,由走廊和门连在一起。
你不会因为要做饭就单独盖一栋餐厅,也不会因为要停车就在城另一头修一个商业车库。
Postgres 就是这样。
一栋房子,很多房间。搜索、向量、时序、队列,全都在同一个屋檐下。
但这恰恰是那些专用数据库厂商最不想让你听到的话。
多年来,他们的营销团队一直在向你灌输一句话:“为合适的工作选择合适的工具。”
这话听上去很合理,也很明智,而且确实卖出了很多数据库。
下面我想说明,为什么这其实是个陷阱,以及为什么在 99% 的场景里,Postgres 才是更好的选择。

你肯定听过这句建议:“为合适的工作选择合适的工具。”
听起来很有道理。于是你的系统就变成了这样:
恭喜你。
现在你要维护七套数据库,学习七种查询语言,维护七套备份策略,审计七种安全模型,轮换一堆凭证,盯着七个监控面板,还得提防七套系统都可能在凌晨 3 点掉链子。
而一旦真出问题了?
祝你好运,先把测试环境拉起来再说。
换个思路:直接用 Postgres。
这已经不只是简化系统的问题。AI 智能体的出现,让数据库摊子铺得太大这件事彻底成了噩梦。
想想智能体需要做什么:
如果你只有一个数据库?一条命令就够了。fork 一个副本出来,测完就销毁。
如果你有七个数据库?那你就得:
没有大量研发投入,这几乎做不到。
而且这还不只是智能体的问题。
每次凌晨 3 点系统出故障,你都得先拉起一套测试环境才能排查。
六七个数据库要一起协调,简直是协同噩梦;如果只有一个数据库,这就是一条命令的事。
在 AI 时代,简洁不只是优雅,而是刚需。
我们正面回应这个问题。
常见神话: 专用数据库在各自场景里会强很多。
现实情况: 有时候,在一个非常狭窄的任务上,它们确实略占优势。
但与此同时,它们也引入了完全没必要的复杂度。就像你每顿饭都雇一个私厨一样。
听上去很高级,但成本更高、协调更麻烦,还会制造出你原本根本没有的问题。
关键在于:99% 的公司根本用不上这些东西。
真正属于那 1% 的公司,通常有几千万用户,也有与之匹配的大型工程团队。
你读过他们的博客,看他们夸某个专用数据库多么好用。但那是他们的规模、他们的团队、他们的问题。
对绝大多数公司来说,Postgres 已经绰绰有余。
更关键的是,很多人没有意识到:Postgres 扩展在很多场景下,用的就是和专用数据库相同,甚至更好的算法。
所谓“专用数据库”的溢价,很多时候只是营销。
需求 | 专用工具 | Postgres 扩展 | 算法是否相同? |
|---|---|---|---|
全文检索 | Elasticsearch | pg_textsearch | ✅ 都使用 BM25 |
向量检索 | Pinecone | pgvector + pgvectorscale | ✅ 都使用 HNSW / DiskANN |
时序数据 | InfluxDB | TimescaleDB | ✅ 都使用时间分区 |
缓存 | Redis | UNLOGGED tables | ✅ 都使用内存存储 |
文档数据 | MongoDB | JSONB | ✅ 都使用文档索引 |
地理空间 | 专用 GIS | PostGIS | ✅ 自 2001 年起就是行业标准 |
这些不是缩水版替代品。
它们用的是相同甚至更好的算法,经过长期实战验证,开源,而且很多时候还出自同一批研究者之手。
基准测试也支持这一点:
除了 AI 智能体带来的问题,多数据库架构的成本还会不断叠加:
任务 | 一个数据库 | 七个数据库 |
|---|---|---|
备份策略 | 1 | 7 |
监控面板 | 1 | 7 |
安全补丁 | 1 | 7 |
值班手册 | 1 | 7 |
故障切换演练 | 1 | 7 |
认知负担: 你的团队得同时掌握 SQL、Redis 命令、Elasticsearch Query DSL、MongoDB 聚合、Kafka 模式,以及 InfluxDB 那套并非原生的 SQL 兼容层。这不是专业化,这是碎片化。
数据一致性: 想让 Elasticsearch 和 Postgres 保持同步?你得写同步任务。同步任务会失败。数据会漂移。于是你再写一套对账逻辑。然后它也会失败。最后你维护的已经不是产品功能,而是一整套胶水基础设施。
SLA 计算: 三个系统各自 99.9% 的可用性,叠在一起只有 99.7%。也就是说,每年停机时间不是 8.7 小时,而是 26 小时。系统越多,故障模式就越多。
这些扩展并不新,很多都已经在生产环境稳定使用多年:
已有 48,000 多家公司使用 PostgreSQL,包括 Netflix、Spotify、Uber、Reddit、Instagram 和 Discord。
扩展 | 替代对象 | 亮点 |
|---|---|---|
pgvectorscale | Pinecone、Qdrant | DiskANN 算法。延迟低 28 倍,成本低 75%。 |
pg_textsearch | Elasticsearch | 在 Postgres 内原生提供真正的 BM25 排名。 |
pgai | 外部 AI 流水线 | 数据变更时自动同步 embeddings。 |
这意味着什么? 过去做一个 RAG 应用,往往需要 Postgres + Pinecone + Elasticsearch + 一堆胶水代码。
现在呢?
只要 Postgres。
一个数据库,一种查询语言,一套备份策略。你的 AI 智能体一条命令就能 fork 出测试环境。
你真正需要的只有这些:
-- 使用 BM25 的全文检索
CREATE EXTENSION pg_textsearch;
-- 用于 AI 的向量检索
CREATE EXTENSION vector;
CREATE EXTENSION vectorscale;
-- AI embedding 与 RAG 工作流
CREATE EXTENSION ai;
-- 时序数据
CREATE EXTENSION timescaledb;
-- 消息队列
CREATE EXTENSION pgmq;
-- 定时任务
CREATE EXTENSION pg_cron;
-- 地理空间
CREATE EXTENSION postgis;
就这些。
下面按场景给出可用示例,需要什么看什么。
扩展:pg_textsearch(真正的 BM25 排序)
你要替代的是:
你得到的是:与 Elasticsearch 相同的 BM25 算法,直接运行在 Postgres 里。
-- 创建表
CREATETABLE articles (
idSERIAL PRIMARY KEY,
title TEXT,
contentTEXT
);
-- 创建 BM25 索引
CREATEINDEX idx_articles_bm25 ON articles USING bm25(content)
WITH (text_config = 'english');
-- 使用 BM25 评分搜索
SELECT title, -(content <@> 'database optimization') as score
FROM articles
ORDERBYcontent <@> 'database optimization'
LIMIT10;
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。
扩展: pgvector + pgvectorscale
你要替代的是:
你得到的是: pgvectorscale 使用 DiskANN 算法(来自 Microsoft Research),在 99% 召回率下,p95 延迟比 Pinecone 低 28 倍,吞吐高 16 倍。
-- 启用扩展
CREATE EXTENSION vector;
CREATE EXTENSION vectorscale CASCADE;
-- 包含 embedding 的表
CREATETABLE documents (
idSERIAL PRIMARY KEY,
contentTEXT,
embedding vector(1536)
);
-- 高性能索引(DiskANN)
CREATEINDEX idx_docs_embedding ON documents USING diskann(embedding);
-- 查找相似文档
SELECTcontent, embedding <=> '[0.1, 0.2, ...]'::vector as distance
FROM documents
ORDERBY embedding <=> '[0.1, 0.2, ...]'::vector
LIMIT10;
配合 pgai 自动同步 embeddings:
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 都会自动重算 embedding。不需要同步任务,不会产生漂移,也少了凌晨 3 点的告警。
扩展:TimescaleDB(GitHub 21K+ Stars)
你要替代的是:
你得到的是:自动时间分区、最高 90% 的压缩率、连续聚合,以及完整 SQL。
-- 启用 TimescaleDB
CREATE EXTENSION timescaledb;
-- 创建表
CREATETABLE metrics (
time TIMESTAMPTZ NOTNULL,
device_id TEXT,
temperature DOUBLEPRECISION
);
-- 转成 hypertable
SELECT create_hypertable('metrics', 'time');
-- 按时间桶查询
SELECT time_bucket('1 hour', time) ashour,
AVG(temperature)
FROM metrics
WHEREtime > NOW() - INTERVAL'24 hours'
GROUPBYhour;
-- 自动删除旧数据
SELECT add_retention_policy('metrics', INTERVAL'30 days');
-- 压缩(存储减少 90%)
ALTERTABLE metrics SET (timescaledb.compress);
SELECT add_compression_policy('metrics', INTERVAL'7 days');
能力: UNLOGGED 表 + JSONB
-- UNLOGGED = 没有 WAL 开销,写入更快
CREATE UNLOGGED TABLEcache (
keyTEXT PRIMARY KEY,
value JSONB,
expires_at TIMESTAMPTZ
);
-- 写入并设置过期时间
INSERTINTOcache (key, value, expires_at)
VALUES ('user:123', '{"name": "Alice"}', NOW() + INTERVAL'1 hour')
ON CONFLICT (key) DOUPDATESETvalue = EXCLUDED.value;
-- 读取
SELECTvalueFROMcacheWHEREkey = 'user:123'AND expires_at > NOW();
-- 清理(可用 pg_cron 调度)
DELETEFROMcacheWHERE expires_at < NOW();
扩展: 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 (
idSERIAL PRIMARY KEY,
payload JSONB,
statusTEXTDEFAULT'pending'
);
-- Worker 以原子方式领取任务
UPDATE jobs SETstatus = 'processing'
WHEREid = (
SELECTidFROM jobs WHEREstatus = 'pending'
FORUPDATESKIPLOCKEDLIMIT1
) RETURNING *;
能力: 原生 JSONB
CREATE TABLEusers (
idSERIAL PRIMARY KEY,
data JSONB
);
-- 插入嵌套文档
INSERTINTOusers (data) VALUES ('{
"name": "Alice",
"profile": {"bio": "Developer", "links": ["github.com/alice"]}
}');
-- 查询嵌套字段
SELECTdata->>'name', data->'profile'->>'bio'
FROMusers
WHEREdata->'profile'->>'bio'LIKE'%Developer%';
-- 为 JSON 字段建索引
CREATEINDEX idx_users_email ONusers ((data->>'email'));
扩展: PostGIS
CREATE EXTENSION postgis;
CREATETABLE stores (
idSERIAL PRIMARY KEY,
nameTEXT,
location GEOGRAPHY(POINT, 4326)
);
-- 找出 5km 范围内的门店
SELECTname, 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);
扩展: 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$$);
对于 AI 应用,你经常既需要关键词检索,也需要语义检索:
-- Reciprocal Rank Fusion:合并关键词检索与语义检索
WITH bm25 AS (
SELECTid, ROW_NUMBER() OVER (ORDERBYcontent <@> $1) asrank
FROM documents LIMIT20
),
vectors AS (
SELECTid, ROW_NUMBER() OVER (ORDERBY embedding <=> $2) asrank
FROM documents LIMIT20
)
SELECT d.*,
1.0/(60 + COALESCE(b.rank, 1000)) +
1.0/(60 + COALESCE(v.rank, 1000)) as score
FROM documents d
LEFTJOIN bm25 b ON d.id = b.id
LEFTJOIN vectors v ON d.id = v.id
WHERE b.id ISNOTNULLOR v.id ISNOTNULL
ORDERBY score DESCLIMIT10;
如果用 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
-- 找出某个经理名下的所有下属(组织架构)
WITHRECURSIVE org_tree AS (
SELECTid, name, manager_id, 1asdepth
FROM employees WHEREid = 42
UNIONALL
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 家公司使用。
那剩下的 1% 呢?
对 99% 的公司来说,Postgres 足以满足你需要的一切。
那 1% 呢?
可能是你要在数百个节点上处理 PB 级日志,或者你确实需要 Kibana 那些特定仪表盘,又或者你的场景真的超出了 Postgres 的能力边界。
但关键是:如果你真的属于那 1%,你自己会知道。
你会亲自跑过基准测试,也会明确撞上一堵真实的墙。你不需要某个厂商的营销团队来提醒你。
在那之前,不要因为别人告诉你“要为合适的工作选择合适的工具”,就把数据分散到七栋楼里。这种建议能卖数据库,但未必对你有利。
先从 Postgres 开始。能一直用 Postgres,就一直用。只有在你真正证明自己需要它时,再把复杂性加进去。
都 2026 年了,直接用 Postgres 吧。
这些扩展都可以在 Tiger Data 上使用。几分钟就能创建一个免费数据库:
psql "postgresql://user:pass@your-instance.tsdb.cloud.timescale.com:5432/tsdb"
CREATE EXTENSION pg_textsearch; -- BM25 搜索
CREATE EXTENSION vector; -- 向量检索
不需要专用数据库,直接用 Postgres 就行。