Wiki Notes

Appearance

05. 主流方案、架构形态与选型清单 ​

版本：v1.6

最后更新：2026-07-09

适用对象：已经理解向量检索基本原理，正在决定 Pinecone / Weaviate / Qdrant / Milvus / Azure AI Search / pgvector / FAISS，以及 Elasticsearch / OpenSearch / Apache Solr / MongoDB Atlas / Redis / Neo4j / Vespa / LanceDB / Chroma / Astra DB / ClickHouse / SingleStore / TiDB / Couchbase / Supabase / AlloyDB AI / Azure Database for PostgreSQL / Neon / Databricks AI Search / Snowflake Cortex Search / Cloudflare Vectorize / Turbopuffer / Oracle AI Vector Search / Typesense / Meilisearch / Vald / KDB.AI / Zilliz Cloud / Gemini Enterprise Agent Platform Vector Search / Azure Cosmos DB / ScyllaDB / Turso / Tiger Data 这类生态位该怎么选、该放在哪一层的团队

很多团队问“向量数据库选哪家”时，真正还没想清楚的其实不是品牌，而是 架构形态。

因为根据 2026-07-09 复核可访问的官方资料，不同方案在设计目标上差异非常大：

  • 有的是托管型向量数据库
  • 有的是搜索引擎里内置向量能力
  • 有的是分布式向量引擎
  • 有的是关系数据库扩展
  • 有的是托管 PostgreSQL / 兼容 Postgres 的 AI 数据库路线
  • 有的是文档数据库、缓存、图数据库里的原生向量能力
  • 有的是开发者友好搜索引擎里的向量与 hybrid 能力
  • 有的是云原生 / Kubernetes 原生的向量引擎
  • 还有的是面向本地或湖仓工作流的嵌入式检索引擎
  • 还有的是长在 lakehouse、数据云、边缘平台、对象存储、时序平台和传统企业数据库里的原生向量检索能力
  • 还有的是本地 ANN 库，而不是完整服务

所以第一步不该是直接比较名字，而是先分清：你到底需要一个什么形态的检索底座。

1. 先选架构形态，再选产品名字 ​

企业里常见的几类形态大致是这样：

形态代表方案更适合什么情况最容易踩的坑
托管型向量数据库Pinecone想快速上线、团队不想自己管底层集群、重点在 RAG 产品交付把它当成“完整搜索系统”，忽略上层过滤、重排和应用治理
托管 Milvus 服务Zilliz Cloud想走 Milvus 生态，但又不想自己扛集群、索引和扩缩容误以为“托管版 Milvus”就自动等于完整搜索产品，不补上层过滤、工作流和权限
向量 + 搜索一体化引擎Azure AI Search、Weaviate同时需要关键词、过滤、语义、重排、企业搜索能力误以为“有向量”就等于只需要向量，不去设计全文和结构化字段
云厂商托管向量检索服务Gemini Enterprise Agent Platform Vector Search已经在 Google Cloud / Agent Platform 体系，想让检索和 RAG Engine、生成式工作流贴得更近把“云上托管可用”误解成无需考虑索引、过滤、刷新和应用层能力边界
搜索平台内置向量能力Elasticsearch、OpenSearch、Vespa、Apache Solr已经有搜索工程体系，希望把全文、过滤、聚合、排序和向量放在同一搜索底座只看到向量能力，忽略 schema、ranking、serving 依然需要搜索工程治理
自托管分布式向量引擎Milvus、Qdrant、Weaviate对部署边界、成本模型、底层控制权要求更高低估运维、备份、升级、隔离和观测成本
宽列 / 高吞吐数据库内置向量能力ScyllaDB已经在 Cassandra / Scylla 心智下经营高吞吐主数据，希望把向量能力接进现有集群忽略向量索引节点、查询模式和热数据布局仍需单独设计
云原生 / Kubernetes 原生向量引擎Vald团队已经有 Helm / GitOps / Kubernetes 基础，希望把向量索引作为云原生基础设施长期经营低估分布式索引、备份恢复、滚动升级和观测门槛
开发者友好 / local-first 向量存储Chroma本地优先、Agent 记忆、小团队快速原型、先把 retrieval 跑通把开发便捷性误当成完整线上多租户平台能力
开发者友好搜索 API / 轻量搜索引擎Meilisearch、Typesense想快速交付站内搜索、商品搜索或文档搜索，同时要全文、typo tolerance、filter 和 hybrid误以为 API 简洁就不需要 relevance tuning、多租户治理和异步任务运营
API 原生 / 宽列系 serverless 向量数据库Astra DB想用 Data API、向量集合 / 表、混合检索快速接入应用忽略数据模型、主键 / 分区与平台治理仍要认真设计
文档数据库内置向量能力MongoDB Atlas Vector Search业务主数据已经在 MongoDB，希望把 operational data + vector search 放一起把开发便捷性误当成大规模检索平台替代，不评估索引隔离与查询成本
JSON 文档数据库内置向量能力Azure Cosmos DB for NoSQL文档和向量想直接存在同一份 JSON 记录里，且本来就跑在 Cosmos DB误把文档就地向量化当成默认最优，不评估过滤、分区和成本模型
文档数据库 + 搜索服务一体CouchbaseJSON 文档、全文检索、向量检索和业务访问路径想尽量放在同一底座没有提前规划搜索索引、查询服务和业务流量的容量边界
内存型实时向量能力Redis热数据、会话态、缓存和低时延检索要放在同一层误把内存底座当长期冷数据总库，不提前评估持久化与成本边界
图数据库内置向量能力Neo4j同时要语义召回、图关系遍历、GraphRAG 和知识图谱推理只看向量相似度，不投入图模式建模与关系维护
关系库扩展pgvector已经强依赖 PostgreSQL，数据关系和事务比极限召回更重要让 OLTP 和向量检索共享同一资源池，却没做容量隔离
托管 PostgreSQL / 兼容 Postgres AI 数据库AlloyDB AI、Azure Database for PostgreSQL、Neon想保留 PostgreSQL 事务 / JOIN / 权限心智，同时拿到托管运维、云数据库能力和向量检索增强误以为“兼容 Postgres”就天然等于任何规模下都适合共库，不评估索引策略、资源竞争和隔离边界
托管 Postgres AI 平台Supabase（底层仍是 pgvector）想把 Postgres、RLS、Edge Functions、向量检索和应用开发一起推进误以为“托管更省心”就不需要索引调优、RLS 和成本治理
SQLite / edge 原生向量数据库Turso / libSQL想让向量和关系数据直接留在 SQLite / edge / local-first 应用里把“原生内建”误当成通用企业知识库方案，不评估索引规模和同步边界
Postgres + 实时分析 + 向量一体化Tiger Data已经把时间序列、事件和实时分析放在 Postgres 路线里，希望顺手接入向量检索忽略事务、分析和检索混部下的资源隔离与查询模式设计
分析型 / HTAP SQL 引擎ClickHouse、SingleStore、TiDB想把向量检索和 SQL 分析、混合检索、实时数据处理放在一个查询体系里把分析引擎直接当成开箱即用知识平台，不补权限、工作流和服务层
Lakehouse / 数据平台内置向量检索Databricks AI Search数据、权限和索引治理已经在湖仓平台里，想把检索贴着 Delta / Unity Catalog 演进把数据平台里的检索能力误当成现成应用搜索产品，不补应用层体验与权限透传
数据云 / 云数仓内搜索服务Snowflake Cortex Search数据已经在 Snowflake 里，希望把模糊搜索、RAG 检索和平台权限留在同一数据云把数据云里的搜索服务误当成现成终端搜索产品，不补应用体验、刷新成本和写路径治理
实时 / 时序向量数据库KDB.AI检索对象和时间序列、流式特征、实时相似度分析强耦合，希望把结构化与非结构化检索一起处理误把时序优势当成通用企业知识库默认最优，不评估业务语义建模和搜索体验差异
边缘 / 全球分布式向量数据库Cloudflare Vectorize应用跑在 Workers 或全球边缘侧，希望检索也就近执行误以为边缘就天然适合所有重型企业知识库，不评估索引规模、冷数据和复杂治理
对象存储原生 serverless 向量数据库Turbopuffer希望把 namespace、过滤、全文 / 向量混合和弹性容量放进极简 serverless 检索层只看到低运维和弹性，忽略查询模型、数据布局和上层权限体系仍需设计
企业数据库内置 AI Vector SearchOracle Database已经重度依赖 Oracle，希望把 SQL、事务、企业治理和向量检索放在同一数据库里误把“库内一体化”当成默认高性价比，不评估索引资源、schema 和服务边界
搜索 API / 产品化检索引擎Typesense想快速交付全文 + 向量 + hybrid 的站内检索或搜索 API忽略 schema、relevance tuning 和多租户治理仍要自己设计
本地 / 湖仓型嵌入式检索LanceDB本地优先、多模态数据集、训练数据与检索一体的 AI 工作流直接把嵌入式能力当成完整多租户服务，不补权限、运维和发布层
本地 ANN 库FAISS本地实验、离线批处理、研究或自建检索服务把库当成完整数据库，忽略权限、过滤、备份和 API 服务层

