为什么PG将主宰AI时代的数据库

Agent 时代，软件架构的底层逻辑变了。

过去十年，我们为了迁就人类团队的协作边界，搞出了微服务和“多元持久化”（Polyglot Persistence），把系统拆得七零八落。但在 AI Agent 崛起的新范式下，这种碎片化架构正在成为一种昂贵的“技术负债”。

最稀缺的资源不再是存储或算力，而是 LLM 的注意力带宽（Context Window）。

微服务带来的复杂度与碎片化，正在向 AI Agent 征收巨额的“认知税”。而这剂毒药的解药，只有 PostgreSQL。本文就来聊聊，为什么 PG 会成为 AI 时代的“数据库之王”。

—— 老冯在 “第八届中国 PG 生态大会” 上的闪电演讲

多元持久化：碎片化的认知噩梦
#

在传统的“最佳实践”中，我们习惯把数据拆得支离破碎：MySQL 存交易，Redis 做缓存，Mongo 存文档，Elasticsearch 搞搜索，Milvus 存向量。

这种设计理念被称作“多元持久化”（Polyglot Persistence） —— 在单个系统中使用多种数据存储技术，以满足不同的数据存储需求

看上去 “用专业的工具做专业的事”很美好，然而这为 AI Agent （以及人类工程师）带来了一个高度对抗性的环境。 Agent 主要在上下文窗口的边界内运作，这个有限的缓冲区——无论是 8k、128k 还是 1M Token——就是 Agent 的全部：短期记忆、工作草稿、接口定义，全部挤在这里。

想象一个典型的跨域查询任务：“找出购买了 X 商品并访问过 Y 页面，且工单情绪负面的用户”。在多元持久化架构下，Agent 必须经历一场“由于数据孤岛导致的消耗战”：

加载驱动与 Schema（烧钱）：Agent 必须把 MongoDB 的语法、ES 的 DSL、Neo4j 的 Cypher，以及各端的 Schema 定义统统塞进上下文。每一个用于解释 API 的 Token，都是从核心推理能力中窃取的资源。
编写胶水代码（高危）：Agent 被迫充当“分布式调度器”，编写 Python 代码去连接三个不同的系统，处理网络超时、认证失败和版本不匹配。
应用层 Join（低效）：数据在不同系统间搬运，Agent 被迫在有限的内存里做数据清洗和连接。

这种“乒乓（Ping-Pong）”架构不仅效率低下，更会导致上下文过载。将所有工具定义塞进一个巨型 Agent 会迅速耗尽预算，当无关的 Schema 和中间数据填满窗口，LLM 的推理能力会被锁死天花板，直接导致“幻觉”飙升。

上下文经济学偏爱“小而美”的工具，厌恶庞杂的异构系统。

PostgreSQL：零胶水架构
#

解药是什么？是大一统。

我们需要一个能在一个连接、一种方言里解决所有问题的“数据操作系统”。PostgreSQL 凭借其独步天下的扩展性（Extensibility），早已超越了关系型数据库的范畴，进化为全能的数据平台。

PG 的哲学很简单：把复杂性下推（Push-down）到数据库内核，让 Agent 保持轻量。

全栈数据融合：三位一体
#

PG 的扩展生态系统有效吸收了专用系统的能力：

在 PG 生态中，你不需要为了一个新特性去引入一个新的数据库组件：

领域	扩展	替代对象
向量搜索	pgvector, pgvectorscale, vchord	Milvus, Pinecone, Weaviate
全文检索	pg_search, pgroonga, zhparser, vchord_bm25	Elasticsearch
时序数据	TimescaleDB	InfluxDB, TDengine
地理空间	PostGIS	专用 GIS 数据库
文档存储	jsonb + GIN 索引	MongoDB
消息队列	pgq, pgmq	Kafka
缓存	spat, pgmemched, redis_fdw, unlogged table	Redis
数据湖仓	pg_duckdb, pg_mooncake, pg_parquet, pg_lake	ClickHouse，StarRocks

对 Agent 而言，这意味着语义宇宙的统一。它不需要在 SQL、DSL 和 API 之间精神分裂。

更重要的是**混合检索（Hybrid Search）**的民主化。你可以在一条 SQL 中，同时完成精准过滤、全文关键词检索和向量语义检索。这不是三个系统的拼凑，而是一个引擎内部算子的优雅流水线。

把数据逻辑收敛到单一的、符合 ACID 的 PostgreSQL 引擎中，Agent 不需要关心分布式事务的最终一致性，不需要处理跨服务的数据竞争。事务要么提交，要么回滚。这种确定性让 Agent 能将数据层视为一个可靠的原子原语（Primitive），而不是一个充满不确定性的分布式混沌系统。

FDW：零胶水架构与位置透明
#

如果你确实有外部数据需要访问，又怎么办呢？PG 的外部数据包装器（FDW）是 Agent 的“上帝视角”。

通过 FDW，Postgres 可以挂载万物：DuckDB、MySQL、Redis、Kafka、S3 上的 CSV，甚至是 Stripe 的 API 或系统监控指标。

对于 Agent，这实现了完美的位置透明性（Location Transparency）。 Agent 只需要执行 SELECT * FROM sales_data。它不知道，也不需要知道这份数据到底是躺在 S3 冷存储里，还是在 Snowflake 的数仓里。PG 负责了所有的协议转换和数据搬运。

这就是“零胶水”架构的终极形态：Agent 不再需要写几百行 Python 代码来做 ETL，它只需要发送一段高密度的 SQL 指令，声明自己想要的东西。

存储过程：服务器端工具箱
#

PostgreSQL 支持用 Python、JavaScript、Rust 等二十多种语言编写存储过程。这不仅是功能，更是架构上的降维打击：

Token 节省：复杂的业务逻辑（RAG 流程、数据清洗）固化在数据库函数中，不再占用宝贵的 Prompt 空间。
安全性与沙箱：Agent 调用的是封装好的函数（Tool），而不是裸奔的 SQL，权限边界清晰可控。
性能：逻辑贴着数据跑，消除了网络 IO 开销 —— 通常是最大的性能瓶颈

接口标准化：psql 即 IDE
#

PG 的 SQL 方言，libpq PG线缆协议几乎是所有 LLM 训练数据中都覆盖的知识。GPT-4 和 Claude 对写 PG 风格的 SQL 驾轻就熟。

通过在 Postgres 上标准化，我们为 Agent 提供了一个确定性的环境。你甚至不需要 MCP，pymongo、redis-py、neo4j-driver 这些驱动都可以扔掉了。命令行里的一个 psql + 连接串就可以开始工作，接口定义简化为一行： postgresql://user:password@hostname:5432/db

仅凭这一个连接，Agent 就能利用 pg_net / pg_curl 联网，利用 FDW 读写万物，利用 SQL 编排逻辑。甚至是执行 Shell 命令。

psql 提供 Bash 的功能超集，天然适合成为 AI Agent 的下一个首选执行环境。