别急着上Milvus——FAISS、Chroma、LanceDB，轻量级向量库怎么选

烟雨平生

发布于 2026-06-24 16:00:09

3320

上次写了Pinecone、Milvus、Qdrant、Weaviate的横评，评论区有粉丝问：

问得好。说实话，我第一次搭RAG的时候，上来就部署Milvus，折腾了半天etcd+MinIO三件套，最后发现我的数据量才5000条。

杀鸡用牛刀，刀还把厨房炸了。

今天补上这篇，专门聊轻量级向量库——FAISS、Chroma、LanceDB，加上一个新选手sqlite-vec。到底什么场景该用它们，什么时候必须换重的。

先搞清楚：为什么需要轻量级向量库

不是所有项目都需要亿级向量存储。实际工作中，大量RAG项目的数据规模是这样的：

个人知识库：几百到几千条文档
小型客服系统：一两万条FAQ
企业内部Wiki：几万条
个人项目/Demo：几十到几百条

这种规模，你去部署Milvus？就像买个仓库来放一个书包。

轻量级向量库的核心价值就三个字：够用就行。

不用部署服务，不用装Docker，pip install一下就能跑。开发快，调试方便，部署简单。

但它们也有天花板——到了一定规模，你必须迁移到生产级方案。这个天花板在哪，下面逐个讲。

FAISS：Meta出品的老牌选手

FAISS是Facebook（现在的Meta）开源的相似度搜索库，2017年就发布了，算是向量检索领域的"祖师爷"。

严格来说，FAISS不是数据库，是一个算法库。它只负责一件事：给你一堆向量，帮你快速找到最相似的。没有HTTP API，没有CRUD，没有权限管理。

▪ 核心优势

性能极致。 FAISS用C++写的，底层做了大量SIMD指令优化。在我实测中，100万条768维向量，IVF索引下查询延迟稳定在2-5ms，比Qdrant还快一截。

索引算法丰富。 Flat（暴力搜索，精确）、IVF（倒排索引）、HNSW（图索引）、PQ（乘积量化压缩）、IVF-PQ组合……你可以根据数据量、内存预算、精度要求自由组合。

▪ 代码示例（最简用法）

import faiss import numpy as np # 1000条768维向量 vectors = np.random.rand(1000, 768).astype('float32') # 建索引（最简单的Flat暴力搜索） index = faiss.IndexFlatIP(768) index.add(vectors) # 查询最相似的5条 query = np.random.rand(1, 768).astype('float32') scores, indices = index.search(query, 5)

就这几行代码，你就有了一个能做向量搜索的东西。

▪ 致命短板

没有任何数据库功能。 没有持久化（得自己存文件），没有增删改查（删一条向量要重建索引），没有过滤（不能说"只在我这个namespace里搜"），没有HTTP服务（你得自己包一层API）。

只适合嵌入式使用。 你需要自己管理向量到文档ID的映射、自己处理持久化、自己做metadata过滤。等于你拿引擎自己造车。

▪ 适合谁

你只需要向量检索算法，其他自己搞
对性能有极致要求（比如千万级向量，毫秒级响应）
你的项目已经有数据库，只缺一个相似度搜索模块
研究型项目、论文复现

不适合： 需要完整CRUD、需要过滤、不想自己造轮子的人。

Chroma：RAG时代的当红炸子鸡

Chroma（之前叫ChromaDB）是专门为RAG设计的轻量级向量库，2022年发布，借着LLM的东风迅速火了起来。

和FAISS最大的区别：Chroma是完整的向量数据库，不只是算法库。

▪ 核心优势

开箱即用。 pip install chromadb，三行代码就能跑：

import chromadb client = chromadb.PersistentClient(path="./my_db") collection = client.create_collection("docs") # 直接存文本，Chroma自动调embedding模型做向量化 collection.add( documents=["Java是一门语言", "Python也很流行"], metadatas=[{"topic": "java"}, {"topic": "python"}], ids=["1", "2"] ) # 查询 results = collection.query( query_texts=["编程语言"], n_results=2 )