这个顺序很重要，因为很多“选型争论”本质上是把不同层级的东西拿来硬比。

2. 主流方案各自更擅长什么 ​

2.1 Pinecone：更像托管型向量检索底座 ​

Pinecone 当前官方资料把 structured IDs、metadata、namespaces、data freshness 和 production checklist 放得很靠前，这很能说明它的产品重心：

  • 帮你把向量索引、命名空间、过滤和生产化基本面跑稳
  • 适合做多租户 SaaS、RAG API、知识检索底座
  • 团队更关注业务交付，而不是自己运维搜索基础设施

更适合优先考虑 Pinecone 的情况通常是：

  • 你希望用托管服务快速交付第一版生产系统
  • 你的重点是 namespace、metadata、traceability、freshness
  • 你不想自己搭太多底层搜索和向量集群运维体系

但要注意：

  • Pinecone 不是关系数据库
  • 也不是完整企业搜索门户
  • 如果大量依赖复杂 SQL 关联、事务写路径和业务库联表，通常还要配合别的存储层

2.2 Weaviate：更强调多向量、集合治理和搜索组合能力 ​

Weaviate 当前官方资料比较强调：

  • named vectors
  • hybrid search
  • multi-tenancy
  • tenant states
  • reranking 与多目标检索

这意味着它更适合：

  • 一个知识对象需要多个向量表示空间
  • 既做语义检索，也做 hybrid、rerank 和结构化过滤
  • 希望把 collection、tenant、vector config 放在同一套治理模型里

如果你的场景天然存在这些要求，Weaviate 会比较顺手：

  • 标题和正文用不同 embedding
  • 多语言或多模态要多套表示空间
  • 同一对象既服务 FAQ，又服务长文 grounding
  • 需要明确 tenant 生命周期和资源状态

2.3 Qdrant：更强调 payload、过滤、混合查询和可控部署 ​

Qdrant 当前官方资料里，payload、filtering、hybrid queries、multitenancy、snapshots、Qdrant Edge 都是非常明确的主线。

它比较适合：

  • 想把结构化字段过滤做得很明确
  • 想结合 dense / sparse / hybrid 查询
  • 需要自托管、云部署、边缘部署等多种形态
  • 希望备份、迁移、快照路径相对直接

Qdrant 的一个很实用视角是：

如果你的检索系统不是只有“相似度”这一个问题，而是还有 payload filter、租户边界、快照回滚、边缘同步这些问题，Qdrant 会比较对题。

但也要注意：

  • 它依然主要是检索底座，不是完整门户搜索产品
  • 如果你非常依赖复杂全文检索、分面、搜索运营台，通常还要和别的能力组合

2.4 Milvus：更偏大规模分布式向量基础设施 ​

Milvus 当前文档在几个方向上很突出：

  • filtered search
  • partition key
  • consistency
  • multi-vector hybrid search
  • 大规模向量索引与多种索引策略

这类信号通常说明它更适合：

  • 数据规模较大
  • 对底层索引和部署控制权要求高
  • 需要多向量、复杂过滤、分区策略和一致性调优
  • 团队愿意自己承担更多基础设施复杂度

Milvus 更像一套偏底层的向量基础设施能力，而不是“开箱即用的知识应用平台”。

所以如果你选它，通常要同步准备：

  • 集群部署与升级策略
  • 备份与恢复策略
  • 观测与容量治理
  • 上层权限、工作流和应用检索链路

2.5 Azure AI Search：更像企业搜索引擎，而不是单纯向量库 ​

Azure AI Search 当前官方资料把这些能力放在一起讲：

  • hybrid search
  • RRF
  • semantic ranker
  • filters / facets / relevance

这说明 Azure AI Search 的强项不只是“存向量”，而是把企业搜索常见能力打成一体：

  • 关键词检索
  • 向量检索
  • 过滤
  • 排序
  • 语义重排
  • 搜索结果组织

如果你的目标是：

  • 企业知识门户
  • 文档搜索站内检索
  • 带关键词、过滤、语义和排序的企业搜索体验

那 Azure AI Search 往往比“单独比较向量数据库”更贴近真实需求。

2.6 pgvector：更像把向量能力带进现有 PostgreSQL ​

pgvector 官方 README 现在仍然非常清楚地强调几件事：

  • Postgres 里可以做 exact 和 approximate nearest neighbor search
  • 支持 HNSW 和 IVFFlat
  • 向量和业务表可以放在同一个数据库里
  • 可以直接利用 PostgreSQL 的事务、JOIN、备份和恢复能力

这类方案最适合：

  • 已经大量使用 PostgreSQL
  • 业务记录和向量记录强耦合
  • 需要事务一致性、联表、权限、审计一起落在数据库层
  • 规模还没有大到必须拆成独立向量平台

它最大的优势不是“ANN 最强”，而是：

它让你在现有数据体系里最小化引入新基础设施。

但也要看到现实边界：

  • OLTP 和向量检索会共享数据库资源
  • 过滤 + ANN 的性能要认真测试
  • 当规模、吞吐和隔离要求继续上升时，可能还是要演进到独立检索底座

2.6.1 托管 PostgreSQL 路线：AlloyDB AI / Azure Database for PostgreSQL / Neon ​

如果你已经接受 PostgreSQL 作为主数据与检索共存底座 这条路线，那么现在也不能只盯着裸 pgvector 了。

