翻译：2026年了，直接用 PostgreSQL 吧

翻译：2026年了，直接用 PostgreSQL 吧

以下是 It's 2026, Just Use Postgres | Tiger Data 的中文翻译

---

把你的数据库想象成你的家。家里有客厅、卧室、浴室、厨房和车库，每个房间用途不同，但都在同一屋檐下，由走廊和门相连。你不会因为需要做饭就单独盖一栋餐厅大楼，也不会为了停车而在城外另建一座商业车库。

PostgreSQL 就是这样的"家"------一个屋檐下容纳多个功能房间：搜索、向量、时序数据、队列......全部一体化。

而这恰恰是那些专用数据库厂商不愿让你知道的真相。他们的营销团队花了数年时间说服你"为不同任务选用合适的工具"。听起来很合理，很睿智，也确实卖出了大量数据库。

让我告诉你为什么这是个陷阱，以及为什么在 99% 的场景下，PostgreSQL 才是更优解。

"选用合适工具"的陷阱

你一定听过这样的建议："为不同任务选用合适的工具。"

听起来很睿智。于是你最终拥有了：

1. Elasticsearch 用于搜索
2. Pinecone 用于向量检索
3. Redis 用于缓存
4. MongoDB 用于文档存储
5. Kafka 用于消息队列
6. InfluxDB 用于时序数据
7. PostgreSQL 用于......剩下的杂项

恭喜你，现在你需要管理七个数据库。学习七种查询语言，维护七套备份策略，审计七种安全模型，轮换六组凭证，监控七个仪表盘，以及应对七个可能在凌晨三点崩溃的系统。

而当系统真的崩溃时？祝你好运------你得搭建一个包含全部七种数据库的测试环境来调试问题。

换个思路：直接用 PostgreSQL 吧。

为什么现在尤其重要：AI 时代

这不只是关于简化架构。AI 智能体已让数据库碎片化成为一场噩梦。

想想智能体需要做什么：

• 快速用生产数据搭建测试数据库
• 尝试修复或实验
• 验证效果
• 销毁环境

使用单一数据库？一条命令即可：Fork、测试、完成。

使用七个数据库？你需要：

• 协调 PostgreSQL、Elasticsearch、Pinecone、Redis、MongoDB 和 Kafka 的快照
• 确保所有数据处于同一时间点
• 启动七种不同服务
• 配置七组连接字符串
• 祈祷测试过程中数据不发生漂移
• 测试结束后销毁七种服务

没有大量研发投入，这几乎不可能实现。

这还不只是智能体的问题。每次凌晨三点系统崩溃，你都需要搭建测试环境调试。六个数据库意味着协调噩梦；一个数据库，只需一条命令。

在 AI 时代，简洁不只是优雅，更是必需。

"但专用数据库性能更好啊！"

我们直面这个问题。

迷思：专用数据库在其特定任务上远超通用方案。

现实：它们可能在狭窄场景下略占优势，但同时引入了不必要的复杂性。这就像为每顿饭都雇佣一位私人厨师------听起来奢华，实则增加成本、协调开销，并制造了本不存在的问题。

关键在于：99% 的公司根本不需要它们。那 1% 的顶级公司拥有数千万用户和与之匹配的庞大工程团队。你读过他们吹捧"专用数据库 X 如何惊艳"的博客，但那是他们的规模、他们的团队、他们的问题。对其他人而言，PostgreSQL 完全够用。

大多数人没意识到的是：PostgreSQL 扩展使用的算法与专用数据库相同甚至更优（很多情况下确实如此）。

所谓"专用数据库溢价"？大多是营销话术。

你的需求	专用工具	PostgreSQL 扩展	算法是否相同？
全文搜索	Elasticsearch	pg_textsearch	✅ 均使用 BM25
向量检索	Pinecone	pgvector + pgvectorscale	✅ 均使用 HNSW/DiskANN
时序数据	InfluxDB	TimescaleDB	✅ 均使用时间分区
缓存	Redis	UNLOGGED 表	✅ 均使用内存存储
文档	MongoDB	JSONB	✅ 均使用文档索引
地理空间	专用 GIS	PostGIS	✅ 自 2001 年起的行业标准

这些不是缩水版实现，而是相同/更优的算法，经过实战检验、开源，并常由相同研究者开发。

基准测试也证实了这一点：

• pgvectorscale：延迟比 Pinecone 低 28 倍，成本降低 75%
• TimescaleDB：性能媲美或超越 InfluxDB，同时提供完整 SQL 支持
• 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 与 PostgreSQL 同步？你需要构建同步作业。它们会失败，数据会漂移，你得添加对账逻辑。对账也会失败。最终你维护的是基础设施，而非产品功能。

