你有一个 RAG 项目，或者想做语义搜索，或者想给用户推荐"相似内容"。打开搜索引擎一搜——好家伙，十个八个向量数据库出现在你面前。Milvus、Qdrant、ChromaDB、Pinecone、pgvector、Redis Stack、LanceDB、Weaviate、FAISS、sqlite-vec……

你一个项目都还没写，先花了两天选型。

这文章帮你省掉那两天。我不是来推销其中任何一个的。我是来给你一张地图，外加一句直接的话：按你的项目规模选，别按热度选。

先搞清楚你属于哪个阵营

选向量数据库之前，先回答三个问题：

你有多大数据量？ 几百个文档？几千万条记录？百亿级？
你在不在乎运维成本？ 一个人搞定还是有个团队？
你怕不怕厂商锁定？ 全托管的爽是一时的，迁移的痛是长久的。

按这三个维度，我把项目分为四个规模档：

规模	向量数	典型场景	核心约束
微型	<1万	个人知识库、小站相似推荐	零运维、嵌入现有系统
小型	1万-100万	中小型 RAG、内容平台	成本可控、部署简单
中型	100万-1亿	企业级搜索、推荐系统	性能要稳、能水平扩展
大型	>1亿	搜索引擎、多模态检索	分布式、GPU加速、多租户

下面每个档位我给出推荐方案和理由，顺带告诉你 「谁在这个档位是坑」——不绕弯。

微型项目（<1万向量）

你只是一个程序员，一个个人项目，一个周末想跑起来的验证概念原型。别碰任何需要装 Docker 的东西。

✅ 首选：sqlite-vec

一句话定位：给 SQLite 装上向量搜索能力的纯 C 扩展，零依赖、单文件、pip install 就能用。

优点：

零运维——你的 SQLite 数据库文件里就能存向量
单文件架构，备份就是拷个文件
支持多种索引类型（flat、IVF、HNSW）
和 SQLite 的全文搜索（FTS5）可以混用，做 hybrid search 不需要额外组件
Apache 2.0 协议，MIT 可选

缺点：

项目还在 v0.1.x，API 可能变
没有分布式能力，数据量大了就是瓶颈
纯 CPU 模式下，百万级向量搜索延迟开始上升

适用场景：个人博客的相似文章推荐、本地知识库、原型验证。

# 就这么简单
import sqlite3
import sqlite_vec

db = sqlite3.connect(":memory:")
db.enable_load_extension(True)
sqlite_vec.load(db)
db.enable_load_extension(False)

# 建表、插入、查询——全在 SQL 里
db.execute("""
    CREATE VIRTUAL TABLE vec_items USING vec0(
        embedding float[384] distance_metric=cosine
    )
""")

这就是全部。没有 Docker Compose，没有配置文件，没有环境变量。

✅ 备选：LanceDB

一句话定位：嵌入式列式向量数据库，和 ML 生态（PyTorch、HuggingFace、Pandas）深度绑定。

优点：

列式存储（Lance 格式），零拷贝读取
原生支持多模态数据（文本 + 图像 + 表格）
和 ML pipeline 集成极好
支持按时间旅行查询（数据版本控制）

缺点：

目前 5K GitHub stars，社区还在成长
写放大问题在大量小写入时比较明显
纯嵌入式，没有 server 模式

选谁：如果你的数据已经以 Parquet/Arrow 格式存在，LanceDB 是天然拍档。如果你的数据就是 SQL 世界的东西，sqlite-vec 更自然。

❌ 这个档位不要碰：Milvus、Pinecone、Weaviate

不是它们不好，是它们为这个档位太重了。你只有几百个向量的时候，启动一个 Milvus 集群的时间比你写完整业务代码的时间还长。Pinecone 你需要注册账号、绑定信用卡、处理 API 限流——只为了搜 500 篇文章。没必要。

小型项目（1万-100万向量）

你需要一个真正跑在服务器上的服务了，但仍希望运维成本低到"一个 Docker Compose 文件搞定"。

✅ 首选：ChromaDB

一句话定位：Python 生态最友好的向量数据库，pip install chromadb 就能跑，内存占用极小。

优点：

部署难度为 1——真·pip install，不开玩笑
单进程运行，内存占用 200MB 就能跑 50 万向量
Python-first，embedding 函数可以直接传进去自动计算
天然支持 metadata 过滤
Apache 2.0