根据当前官方资料：

  • AlloyDB AI 直接把高性能 vector search、embeddings 和 PostgreSQL 兼容数据库放在一起讲，还单独提供向量索引策略说明。
  • Azure Database for PostgreSQL 当前已经把 pgvector、DiskANN 和向量搜索性能优化作为明确文档路径。
  • Neon 当前把 pgvector 扩展、向量搜索和优化指南做成了很完整的托管 Postgres AI 路线。

这组方案更适合：

  • 业务已经强依赖 Postgres 数据模型、事务和 JOIN
  • 团队希望少引入新中间件，先沿现有 Postgres 心智把 RAG 接进去
  • 更在意托管能力、备份恢复、云数据库集成和应用交付速度

它们的共同价值更像是：

不是重新发明独立向量数据库，而是把“Postgres + 向量检索”这条路做得更生产化。

但要保持清醒：

  • 托管不等于没有资源竞争，OLTP 和检索依然可能互相影响
  • 还是要认真评估 HNSW / IVFFlat / DiskANN 等索引策略与过滤路径
  • 当并发、隔离、多租户或检索规模继续上涨时，仍可能需要独立检索底座分担压力

2.7 FAISS：更像底层库，不是完整数据库 ​

FAISS 官方文档的定位一直很稳定：

  • 它是相似度搜索与向量聚类库
  • 支持 CPU / GPU
  • 适合本地、研究、离线、定制化 ANN 管线

它非常适合：

  • 离线召回实验
  • 本地原型
  • 自己实现检索服务
  • 大规模 ANN 算法验证

但 FAISS 默认不提供你在生产系统里常要的很多东西：

  • 多租户治理
  • 认证授权
  • payload / metadata 管理体系
  • 快照、备份、回滚工作流
  • 企业级 API 服务边界

所以 FAISS 更应该被看作 ANN 引擎组件，而不是完整向量数据库替代品。

2.8 Elasticsearch / OpenSearch / Vespa：更像搜索平台里的向量能力 ​

Elastic 当前官方文档已经明确写到：Elasticsearch 可以作为向量数据库使用，但它的价值不只在向量相似度，而是在同一引擎里把 full-text search + filters + aggregations + ranking 组合起来。

OpenSearch 当前官方文档也把 vector search 直接描述为 complete vector database solution，并强调可以把 embeddings 和已有数据放在同一搜索体系里。

Vespa 当前官方学习资料则继续沿着它一贯的路径，把：

  • text index
  • vector index
  • filtering / sorting attributes
  • ranking pipeline

放在同一 serving 架构里。

这类方案更适合：

  • 团队已经有搜索平台经验
  • 不只做 RAG，还做站内搜索、推荐、排序和聚合分析
  • 希望在同一查询里融合关键词、向量、过滤和多阶段 ranking

要特别注意的是：

  • 它们的强项通常是“搜索系统一体化”，不是只拼 ANN 指标
  • schema、ranking expression、query rewrite、serving 调优依然是长期工作
  • 如果团队没有搜索工程经验，未必会比托管型向量库更省心

2.9 MongoDB Atlas Vector Search：更像把语义检索带进现有文档模型 ​

MongoDB 当前官方资料把 Vector Search 直接放在 Atlas 里，明确支持：

  • ANN 和 ENN
  • hybrid search
  • 在向量查询前对布尔、日期、数值、字符串、UUID 等字段做 pre-filter

这类方案更适合：

  • 主业务数据已经落在 MongoDB 集合里
  • 文档模型、应用开发和检索希望尽量共用同一套数据心智
  • 先把 operational data 和语义检索接起来，比独立搜索平台更重要

但要提前看清：

  • 这条路径解决的是“就地接入”，不自动等于“最适合大规模检索平台化”
  • 向量索引和业务查询是否互相影响，需要认真做容量评估
  • 如果后续要走更复杂的企业搜索、排序和评测链路，可能仍要分层

2.10 Redis：更像实时热数据和向量检索合在一起 ​

Redis 当前官方资料已经把它明确描述为可以作为 vector database 使用，并且强调：

  • 向量和 metadata 可以存进 hashes 或 JSON documents
  • 可以建立 secondary indices
  • 支持 vector search、full-text search、filters、update 和 delete

这让 Redis 特别适合：

  • 热点知识、会话记忆、实时缓存、个性化上下文
  • 要把低时延 KV、搜索和向量能力放在同一层
  • 检索对象生命周期偏短，或者冷热分层本来就存在

但它不太适合被不加区分地拿来承接整个企业冷知识库，因为：

  • 热数据和冷数据的成本模型不一样
  • 内存型系统更需要提前设计 TTL、持久化和数据分层
  • 如果 corpus 很大，却没有分层策略，成本会很快放大

2.11 Neo4j：更像“向量召回 + 图关系推理”的组合底座 ​

Neo4j 当前官方文档把 vector indexes 描述为可以对节点和关系做相似度搜索，并明确提到它可以和 full-text search 或其他 ranked sources 组合成 hybrid search。

这意味着 Neo4j 更适合：

  • 你本来就需要图谱、实体关系、路径遍历
  • 检索不是只找相似 chunk，还要找相邻实体、上游下游关系和依赖链
  • 想做 GraphRAG、根因定位、组织权限传播、知识图谱问答

它的关键优势不是“向量更快”，而是：

你可以把语义近邻和图关系约束放进同一推理路径里。

代价也很明确：

  • 图模式设计和关系维护本身就是成本
  • 如果业务并不依赖关系推理，只是普通 RAG，Neo4j 往往会显得偏重

2.12 LanceDB：更像本地优先的多模态检索与数据工作流底座 ​

LanceDB 当前官方文档把自己定位成 multimodal lakehouse for AI，并且明确把：

  • vector search
  • full-text search
  • hybrid search
  • filtering
  • reranking

放在同一组 search primitives 里。

它更适合：

  • 本地优先或嵌入式工作流
  • 训练数据、检索数据、多模态样本想放在同一数据层
  • 数据科学、评测、样本治理和检索实验需要频繁迭代

它的优点不是传统“托管数据库体验”，而是：

  • 数据层和 AI 工作流距离更近
  • 对多模态样本、训练集、检索集一体治理更顺手

但如果你要的是：

  • 成熟的多租户服务治理
  • 企业级访问控制
  • 开箱即用的线上平台能力

那通常还需要额外补服务层和运维层。

2.13 Chroma：更像 local-first 的开发者友好向量存储 ​

Chroma 当前官方资料把自己直接定位成 open-source data infrastructure for AI，并且在入门文档里把下面这些能力放成默认主线：

  • collections
  • documents + metadata
  • dense / sparse retrieval
  • embedding functions
  • 本地运行与快速接入

这意味着 Chroma 更适合：

  • 本地优先的知识工具
  • Agent memory 或个人检索工作台
  • 小团队先把 retrieval 闭环快速跑通
  • 希望用 Python / TypeScript 很快接到应用里

它的优势不在“超大规模分布式向量平台”，而在：

把向量存储、文档、metadata 和查询 API 以很低心智成本交给开发者。

但也要明确：

  • local-first 体验不等于天然多租户生产治理
  • 如果你要复杂权限、容量隔离、强审计和成熟恢复路径，通常还得额外补平台层

2.14 Astra DB：更像 API 原生的 serverless 向量数据库 ​

Astra DB 当前官方资料把 vector-enabled collections and tables、Data API、$vector / $vectorize、filters、hybrid search 放得很靠前。

