同一条 AI 聊天消息,过去要写两遍 — 一遍进 MySQL,一遍进 Milvus(一种专用向量数据库)。任意一边失败,就出现「数据在但搜不到」或「搜得到但打不开」的尴尬。PostgreSQL(一种老牌开源关系数据库)加 pgvector 扩展后,一张表装下两件事。

这事值得工程圈关心 — 它意味着 AI 长期记忆的基建成本可能被打掉一大截。

这是什么

AI 要长期记住聊天记录,本质需要两类能力并存:关系查询(按用户、会话、时间拿数据)和语义检索(找意思相近的消息)。过去工程共识是「两个数据库伺候」:MySQL 管结构化,Milvus 管语义。

问题不在性能,而在「双写」:同一条消息写两边,任意一边失败就数据不一致 — 数据库里有这条消息但搜不到,或反之。要解决就得引入事务、重试队列、补偿任务,相当于为存聊天记录搭一套分布式系统。

PostgreSQL 的解法直接:在消息表加一个 embedding(向量)字段,用 pgvector 扩展提供语义检索能力。一张表、一套 SQL、一次写入,关系查询和向量检索共用同一份数据。

行业怎么看

支持方判断很清楚:架构变简单,运维成本下降,对小团队尤其友好。一个全栈工程师 + 一个 PG 实例就能搭起 ChatGPT 的记忆系统,过去得后端、数据、平台三组协作。

但反对意见同样真实:

  • pgvector 在亿级向量规模下的检索速度,通常仍落后 Milvus 等专业方案
  • 存量系统迁移成本高 — 大厂的 MySQL/Milvus 不会一夜替换
  • 单库意味着单点 — 一旦 PG 挂掉,关系数据和向量数据同时不可用,过去是只挂一半

务实结论:PG + pgvector 是中小企业和中等规模 AI 产品的更优解,但不是「数据库大一统」的终局。

对普通人的影响

对企业 IT:评估 AI 产品自建方案时,PG 单库方案值得作为基线 — 工程人力、运维投入会显著低于双库路线。

对个人职场:全栈工程师的数据库能力要求在变高 — 不只写 CRUD(增删改查),还要懂向量嵌入(把文字转成数字)、索引原理、查询优化。

对消费市场:AI 聊天产品的「记忆」功能会更稳定、更便宜 — 写入失败导致「刚才聊的找不到」的体验问题会减少。