数据库管理员的新考题：当PG遇上向量和AI

做了几年DBA，我早已习惯了和数据字典、执行计划、索引优化、备份恢复打交道。每天的工作围绕着如何让数据库跑得更快、更稳、更安全。直到去年开始，陆续有研发同事来问我："咱们的PG能存向量吗？""这个AI应用要用的pgvector扩展，你帮我装一下？""Embedding是什么？这个数据类型怎么建索引？"

这些问题让我意识到，数据库的世界正在发生一场缓慢但确定无疑的变化。传统的关系型数据依然是主流，但一种新的数据类型——向量——正在从AI应用的外围慢慢渗透到核心业务里。而一个DBA如果对这些新东西毫无准备，很可能在接下来的几年里被业务需求推着走，而不是走在业务前面。

为什么向量突然成了数据库的"必修课"

向量不是什么新鲜概念。数学课上大家都学过，一组数字的排列就是向量。但在数据库语境里，它最近两年突然火起来，唯一的驱动因素是AI大模型的普及。

大模型的核心能力之一是理解和生成，但它的记忆是有限的。当你想让大模型"记住"你的私有数据时，最主流的方式就是把文字转成向量存起来，等用户提问的时候去"语义搜索"最相关的内容。这整个过程里，向量的存储和检索就成了绕不开的环节。以前这些向量可能被存在专门的向量数据库里，但越来越多的企业希望"能在一个数据库里搞定所有事"——包括传统的关系数据和新增的向量数据。于是，PostgreSQL + pgvector的组合就成了最自然的选择：PG负责传统的ACID事务和复杂查询，pgvector扩展负责高效的向量存储和相似性检索。

DBA的角色正在被重新定义。过去你只需要懂关系模型、懂SQL优化、懂事务隔离级别。现在你需要懂向量是什么、embedding是怎么产生的、向量索引和B-tree索引有什么区别、相似性搜索的执行计划怎么看。这些知识不在传统DBA的知识体系里，但它们正在成为业务对DBA的新要求。

我亲身经历的两次"向量之痛"

第一个故事来自一个知识库问答项目。研发团队用pgvector存了上百万条文档的向量，上线之后查询性能越来越慢，原本几十毫秒的相似性搜索，后来涨到了几百毫秒，用户开始抱怨"转圈圈"。

研发找过来的时候，我第一反应是按照传统DBA的思路去排查：内存够不够？CPU有没有跑满？磁盘IO高不高？结果这些指标都正常。后来才反应过来——我根本没检查向量索引。原来研发用的是暴力搜索（精确计算所有向量和查询向量的距离），百万级别数据量下，计算量是百万次浮点运算，当然慢。解决方案是用IVFFlat或HNSW索引替代暴力搜索，用一点精度换几个数量级的性能提升。但当时我对这些索引类型毫无概念，只能连夜补课，才把问题解决。

第二个故事来自一个多模态检索项目。这个项目里既存了商品的图片向量，也存了文本描述向量，还需要做跨模态的混合检索——用户输入文字搜图片，或者输入图片搜文字。研发需要我把两种向量放在同一个表里做联合查询，同时还要关联商品的其他结构化属性（价格、类别、库存状态等）。

如果只用专门的向量数据库，这种"向量+结构化"的混合查询很难做，需要把两次查询的结果在应用层做拼装。但在PG里，向量和普通字段可以在同一个表里共存，同一个SQL里既能做向量相似性搜索，又能做价格区间过滤和类别筛选。这恰恰是PG方案相比纯向量数据库最独特的优势。为了支持这个项目，我花了大量时间学习如何设计混合查询的索引策略——既要兼顾向量的ANN索引，又要兼顾结构化字段的B-tree索引，两者的执行计划和资源消耗需要统筹考虑。这种"混合负载"的优化能力，正在成为DBA的新核心技能。

我更看好PG在AI方向的前景

在众多数据库里，我觉得PG最适合成为"AI时代的通用数据底座"，原因有两个。

第一个原因是PG的扩展生态。PG最大的特点就是"会生不会养"——核心只做最稳定的事情，把一切扩展能力交给社区。pgvector只是其中一个例子，还有pg_trgm做文本相似度、pg_stat_statements做性能监控、PostGIS做空间数据……各种扩展可以组合使用。这就意味着在PG里，你可以同时处理向量数据、地理位置数据、JSON数据、关系型数据，所有类型在同一个事务引擎里保持一致性和完整性。这种"一站式"的能力，在AI应用越来越复杂的趋势下显得格外有价值。

第二个原因是AI正在变成基础设施，而非上层应用。当AI能力逐渐下沉到数据层，数据库层面直接支持向量的存储和检索会变成常态。不需要再额外维护一套独立的向量数据库，DBA只需要在熟悉的PG环境里新增一个扩展，就可以同时支持传统业务和新AI业务。这种"平滑过渡"的路径，是其他数据库很难提供的。

给同行的一些建议

如果你也是一名DBA，正在观望这些新技术要不要学，我的建议是：早点动手，不用全学，先搭一个pgvector环境玩一玩。装扩展、建表、插入几条向量、跑几个查询、看看执行计划长什么样。不需要多深入，先把"这东西怎么工作的"搞明白就行。有了这个认知基础，当研发同事再来找你沟通向量方案时，你不会是一个完全的"局外人"。

更高阶的一步是关注PG在AI方向的新动向。PG社区正在做的事情包括：更好的向量索引类型、更高效的内存管理、更丰富的AI工具链集成。这些变化现在看起来像"边缘需求"，但它们正在一步步走向主流。等到所有业务都开始用的时候你再去学，可能已经落后了。

DBA这个职业能活多久，不取决于数据库怎么发展，而取决于我们能不能跟着数据库一起发展。 PG+向量+AI这条路线，是这个时代给DBA的一份新考卷。卷子已经发下来了，接不接、什么时候接，决定了我们在未来的数据世界里是"掌舵者"还是"旁观者"。