为何说99%的场景下,PostgreSQL都是更好的选择?

Raja Rao DV 2026-04-27 10:56:39

 

可以把数据库想象成你的家:家中设有客厅、卧室、浴室、厨房与车库,各个空间各司其职,却又同处一屋檐之下,由走廊与房门彼此连通。你不会因为需要烹饪,就专门修建一座独立餐厅;也不会为了停放车辆,特意在城市的另一端建一个商用停车场。

 

这正是PostgreSQL的设计理念:一座居所,内设多间功能室。全文检索、向量存储、时序数据、消息队列等能力,皆集成于同一数据库体系之中。

 

而这恰恰是各类专用数据库厂商不愿让你知道的真相。多年来,他们的营销团队始终向市场灌输 “用合适的工具处理合适的场景”这一理念。这听起来合情合理,颇具远见,而且确实能卖出很多数据库产品。

 

接下来我将为你说明,为什么这个理念实则是一种陷阱,以及为何在99%的场景下,PostgreSQL都是更好的选择。

 

一、“使用正确的工具”陷阱

 

你一定听过这样的建议:“用合适的工具处理合适的场景”。

 

听起来很有道理,于是你的技术栈变成了: 

 

  • Elasticsearch做检索

  • Pinecone存向量

  • Redis做缓存

  • MongoDB存文档

  • Kafka做消息队列

  • InfluxDB存时序数据

  • PostgreSQL,就用来处理剩下的零散事务

 

如此一来,你就要维护七套数据库,学习七种查询语言,制定七套备份方案,审计七套安全模型,定期轮换六套凭证,盯守七张监控面板,还要应对七处可能在凌晨三点突然故障的隐患。

 

而一旦真的出现问题,想要搭建测试环境进行排查调试,更是难上加难。

 

不妨换一种思路:只用PostgreSQL即可。

 

二、为什么在人工智能时代至关重要

 

这不仅关乎简洁高效,在AI智能体的应用场景下,数据库泛滥已经成为一场灾难。

 

试想一下智能体所需完成的工作:

 

  • 快速基于生产数据搭建测试数据库

  • 尝试修复方案或开展试验

  • 验证方案是否有效

  • 完成后销毁环境

 

如果只使用一套数据库?只需一条指令即可完成:克隆、测试、结束。

 

可如果同时维护七套数据库,你就必须完成以下工作: 

 

  • 对PostgreSQL、Elasticsearch、Pinecone、Redis、MongoDB以及Kafka分别协调数据快照

  • 确保所有数据处于同一时间节点

  • 启动七个不同的服务实例

  • 配置七条各不相同的连接字符串

  • 在测试过程中还要祈祷数据不会出现偏差

  • 最后再逐一关停这七套服务

 

如果没有大量的研发投入,这几乎是不可能的。

 

而且问题不仅限于智能体场景。每当凌晨三点系统出现故障,你都需要搭建测试环境进行排查。面对多套数据库,数据同步与协调堪称一场噩梦。而依托单一数据库,仅需一条指令便能完成。

 

在AI时代,简洁不仅是优雅的设计追求,更是必不可少的核心要求。

 

三、“但是专业数据库更好!”

 

我们来直面这个问题。

 

误区:专业数据库在各自领域上碾压其它数据库。

 

现实:这类专业数据库或许在某一细分领域略胜一筹,却也随之带来了不必要的复杂性。这就好比每餐都聘请一位私人厨师,听起来很奢侈,但实际上增加了开销和协调成本,还会出现原本不存在的新问题。

 

事实:99% 的企业根本不需要这类数据库。只有头部那 1% 拥有数千万用户、并配备相应规模研发团队的巨头公司才用得上。你或许读过他们的技术博客,夸赞某专用数据库表现多么出色,但那是适配他们的业务规模、团队配置与实际问题的方案。对于绝大多数企业而言,Postgres 早已绰绰有余。

 

大多数人没有意识到的是:在许多场景下,Postgres 扩展所采用的算法,与专用数据库相比不相上下,甚至更出色。

 

所谓专用数据库的溢价,很多时候只是营销噱头。

 

你需要什么
专用工具
Postgres 扩展
相同的算法?

全文检索

Elasticsearch