缺点：

超过 100 万向量后性能开始下降
没有原生的分布式能力
并发写性能一般

import chromadb

client = chromadb.Client()  # 一行搞定
collection = client.create_collection(name="my_docs")

# 自动 embedding
collection.add(
    documents=["这是第一篇文章", "这是第二篇文章"],
    metadatas=[{"source": "blog"}, {"source": "blog"}],
    ids=["doc1", "doc2"]
)

results = collection.query(query_texts=["找相似的文章"], n_results=5)

适用场景：中小型 RAG 系统、文档问答、原型到 MVP 的无缝过渡。

✅ 次选：pgvector（如果你已经在用 PostgreSQL）

一句话定位：PostgreSQL 的向量搜索扩展，让你在原有数据库上直接做语义搜索，不需要引入任何新组件。

优点：

如果你已经在用 PostgreSQL，零新增运维
ACID 事务、备份、高可用——PG 的能力全继承
支持 IVFFlat 和 HNSW 两种索引
可以和全文搜索、地理空间搜索自由组合
协议友好

缺点：

索引构建慢（特别是 IVFFlat 的 training 阶段）
查询性能比专用向量库差一些（但 100 万级以内完全够用）
混合查询（向量 + 标量过滤）的优化不如 Qdrant 等专用库

-- 几百万向量以内，就这一张表
CREATE TABLE documents (
    id BIGSERIAL PRIMARY KEY,
    content TEXT,
    embedding vector(384)
);

CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

SELECT content, 1 - (embedding <=> query_embedding) AS similarity
FROM documents
ORDER BY embedding <=> query_embedding
LIMIT 10;

为什么在这里推荐 pgvector 而不是前面的 sqlite-vec？ 因为 10 万+向量时，pgvector 的 HNSW 索引和 PostgreSQL 的并发能力明显优于 SQLite 单线程模型。

✅ 备选：Redis Stack

一句话定位：如果系统已经在用 Redis，加一个向量搜索模块不需要引入新技术栈。

优点：

亚毫秒级搜索延迟（纯内存）
支持 TTL、pub/sub、stream——同一个 Redis 实例
FT.SEARCH 语法和全文搜索统一
支持 KNN 和 range search

缺点：

纯内存存储，100 万 384 维 float 向量 ≈ 1.5GB 内存
超过可用内存就需要淘汰策略
持久化不如 PG 健壮

适合场景：实时推荐、缓存侧的向量搜索、高吞吐低延迟场景。不适合：数据量大到超出内存、需要强一致性的场景。

❌ 这个档位可能踩的坑：Pinecone

Pinecone 在小规模（10万向量以内）体验很好，免费额度也够用。但它的问题是定价模糊——看起来免费，一旦向量数从 10 万涨到 50 万，月费直接跳到三位数。而且从 Pinecone 迁移到自建方案的成本很高，因为导出的向量格式是私有的。作为 MVP 合适，但长期持有要小心。

中型项目（100万-1亿向量）

你需要分布式能力了。单机内存不够放了，查询并发上来了，索引构建不能停服了。这个档位开始，选型变得关键——选错了迁移成本很高。

✅ 首选：Qdrant

一句话定位：Rust 写的高性能向量数据库，单二进制部署，预过滤能力是业界标杆。

优点：

Rust 实现，性能强悍、内存安全
单二进制文件部署（Docker 也只要一个镜像）
预过滤能力——向量搜索之前先做标量过滤，性能远优于 pgvector 的后过滤
支持 payload 存储和索引（JSON schema）
水平扩展（节点间自动分片复制）
gRPC + REST API

缺点：

生态不如 Milvus 丰富
GPU 加速不如 Milvus 成熟
企业功能需要商业许可（但核心功能开源足够）

from qdrant_client import QdrantClient

client = QdrantClient(host="localhost", port=6333)

# 带 payload 过滤的查询
client.search(
    collection_name="my_collection",
    query_vector=[0.1, 0.2, ...],
    query_filter=models.Filter(
        must=[
            models.FieldCondition(
                key="category",
                match=models.MatchValue(value="technology")
            ),
            models.FieldCondition(
                key="timestamp",
                range=models.Range(gte=1700000000)
            )
        ]
    ),
    limit=10
)

