"选对工具"是个伪命题

你一定听过这句话："为正确的工作选择正确的工具"。

乍一听很有道理。于是你的技术栈变成了：

• Elasticsearch 负责搜索
• Pinecone 负责向量检索
• Redis 负责缓存
• MongoDB 负责文档存储
• Kafka 负责消息队列
• InfluxDB 负责时序数据
• PostgreSQL 负责……兜底

恭喜你，现在你有七个数据库要维护。七种查询语言要学。七套备份策略要制定。七套安全模型要审计。六组凭证要轮换。七个监控面板要盯。还有七样东西可能在凌晨三点一起炸锅。

真要出问题了？祝你搭建测试环境排查顺利。

换个思路：直接上 Postgres

这不仅关乎简洁。AI Agent 的崛起让多数据库架构变成了噩梦。

想想 Agent 的日常操作：

• 快速启动一个带生产数据的测试环境
• 尝试某个修复或实验
• 验证效果
• 销毁环境

单数据库架构？一条命令搞定。Fork，测试，完事。

七个数据库呢？你需要：

• 协调 Postgres、Elasticsearch、Pinecone、Redis、MongoDB 和 Kafka 的快照
• 确保时间戳对齐
• 启动七个服务
• 配置七条连接串
• 祈祷测试期间数据别漂移
• 测完再销毁七个服务

没有专门的基建团队，这几乎不可能。

还不只是 Agent 的问题。每次凌晨三点出故障，你都得搭测试环境排查。六个数据库的协调简直是地狱模式。单数据库？一条命令的事。

在 AI 时代，简洁不是优雅，而是刚需。

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

我们来直面这个问题。

迷思： 专用数据库在各自领域碾压通用方案。

现实： 某些极端场景下它们确实有优势，但代价是不必要的复杂度。就像为了每顿饭请一位私人厨师——听起来很奢华，但增加了开销、协调成本，还制造了原本不存在的问题。

关键是：99% 的公司根本用不上它们。 那 1% 是拥有千万级用户和庞大工程团队的巨头。你读了他们的博客，觉得专用数据库 X 对他们很有效。但那是他们的规模、他们的团队、他们的问题。对其他人来说，Postgres 绰绰有余。

大多数人没意识到：Postgres 扩展使用的算法与专用数据库相同，甚至更好。

"专用"的溢价？大部分是营销。

需求场景对比表

这些不是阉割版。它们是相同甚至更好的算法，经过生产验证，开源，很多出自同一批研究者之手。

Benchmark 数据也能印证：

• pgvectorscale：比 Pinecone 延迟低 28 倍，成本降低 75%
• TimescaleDB：性能持平甚至更优 InfluxDB，同时支持完整 SQL
• pg_textsearch：与 Elasticsearch 底层完全一致的 BM25 排序算法

隐性成本在累积

除了开发成本，数据库碎片化带来的复合成本也非常惊人：如果使用七个数据库，那么备份与恢复、监控与告警、安全补丁、灾备演练都需要准备七份，All in PG 则只需要一份就好。

认知负担： 你的团队需要掌握 SQL、Redis 命令、Elasticsearch Query 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 年）。GitHub 21K+ star。
• pgvector：自 2021 年（4 年）。GitHub 19K+ star。

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

AI 时代的扩展

AI 浪潮催生了新一代扩展：

这意味着什么：以前构建 RAG 应用需要 Postgres + Pinecone + Elasticsearch + 胶水代码。

现在？直接 Postgres。 一个数据库。一种查询语言。一套备份。AI Agent 只需一条 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;

就这些。

代码示例

全文搜索（替代 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 p95 延迟低 28 倍、吞吐量高 16 倍。

-- 启用扩展
CREATE EXTENSION vector;
CREATE EXTENSION vectorscale CASCADE;

-- 带 embedding 的表
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 自动同步 embedding：

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。无需同步任务。没有数据漂移。不会被凌晨三点的告警叫醒。

时序数据（替代 InfluxDB）

扩展：TimescaleDB（GitHub 21K+ star）

你要替代的东西：

• InfluxDB：独立数据库，Flux 查询语言或非原生 SQL，SQL 支持有限
• Prometheus：做指标监控不错，但不适合应用数据

你得到的：自动时间分区、高达 90% 的压缩率、连续聚合。完整 SQL 支持。

-- 启用 TimescaleDB
CREATE EXTENSION timescaledb;

-- 建表
CREATE TABLE metrics (
  time TIMESTAMPTZ NOT NULL,
  device_id TEXT,
  temperature DOUBLE PRECISION
);

-- 转换为 hypertable
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

或原生 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)
);

-- 查找 5km 内的门店
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');

RAG 混合搜索

对于 AI 应用，你往往需要关键词搜索和语义搜索兼备：

-- 倒数排名融合（RRF）：结合关键词搜索 + 语义搜索
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%。 不需要厂商的市场团队来告诉你。你自己会跑过 benchmark，碰到真正的瓶颈。

在那之前，不要因为有人告诉你"为正确的工作选择正确的工具"就把数据散落在七栋楼里。 那句话卖的是数据库，不是为你服务的。

从 Postgres 开始。留在 Postgres。只在真正需要时才引入复杂度。2026 年了，用 Postgres 就够了。

参考链接

• Pinecone alternatives
• You don't need Elasticsearch: BM25 is now in Postgres
• PostGIS History
• PostgreSQL History
• PostgreSQL Customers List
• pgvectorscale
• pg_textsearch
• pgai
• TimescaleDB
• pgvector
• I Replaced Redis with PostgreSQL (And It's Faster)