这类信号说明它更适合：

  • 想用 API 直接接向量查询，而不是先搭很重的搜索底座
  • 希望在 serverless 数据平台里同时保留结构化记录与向量能力
  • 需要把 vector search、metadata filters 和 hybrid search 比较快接进应用

它的一个实用价值在于：

你可以把“文档对象 + 向量检索 + API 访问”放进一套比较统一的开发体验里。

但它并不会替你自动解决：

  • 分区和主键设计
  • 数据生命周期
  • 多租户成本边界
  • 上层引用、评测和治理闭环

2.15 ClickHouse / SingleStore / TiDB：更像 SQL / HTAP 体系里的向量检索 ​

这三类方案都不是传统意义上的“只做向量”的产品，它们当前官方资料共同强调的是：

  • 原生 vector 数据类型或向量索引
  • kNN / ANN 查询
  • SQL 查询能力
  • 向量与结构化过滤、分析或混合检索并存

但它们各自的生态位略有差异：

  • ClickHouse 更偏高吞吐分析、列式存储和向量索引 + 文本索引组合
  • SingleStore 更偏实时 SQL、向量类型、向量索引、hybrid rerank 与在线服务一体
  • TiDB 更偏分布式 HTAP / MySQL 兼容体系里把向量类型、向量索引和 KNN 查询接进现有数据库心智

这类方案更适合：

  • 数据团队强依赖 SQL
  • 检索系统需要和分析、报表、实时处理共用数据底座
  • 你更关心“现有数据库体系怎么长出向量能力”，而不是另起一套检索基础设施

真正该提前确认的是：

  • 向量查询和业务 / 分析查询会不会互相抢资源
  • 权限、审计、回放、版本回退由数据库层还是应用层负责
  • 你的目标是“向量能力接进 SQL”，还是“构建完整知识检索平台”

2.16 Couchbase：更像业务文档库和搜索服务合一的向量底座 ​

Couchbase 当前官方资料把 Vector Search 放在 Search Service 体系里讲，并明确提到：

  • 可以创建 Search Vector Index
  • 可以在 SDK 中做 vector search
  • 新版本也支持把向量查询与 GSI / SQL++ 结合

这让 Couchbase 更适合：

  • 业务主数据本来就以 JSON 文档形式落在 Couchbase
  • 全文检索、向量检索和应用访问路径希望尽量共用
  • 需要 operational serving 与搜索能力之间的低搬运成本

它的关键优势不是单独某个 ANN 指标，而是：

业务文档、搜索索引和向量检索可以沿着同一套文档数据库心智推进。

但也要保持清醒：

  • 搜索索引设计依然是独立工作
  • 业务流量和检索流量的容量边界仍然要提前治理
  • 如果最终目标是重平台化企业搜索，仍可能需要补更强的搜索运营层

2.17 Supabase：更像托管版 pgvector + RLS + 应用开发体验 ​

Supabase 当前官方资料明确写到：

  • 向量能力底层是 pgvector
  • 可以在 Postgres 里存储与查询 embeddings
  • 文档里直接给出 semantic search、RAG with permissions、RLS 这些路径

这使它特别适合：

  • 已经在用 Supabase 做应用后端
  • 想把认证、RLS、数据库、函数和向量检索放在一套平台体验里
  • 对“带权限的 RAG”有直接需求

它的价值更多在于：

不是重新发明向量数据库，而是把 pgvector 这条路做成更完整的开发与权限集成体验。

但仍要注意：

  • 本质上还是 Postgres 资源模型
  • 仍然要面对 HNSW / IVFFlat、表设计、冷热分层和容量治理
  • 当检索规模继续上涨时，是否继续共库仍然需要重新评估

2.18 Databricks AI Search：更像长在湖仓和数据平台里的检索层 ​

Databricks 当前官方资料把 AI Search 放在 Mosaic AI / Data Intelligence 平台路径里，强调它不是孤立向量库，而是和：

  • Delta / Unity Catalog 数据底座
  • 托管索引
  • metadata 过滤
  • 关键词 + 向量混合检索

一起理解。

这让它更适合：

  • 数据和权限治理本来就在 Databricks 体系里
  • 想把检索直接贴着湖仓数据与特征流演进
  • 团队更偏数据平台，而不是单独再建一套检索中台

它真正的优势更像是：

把向量检索放回现有数据平台治理体系，而不是另起一套检索孤岛。

但也要看清：

  • 它不自动等于成熟的终端搜索产品体验
  • 应用层权限透传、结果呈现和业务工作流仍然要补
  • 如果团队并不运行 Databricks，这条路的迁移门槛并不低

2.18.1 Snowflake Cortex Search：更像数据云里的检索服务 ​

Snowflake 当前官方资料把 Cortex Search 直接定义成面向 Snowflake 数据的低时延、高质量 fuzzy search，并明确说明它适合 RAG 场景；同时文档给出了：

  • Cortex Search Service 的创建路径
  • 通过 Python / REST / SQL 查询服务的路径
  • 刷新、成本和服务化使用方式

这意味着它更适合：

  • 数据已经稳定落在 Snowflake
  • 权限、治理、建模和数据共享主要围绕数据云展开
  • 团队希望把检索尽量贴着现有 Snowflake 数据产品，而不是再额外搬一套搜索底座

它真正解决的问题更像是：

让“数据云里的表”可以更自然地长出检索与 RAG 服务，而不是先把数据复制到另一个向量平台。

但边界同样很明确：

  • 它不是事务型业务数据库，也不是天然完整的终端搜索门户
  • 刷新频率、虚拟仓库成本和服务延迟边界需要提前测清楚
  • 如果要做复杂应用工作流、强实时写入和前台搜索体验，往往还要补应用层服务

2.19 Cloudflare Vectorize：更像贴着边缘计算长出来的向量数据库 ​

Cloudflare 当前官方资料直接把 Vectorize 定位成：

  • built on Cloudflare's network 的 vector database
  • 可直接和 Workers 配合
  • 支持 metadata filtering

这说明它最适合的不是传统重型知识平台，而是：

  • 全球分布式应用
  • 边缘侧个性化、检索增强或实时匹配
  • 希望把检索和边缘执行放在同一运行时里

它的关键价值在于：

不是单纯多一个向量库品牌，而是让“边缘执行 + 向量检索”可以沿同一平台心智设计。

但也别高估：

  • 边缘检索不等于自动适配超大冷知识库
  • 跨区域数据布局、容量和更新节奏仍然要设计
  • 企业级权限和复杂工作流通常还要配合上层系统

2.20 Turbopuffer：更像对象存储原生的 serverless 检索底座 ​

Turbopuffer 当前官方资料把自己描述成 serverless vector search，并强调：

  • namespaces
  • filters
  • full-text search
  • hybrid search
  • 写入后结果可立即查询

这让它很适合：

  • 想要极简、弹性、低运维的检索底座
  • namespace 很多、租户或数据集边界很清晰
  • 希望把对象存储式的数据布局和检索层结合起来

它的亮点不是“又一个 ANN 名字”，而是：

把 serverless 检索、对象级隔离和写后快速可见性放在同一个简洁模型里。

但也要注意：

  • serverless 不会替你自动完成权限建模
  • 查询模式、索引组织和成本边界依然需要测出来
  • 如果应用强依赖复杂全文运营能力，仍可能要补搜索层