适用场景：企业级语义搜索、电商推荐、内容平台的个性化推荐。

⚠️ 次选：Weaviate

一句话定位：图语义 + 向量混合的数据库，自带 vectorizer 模块，不需要自己跑 embedding 模型。

优点：

内置 vectorizer（OpenAI、Cohere、HuggingFace 等 15+ 模型）
GraphQL API，查询表达力强
混合搜索（BM25 + vector hybrid）开箱即用
对象之间可以建立 cross-reference 关系

缺点：

架构复杂（需要容器编排，模块镜像管理麻烦）
相比 Qdrant，配置项多、学习曲线陡
内置 vectorizer 虽然是方便，但也意味着每次查询都过一遍模型——延迟和成本需要估算

适合场景：知识图谱 + 语义搜索结合的项目、需要 GraphQL API 的团队。不太适合：纯向量检索场景（太重了）。

❌ 这个档位的争议点：Milvus

Milvus 在这个档位是矛盾的。它的架构（消息队列 + 分布式 worker + GPU 索引）是为大型集群设计的，在千万级也跑得不错。但问题在于运维成本——你的团队里有一个懂 Milvus 的人吗？出了 P channel 分裂、index node 挂了、query node OOM 了，谁来修？

如果你有专职的 infra/DevOps 团队，并且需要 GPU 加速索引，Milvus 是合理的。如果是一个 3-5 人的后端团队兼运维，Qdrant 是更好的选择。

大型项目（>1亿向量）

你要么在做搜索引擎，要么在做多模态检索。这个档位拼的是分布式能力、GPU 加速、多租户隔离。

✅ 首选：Milvus（准确说，是 Zilliz Cloud）

一句话定位：分布式向量数据库的事实标准，GPU 加速索引，微服务架构，支持十亿级向量检索。

优点：

GPU 加速索引构建（IVF_PQ、HNSW、DiskANN）
微服务架构（独立扩缩容 query node/index node/data node）
支持 dense + sparse hybrid 搜索
多租户原生支持（collection level 隔离）
国内有 Zilliz Cloud 服务

缺点：

部署复杂度 4/5（至少需要 etcd + MinIO/S3 + 多个 worker）
运维难度高（出了性能问题需要看几个组件的日志）
资源消耗大（3 节点起步，内存/CPU 需求不小）

✅ 备选：Pinecone（如果你不想管运维）

Pinecone 在大规模场景下的价值在于真的不用你管——自动扩缩容、自动索引优化、自动故障恢复。你只管丢向量进去，它 backend 是什么你完全不需要关心。

代价：

贵（大规模下月费数千到数万美金）
锁定（私有格式，导出困难）
你没有控制权（哪天定价变了、功能下线了，你只能接受）

✅ FAISS + 自定义检索层

对于真正的"工业级"场景（十亿级、百亿级），很多公司最终走的是 FAISS + 自定义路子。FAISS 不做持久化、不做分布式、不是 DB——但它给你最高性能和完全控制权。

典型架构：FAISS 做索引 + S3/MinIO 做持久化 + Redis 做缓存 + 自研调度层。上层微服务处理写入和查询分发。

适合：搜索引擎公司、大型 AI infra 团队。不适合：不想自己写 infra 的团队（那你用 Milvus 或 Pinecone）。

横向对比总表

方案	部署难度	小规模	中规模	大规模	运维成本	License	适合谁
sqlite-vec	1/5	✅✅	❌	❌	零	Apache 2.0	个人项目
LanceDB	1/5	✅✅	⚠️	❌	极低	Apache 2.0	ML pipeline
ChromaDB	1/5	✅✅	✅	❌	极低	Apache 2.0	RAG MVP
FAISS	2/5	✅✅	✅✅	✅✅	中	MIT	高纯性能需求
pgvector	2/5	✅✅	✅	⚠️	低	PG 协议	PG 用户
Redis Stack	2/5	✅✅	⚠️	❌	低	RSALv2	实时搜索
Qdrant	2/5	✅✅	✅✅	✅	低	Apache 2.0	中型企业首选
Weaviate	3/5	✅	✅	✅	中	BSD-3	知识图谱
Milvus	4/5	❌	⚠️	✅✅	高	Apache 2.0	大型集群
Pinecone	0/5	✅✅	✅✅	✅✅	零	Proprietary	不想管运维