pg_textsearch

✅ 两者都使用 BM25

向量搜索

松果

pgvector + pgvectorscale

✅ 两者都使用 HNSW/DiskANN

时间序列

InfluxDB

TimescaleDB

✅两者都使用时间分区

缓存

Redis

无日志表

✅ 两者都使用内存存储

文件

MongoDB

JSONB

✅两者都使用文档索引

地理空间

专业地理信息系统

PostGIS

✅ 自2001年以来一直是行业标准

 

这些并非功能精简的简化版本,它们采用的是同等甚至更优的算法,经过实战检验且开源免费,其开发者往往也与专用数据库的研究人员同源。

 

相关性能测试数据也印证了这一点:

 

  • pgvectorscale:延迟比Pinecone低28倍,成本低 75%。

  • TimescaleDB:性能持平甚至超越InfluxDB,同时提供完整的SQL功能 

  • pg_textsearch :采用与Elasticsearch完全一致的BM25相关性排序算法

 

四、隐性成本累积起来会很高

 

除了人工智能与智能体场景带来的问题外,数据库滥用还会产生叠加式的成本损耗:

 

任务
一个数据库
七个数据库

备用策略

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%。这意味着每年停机时间会从8.7小时增至26小时。每新增一套系统,故障风险便会成倍放大。

 

五、现代 PostgreSQL 技术栈

 

这些扩展程序并非新鲜事物,它们早已成熟并稳定应用于生产环境多年:

 

  • PostGIS:自2001年起(至今24年),为 OpenStreetMap 和 Uber 提供支持。

  • 全文检索:自2008年起(至今17年),已内置于 Postgres 核心库中。

  • 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。

 

人工智能时代的扩展

 

人工智能时代带来了新一代:

 

扩大
替换
精彩片段

pgvectorscale

Pinecone ,Qdrant

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

pg_textsearch

Elasticsearch

Postgres 中原生支持真正的 BM25 排名。

pgai

外部人工智能管道

数据更改时自动同步嵌入内容。

 

这意味着过去构建一款RAG应用需要Postgres、Pinecone、Elasticsearch,并编写大量粘合代码才能实现。

 

现在呢?只需Postgres即可。一个数据库,一种查询语言,一次备份,一条fork命令,就能让你的AI智能体创建一个测试环境。

 

六、快速入门:添加这些扩展程序

 

你需准备:

 

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
-- Full-text search with BM25CREATE EXTENSION pg_textsearch;
-- Vector search for AICREATE EXTENSION vector;CREATE EXTENSION vectorscale;
-- AI embeddings & RAG workflowsCREATE EXTENSION ai;
-- Time-seriesCREATE EXTENSION timescaledb;
-- Message queuesCREATE EXTENSION pgmq;
-- Scheduled jobsCREATE EXTENSION pg_cron;
-- GeospatialCREATE EXTENSION postgis;

 

就这么简单。

 

七、代码示例

 

以下是每个场景的示例,可按需跳转。

 

 
1、全文搜索(替代Elasticsearch)

 

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

 

你要替换的是: 

 

  • Elasticsearch:独立的JVM集群、复杂的映射配置、同步管道、Java堆调优 

  • Solr:换汤不换药

  • Algolia:每1000次搜索收费1美元,依赖外部API

 