2.21 Oracle AI Vector Search：更像企业数据库里的内生向量能力 ​

Oracle 当前官方资料明确把 AI Vector Search 讲成数据库内能力，核心点包括：

  • VECTOR 数据类型
  • similarity search
  • vector indexes
  • SQL 与数据库治理体系内集成

这让它更适合：

  • 企业主数据本来就重度依赖 Oracle
  • 想把事务、SQL、审计和向量检索放在一个数据库心智里
  • 检索要贴着既有企业数据模型和治理流程演进

它真正有价值的地方通常是：

不把向量检索当成外置能力，而是把它纳入既有企业数据库和 SQL 运行模型。

但边界也很清楚：

  • 库内一体化并不等于所有场景都更省钱
  • schema、索引资源和查询隔离仍要认真治理
  • 如果目标是面向终端的大型搜索产品，应用层能力仍要自己补

2.22 Typesense：更像开发者友好的搜索 API + 向量能力 ​

Typesense 当前官方资料把 vector_query、hybrid search、reranking 和自动 embedding 路径放在同一条开发者体验里。

这意味着它更适合：

  • 想快速交付站内搜索、文档搜索或搜索 API
  • 同时需要关键词命中和语义召回
  • 团队更想要简单搜索产品体验，而不是重型检索平台建设

它的优势更像是：

把搜索 API、hybrid 和向量能力打包成较低心智成本的应用开发路线。

但也要提前想清楚：

  • relevance tuning 仍然是长期工作
  • 多租户、权限和复杂治理不会因为 API 简洁就自动消失
  • 当规模和隔离要求继续上升时，是否还适合继续共用同一套底座

2.23 Meilisearch：更像把 typo-tolerant 搜索和 hybrid 检索做成开发者友好产品 ​

Meilisearch 当前官方资料把这些能力放在一条很连贯的产品路径里：

  • hybrid / semanticRatio
  • user-provided embeddings
  • tenant tokens
  • tasks / task webhooks
  • typo tolerance、facets、filtering

这说明它更适合：

  • 想快速交付站内搜索、文档搜索、商品搜索或知识搜索 API
  • 既想保留成熟全文搜索体验，又希望逐步引入 vector / semantic / hybrid
  • 希望多租户隔离先落在 token + filter 这一层，而不是先自建重型搜索平台

它的工程启发很直接：

如果你的核心目标是“先把搜索产品体验和应用接入做顺”，Meilisearch 往往比纯向量底座更贴题。

但也要保持清醒：

  • tenant token 不是完整权限系统替代品
  • hybrid 仍然要做 query、字段权重和结果分析
  • 当索引规模、隔离要求和复杂排序继续上升时，要评估是否要演进到更重的搜索底座

2.24 Apache Solr：更像经典企业搜索平台补齐 dense retrieval 之后的路线 ​

Apache Solr 当前官方参考指南已经把这些能力补得比较完整：

  • Dense Vector Search
  • knn / vectorSimilarity
  • knn_text_to_vector
  • Query Re-Ranking

这意味着 Solr 更适合：

  • 团队已经有 Lucene / Solr 搜索工程积累
  • 目标不是只做 ANN，而是把 schema、全文、过滤、facet、rerank 和 dense retrieval 放在同一搜索平台
  • 希望延续经典企业搜索治理方式，而不是重起一套全新检索栈

它的价值更像是：

不是另起一个“新型向量库”，而是把已有企业搜索平台升级成能做 dense retrieval 的现代检索底座。

边界也很清楚：

  • Solr 的上手门槛不在“能不能查向量”，而在长期搜索工程治理
  • text-to-vector 只是入口，真正上线前仍要压测索引、模型调用和 rerank 成本
  • 如果团队没有搜索平台经验，它不一定比托管型向量库更省心

2.25 Vald：更像 Kubernetes 原生的分布式 ANN 基础设施 ​

Vald 当前官方资料把自己定位成：

  • highly scalable distributed ANN search engine
  • cloud-native architecture
  • automatic vector indexing
  • backup / restore
  • horizontal scaling

这说明它更适合：

  • 团队已经有比较成熟的 Kubernetes、Helm、GitOps 和平台运维能力
  • 你想把向量索引做成平台层基础设施，而不是单个应用侧的内嵌组件
  • 你特别在意滚动升级、分布式索引恢复和集群级长期运营

它的优势不只是“能搜向量”，而是：

把分布式 ANN、Kubernetes 调度和备份恢复路径放在同一套云原生运行模型里。

但也要注意：

  • 这条路对平台工程能力要求明显高于托管服务
  • 备份、恢复、升级和索引一致性都要认真演练
  • 如果只是做一个中等规模 RAG 产品，Vald 可能会显得偏重

2.26 KDB.AI：更像把向量检索放进实时 / 时序数据工作流 ​

KDB.AI 当前官方资料比较强调：

  • similarity search
  • filters
  • 多种 index 类型，例如 Flat / qFlat / IVF / IVFPQ / HNSW / qHNSW
  • contextual / time-series search

这意味着它更适合：

  • 检索对象本身带有时间序列、流式特征或实时模式匹配需求
  • 希望把结构化字段过滤、向量检索和时序分析放进同一条数据工作流
  • 对低延迟、实时数据到达后的近实时搜索有更高要求

它的独特价值通常在于：

不是只做“文本块找相似文本块”，而是把向量检索和时间维度、实时分析一起建模。

当然也要提前想清楚：

  • 时序优势并不自动等于更适合通用知识库问答
  • 应用搜索体验、语义分块和上层引用治理仍然要自己补
  • 如果场景本质上不是实时 / 时序驱动，这条路线未必比通用检索底座更划算

2.27 Zilliz Cloud：更像托管版 Milvus，而不是另一套完全不同的方法论 ​

Zilliz 当前官方资料把它明确描述成 fully managed vector database powered by Milvus，同时把 basic vector search、full-text search、hybrid search、multitenancy 和安全能力放在主路径里。

它更适合：

  • 认可 Milvus 这条分布式向量基础设施路线
  • 但不想自己扛集群、索引节点、扩缩容和日常 SRE 工作
  • 需要托管服务形态下的向量、全文和 hybrid 组合能力

这类方案的价值通常不是“比 Milvus 多了一个全新技术栈”，而是：

把 Milvus 生态里的能力，包装成更容易被业务团队承接的托管底座。

但也要注意：

  • 托管之后，上层数据模型、过滤和权限问题并不会消失
  • 如果你的目标是完整企业搜索门户，依然要补搜索产品层能力

2.28 Gemini Enterprise Agent Platform Vector Search：更像 Google Cloud 托管向量检索服务 ​

Google Cloud 当前官方资料把 Vector Search API 直接描述为 fully-managed vector database，并把它放进 Gemini Enterprise Agent Platform 的 Agent Retrieval / RAG Engine 路线里。

它更适合：

  • 主技术栈已经在 Google Cloud
  • 希望检索和 Agent / 生成式工作流贴得更近
  • 更看重托管扩展性、向量索引服务和云上集成，而不是自己组装底层检索集群

这条路线的典型价值更像：

  • 检索底座直接进入云上的生成式应用框架
  • 检索与上层工作流、权限和平台能力更容易一起演进

但要保持清醒：

  • 托管型向量检索不自动等于完整搜索体验
  • 文档结构、过滤设计、证据链和评测体系还是要自己补