三个场景的直觉判断

场景一：你在做一个个人博客的「相似文章」推荐 → sqlite-vec。在你的 SQLite 数据库上直接做，一行代码的事。向量数不会超过几千，没必要引入任何组件。

场景二：你在做一个 SaaS 产品的 RAG 问答功能，有几万到几十万文档 → 已用 PostgreSQL → pgvector。未用 PostgreSQL → ChromaDB。MVP 阶段不用考虑分布式，等跑起来流量确定了再迁不迟。

场景三：你的公司要做电商语义搜索，千万级 SKU，高并发 → Qdrant。Rust 性能、预过滤能力、部署简单是你需要的平衡点。等规模到亿级再考虑 Milvus。 → 如果你不想运维任何人 → Pinecone。但接受它不便宜的定价。

场景四：你在做搜索引擎 / 多模态检索，百亿级数据 → Milvus 集群或者自建 FAISS 体系。这条路没有捷径，你的团队里必须有懂向量索引的工程师。

最后的建议

向量数据库这个领域，2026 年的现状是：选项很多，但真正差异化的不多。

HNSW 索引算法，FAISS 有、Qdrant 有、Milvus 有、pgvector 有——核心搜索能力趋同
差异在：部署模型、运维成本、生态集成、payload 过滤、分布式策略

所以我的选型逻辑很简单：先看你的 PG 能不能扛，再看你愿不愿意管一个专用服务。两者都否，上 ChromaDB 最快。还不够——上 Qdrant。还不够——请人。

别被 GitHub star 数骗了。star 多不等于适合你的项目。你的 10 万文档小项目，sqlite-vec 或 pgvector 轻松扛住，但你选了 Milvus——多出来的运维债务，不会因为你 star 多就自动消失。

Vector Database Selection Guide 2026: From a Single File to Billion-Scale Clusters

You have a RAG project, or semantic search to implement, or "similar content" recommendation. Open a search engine — a dozen vector databases hit you in the face. Milvus, Qdrant, ChromaDB, Pinecone, pgvector, Redis Stack, LanceDB, Weaviate, FAISS, sqlite-vec…

You haven't written a line of code yet, and you've already spent two days on "selection."

This article saves you those two days. I'm not here to sell you any of them. I'm giving you a map and a direct statement: Pick by your project size, not by hype.

First, figure out which camp you're in

Before choosing a vector database, answer three questions:

How much data? A few hundred documents? Millions? Billions?
What's your ops budget? One person handling everything, or a team?
How afraid are you of vendor lock-in? Fully managed is nice until you need to leave.

Based on these three dimensions, I split projects into four tiers:

Tier	Vector Count	Typical Use	Main Constraint
Micro	<10K	Personal knowledge base, small-site recommendations	Zero ops, embed into existing stack
Small	10K-1M	Small-to-medium RAG, content platforms	Cost control, simple deploy
Medium	1M-100M	Enterprise search, recommendation systems	Stable performance, horizontal scaling
Large	>100M	Search engines, multimodal retrieval	Distributed, GPU-accelerated, multi-tenant

Below is my recommendation for each tier, along with honest "who's a trap here." No beating around the bush.

Micro Projects (<10K Vectors)

You're a solo developer with a weekend project or a proof-of-concept. Don't touch anything that requires Docker.

✅ First Choice: sqlite-vec

One-liner: A pure C extension that gives vector search to SQLite. Zero dependencies, single file, works with pip install.

Pros:

Zero ops — your SQLite DB file now holds vectors
Single-file architecture — backup means copying one file
Multiple index types (flat, IVF, HNSW)
Works with SQLite FTS5 for hybrid search without extra components
Apache 2.0 (also MIT-relicensable)

Cons:

Still v0.1.x, API may change
No distributed capability
CPU-only, latency rises at million-scale

Best for: Personal blog similar-article recommendations, local knowledge bases, prototype validation.

import sqlite3
import sqlite_vec

db = sqlite3.connect(":memory:")
db.enable_load_extension(True)
sqlite_vec.load(db)
db.enable_load_extension(False)

