外国专家说PG 18 AI能力不行，到底行不行？-优快云博客

❝
开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3300人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群近400 9群 200+，开10群PolarDB专业学习群100+)

起因

在这篇文章中有这么一段，

不过，PostgreSQL 仍有一个致命弱点 —— 它在在线分析处理（OLAP）上表现不佳，这妨碍了其在 AI 时代的应用。随着企业日益采用混合事务/分析处理（HTAP）架构来支持 AI 工作负载（特别是 Agentic AI），这一短板逐渐放大。

Percona 技术布道师 Alastair Turner 表示：

“PostgreSQL 18 中没有任何专门针对分析和 AI 工作负载的功能。”

但这篇文章并未说明，他提出这个观点的原因，只是说明PG18在AI上不值得期待的这样的一条结论。

如果看完这篇文章后，我反问一句。

pgvector扩展是否是AI在PG上的功能，pgvector用于在 Postgres 中存储、索引和查询高维向量（embeddings），支持多种距离度量（L2, inner product, cosine 等）以及近似最近邻（ANN）索引，如 HNSW.向量检索是许多 AI 部署（如语义搜索、推荐系统、聊天机器人 / RAG 检索等）的核心需求。PG + pgvector 允许将向量数据和业务关系型数据保存在同一个系统中，省去了很多复杂的数据同步/迁移。

在最新版本（如 pgvector 0.8.0）在过滤条件（WHERE + 启用索引）情况下的估算、迭代扫描（iterative scans）、对 HNSW / IVFFlat 索引插入 /构建 /扫描的性能改进。使得向量查询在实际、带条件过滤的业务环境中，性能更可用，响应时间与资源消耗更可控。

然后我们就得出PG18在AI方面不值得期待。

我们是不是首先要分析一下，AI数据库的特征，商业AI 数据的一些特征，我们也梳理一下

AI 数据库专注于向量数据库 / AI 检索，核心任务是高效相似度搜索、语义检索、RAG 支撑，原生向量存储 + ANN 索引，通常支持稠密向量和稀疏向量（Hybrid Search）专业化 ANN（HNSW、IVF、PQ、DiskANN 等），对亿级以上向量优化，分布式架构，原生支持语义+元数据+全文搜索，优化较好，分布式原生架构，支持水平扩展到数百节点，与 LLM 框架（LangChain、LlamaIndex）、AI 推理平台、云 AI 服务深度绑定，一般只保证弱事务或最终一致，优化检索 > 强事务。

总结：AI数据库是为AI而生的，AI数据库一部分商业的数据库是通过分布式来分解计算压力，同时在事务本身方面，并不支持一个强事务的模型，这些商业的AI数据库只支持向量的查询，连OLAP的支持能力都不是他们的能力所及。

OK，说问题，讲事实，咱们得对比，弄清楚不值得期待到底是为什么。

在梳理清楚后，我明白了这位国外的专家的“不值得”是什么？

1 抱怨PG18 没有在新的版本上增强AI的能力，也就是刚才提到的AI数据库的标签。

2 抱怨，PG18没有对AI的性能进行优化。

这里我就想进行一个问题的说明

PG的主要的在PG18的更改部分是什么，或者PG18的版本升级的重点是什么。

PG18主要是改进，本身OLTP性能的问题，通过了Linux 接口 io_uring 使用异步 I/O 将显著改善 IO 性能，降低延迟。这对 OLTP 来说是重大利好，尤其是在使用网络附加存储的环境中，效果会更好。“异步 IO 允许数据库工作进程在不必等待之前 IO 完成的情况下，发起多个 IO 指令，从而避免了阻塞。这显著提高了处理效率。”

以上也是这个专家所提出的，PG18主要改进的对象。同时PG18还对企业一直对PG不满意的企业数据库安全的部分进行了改造，引入了OAuth.

所以个人认为,PG18的重点还是将PG作为一个综合性的数据库产品来进行打造，并不是让他完全去占领 AI 数据库的市场。如果将PG向AI数据库倾斜，会导致PG数据库的综合能力的人设打破。

PG作为一个六边形战士，讲究的是综合的能力，而非是他是AI顶尖的数据库，他是OLAP顶尖的数据库，PG的人设是一个什么都可以的，什么都兼容，符合大部分应用场景的数据库产品，如果对某一个业务场景有极端的要求，应该去求助为某个场景极端打造的数据库，或PG的插件，而非指责 PG数据库本身没有满足自己的要求，这就如同买了 PostgreSQL 一辆多功能运动SUV，你非要他有 F1的加速能力一样，显得有点 “吹毛求疵”。