2.29 Azure Cosmos DB：更像“文档和向量存在同一份 JSON 里”的 NoSQL 路线 ​

Azure Cosmos DB 当前官方资料把向量能力直接描述为 integrated vector database，并强调向量可以作为字段直接进入 JSON 文档，同时保留现有文档模型和查询路径。

它更适合：

  • 主业务数据本来就在 Cosmos DB
  • 你不想为第一版 RAG 先搬一套数据到独立向量库
  • 业务更偏 NoSQL 文档模型，而不是搜索平台或独立检索中台

这类路线最核心的价值通常是：

不是另起一套检索基础设施，而是让 operational document + vector search 先在同一条数据路径里闭环。

但要提前想清楚：

  • 分区键、过滤路径和查询成本是否适合你的问答流量
  • 如果后面要做更复杂的 hybrid、搜索运营或多层排序，是否还要再拆搜索层

2.30 ScyllaDB：更像把向量搜索接进高吞吐宽列数据库 ​

ScyllaDB 当前官方资料把 vector search 和 work with vector search 做成独立路径，强调可以在现有 Scylla / CQL 心智里增加向量索引与 ANN 检索能力。

它更适合：

  • 已经在 Cassandra / Scylla 体系里维护高吞吐主数据
  • 希望向量搜索贴着现有宽列表和分区模型生长
  • 更重视写吞吐、低延迟和现有数据库心智延续

这类方案的价值通常在于：

  • 检索能力不必一定迁到完全陌生的新数据库
  • 向量和主业务数据的分区、复制和查询模型更容易保持一致

但也要看到边界：

  • 它首先仍是数据库路线，不是开箱即用的搜索产品
  • 过滤、重排、权限和工作流仍需要上层自己设计

2.31 Turso / libSQL：更像把向量检索带进 SQLite / edge / local-first 应用 ​

Turso 当前官方资料把向量搜索作为 libSQL 的内建能力来介绍，而且明确支持 dense、sparse、binary 和 quantized vectors。

它更适合：

  • local-first 应用
  • SQLite 心智很强的团队
  • 希望在边缘、桌面端或轻量服务里直接把向量和关系数据放在一起

这类路线最吸引人的地方通常不是“最强平台能力”，而是：

你不需要先引入一套额外向量数据库，检索可以直接长在 SQLite / edge 数据层里。

但要提前评估：

  • 同步、复制和多租户边界怎么处理
  • 规模上来后是否还适合继续留在这条轻量路线

2.32 Tiger Data：更像把 pgvector 路线继续推向实时分析与时间维度 ​

Tiger Data 当前官方资料把 vector search 和 AI 能力明确放在产品文档里，并提供向量服务创建与 SQL 接入路径。它延续的是 Postgres 心智，但更强调实时分析、时间序列与应用数据一起运转的工作负载。

它更适合：

  • 已经在 Timescale / Tiger Data 路线上经营事件流、时间序列或实时分析
  • 希望向量检索不要和实时分析平台割裂
  • 团队已经接受 Postgres 路线，而不是额外维护独立检索中台

这类方案最有价值的地方通常是：

  • 向量检索可以和实时分析、时间维度、SQL 查询贴在一起
  • 很多“数据搬来搬去”的工程开销会更小

但同样要留意：

  • 实时分析与检索混部依然要评估资源竞争
  • 如果目标是复杂企业搜索体验，数据库路线仍然不自动等于搜索产品路线

3. 一张够用的选型速查表 ​

方案更像什么最强项最该提前确认什么
Pinecone托管型向量数据库快速上线、namespace、metadata、生产清单是否还需要额外的全文检索、门户搜索和业务库联动
Zilliz Cloud托管版 Milvus 路线Milvus 生态 + 托管交付、全文 / hybrid 能力、减少自运维是否真的只是不想自建 Milvus，还是其实更需要完整搜索平台
Weaviate向量 + 搜索组合引擎named vectors、hybrid、多租户、集合治理向量配置、目标向量、租户模型是否已经设计清楚
Qdrant可控部署的检索底座payload 过滤、hybrid queries、快照、多形态部署collection / payload / tenant 设计是否合理
Milvus分布式向量基础设施规模、索引灵活性、多向量、过滤与一致性调优是否有足够运维能力承接集群复杂度
ValdKubernetes 原生向量引擎云原生部署、自动索引、备份恢复、水平扩展平台团队是否真能长期承接 K8s 集群与索引运维
Azure AI Search企业搜索引擎hybrid、RRF、semantic ranker、filters/facets你的目标是不是“企业搜索”，而不只是“向量库”
Gemini Enterprise Agent Platform Vector SearchGoogle Cloud 托管向量检索云上托管扩展性、Agent Retrieval / RAG 集成、向量索引服务是否已经在 Google Cloud / Agent Platform 生态内，且应用层搜索体验怎么补
Elasticsearch / OpenSearch / Vespa / Apache Solr搜索平台内置向量能力全文、过滤、聚合、排序与向量一体化团队是否真有搜索 schema、ranking、serving 的长期治理能力
Chromalocal-first 向量存储快速原型、Agent memory、文档 + metadata + 查询 API 上手快后续多租户、权限、恢复路径是否需要额外补平台
Astra DBAPI 原生 serverless 向量数据库Data API、vector-enabled collections/tables、hybrid search分区、主键、租户边界和治理模型是否已经设计清楚
ClickHouse / SingleStore / TiDBSQL / HTAP 向量能力SQL + 向量检索 + 结构化过滤 / 分析一体资源隔离、服务治理和知识平台层能力由谁补
MongoDB Atlas Vector Search文档数据库内置向量operational data + 向量检索就地整合是否会和主业务集合争抢资源，后续是否还要拆搜索层
Azure Cosmos DBJSON 文档内置向量向量直接进入文档、NoSQL 模型延续、少搬数据分区键、过滤和成本模型是否适合高频问答检索
Couchbase文档数据库 + 搜索服务JSON 文档、全文与向量检索一体、业务侧接入顺手Search Service 与业务查询服务的容量边界如何治理
Redis内存型实时向量能力热数据、缓存、会话态、低时延检索冷热分层、持久化和长期成本怎么设计
ScyllaDB宽列数据库内置向量高吞吐、现有 CQL / 分区模型延续、向量贴着主数据生长查询模式、热分区与向量索引布局是否会变成新的瓶颈
Neo4j图数据库内置向量图关系 + 语义召回 + GraphRAG是否真的需要关系推理，而不只是普通语义检索
pgvectorPostgreSQL 扩展JOIN、事务、最小化新组件引入向量检索是否会挤占主业务库资源
AlloyDB AI / Azure Database for PostgreSQL / Neon托管 PostgreSQL 向量路线兼容 Postgres、托管运维、向量索引增强、较少新组件引入共库资源竞争、索引策略和事务 / 检索混部边界是否能承受
Supabase托管 Postgres AI 平台pgvector + RLS + 应用开发一体化是否清楚这仍是 Postgres 资源模型，而不是独立检索集群
Tiger DataPostgres + 实时分析 + 向量SQL、时间维度、实时分析和向量一体化分析、事务与检索混部下的容量治理是否能承受
Databricks AI Search湖仓 / 数据平台内检索层Delta / 治理 / 检索一体，贴着数据平台演进应用层搜索体验、权限透传和终端工作流谁来补
Snowflake Cortex Search数据云内搜索服务检索贴着 Snowflake 数据与治理体系刷新成本、服务延迟和终端应用体验是否满足场景
KDB.AI实时 / 时序向量数据库实时数据、时序模式、过滤与多索引路线结合场景是否真的需要时序 / 流式特性，而不只是通用知识检索
Cloudflare Vectorize边缘向量数据库Workers 集成、边缘执行、全球就近服务索引规模、冷数据、复杂治理是否适合放在边缘
Turso / libSQLSQLite / edge 原生向量向量内建、dense / sparse / binary / quantized 支持、lightweight edge 交付同步、多租户和规模增长后是否还适合继续留在轻量路线
Turbopuffer对象存储原生 serverless 检索namespace、filters、hybrid、低运维弹性查询模式、成本边界和权限体系是否设计清楚
Oracle AI Vector Search企业数据库内向量能力SQL、事务、审计和向量检索共用一套数据库治理索引资源、schema 与终端搜索能力边界是否清楚
Typesense搜索 API + 向量能力开发者友好、全文 + 向量 + hybrid 交付快relevance tuning、多租户和长期治理是否可承接
Meilisearch轻量搜索引擎 + hybridtypo tolerance、全文体验、tenant token、task webhooks权限是否只靠 token 还不够，后续相关性治理能否跟上
LanceDB本地 / 湖仓型嵌入式检索多模态样本、训练数据、检索工作流一体线上多租户、权限和服务治理由谁补
FAISSANN 库本地、离线、GPU、自定义算法管线生产所需的权限、过滤、备份、API 层谁来补