db.execute("""
    CREATE VIRTUAL TABLE vec_items USING vec0(
        embedding float[384] distance_metric=cosine
    )
""")

That's it. No Docker Compose, no config files, no environment variables.

✅ Backup: LanceDB

One-liner: Embedded columnar vector database, tightly integrated with ML ecosystems (PyTorch, HuggingFace, Pandas).

Pros:

Columnar storage (Lance format), zero-copy reads
Native multi-modal data support (text + image + tables)
Excellent ML pipeline integration
Time-travel queries (data versioning)

Cons:

~5K GitHub stars, community still growing
Write amplification under small, frequent writes
Pure embedded, no server mode

Pick this if your data already exists in Parquet/Arrow format. Otherwise, sqlite-vec is more natural.

❌ Don't Touch at This Tier: Milvus, Pinecone, Weaviate

They're not bad — they're just too heavy for this tier. Starting a Milvus cluster takes longer than writing your entire business logic for 500 vectors. Pinecone needs an account, a credit card, and API rate-limit management. Unnecessary.

Small Projects (10K-1M Vectors)

You need a real service running on a server, but ops cost should be "one Docker Compose file."

✅ First Choice: ChromaDB

One-liner: The most Python-friendly vector database. pip install chromadb and you're running. Tiny memory footprint.

Pros:

Deployment difficulty: 1/5
Runs in a single process, ~200MB RAM for 500K vectors
Python-first — pass embedding functions directly
Native metadata filtering
Apache 2.0

Cons:

Performance degrades past 1M vectors
No native distributed support
Concurrent write performance is average

import chromadb

client = chromadb.Client()
collection = client.create_collection(name="my_docs")

collection.add(
    documents=["First article", "Second article"],
    metadatas=[{"source": "blog"}, {"source": "blog"}],
    ids=["doc1", "doc2"]
)

results = collection.query(query_texts=["Find similar articles"], n_results=5)

Best for: Small-to-medium RAG systems, document Q&A, seamless MVP-to-production transition.

✅ Secondary: pgvector (if you already use PostgreSQL)

One-liner: Vector search as a PostgreSQL extension. Add semantic search without introducing a new component.

Pros:

If you already run PostgreSQL, zero incremental ops
Inherits ACID, backups, HA from PG
Supports IVFFlat and HNSW indexes
Combines freely with full-text and geospatial search

Cons:

Index building is slow (especially IVFFlat training)
Query performance lags behind specialized vector DBs (fine at <1M scale)
Hybrid queries (vector + scalar filter) are less optimized

CREATE TABLE documents (
    id BIGSERIAL PRIMARY KEY,
    content TEXT,
    embedding vector(384)
);

CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

SELECT content, 1 - (embedding <=> query_embedding) AS similarity
FROM documents
ORDER BY embedding <=> query_embedding
LIMIT 10;

Why recommend pgvector over sqlite-vec here? At 100K+ vectors, pgvector's HNSW index and PostgreSQL's concurrency significantly outperform SQLite's single-threaded model.

✅ Backup: Redis Stack

One-liner: Add vector search to an existing Redis instance without introducing a new tech stack.

Pros:

Sub-millisecond search latency (in-memory)
Shares TTL, pub/sub, streams with your existing Redis
Unified FT.SEARCH syntax with full-text
KNN and range search

Cons:

Pure in-memory — 1M 384D float vectors ≈ 1.5GB RAM
Requires eviction policy when out of memory
Persistence is less robust than PG

Best for: Real-time recommendations, cache-side vector search, high-throughput low-latency scenarios. Not for: data that exceeds RAM, strong consistency requirements.

❌ Watch Out: Pinecone

Pinecone's experience at small scale (under 100K vectors) is great, and the free tier is usable. But the problem is opaque pricing — what seems free jumps to hundreds per month once you hit 500K vectors. And migrating out of Pinecone is expensive because the export format is proprietary. Fine for MVP, but think twice before committing long-term.

Medium Projects (1M-100M Vectors)

You need distributed capability. Single-node memory isn't enough, query concurrency is rising, index building can't take downtime. This is where selection really matters — wrong choice means a painful migration.

✅ First Choice: Qdrant

One-liner: A high-performance vector database written in Rust, single-binary deployment, pre-filtering is best-in-class.

Pros:

Rust — rock-solid performance, memory safety
Single binary deployment (or one Docker image)
Pre-filtering — apply scalar filters before vector search, far outperforms pgvector's post-filter
Payload storage with JSON schema indexing
Horizontal scaling (auto sharding + replication)
gRPC + REST API

Cons:

Ecosystem smaller than Milvus
GPU acceleration less mature than Milvus
Enterprise features need commercial license (core is open source)

from qdrant_client import QdrantClient

client = QdrantClient(host="localhost", port=6333)

client.search(
    collection_name="my_collection",
    query_vector=[0.1, 0.2, ...],
    query_filter=models.Filter(
        must=[
            models.FieldCondition(
                key="category",
                match=models.MatchValue(value="technology")
            ),
            models.FieldCondition(
                key="timestamp",
                range=models.Range(gte=1700000000)
            )
        ]
    ),
    limit=10
)

Best for: Enterprise semantic search, e-commerce recommendations, content platform personalization.

⚠️ Secondary: Weaviate

One-liner: Graph-semantic + vector hybrid database with built-in vectorizer modules — no need to run embedding models separately.

Pros:

Built-in vectorizers (15+ models: OpenAI, Cohere, HuggingFace)
GraphQL API, expressive query language
Hybrid search (BM25 + vector) out of the box
Cross-referencing between objects

Cons:

Complex architecture (needs container orchestration, module image management)
More configuration and a steeper learning curve than Qdrant
Built-in vectorizer means every query goes through a model — latency and cost need estimation

Best for: Knowledge graph + semantic search projects, teams wanting GraphQL. Less ideal for: pure vector retrieval (too heavy for the use case).

❌ The Controversial Pick: Milvus

Milvus is contradictory at this tier. Its architecture (message queue + distributed workers + GPU index) was designed for large clusters, and it runs fine at tens of millions. But the question is ops cost — does your team have someone who understands Milvus? When a P channel splits, an index node crashes, or a query node runs OOM, who fixes it?

If you have a dedicated infra/DevOps team and need GPU-accelerated indexing, Milvus makes sense. If it's a 3-5 person backend team handling ops on the side, Qdrant is a better choice.

Large Projects (>100M Vectors)

You're building a search engine or a multimodal retrieval system. This tier demands distributed capability, GPU acceleration, and multi-tenant isolation.

✅ First Choice: Milvus (or Zilliz Cloud)

One-liner: The de facto standard for distributed vector databases. GPU-accelerated indexing, microservice architecture, billion-scale retrieval.

Pros:

GPU-accelerated index building (IVF_PQ, HNSW, DiskANN)
Microservice architecture (independently scale query/index/data nodes)
Dense + sparse hybrid search
Native multi-tenant support (collection-level isolation)
Zilliz Cloud available in China

Cons:

Deployment complexity: 4/5 (needs etcd + MinIO/S3 + multiple workers)
High ops difficulty (debugging means checking multiple component logs)
Heavy resource consumption (3-node minimum)

✅ Backup: Pinecone (if you want zero ops)

Pinecone's value at scale is that you truly don't manage it. Auto-scaling, auto-indexing, auto-failover. Just throw vectors in and forget the rest.

Cost:

Expensive (thousands to tens of thousands per month at scale)
Lock-in (private format, hard to export)
Zero control (pricing changes, feature deprecation — you accept it)

✅ FAISS + Custom Retrieval Layer

For truly industrial-grade scenarios (billions of vectors), many companies end up with FAISS plus a custom layer. FAISS doesn't do persistence, distribution, or DB semantics — but it gives you maximum performance and full control.

Typical architecture: FAISS for indexing + S3/MinIO for persistence + Redis for caching + custom scheduling layer. Microservices handle writes and query dispatch above.

Best for: Search engine companies, large AI infra teams. Not for: teams that don't want to write their own infrastructure (use Milvus or Pinecone).

Comparison Table

