
可以把数据库想象成你的家:家中设有客厅、卧室、浴室、厨房与车库,各个空间各司其职,却又同处一屋檐之下,由走廊与房门彼此连通。你不会因为需要烹饪,就专门修建一座独立餐厅;也不会为了停放车辆,特意在城市的另一端建一个商用停车场。
这正是PostgreSQL的设计理念:一座居所,内设多间功能室。全文检索、向量存储、时序数据、消息队列等能力,皆集成于同一数据库体系之中。
而这恰恰是各类专用数据库厂商不愿让你知道的真相。多年来,他们的营销团队始终向市场灌输 “用合适的工具处理合适的场景”这一理念。这听起来合情合理,颇具远见,而且确实能卖出很多数据库产品。
接下来我将为你说明,为什么这个理念实则是一种陷阱,以及为何在99%的场景下,PostgreSQL都是更好的选择。
一、“使用正确的工具”陷阱
你一定听过这样的建议:“用合适的工具处理合适的场景”。
听起来很有道理,于是你的技术栈变成了:
Elasticsearch做检索
Pinecone存向量
Redis做缓存
MongoDB存文档
Kafka做消息队列
InfluxDB存时序数据
而PostgreSQL,就用来处理剩下的零散事务
如此一来,你就要维护七套数据库,学习七种查询语言,制定七套备份方案,审计七套安全模型,定期轮换六套凭证,盯守七张监控面板,还要应对七处可能在凌晨三点突然故障的隐患。
而一旦真的出现问题,想要搭建测试环境进行排查调试,更是难上加难。
不妨换一种思路:只用PostgreSQL即可。
二、为什么在人工智能时代至关重要
这不仅关乎简洁高效,在AI智能体的应用场景下,数据库泛滥已经成为一场灾难。
试想一下智能体所需完成的工作:
快速基于生产数据搭建测试数据库
尝试修复方案或开展试验
验证方案是否有效
完成后销毁环境
如果只使用一套数据库?只需一条指令即可完成:克隆、测试、结束。
可如果同时维护七套数据库,你就必须完成以下工作:
对PostgreSQL、Elasticsearch、Pinecone、Redis、MongoDB以及Kafka分别协调数据快照
确保所有数据处于同一时间节点
启动七个不同的服务实例
配置七条各不相同的连接字符串
在测试过程中还要祈祷数据不会出现偏差
最后再逐一关停这七套服务
如果没有大量的研发投入,这几乎是不可能的。
而且问题不仅限于智能体场景。每当凌晨三点系统出现故障,你都需要搭建测试环境进行排查。面对多套数据库,数据同步与协调堪称一场噩梦。而依托单一数据库,仅需一条指令便能完成。
在AI时代,简洁不仅是优雅的设计追求,更是必不可少的核心要求。
三、“但是专业数据库更好!”
我们来直面这个问题。
误区:专业数据库在各自领域上碾压其它数据库。
现实:这类专业数据库或许在某一细分领域略胜一筹,却也随之带来了不必要的复杂性。这就好比每餐都聘请一位私人厨师,听起来很奢侈,但实际上增加了开销和协调成本,还会出现原本不存在的新问题。
事实:99% 的企业根本不需要这类数据库。只有头部那 1% 拥有数千万用户、并配备相应规模研发团队的巨头公司才用得上。你或许读过他们的技术博客,夸赞某专用数据库表现多么出色,但那是适配他们的业务规模、团队配置与实际问题的方案。对于绝大多数企业而言,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;
就这么简单。
七、代码示例
以下是每个场景的示例,可按需跳转。
扩展: 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;
SELECTtitle,-(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 即可。
扩展: 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,不用同步任务,不会出现代码漂移和凌晨三点页面崩溃的情况。
扩展: 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', time) as 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');
功能:无日志表 + 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();
扩展: 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', 30, 5);-- 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 *;
特性:原生 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'));
扩展: 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.4, 37.78)::geography) as metersFROM storesWHERE ST_DWithin(location, ST_MakePoint(-122.4, 37.78)::geography, 5000);
扩展: 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$$);
对于人工智能应用,通常需要同时使用关键词搜索和语义搜索:
-- Reciprocal Rank Fusion: combine keyword + semantic searchWITH bm25 AS (SELECT id, ROW_NUMBER() OVER (ORDER BY content <@> $1) as rankFROM documents LIMIT 20),vectors AS (SELECT id, ROW_NUMBER() OVER (ORDER BY embedding <=> $2) as rankFROM 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中:仅需一条查询,一个事务,一个结果。
扩展: 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;
特性:递归CTE
-- Find all reports under a manager (org chart)WITH RECURSIVE org_tree AS (SELECT id, name, manager_id, 1 as depthFROM employees WHERE id = 42UNION ALLSELECT e.id, e.name, e.manager_id, t.depth + 1FROM employees eJOIN org_tree t ON e.manager_id = t.idWHERE 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能担此任吗?欢迎评论区讨论~
活动推荐
5月22日,2026 XCOPS 智能运维管理人年会「广州站」重磅来袭!聚焦大模型迭代、AI Agent 深度应用等技术热点,邀请一众行业领军人物、技术大咖,从技术架构、实战案例到科研成果,与大家一起探索AI应用于智能运维与数据库的最佳方式,共同破解垂类智能体落地、多Agent协同、数据库自治技术工程化、核心系统信创与智能化平衡等现实难题。
扫描下方二维码即可报名:
如果字段的最大可能长度超过255字节,那么长度值可能…
只能说作者太用心了,优秀
感谢详解
一般干个7-8年(即30岁左右),能做到年入40w-50w;有…
230721