摘要： 做 AI 应用时，数据库应该怎么选？为什么 PostgreSQL、MongoDB、Qdrant、Milvus、Neo4j、ClickHouse 都经常出现在 AI 技术栈中？它们究竟有什么区别，又是否需要同时使用？本文尝试建立一张 AI 数据库地图，从数据类型、核心能力和典型应用场景出发，梳理不同数据库的定位与选型逻辑。
一、先建立认知：不存在一个包办所有事情的 AI 数据库
传统应用主要解决数据的存储、查询、更新和统计问题。AI 应用在此基础上，又增加了几类需求：
- 语义检索： 根据问题的含义寻找相关内容，而不是只匹配关键词。
- 知识关联： 理解人物、项目、文档、事件之间的复杂关系。
- 上下文记忆： 帮助 AI 找回历史信息、用户偏好和经过确认的经验。
- 大规模分析： 从大量业务数据中计算指标、识别规律和验证假设。
- 多模态检索： 从文本、图片、音频、视频等不同类型的内容中寻找相关信息。
这些需求并不完全相同，因此产生了不同的数据库技术路线。
首先需要明确：AI 数据库并不是一个严格统一的数据库类别。 它既包括传统数据库增加 AI 检索能力后的形态，也包括专门为向量搜索、图关系查询等任务设计的数据库。
二、AI 数据库全景地图
可以先将整个技术生态划分为以下九类。
| 数据库类别 | 代表产品 | 主要解决的问题 |
|---|---|---|
| 关系型数据库 | PostgreSQL、MySQL、SQL Server、SQLite | 业务数据、事务、结构化关系 |
| 向量数据库 | Qdrant、Milvus、Weaviate、Pinecone、Chroma | 语义搜索、相似内容检索 |
| 搜索引擎 | Elasticsearch、OpenSearch | 全文检索、关键词搜索、混合搜索 |
| 图数据库 | Neo4j | 实体关系、知识图谱、关系推理 |
| 文档型数据库 | MongoDB | 灵活的文档结构、半结构化数据 |
| 键值与缓存数据库 | Redis | 缓存、临时状态、高速访问 |
| 分析型数据库 | ClickHouse、DuckDB、Snowflake、BigQuery | 大规模统计、聚合和数据分析 |
| 时序数据库 | TimescaleDB、InfluxDB | 设备状态、时间序列、持续监控 |
| 数据湖与湖仓生态 | 对象存储、Parquet、Iceberg、Delta Lake | 大规模文件数据、历史数据与分析处理 |
需要注意，最后一类属于数据存储格式、存储设施和数据平台的组合，并不全是独立的数据库产品。
1. 关系型数据库：AI 应用的业务底座
代表产品：PostgreSQL、MySQL、SQL Server、SQLite。
这类数据库负责保存具有明确结构和关联关系的数据，例如：
- 用户身份、权限和配置
- AI Agent、Capability、Skill 及其版本
- Task、Execution 和执行结果
- 资产元数据与版本
- 复盘指标、实验记录和用户确认的结论
以 PostgreSQL 为例，它除了支持事务和关系查询，还具有 JSONB、全文检索、视图等能力。通过 pgvector 扩展，还可以增加向量相似度搜索。
这意味着，很多 AI 应用并不需要一开始就引入专用向量数据库。
参考：PostgreSQL 官方文档；pgvector 项目。
2. 向量数据库：让 AI 按语义寻找内容
代表产品：Qdrant、Milvus、Weaviate、Pinecone、Chroma。
向量数据库主要解决一个问题：当用户的问题与原文没有完全相同的关键词时，如何找到语义上相关的内容？
例如，知识库里有一篇文章讨论"如何提高短视频前几秒的吸引力"，用户却问：
"以前总结过哪些方法，可以减少观众刚开始就划走？"
传统关键词搜索可能错过部分结果；向量检索则可以通过文本的向量表示寻找语义相近的内容。
其基本过程是：
- 将文本、图片或其他内容输入 Embedding 模型。
- 把模型生成的向量与原始内容关联保存。
- 将用户问题转换成查询向量。
- 检索相似向量，并返回对应内容供 AI 使用。
不同产品各有侧重。Qdrant 和 Milvus 提供专门的向量检索能力；Weaviate 强调向量数据与 AI 应用集成；Pinecone 提供托管式向量数据库服务；Chroma 常用于开发和构建 AI 检索应用。
需要注意：向量数据库不会自动理解所有知识，也不会替代 Embedding 模型、数据整理和检索质量评估。
3. 搜索引擎：关键词和语义检索可以结合
代表产品：Elasticsearch、OpenSearch。
搜索引擎擅长全文检索、关键词匹配、过滤和相关性排序。现代搜索引擎也支持向量检索，因此可以把关键词检索与语义检索结合起来。
例如，用户搜索一个软件报错：
"PostgreSQL 连接池超时。"
关键词搜索能够精准找到错误代码、日志和文档；语义检索可以找到使用不同措辞描述相同故障的解决方案。
这种混合检索在技术文档、客服知识库、代码搜索和企业搜索中很有价值。
参考：Elasticsearch 向量搜索；OpenSearch 向量搜索。
4. 图数据库：重点是实体之间的关系
代表产品：Neo4j。
关系型数据库也能保存实体关系，但当查询需要沿着多层关系不断扩展时，图数据库具有不同的建模与查询优势。
例如，一个 AI 平台可能包含以下关系：
- 用户拥有一个 Node。
- Node 具有多个 Capability。
- Capability 调用不同的 Skill。
- Skill 生成资产。
- 某项复盘结论来自特定内容和实验。
- 某条经验又影响后续的执行策略。
当系统需要频繁回答"这些对象是如何关联的""这个结论来自哪些证据"等问题时，知识图谱可能具有价值。
Neo4j 可以用节点、关系和属性表达这类结构，也可以用于 GraphRAG，即结合图关系与文本检索为 AI 提供上下文。
但不是所有知识库都需要图数据库。普通文档检索和常规业务关联，通常不必因为引入 AI 就直接改用图数据库。
参考：Neo4j 知识图谱。
5. 文档数据库：适合结构灵活的数据
代表产品：MongoDB。
文档型数据库以文档为主要数据组织方式，适合字段结构经常变化的业务数据。
例如，来自不同模型的调用结果、外部 API 返回的数据，以及不同类型的内容元数据，可能具有不同字段。
不过，PostgreSQL 的 JSONB 也能够存储和查询灵活的 JSON 数据。因此，选择 MongoDB 不应仅仅因为数据中存在 JSON，而应该结合数据关系、查询方式、事务要求和现有技术栈决定。
6. 键值数据库与缓存：提高访问速度
代表产品：Redis。
Redis 常用于缓存、会话、临时状态、队列相关场景，也具备全文与向量搜索能力。
在 AI Agent 系统中，它可以帮助处理短期运行状态、热点数据和需要快速访问的信息。
但需要区分两件事：缓存里的数据和长期需要保存的业务事实不是同一回事。Redis 不应仅仅因为访问速度快，就默认成为所有 AI 数据的唯一长期存储。
参考：Redis 搜索与查询。
7. 分析型数据库：用于大规模统计与复盘
代表产品：ClickHouse、DuckDB、Snowflake、BigQuery。
分析型数据库针对大规模扫描、聚合和统计进行了优化。
例如，运营系统积累了大量内容表现数据，需要按平台、发布时间、内容类型、主题和实验批次计算指标。随着数据规模扩大，分析型数据库可能比直接在业务数据库中执行复杂统计更合适。
其中：
- DuckDB： 适合本地分析、数据探索，以及直接查询 CSV、Parquet 等文件。
- ClickHouse： 面向高性能列式分析和大规模聚合查询。
- Snowflake、BigQuery： 适合云端数据仓库和更大规模的数据分析需求。
但数据规模较小时，PostgreSQL 的 SQL 查询、View 和 Materialized View 就可能足够。是否引入独立分析数据库，应由实际查询负载和性能需求决定。
参考：DuckDB；ClickHouse。
8. 时序数据库：专门处理随时间变化的数据
代表产品：TimescaleDB、InfluxDB。
当数据主要由时间戳与持续产生的指标组成时，例如设备遥测、系统监控、传感器状态和运行指标，时序数据库可以提供专门的存储与查询能力。
如果只是保存 AI 任务的开始时间、结束时间和执行状态，普通关系型数据库通常就够了；只有在持续写入、高频时间窗口分析等需求明显时，才需要进一步评估时序数据库。
9. 数据湖与湖仓：面向大量原始文件和历史数据
当系统开始积累大量视频、图片、文档、日志和数据快照时，可以把文件本体放入本地文件系统或对象存储，并使用 Parquet、Iceberg 等格式或生态进行后续分析。
这与关系型数据库、向量数据库并不冲突：
- 数据库保存业务记录、索引和元数据。
- 对象存储保存文件本体。
- 分析引擎读取文件或数据集进行批量处理。
对多模态 AI 系统而言，这一层尤其重要，因为视频和音频等文件不适合全部塞进业务数据库。
三、这些数据库之间是什么关系？
可以把 AI 应用的数据架构理解为几个互相协作的层次：
第一层：权威数据存储
保存业务事实、对象关系、任务记录、知识元数据和用户确认的信息。
第二层：检索与索引
通过全文索引、向量索引、搜索引擎或图索引，让 AI 能够快速找到相关信息。
第三层：分析处理
对历史数据进行聚合、统计、比较和实验分析。
第四层：AI 应用
Agent 根据任务需要调用相应的查询和检索能力，把相关数据作为上下文，再生成结果或执行操作。
这些层不一定对应四套独立产品。同一个 PostgreSQL 实例就可以同时承担业务数据存储、全文检索、一定规模的统计分析和向量检索。
四、以个人 AI Node 为例，应该如何选择？
如果目标是构建一个长期可扩展的个人 AI Node，我更倾向于从简单、统一的底座开始，而不是一次性组合所有数据库。
第一阶段：建立自己的数据底座
- PostgreSQL：存储 Identity、Capability、Agent、Skill、Execution、Knowledge、Memory 和 Analytics 等结构化数据。
- 本地文件系统：存储视频、图片、音频、PDF 和代码包。
- Node Service：统一处理数据访问、业务规则、权限和 API。
第二阶段：根据真实需求增加检索能力
先使用 PostgreSQL 全文检索。如果发现用户经常通过不同措辞查找知识、普通关键词搜索效果不足，再评估 pgvector。
只有当向量检索的性能、规模或独立运维需求足以证明拆分的价值时，才考虑 Qdrant、Milvus 等专用向量数据库。
第三阶段：按负载拆分专门能力
如果数据量和查询负载持续增长，可以分别评估：
- ClickHouse 或 DuckDB：分析处理。
- Elasticsearch 或 OpenSearch：复杂全文搜索与混合检索。
- Neo4j：复杂关系查询和知识图谱。
- 对象存储与湖仓技术：大量原始文件和历史数据。
这里的顺序不是固定的技术路线，而是一种避免过早增加复杂度的选型方法。
五、真正选择数据库时，应该问什么？
数据库选型不应只比较功能列表或热门程度。建议先回答以下问题：
- 数据主要是结构化记录、灵活文档、向量，还是复杂关系？
- 查询以事务读写、关键词搜索、语义搜索，还是大规模统计为主？
- 数据量、写入频率、并发量和响应时间要求是多少？
- 是否需要本地部署、离线运行、数据自主控制？
- 团队是否能维护多套数据库，额外的部署、备份和同步成本是否值得？
- 是否能先用已有数据库实现，再根据真实瓶颈扩展？
最后的结论： AI 时代并不是所有数据库都将被向量数据库取代。更合理的理解是，传统数据库继续承担可靠的数据管理职责，而向量检索、全文搜索、图查询和分析引擎分别解决不同的问题。
对一个正在从零构建的 AI 平台来说，先建立统一的数据模型，再根据实际需求增加专门能力，往往比一开始部署一整套复杂技术栈更容易维护，也更有利于长期演进。