4. 选型时真正该比较的六件事 ​

4.1 过滤是不是一等公民 ​

企业场景里，检索条件通常不只是一个 query embedding。

你往往还需要：

  • tenant
  • owner / group
  • 文档类型
  • 生效时间
  • 产品线
  • 版本号
  • 状态位

如果过滤能力不强，或者团队根本没打算认真设计 payload / metadata，那么最终效果很容易停留在 Demo。

4.2 多租户隔离做在什么层 ​

这是最容易被晚发现、但修起来最贵的问题之一。

要提前确认：

  • 是 namespace per tenant、collection per tenant，还是 metadata filter
  • 检索层是否就能做到硬隔离
  • 不活跃租户能不能单独降配、冻结或迁移
  • 是否支持租户生命周期治理和回收

4.3 混合检索、重排、多向量是否是原生能力 ​

如果业务里有编号、错误码、接口名、工单号、日期、产品名，只做纯向量检索通常不够。

所以要看：

  • hybrid search 能不能自然接入
  • 是否支持 rerank / semantic reranker
  • 是否支持多个向量空间
  • 是否支持 dense + sparse 或多表示融合

4.4 新鲜度、快照、回滚和恢复路径 ​

生产系统迟早会遇到这些事：

  • 某批文档入错了
  • 某次 re-embed 效果变差了
  • 某个租户数据需要单独回退
  • 某个索引版本需要蓝绿切换

所以比起“top-k 查得快不快”，更应该先问：

  • 有没有快照 / 备份 / 恢复路径
  • 文档更新后旧记录怎么清
  • embedding 模型切换怎么重建
  • 失败时怎么回滚到上一版

4.5 和现有数据底座怎么配合 ​

如果你本来就有 PostgreSQL、MongoDB、Redis、ES / OpenSearch、对象存储、审计系统、权限系统，那么检索底座不应该孤立设计。

需要提前看清：

  • source of truth 在哪里
  • 父文档、chunk、版本、权限是否能追溯
  • 事务写路径是否需要和业务记录一致
  • 最终是“数据库主导”，还是“检索平台主导”

4.6 团队是否真的有能力承接这套复杂度 ​

同样一套向量能力，对不同团队的真实成本完全不同。

如果团队：

  • 没有专门平台工程能力
  • 没有完善的监控和备份体系
  • 业务上线速度比底层最优更重要

那托管型或一体化能力往往更现实。

反过来，如果团队已经具备：

  • 集群运维
  • 容量治理
  • 蓝绿发布
  • 数据回滚
  • 搜索效果评测

那自托管或更底层的向量基础设施才更容易发挥优势。

5. 按场景给一个更直接的建议 ​

5.1 已有 PostgreSQL，规模中等，想最快把 RAG 接进现有业务 ​

优先试 pgvector。

原因通常不是它“最强”，而是它能把：

  • 向量
  • 业务表
  • 权限
  • 事务
  • 备份恢复

尽量留在同一套数据库心智里。

如果你已经跑在 AlloyDB AI / Azure Database for PostgreSQL / Neon 这类托管 Postgres 路线上，也应该优先沿这条路线先把检索做深，再决定是否真的要外接独立向量库。

5.2 做企业搜索门户，关键词、过滤、语义和排序都重要 ​

优先看 Azure AI Search / Elasticsearch / OpenSearch / Vespa 这类搜索引擎形态。

因为你的问题更像 企业搜索，而不是单纯“存向量”。

5.3 做多租户 SaaS 知识检索，想快点上线并减少自运维 ​

优先看 Pinecone，其次结合团队偏好考虑 Qdrant Cloud 或其他托管形态。

重点先把这些设计清楚：

  • namespace / tenant 边界
  • metadata
  • structured IDs
  • freshness
  • 删除回滚

5.4 做自托管、高规模或多向量检索平台 ​

优先看 Milvus / Weaviate / Qdrant 这一类。

这时候不该只问谁的 ANN 快，而要问：

  • 谁更适合你的部署边界
  • 谁更适合你的租户模型
  • 谁更适合你的 hybrid / rerank / multi-vector 设计
  • 谁的备份恢复与升级路径更能被团队承接

5.5 做本地、边缘、离线或研究型检索 ​

优先看 FAISS / LanceDB，以及需要时结合 Qdrant Edge 这类更贴近落地的边缘方案。

这种场景下你通常最关心的是：

  • 本地性能
  • GPU 利用
  • 自定义索引控制
  • 轻量同步或离线处理

5.6 业务主数据就在 MongoDB，想把语义检索就地接进去 ​

优先看 MongoDB Atlas Vector Search。

这类场景的关键不是“最强检索引擎”，而是：

  • operational data 已经在集合里
  • 你希望尽量少搬运数据
  • 应用开发、查询接口和数据治理想先共用一套文档模型

5.7 热点知识、会话记忆或缓存态检索特别重 ​

优先看 Redis。

因为这时你往往更在意：

  • 亚秒级甚至更低延迟
  • 会话态、个性化上下文与检索结果一起管理
  • 向量、过滤和缓存命中在同一实时层协同

5.8 检索要和实体关系、路径依赖、GraphRAG 一起推理 ​

优先看 Neo4j。

因为你的核心问题已经不只是“找相似 chunk”，而是：

  • 相似内容属于哪个实体
  • 实体之间怎么连
  • 哪条依赖链或权限传播路径需要一起进入答案上下文

5.9 已经在做 local-first 工具、Agent memory 或个人知识工作台 ​

优先看 Chroma。

因为这时你通常更在意：

  • 本地即可运行
  • 集合、文档、metadata 与查询 API 尽快接起来
  • 用最低的基础设施成本把 retrieval 闭环先跑通

