在大模型项目里很多人会把 PostgreSQL 简单概括成一句话“用来保存用户和文档元数据。”这句话没有错但远远不完整。一个真正可运行的 AI 应用通常需要保存用户、组织、权限、文档、版本、任务、会话、反馈、审计记录和业务状态。PostgreSQL 往往承担的是整个应用的业务事实层而不是只做向量数据库旁边的一个辅助表。本文沿着一个企业知识库和智能客服的典型流程说明 PostgreSQL 在大模型系统中究竟负责什么以及哪些事情不应该交给它。给出一个工程边界PostgreSQL 是 AI 应用的业务事实库不等于“所有 AI 数据都放进去”。常见系统会把职责拆成几层PostgreSQL用户、租户、权限、文档状态、任务、会话、审计 对象存储PDF、Word、图片等原始文件 pgvector / Milvus向量、索引和相似度检索 Redis短期缓存、限流和会话热点数据PostgreSQL 的价值在于用主键、外键、约束、事务和查询把这些对象组织成可审计的业务状态。它不应该被描述成“RAG的向量库”也不应该直接承担文件服务器和模型推理服务的职责。一、先把“模型数据”和“业务数据”分开大模型应用中至少存在三类数据模型数据 ├── Prompt ├── Token ├── Embedding 向量 └── Reranker 分数 业务数据 ├── 用户、租户、角色 ├── 文档、版本、权限 ├── 会话、消息、反馈 └── 订单、客户、审批状态 文件数据 ├── PDF、Word、Excel ├── 图片、音频、视频 └── 原始附件PostgreSQL 主要负责第二类也会保存第一类和第三类数据的索引信息原始大文件和大规模向量则可以根据场景放到对象存储或专用向量数据库中。二、PostgreSQL 的第一项职责保存身份、组织和权限AI 应用的回答必须知道“谁在问”和“他能看什么”。因此用户和权限通常要在 PostgreSQL 中有明确的数据模型users ↓ memberships ↓ organizations / departments ↓ roles / permissions一个简化的表结构可能是CREATE TABLE users ( id UUID PRIMARY KEY, username TEXT NOT NULL UNIQUE, created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE TABLE knowledge_bases ( id UUID PRIMARY KEY, tenant_id UUID NOT NULL, name TEXT NOT NULL, status TEXT NOT NULL DEFAULT active, created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE TABLE knowledge_base_members ( knowledge_base_id UUID NOT NULL, user_id UUID NOT NULL, role TEXT NOT NULL, PRIMARY KEY (knowledge_base_id, user_id) );用户权限不能只写进 Prompt也不能只依赖向量数据库中的一个字符串字段。应用服务应该先从业务数据库确定访问范围再把过滤条件传给检索层。三、第二项职责保存文档生命周期知识库里的文档不是“上传后永远不变的一段文本”。它通常有生命周期上传 ↓ 解析中 ↓ 解析完成 ↓ 向量化中 ↓ 已发布 ↓ 新版本替换 ↓ 归档或删除PostgreSQL 可以保存这些状态和关系CREATE TABLE documents ( id UUID PRIMARY KEY, knowledge_base_id UUID NOT NULL, title TEXT NOT NULL, storage_key TEXT NOT NULL, status TEXT NOT NULL, current_version INTEGER NOT NULL DEFAULT 1, uploaded_by UUID NOT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE TABLE document_versions ( id UUID PRIMARY KEY, document_id UUID NOT NULL, version_no INTEGER NOT NULL, content_hash TEXT NOT NULL, parser_version TEXT, embedding_model TEXT, status TEXT NOT NULL, UNIQUE (document_id, version_no) );这样系统才能回答当前使用哪一版哪次解析失败文档由谁上传向量是否已经完成更新四、第三项职责保存会话和消息一个聊天应用通常需要保存会话 ID用户和租户消息角色用户消息和模型回答使用的模型版本检索来源Token、延迟和错误信息用户反馈。可以用关系表保存核心字段用 JSONB 保存可扩展的调用信息CREATE TABLE conversations ( id UUID PRIMARY KEY, user_id UUID NOT NULL, title TEXT, created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE TABLE messages ( id BIGSERIAL PRIMARY KEY, conversation_id UUID NOT NULL, role TEXT NOT NULL CHECK (role IN (user, assistant, tool, system)), content TEXT NOT NULL, model_name TEXT, input_tokens INTEGER, output_tokens INTEGER, trace_id TEXT, metadata JSONB NOT NULL DEFAULT {}::jsonb, created_at TIMESTAMPTZ NOT NULL DEFAULT now() );但要注意聊天记录可能增长很快。生产系统需要考虑分区、归档、脱敏、保留期限和查询索引不能无限制地把所有 Prompt 和输出永久保存。五、第四项职责保存任务和状态文档解析、Embedding、批量导入和 Agent 长任务通常是异步执行的。PostgreSQL 很适合保存任务的业务状态pending → running → succeeded ↓ failed → retrying示例CREATE TABLE ingestion_jobs ( id UUID PRIMARY KEY, document_id UUID NOT NULL, job_type TEXT NOT NULL, status TEXT NOT NULL DEFAULT pending, attempts INTEGER NOT NULL DEFAULT 0, error_message TEXT, started_at TIMESTAMPTZ, finished_at TIMESTAMPTZ, created_at TIMESTAMPTZ NOT NULL DEFAULT now() );消息队列负责“把任务送给 Worker”PostgreSQL 负责“记录任务当前是什么状态”。两者是互补关系。六、第五项职责保存引用、反馈和审计如果系统回答“公司的年假政策是……”用户可能希望知道依据哪份文件、哪一页、哪个版本。回答引用可以保存为结构化数据{ document_id: doc_123, version: 3, page: 8, chunk_id: chunk_456, retrieval_score: 0.87 }审计记录则需要说明谁在什么时候做了什么CREATE TABLE audit_events ( id BIGSERIAL PRIMARY KEY, tenant_id UUID NOT NULL, actor_id UUID, action TEXT NOT NULL, resource_type TEXT NOT NULL, resource_id TEXT NOT NULL, request_id TEXT, details JSONB NOT NULL DEFAULT {}::jsonb, created_at TIMESTAMPTZ NOT NULL DEFAULT now() );尤其是 Agent 调用外部工具、修改业务数据或触发人工审批时审计信息不能只存在模型输出里。七、为什么 PostgreSQL 适合做 AI 应用的业务数据库7.1. 关系模型适合表达业务关系用户、组织、文档、版本、权限、任务和消息之间存在明确的关系。关系数据库的主键、外键、唯一约束和检查约束可以把这些规则固化下来。7.2. 事务保证多个状态同步变化文档发布时可能需要同时更新文档版本、当前状态和检索索引任务。如果其中一步失败事务可以避免业务状态停留在一个无法解释的中间状态。PostgreSQL 官方文档提供了事务隔离、锁和并发控制机制帮助多个会话在读写同一数据时维持数据一致性。7.3. SQL 适合查询和统计企业系统经常需要查询某部门本月使用了多少次 AI、哪个知识库错误率最高、哪些文档从未被检索、某个用户有哪些会话。SQL 和索引对这类统计非常合适。7.4. JSONB 提供扩展能力模型调用参数、工具结果和检索详情有时结构变化较快可以使用 JSONB 保存扩展字段同时保留核心字段的关系模型。7.5. 生态和运维成熟PostgreSQL 有丰富的驱动、备份、复制、云服务和监控工具适合成为企业应用的长期基础设施。连接池和迁移也是应用组件的一部分AI 应用往往同时有在线问答、文档导入、异步 Worker 和后台管理。如果每个请求都新建数据库连接很容易在高并发或长任务期间耗尽连接数。应用通常需要使用连接池并为在线请求和后台任务设置不同的连接上限、超时和优先级。表结构变化也不应靠手工登录生产库执行。建议把 Schema 迁移纳入版本控制代码版本 → 迁移脚本 → 测试数据库 → 预发布验证 → 生产发布涉及大表加列、创建索引、修改枚举或清理历史数据时要评估锁、执行时间、回滚方式和对在线问答的影响。数据库迁移完成不代表 Milvus、对象存储和异步任务状态已经同步完成。八、PostgreSQL 不应该承担什么8.1. 不要默认用它存储所有原始大文件小附件可以存数据库但大量 PDF、图片和视频更适合使用 MinIO、S3 或其他对象存储PostgreSQL 保存对象键、哈希和权限信息。8.2. 不要把它当作天然的大规模向量检索集群pgvector 让 PostgreSQL 具备向量搜索能力但它与专门的 Milvus 集群在规模、扩展方式和工作负载设计上不同。是否使用 pgvector要看数据规模和并发需求。8.3. 不要用 JSONB 代替所有关系设计把整个业务对象都塞进 JSONB短期灵活长期可能导致约束缺失、查询困难和数据结构漂移。稳定且经常查询的字段应该保留为关系列。8.4. 不要让它独自承担消息队列用数据库轮询实现简单任务队列可以作为小项目方案但当异步任务量、重试、消费组和吞吐要求提升后应考虑专用消息队列。九、PostgreSQL 与向量数据库如何配合一个常见设计是PostgreSQL ├── document_id ├── tenant_id ├── permission_scope ├── version ├── source_page └── processing_status Milvus / pgvector ├── chunk_id ├── embedding ├── document_id └── filterable metadata查询时从 PostgreSQL 获取用户可访问的知识库和文档范围向量数据库执行相似度检索和过滤根据document_id、chunk_id回 PostgreSQL 查询来源和版本组装引用并交给大模型。需要避免两个系统的数据不同步。文档删除、版本切换和权限变化都应该有明确的事件或任务更新向量索引。十、一个轻量级 AI 应用的数据流用户登录 ↓ PostgreSQL 查询用户权限 ↓ PostgreSQL 查询会话和历史 ↓ Embedding pgvector 检索 ↓ PostgreSQL 查询来源与版本 ↓ 调用大模型 ↓ PostgreSQL 保存消息、引用和 Token这个方案可以用较少组件完成一个小型企业知识库。数据量和并发增长后再考虑把向量检索拆到 Milvus并保留 PostgreSQL 作为业务事实源。十一、设计 PostgreSQL 表时的几个建议11.1 核心状态用枚举或约束保护不要让status任意写入字符串。可以使用 CHECK 约束或枚举防止出现success、succeeded、done混用。11.2 所有租户数据明确带上 tenant_id多租户系统不要依赖开发者记忆在重要业务表中明确保存租户字段并在查询层强制加入过滤。11.3 保留模型和数据版本记录 parser、embedding、reranker 和 LLM 版本出现效果变化时才能定位原因。11.4 对大表提前规划归档消息、日志、调用记录会快速增长。提前设计按时间分区或归档策略比数据达到数亿行后再迁移更安全。11.5 不把密钥和敏感原文随便写入日志数据库本身的权限和备份也需要纳入数据安全方案。11.6 连接和事务边界要短不要在一个数据库事务中同步等待 Embedding、Reranker 或大模型 API。外部模型调用可能耗时、超时或重试把它放在数据库事务里会长期占用连接和锁。更合理的流程是事务只负责写入“待处理”状态和任务记录提交后由 Worker 调用外部服务成功或失败再用短事务更新结果事务文档状态draft → indexing写入 job 提交 Worker解析 → Embedding → 向量库写入 事务jobsuccess文档状态ready十二、上线前检查清单用户、租户、角色和权限有明确数据模型文档、版本、来源和处理状态可追踪会话、消息、引用和反馈有保存策略异步任务有状态、重试次数和错误记录高风险工具调用有审计事件核心业务状态受约束和事务保护原始大文件与结构化数据分开存储PostgreSQL 与向量库有同步和删除策略记录模型、Embedding 和解析版本日志、备份和历史消息有保留与脱敏策略。使用连接池在线请求与后台任务有连接上限Schema 迁移脚本纳入版本控制并经过预发布验证外部模型调用不长期占用数据库事务和连接已设计 PostgreSQL、对象存储和向量索引的恢复关系十三、结语PostgreSQL 保存的是 AI 应用里的“事实”在大模型项目中PostgreSQL 最重要的价值不是“能不能存一段 JSON”而是把 AI 应用从一次模型调用变成一个有身份、有状态、有权限、有版本、有审计的业务系统。模型负责理解和生成向量库负责相似度检索对象存储负责原始文件而 PostgreSQL 负责把这些对象组织成可以被业务理解和管理的事实。下一篇继续讨论数据库选型《PostgreSQL、MySQL 与 MongoDBAI 应用该如何选择数据库》参考资料PostgreSQL DocumentationConcurrency ControlPostgreSQL DocumentationJSON Functions and OperatorsPostgreSQL DocumentationText Search Functions and OperatorsPostgreSQL DocumentationRow Security PoliciesPostgreSQL DocumentationTransactions and Identifiers10.PostgreSQL 在大模型项目中到底负责什么
