首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >都 2026 年了,直接用 Postgres 吧(译)

都 2026 年了,直接用 Postgres 吧(译)

作者头像
JanYork_简昀
发布2026-03-30 17:18:26
发布2026-03-30 17:18:26
1910
举报

原文:https://www.tigerdata.com/blog/its-2026-just-use-postgres

作者:Raja Rao DV

把数据库想成你的房子。

房子里有客厅、卧室、卫生间、厨房和车库。

每个房间各有用途,但都在同一屋檐下,由走廊和门连在一起。

你不会因为要做饭就单独盖一栋餐厅,也不会因为要停车就在城另一头修一个商业车库。

Postgres 就是这样。

一栋房子,很多房间。搜索、向量、时序、队列,全都在同一个屋檐下。

但这恰恰是那些专用数据库厂商最不想让你听到的话。

多年来,他们的营销团队一直在向你灌输一句话:“为合适的工作选择合适的工具。”

这话听上去很合理,也很明智,而且确实卖出了很多数据库。

下面我想说明,为什么这其实是个陷阱,以及为什么在 99% 的场景里,Postgres 才是更好的选择。

“为合适的工作选择合适的工具”的陷阱

你肯定听过这句建议:“为合适的工作选择合适的工具。”

听起来很有道理。于是你的系统就变成了这样:

  1. Elasticsearch 做搜索
  2. Pinecone 做向量
  3. Redis 做缓存
  4. MongoDB 做文档
  5. Kafka 做队列
  6. InfluxDB 做时序
  7. PostgreSQL 负责……剩下的那些东西

恭喜你。

现在你要维护七套数据库,学习七种查询语言,维护七套备份策略,审计七种安全模型,轮换一堆凭证,盯着七个监控面板,还得提防七套系统都可能在凌晨 3 点掉链子。

而一旦真出问题了?

祝你好运,先把测试环境拉起来再说。

换个思路:直接用 Postgres。

为什么这件事在当下更重要:AI 时代

这已经不只是简化系统的问题。AI 智能体的出现,让数据库摊子铺得太大这件事彻底成了噩梦。

想想智能体需要做什么:

  • 快速拉起一个带生产数据的测试数据库
  • 尝试修复或做实验
  • 验证是否生效
  • 用完就销毁

如果你只有一个数据库?一条命令就够了。fork 一个副本出来,测完就销毁。

如果你有七个数据库?那你就得:

  • 协调 Postgres、Elasticsearch、Pinecone、Redis、MongoDB、Kafka 等系统的快照
  • 确保它们都落在同一个时间点上
  • 拉起七种不同的服务
  • 配置七条不同的连接串
  • 祈祷测试过程中不会发生漂移
  • 结束后再把这七套服务全部清掉

没有大量研发投入,这几乎做不到。

而且这还不只是智能体的问题。

每次凌晨 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 年起就是行业标准

这些不是缩水版替代品。

它们用的是相同甚至更好的算法,经过长期实战验证,开源,而且很多时候还出自同一批研究者之手。

基准测试也支持这一点:

  • pgvectorscale:在成本低 75% 的前提下,延迟比 Pinecone 低 28 倍
  • TimescaleDB:在提供完整 SQL 的同时,性能与 InfluxDB 持平甚至更好
  • pg_textsearch:提供了与 Elasticsearch 相同的 BM25 排名算法

隐性成本会越滚越大

除了 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 小时。系统越多,故障模式就越多。

现代 Postgres 技术栈

这些扩展并不新,很多都已经在生产环境稳定使用多年:

  • PostGIS:自 2001 年起(24 年)。支撑 OpenStreetMap 和 Uber。
  • 全文检索:自 2008 年起(17 年)。直接内置在 Postgres 核心中。
  • JSONB:自 2014 年起(11 年)。速度可与 MongoDB 相当,同时保留 ACID。
  • TimescaleDB:自 2017 年起(8 年)。GitHub 21K+ Stars。
  • pgvector:自 2021 年起(4 年)。GitHub 19K+ Stars。

已有 48,000 多家公司使用 PostgreSQL,包括 Netflix、Spotify、Uber、Reddit、Instagram 和 Discord。

AI 时代的新扩展

扩展

替代对象

亮点

pgvectorscale

Pinecone、Qdrant

DiskANN 算法。延迟低 28 倍,成本低 75%。

pg_textsearch

Elasticsearch

在 Postgres 内原生提供真正的 BM25 排名。

pgai

外部 AI 流水线