你将得到:与Elasticsearch完全相同的BM25算法,直接在Postgres中运行。

 

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
-- Create tableCREATE TABLE articles (  id SERIAL PRIMARY KEY,  title TEXT,  content TEXT);
-- Create BM25 indexCREATE INDEX idx_articles_bm25 ON articles USING bm25(content)  WITH (text_config = 'english');
  -- Search with BM25 scoringSELECT title, -(content <@> 'database optimization'as scoreFROM articlesORDER BY content <@> 'database optimization'LIMIT 10;

 

 
2、混合搜索(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_scoreFROM articlesORDER BY hybrid_score DESCLIMIT 10;

 

这就是 Elasticsearch 需要单独的插件来实现此功能的原因。而在 Postgres 中,只需使用 SQL 即可。

 

 
3、向量搜索(替代Pinecone)

 

扩展: pgvector + pgvectorscale

 

你要替换的是: 

 

  • Pinecone:最低每 70 美元,独立基础设施,数据同步问题多

  • Qdrant、Milvus、Weaviate:需要管理更多基础设施

 

你将得到:pgvectorscale使用DiskANN 算法(微软研究院出品),在 99% 召回率下,其p95延迟比 Pinecone 低28倍,吞吐量比Pinecone高16倍。

 

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
-- Enable extensionsCREATE EXTENSION vector;CREATE EXTENSION vectorscale CASCADE;
-- Table with embeddingsCREATE TABLE documents (  id SERIAL PRIMARY KEY,  content TEXT,  embedding vector(1536));
-- High-performance index (DiskANN)CREATE INDEX idx_docs_embedding ON documents USING diskann(embedding);
-- Find similar documentsSELECT content, embedding <=> '[0.1, 0.2, ...]'::vector as distanceFROM documentsORDER BY embedding <=> '[0.1, 0.2, ...]'::vectorLIMIT 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'));

 

现在每次插入和更新操作都会自动重新生成embedding,不用同步任务,不会出现代码漂移和凌晨三点页面崩溃的情况。

 

 
4、时序数据(替换InfluxDB)

 

扩展: TimescaleDB(GitHub 上超过21K个星标)

 

你要替换的是: 

 

  • InfluxDB:独立数据库,需使用Flux查询语言或非原生SQL,SQL支持有限

  • Prometheus:适用于指标监控,却不适合存储业务应用数据

 

你将得到:自动时序分区、最高 90% 的数据压缩率、持续聚合能力,以及完整的SQL支持。

 

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
-- Enable TimescaleDBCREATE EXTENSION timescaledb;
-- Create tableCREATE TABLE metrics (  time TIMESTAMPTZ NOT NULL,  device_id TEXT,  temperature DOUBLE PRECISION);
-- Convert to hypertableSELECT create_hypertable('metrics''time');
-- Query with time bucketsSELECT time_bucket('1 hour'timeas hour,       AVG(temperature)
       FROM metricsWHERE time > NOW() - INTERVAL '24 hours'GROUP BY hour;
-- Auto-delete old dataSELECT add_retention_policy('metrics'INTERVAL '30 days');
-- Compression (90% storage reduction)ALTER TABLE metrics SET (timescaledb.compress);SELECT add_compression_policy('metrics'INTERVAL '7 days');

 

 
5、缓存(替代Redis)

 

功能:无日志表 + JSONB

 

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
-- UNLOGGED = no WAL overhead, faster writesCREATE UNLOGGED TABLE cache (  key TEXT PRIMARY KEY,  value JSONB,  expires_at TIMESTAMPTZ);
-- Set with expirationINSERT INTO cache (key, value, expires_at)VALUES ('user:123''{"name": "Alice"}', NOW() + INTERVAL '1 hour')ON CONFLICT (key) DO UPDATE SET value = EXCLUDED.value;
-- GetSELECT value FROM cache WHERE key = 'user:123' AND expires_at > NOW();
-- Cleanup (schedule with pg_cron)DELETE FROM cache WHERE expires_at < NOW();

 

 
6、消息队列(替代Kafka)

 

扩展: pgmq

 

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
CREATE EXTENSION pgmq;SELECT pgmq.create('my_queue');
-- SendSELECT pgmq.send('my_queue''{"event": "signup", "user_id": 123}');
-- Receive (with visibility timeout)SELECT * FROM pgmq.read('my_queue'305);
-- Delete after processingSELECT pgmq.delete('my_queue', msg_id);

 

或者原生SKIP LOCKED模式:

 

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
CREATE TABLE jobs (  id SERIAL PRIMARY KEY,  payload JSONB,  status TEXT DEFAULT 'pending');
-- Worker claims job atomicallyUPDATE jobs SET status = 'processing'WHERE id = (  SELECT id FROM jobs WHERE status = 'pending'  FOR UPDATE SKIP LOCKED LIMIT 1) RETURNING *;

 

 
7、文档(替代MongoDB)

 

特性:原生 JSONB

 

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
CREATE TABLE users (  id SERIAL PRIMARY KEY,  data JSONB);
-- Insert nested documentINSERT INTO users (data) VALUES ('{  "name": "Alice",  "profile": {"bio": "Developer", "links": ["github.com/alice"]}}');
-- Query nested fieldsSELECT data->>'name', data->'profile'->>'bio'FROM usersWHERE data->'profile'->>'bio' LIKE '%Developer%';
-- Index JSON fieldsCREATE INDEX idx_users_email ON users ((data->>'email'));

 

 
8、地理空间(替代专用 GIS)

 

扩展: PostGIS

 

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
CREATE EXTENSION postgis;
CREATE TABLE stores (  id SERIAL PRIMARY KEY,  name TEXT,  location GEOGRAPHY(POINT, 4326));
-- Find stores within 5kmSELECT name, ST_Distance(location, ST_MakePoint(-122.437.78)::geography) as metersFROM storesWHERE ST_DWithin(location, ST_MakePoint(-122.437.78)::geography, 5000);

 

 
9、定时任务(替代Cron)

 

扩展: pg_cron

 

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
CREATE EXTENSION pg_cron;
-- Run every hourSELECT cron.schedule('cleanup''0 * * * *'  $$DELETE FROM cache WHERE expires_at < NOW()$$);
  -- Nightly rollupSELECT cron.schedule('rollup''0 2 * * *',  $$REFRESH MATERIALIZED VIEW CONCURRENTLY daily_stats$$);

 

 
10、混合搜索(BM25 + 向量)

 

对于人工智能应用,通常需要同时使用关键词搜索和语义搜索:

 

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
-- Reciprocal Rank Fusion: combine keyword + semantic searchWITH bm25 AS (  SELECT id, ROW_NUMBER() OVER (ORDER BY content <@> $1as rank  FROM documents LIMIT 20),vectors AS (  SELECT id, ROW_NUMBER() OVER (ORDER BY embedding <=> $2as rank    FROM documents LIMIT 20)SELECT d.*  1.0/(60 + COALESCE(b.rank, 1000)) +   1.0/(60 + COALESCE(v.rank, 1000)) as scoreFROM documents dLEFT JOIN bm25 b ON d.id = b.idLEFT JOIN vectors v ON d.id = v.idWHERE b.id IS NOT NULL OR v.id IS NOT NULLORDER BY score DESC LIMIT 10;

 

试试用Elasticsearch + Pinecone实现这个功能。你需要两次API调用、结果合并、故障处理,以及双倍的延迟。

 

在Postgres中:仅需一条查询,一个事务,一个结果。

 

 
11、模糊搜索(容错纠错)

 

扩展: pg_trgm(Postgres内置)

 

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
CREATE EXTENSION pg_trgm;
CREATE INDEX idx_name_trgm ON products USING GIN (name gin_trgm_ops);
-- Finds "PostgreSQL" even with typoSELECT name FROM productsWHERE name % 'posgresql'ORDER BY similarity(name, 'posgresql'DESC;

 

 
12、图遍历(替代图数据库)

 

特性:递归CTE

 

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
-- Find all reports under a manager (org chart)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开始,坚持使用它,必要时才增加复杂性。

 

2026年,只需要用Postgres就行了。

 

你怎么看?你觉得PostgreSQL能担此任吗?欢迎评论区讨论~

 

作者丨Raja Rao DV        编译丨dbaplus社群
来源丨网址:https://www.tigerdata.com/blog/its-2026-just-use-postgres
dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn

活动推荐

5月22日,2026 XCOPS 智能运维管理人年会「广州站」重磅来袭!聚焦大模型迭代、AI Agent 深度应用等技术热点,邀请一众行业领军人物、技术大咖,从技术架构、实战案例到科研成果,与大家一起探索AI应用于智能运维与数据库的最佳方式,共同破解垂类智能体落地、多Agent协同、数据库自治技术工程化、核心系统信创与智能化平衡等现实难题。

扫描下方二维码即可报名:

最新评论
访客 2024年04月08日

如果字段的最大可能长度超过255字节,那么长度值可能…

访客 2024年03月04日

只能说作者太用心了,优秀

访客 2024年02月23日

感谢详解

访客 2024年02月20日

一般干个7-8年(即30岁左右),能做到年入40w-50w;有…

访客 2023年08月20日

230721

活动预告