看到没？你连embedding模型都不用自己找——Chroma内置了默认的embedding函数（sentence-transformers），塞文本进去就能用。

这是Chroma最大的设计哲学：让开发者专注业务逻辑，不折腾基础设施。

持久化自带。 SQLite做底层存储，数据自动落盘，重启不丢。

metadata过滤。 可以按标签过滤搜索范围，这对实际业务太重要了。

▪ 致命短板

性能上限低。 Chroma底层默认用duckDB + sqlite-vec，性能在10万条以下很流畅，到了几十万就开始明显变慢。百万级别？别想了。

分布式不支持。 单机运行，没有集群模式。数据量到天花板了，迁移是唯一出路。

版本迭代破坏性变更多。 0.4到0.5版本API改了好几次，升级的时候容易踩坑。

▪ 适合谁

RAG项目原型开发、Demo验证
个人知识库、小型问答系统
快速验证想法，不想折腾基础设施
数据量10万以内

LanceDB：列式存储的黑马

LanceDB是个比较新的选手，基于Lance列式存储格式（Rust写的），设计思路和前两个完全不同。

它的核心理念：向量库不需要是一个独立服务，而是一个文件格式。

▪ 核心优势

零部署，零服务。 LanceDB的数据全部存在本地文件里（.lance格式），就像SQLite一样——不需要启动任何服务进程，直接读写文件。

import lancedb db = lancedb.connect("./my_lancedb") table = db.create_table("docs", data=[ {"vector": [1.1, 1.2], "text": "hello", "source": "doc1"}, {"vector": [0.2, 1.8], "text": "world", "source": "doc2"} ]) results = (table .search([1.0, 1.0]) .where("source = 'doc1'") .limit(1) )

查询性能优秀。 因为底层是列式存储，向量检索+metadata过滤可以一起优化。在10-100万向量规模下，性能比Chroma好，接近Qdrant。

多模态友好。 Lance格式天然支持存储向量、文本、图像、视频等多种数据类型，适合作多模态RAG的存储层。

真正的Serverless。 数据就是文件，你可以放本地、放S3、放任何对象存储。

▪ 致命短板

生态小。 比Chroma还小。遇到问题，中文资料几乎没有，英文资料也不多。

API还在快速变化。 0.x阶段，每次升级都可能有不兼容变更。

没有独立服务模式。 如果你的多个服务需要共享同一个向量库，文件模式就不太方便了（需要共享文件系统）。

▪ 适合谁

想要Chroma的易用性 + 比Chroma更好的性能
多模态RAG项目
数据量10万-100万
喜欢文件式存储的简洁性

sqlite-vec：最极致的轻量

sqlite-vec是2024年出现的新方案，思路极其暴力：给SQLite加一个向量搜索扩展。

你用SQLite存业务数据，加一个扩展就能做向量检索，不需要任何额外的组件。

-- 加载扩展 .load ./vec0 -- 建表 CREATE TABLE docs ( id INTEGER PRIMARY KEY, content TEXT, embedding FLOAT[768] ); -- 向量搜索 SELECT id, content, distance FROM docs WHERE embedding MATCH '[0.1, 0.2, ...]' ORDER BY distance LIMIT 5;

用SQL直接做向量搜索，不需要学新API，不需要装新依赖。如果你的项目已经在用SQLite，加向量搜索就是一条SQL的事。

性能在几万到几十万规模下够用，更适合小型项目和个人工具。

四个选手对比

维度	FAISS	Chroma	LanceDB	sqlite-vec
定位	算法库	轻量向量库	文件式向量库	SQLite扩展
语言	C++/Python	Python	Rust/Python	C/SQL
内置embedding	❌	✅	❌	❌
metadata过滤	❌	✅	✅	✅（SQL）
持久化	手动管理	✅ 自动	✅ 自动	✅ SQLite
性能天花板	千万级	十万级	百万级	几十万
学习成本	中	极低	低	低
生态	成熟	好	小	刚起步
部署方式	嵌入式	嵌入式	嵌入式	嵌入式