SLA 数学 ：三个系统各自 99.9% 可用性 = 整体 99.7%。这意味着每年26 小时停机时间，而非 8.7 小时。每个系统都在成倍增加故障模式。

现代 PostgreSQL 技术栈

这些扩展并非新生事物，它们已生产就绪多年：

• PostGIS：自 2001 年（24 年），支撑 OpenStreetMap 和 Uber
• 全文搜索：自 2008 年（17 年），内置于 PostgreSQL 核心
• JSONB：自 2014 年（11 年），性能媲美 MongoDB 且支持 ACID
• TimescaleDB：自 2017 年（8 年），GitHub 超 2.1 万星
• pgvector：自 2021 年（4 年），GitHub 超 1.9 万星

超过 48,000 家公司使用 PostgreSQL，包括 Netflix、Spotify、Uber、Reddit、Instagram 和 Discord。

AI 时代的新一代扩展

扩展	替代方案	亮点
pgvectorscale	Pinecone, Qdrant	DiskANN 算法，延迟降低 28 倍，成本降低 75%
pg_textsearch	Elasticsearch	原生支持 BM25 排序
pgai	外部 AI 流水线	数据变更时自动同步嵌入向量

这意味着什么：过去构建 RAG 应用需要 PostgreSQL + Pinecone + Elasticsearch + 胶水代码。

现在？只需 PostgreSQL。一个数据库，一种查询语言，一套备份方案，一条 Fork 命令即可让 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：$1/1000 次搜索，依赖外部 API

你将获得：与 Elasticsearch 完全相同的 BM25 算法，直接内置于 PostgreSQL。

-- 创建表
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 需要额外插件才能实现的功能，在 PostgreSQL 中只需一条 SQL。

向量检索（替代 Pinecone）

扩展：pgvector + pgvectorscale

替代对象：

• Pinecone：$70/月起步，独立基础设施，数据同步头痛
• Qdrant, Milvus, Weaviate：更多需管理的基础设施

你将获得：pgvectorscale 采用微软研究院的 DiskANN 算法 ，在 99% 召回率下实现延迟降低 28 倍、吞吐量提升 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 都会自动重新生成嵌入向量。无需同步作业，无数据漂移，告别凌晨三点的告警电话。

时序数据（替代 InfluxDB）

扩展：TimescaleDB（GitHub 2.1 万+ 星）

替代对象：

• InfluxDB：独立数据库、Flux 查询语言或非原生 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'
);

-- Worker 原子性认领任务
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()$$);

-- 每日凌晨 2 点汇总
SELECT cron.schedule('rollup', '0 2 * * *',
  $$REFRESH MATERIALIZED VIEW CONCURRENTLY daily_stats$$);

核心结论

回到"家"的比喻：你不会为做晚饭单独盖餐厅，也不会为停车在城外建车库。你会使用家中已有的房间。

这正是我们在此展示的：搜索、向量、时序、文档、队列、缓存......它们都是 PostgreSQL 这座"家"中的不同房间。使用与专用数据库相同的算法，历经多年实战检验，被 Netflix、Uber、Discord 及 48,000 多家公司采用。

那么那 1% 的例外呢？

99% 的公司，PostgreSQL 足以应对所有需求。那 1%？当你需要跨数百节点处理 PB 级日志，或必须使用 Kibana 特定仪表盘，或拥有 PostgreSQL 确实无法满足的特殊需求时。

但关键在于：当你属于那 1% 时，你自己会知道。你不需要厂商营销团队告诉你，你会通过基准测试亲自撞上真正的性能墙。

在此之前，不要因为"为不同任务选用合适工具"这句话，就把数据分散到七栋大楼中。那句建议卖出了数据库，却没为你服务。

从 PostgreSQL 开始，坚持使用 PostgreSQL。仅在真正需要时才增加复杂性。

2026 年了，直接用 PostgreSQL 吧。

立即开始

所有这些扩展在 Tiger Data 上均可使用。几分钟内创建免费数据库：

psql "postgresql://user:pass@your-instance.tsdb.cloud.timescale.com:5432/tsdb"

CREATE EXTENSION pg_textsearch;  -- BM25 搜索
CREATE EXTENSION vector;         -- 向量检索

无需专用数据库，只需 PostgreSQL。

延伸阅读

• pg_textsearch 文档
• pgvector GitHub
• pgvectorscale 文档
• TimescaleDB 文档
• pgmq 消息队列
• PostGIS 地理空间