Solution	Deploy Difficulty	Small	Medium	Large	Ops Cost	License	Best For
sqlite-vec	1/5	✅✅	❌	❌	Zero	Apache 2.0	Personal projects
LanceDB	1/5	✅✅	⚠️	❌	Minimal	Apache 2.0	ML pipelines
ChromaDB	1/5	✅✅	✅	❌	Minimal	Apache 2.0	RAG MVP
FAISS	2/5	✅✅	✅✅	✅✅	Medium	MIT	Pure perf needs
pgvector	2/5	✅✅	✅	⚠️	Low	PG license	PG users
Redis Stack	2/5	✅✅	⚠️	❌	Low	RSALv2	Real-time search
Qdrant	2/5	✅✅	✅✅	✅	Low	Apache 2.0	Mid-tier first pick
Weaviate	3/5	✅	✅	✅	Medium	BSD-3	Knowledge graphs
Milvus	4/5	❌	⚠️	✅✅	High	Apache 2.0	Large clusters
Pinecone	0/5	✅✅	✅✅	✅✅	Zero	Proprietary	Zero-ops

Four Scenarios, Intuitive Judgment

Scenario 1: Personal blog "similar articles" recommendation → sqlite-vec. Run directly on your SQLite database. You won't have more than a few thousand vectors. Don't introduce any new component.

Scenario 2: SaaS product with RAG Q&A, tens of thousands of documents → Already on PostgreSQL → pgvector. Not on PostgreSQL → ChromaDB. Don't worry about distribution at MVP stage. Wait until you have traffic data before thinking about migration.

Scenario 3: E-commerce semantic search, millions of SKUs, high concurrency → Qdrant. Rust performance, pre-filtering, simple deployment — the right balance. Consider Milvus when you hit billions. → Want zero ops → Pinecone. Just accept the pricing.

Scenario 4: Search engine / multimodal retrieval, billions of entries → Milvus cluster or custom FAISS stack. There's no shortcut. You need an engineer who understands vector indexing on your team.

Final Advice

Vector databases in 2026: lots of options, few real differentiators.

HNSW index: FAISS has it, Qdrant has it, Milvus has it, pgvector has it. Core search capability is converging.
Real differences: deployment model, ops cost, ecosystem integration, payload filtering, distribution strategy.

So my selection logic is simple: Check if PostgreSQL can handle it. If not, check if you're willing to run a dedicated service. If neither, go ChromaDB. Still not enough — go Qdrant. Still not enough — hire someone.

Don't be fooled by GitHub stars. More stars doesn't mean better fit. Your 100K-document project can run fine on sqlite-vec or pgvector. If you picked Milvus, the extra ops debt doesn't disappear just because it's popular on GitHub.

本文基于 2026 年 6 月各项目公开信息撰写。向量数据库迭代快，建议做最终决策前核实最新版本。

Contents

先搞清楚你属于哪个阵营

微型项目（<1万向量）

✅ 首选：sqlite-vec

✅ 备选：LanceDB

❌ 这个档位不要碰：Milvus、Pinecone、Weaviate

小型项目（1万-100万向量）

✅ 首选：ChromaDB

✅ 次选：pgvector（如果你已经在用 PostgreSQL）

✅ 备选：Redis Stack

❌ 这个档位可能踩的坑：Pinecone

中型项目（100万-1亿向量）

✅ 首选：Qdrant

⚠️ 次选：Weaviate

❌ 这个档位的争议点：Milvus

大型项目（>1亿向量）

✅ 首选：Milvus（准确说，是 Zilliz Cloud）

✅ 备选：Pinecone（如果你不想管运维）

✅ FAISS + 自定义检索层

横向对比总表

三个场景的直觉判断

最后的建议

Vector Database Selection Guide 2026: From a Single File to Billion-Scale Clusters

First, figure out which camp you're in

Micro Projects (<10K Vectors)

✅ First Choice: sqlite-vec

✅ Backup: LanceDB

❌ Don't Touch at This Tier: Milvus, Pinecone, Weaviate

Small Projects (10K-1M Vectors)

✅ First Choice: ChromaDB

✅ Secondary: pgvector (if you already use PostgreSQL)

✅ Backup: Redis Stack

❌ Watch Out: Pinecone

Medium Projects (1M-100M Vectors)

✅ First Choice: Qdrant

⚠️ Secondary: Weaviate

❌ The Controversial Pick: Milvus

Large Projects (>100M Vectors)

✅ First Choice: Milvus (or Zilliz Cloud)

✅ Backup: Pinecone (if you want zero ops)

✅ FAISS + Custom Retrieval Layer

Comparison Table

Four Scenarios, Intuitive Judgment

Final Advice