数据变更时自动同步 embeddings。

这意味着什么? 过去做一个 RAG 应用,往往需要 Postgres + Pinecone + Elasticsearch + 一堆胶水代码。

现在呢?

只要 Postgres。

一个数据库,一种查询语言,一套备份策略。你的 AI 智能体一条命令就能 fork 出测试环境。

快速开始:装上这些扩展

你真正需要的只有这些:

代码语言:javascript
复制
-- 使用 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;

就这些。

直接看代码

下面按场景给出可用示例,需要什么看什么。

全文检索(替代 Elasticsearch)

扩展:pg_textsearch(真正的 BM25 排序)

你要替代的是:

  • Elasticsearch:单独的 JVM 集群、复杂的 mappings、同步流水线、Java 堆调优
  • Solr:本质上也是同一类故事,只是换了个壳
  • Algolia:每 1000 次搜索 1 美元,还依赖外部 API

你得到的是:与 Elasticsearch 相同的 BM25 算法,直接运行在 Postgres 里。

代码语言:javascript
复制
-- 创建表
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;

混合检索:一条查询里同时做 BM25 + 向量

代码语言:javascript
复制
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 算法(来自 Microsoft Research),在 99% 召回率下,p95 延迟比 Pinecone 低 28 倍,吞吐高 16 倍

代码语言:javascript
复制
-- 启用扩展
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:

代码语言:javascript
复制
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 点的告警。

时序数据(替代 InfluxDB)

扩展:TimescaleDB(GitHub 21K+ Stars)

你要替代的是:

  • InfluxDB:单独的数据库、Flux 查询语言或并不原生的 SQL、SQL 支持有限
  • Prometheus:很适合指标监控,但不适合作为你的业务数据存储

你得到的是:自动时间分区、最高 90% 的压缩率、连续聚合,以及完整 SQL。

代码语言:javascript
复制
-- 启用 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');

缓存(替代 Redis)

能力: UNLOGGED 表 + JSONB

代码语言:javascript
复制
-- 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();

消息队列(替代 Kafka)

扩展: pgmq

代码语言:javascript
复制
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 模式:

代码语言:javascript
复制
CREATE TABLE jobs (
idSERIAL PRIMARY KEY,
  payload JSONB,
statusTEXTDEFAULT'pending'
);

-- Worker 以原子方式领取任务
UPDATE jobs SETstatus = 'processing'
WHEREid = (
SELECTidFROM jobs WHEREstatus = 'pending'
FORUPDATESKIPLOCKEDLIMIT1
) RETURNING *;

文档数据(替代 MongoDB)

能力: 原生 JSONB

代码语言:javascript
复制
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'));

地理空间(替代专用 GIS)

扩展: PostGIS

代码语言:javascript
复制
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);

定时任务(替代 Cron)

扩展: pg_cron

代码语言:javascript
复制
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 应用,你经常既需要关键词检索,也需要语义检索:

代码语言:javascript
复制
-- 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 内置)

代码语言:javascript
复制
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

代码语言:javascript
复制
-- 找出某个经理名下的所有下属(组织架构)
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 上使用。几分钟就能创建一个免费数据库:

代码语言:javascript
复制
psql "postgresql://user:pass@your-instance.tsdb.cloud.timescale.com:5432/tsdb"
代码语言:javascript
复制
CREATE EXTENSION pg_textsearch;  -- BM25 搜索
CREATE EXTENSION vector;         -- 向量检索

不需要专用数据库,直接用 Postgres 就行。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2026-03-13,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 木有枝枝 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • “为合适的工作选择合适的工具”的陷阱
  • 为什么这件事在当下更重要:AI 时代
  • “但专用数据库不是更强吗?”
  • 隐性成本会越滚越大
  • 现代 Postgres 技术栈
    • AI 时代的新扩展
  • 快速开始:装上这些扩展
  • 直接看代码
    • 全文检索(替代 Elasticsearch)
    • 混合检索:一条查询里同时做 BM25 + 向量
    • 向量检索(替代 Pinecone)
    • 时序数据(替代 InfluxDB)
    • 缓存(替代 Redis)
    • 消息队列(替代 Kafka)
    • 文档数据(替代 MongoDB)
    • 地理空间(替代专用 GIS)
    • 定时任务(替代 Cron)
    • 混合检索(BM25 + 向量)
    • 模糊搜索(容忍拼写错误)
    • 图遍历(替代图数据库)
  • 结论
  • 开始上手
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档