5.10 想用 API 原生 serverless 方式把向量能力接进应用 ​

优先看 Astra DB。

这类场景的关键往往是：

  • 向量集合或表要尽快可用
  • 希望同时保留 filters / hybrid search
  • 团队更偏应用开发，而不是先建设搜索平台

5.11 想把向量检索和 SQL / 分析工作负载放在同一体系 ​

优先看 ClickHouse / SingleStore / TiDB。

这时更应该问的不是“哪家名字更像向量库”，而是：

  • 你的查询主心智是 SQL 还是搜索 API
  • 向量查询是不是要和分析、聚合、实时数据一起工作
  • 数据团队是否已经能长期治理这套数据库底座

5.12 主业务文档就放在 Couchbase，想把搜索能力就地长出来 ​

优先看 Couchbase。

因为这类场景最重要的通常不是另起一套向量平台，而是：

  • 业务文档模型不想反复搬运
  • 全文搜索和向量搜索都要进入同一应用体系
  • SDK、查询服务和索引服务最好能沿同一套数据库心智演进

5.13 已经用 Supabase 做后端，还要把权限一起带进 RAG ​

优先看 Supabase + pgvector。

这时最有价值的是：

  • Postgres、认证、RLS、函数和向量能力可以一起设计
  • 带权限的检索路径可以直接落在数据库授权模型上
  • 团队不用先拆出一套独立检索平台也能把第一版生产链路做起来

5.14 数据已经在 Databricks / Delta / Unity Catalog，想把检索放进数据平台 ​

优先看 Databricks AI Search。

因为这类场景真正重要的通常是：

  • 数据治理和权限模型已经在湖仓平台里
  • 检索要和表、管道、评测数据一起演进
  • 团队更擅长数据平台，而不是重新维护独立检索中台

如果你的主数据平台其实是 Snowflake，也应该并行评估 Snowflake Cortex Search，因为它解决的是类似的“让检索贴着数据云长出来”的问题，只是生态位不在 Databricks。

5.15 应用跑在 Workers 或边缘侧，希望检索也尽量就近执行 ​

优先看 Cloudflare Vectorize。

这时更关键的是：

  • 执行环境和检索环境最好贴在一起
  • 全球低时延和区域就近访问比复杂平台能力更重要
  • 检索规模、热冷分层和权限需求要提前确认，不要默认边缘能吃下所有负载

5.16 想要 namespace 很多、低运维、写后尽快可查的 serverless 检索底座 ​

优先看 Turbopuffer。

这类场景最看重的通常是：

  • serverless 运维心智
  • dataset / tenant 边界清晰
  • 过滤、hybrid、全文信号和写后可见性都希望在同一层解决

5.17 企业主数据、SQL 和治理体系深绑定 Oracle ​

优先看 Oracle AI Vector Search。

因为这时最有价值的不是另起一套向量平台，而是：

  • 既有 Oracle 数据模型不想搬
  • 检索要和 SQL、事务、审计一起落地
  • 企业数据库团队更容易承接这条演进路线

5.18 想快速做站内搜索、文档搜索或搜索 API，而不是先搭重型平台 ​

优先看 Typesense。

因为这类场景更看重：

  • 开发者友好的搜索 API
  • 关键词、向量和 hybrid 一起快速交付
  • 先把搜索产品体验跑出来，再决定后续是否平台化

5.19 已经在 Google Cloud / Agent Platform 生态，希望检索和生成式工作流贴在一起 ​

优先看 Gemini Enterprise Agent Platform Vector Search。

因为这时你更看重的通常是：

  • 向量检索服务直接长在 Google Cloud 体系里
  • 后续和 Agent Retrieval、RAG Engine、云上生成式应用一起演进
  • 团队更愿意沿云上托管服务交付，而不是先自建检索中台

5.20 想用 Milvus 方法论，但不想自己养 Milvus 集群 ​

优先看 Zilliz Cloud。

因为这类场景的关键通常不是“另找一个完全不同的数据库”，而是：

  • 认可 Milvus 这条向量基础设施路线
  • 但不想先扛扩缩容、索引节点和日常运维
  • 希望先用托管形态把向量、全文和 hybrid 跑起来

5.21 主数据已经在 Cosmos DB，想把文档和向量留在同一份 JSON 模型里 ​

优先看 Azure Cosmos DB。

因为你最在意的通常是：

  • 业务文档不想先搬到另一套检索存储
  • 向量字段希望直接和文档主键、分区键、业务属性一起治理
  • 应用仍然沿现有 NoSQL 文档模型演进

5.22 已经在 Cassandra / Scylla 路线上跑高吞吐业务，想把向量能力接进现有数据库心智 ​

优先看 ScyllaDB。

因为这类场景最重要的往往是：

  • 不想为了第一版语义检索完全改掉主数据底座
  • 分区模型、复制和低时延能力希望延续
  • 团队已经更擅长宽列数据库，而不是搜索中台或独立向量平台

5.23 做 local-first、边缘应用或 SQLite 原生应用，希望向量能力内建而不是外挂 ​

优先看 Turso / libSQL。

因为这时更有价值的通常是：

  • 向量和关系数据直接留在 SQLite / edge 数据层
  • dense、sparse、binary、quantized 这类向量形态可以原生处理
  • 工程复杂度比“平台最强”更重要

5.24 已经在做时间序列、事件流或实时分析，还想把向量检索一起压到 Postgres 路线里 ​

优先看 Tiger Data。

因为这类场景的核心问题通常是：

  • 时间维度和向量检索要不要一起进入 SQL 工作流
  • 检索和实时分析是否应该共用一套数据库心智
  • 团队更愿意沿 Postgres 体系扩展，而不是额外维护独立检索平台

6. 一个比较稳的演进路径 ​

如果你现在还没完全确定方向，比较稳的做法通常是：

  1. 先用最贴近现有系统的方案快速跑通闭环。
  2. 把 chunk、metadata、过滤、版本链路、引用和评测先做对。
  3. 再根据规模、租户隔离、成本和吞吐决定是否上独立检索底座。

常见演进路径通常会长成下面这样：

  • POC / 内部试点：pgvector 或托管型服务快速起步
  • 业务上线：补 namespace / tenant / metadata / rollback / freshness，必要时按热数据 / 冷数据分层
  • 平台化：引入独立检索底座、评测门禁、蓝绿切换、回放和容量治理

这比一开始就为了“未来最强”而上最重基础设施，通常更稳。

7. POC 前最好先问完的十个问题 ​

  1. 你的问题本质上是“企业搜索”还是“RAG 召回底座”？
  2. 你是否已经明确 source of truth 在哪里？
  3. 你最重的过滤条件是什么？
  4. 你是否真的需要多租户硬隔离？
  5. 你是否需要 hybrid search、rerank 或 named vectors？
  6. 文档更新、删除、embedding 升级怎么回滚？
  7. 你要不要把向量和业务表放在一个事务边界里？
  8. 团队是否有能力长期运维自托管集群？
  9. 你当前最敏感的是成本、时延、质量，还是治理？
  10. 未来半年更可能先遇到的是“规模瓶颈”，还是“治理瓶颈”？

如果这十个问题还没回答清楚，直接比较产品名字通常意义不大。

8. 推荐搭配阅读 ​

9. 重点官方资源 ​

以下资源已按 2026-07-09 复核可访问：