Which open-source vector database should you use in 2026? If you already run Postgres, start with pgvector — it adds vector search to a database you already operate, no new service. If you want a clean, dedicated engine, pick Qdrant. Reach for Weaviate for built-in hybrid search, Milvus only when you truly need billions of vectors, and Chroma when you just want to prototype fast. That's the whole decision; the table below is your shortcut, and the sections after it explain each verdict.
| Database | License | Deploy | Rough scale ceiling | Pick it when |
|---|---|---|---|---|
| pgvector | PostgreSQL License | Inside Postgres (self-host, RDS, Supabase, Neon) | Low millions / table | You already run Postgres |
| Qdrant | Apache-2.0 | One container, or Qdrant Cloud | Hundreds of millions | You want a clean dedicated engine |
| Weaviate | BSD-3-Clause | Self-host, or Weaviate Cloud | Hundreds of millions | You want built-in hybrid search |
| Milvus | Apache-2.0 | Distributed cluster, or Zilliz Cloud | Billions | You need billion-scale distributed search |
| Chroma | Apache-2.0 | Embedded or client-server; Chroma Cloud (preview) | ~1M comfortably | You're prototyping RAG |
All five are genuinely open source — no source-available bait-and-switch, no usage-gated core — so self-hosting any of them costs nothing but your own compute. The question isn't "which is best" in the abstract. It's "which is best for one person or a small team who has to run this thing." That reframing kills most of the debate.
pgvector — the default if you already run Postgres#
pgvector isn't a vector database; it's a Postgres extension (the permissive PostgreSQL License, latest 0.8.x) that teaches the database you already operate to store and search embeddings. For a solo founder that framing is decisive: no new service to deploy, monitor, back up, or pay for. Your vectors live next to your users, orders, and documents, and you can filter them with the same SQL and the same transactions.
Setup is genuinely one line, then an index:
CREATE EXTENSION vector;
CREATE TABLE items (id bigserial PRIMARY KEY, embedding vector(1536));
CREATE INDEX ON items USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);It supports both HNSW (better recall/latency) and IVFFlat (faster to build). The gotcha: pgvector shares Postgres's RAM and connection budget, so metadata-filtered vector queries at scale need care with indexing, and a big HNSW build can be memory-hungry. What it means / pick this if: you already run Postgres and your corpus is in the thousands-to-low-millions. This is the correct default for most apps, and you can run it self-hosted or on any managed Postgres (RDS, Supabase, Neon). Only leave when you outgrow it.
Qdrant — the best standalone pick for most founders#
Qdrant is the dedicated engine I'd reach for when Postgres isn't already in the stack, or when vector search is core enough to deserve its own service. It's Apache-2.0, written in Rust, and it self-hosts as a single container — no cluster, no coordinator, no ZooKeeper. That operational simplicity is the whole reason it's the standalone default for a small team: you get real ANN performance, rich payload filtering, and quantization without signing up for distributed-systems homework.
When you don't want to run even that one container, Qdrant Cloud offers a managed service with a free tier, and moving between self-hosted and managed is painless. The gotcha: a single node scales vertically a long way, but true horizontal sharding and replication add operational complexity, so plan your capacity before you're forced into it. What it means / pick this if: you want a clean, fast, dedicated vector database with the least ops of any standalone option, and a managed escape hatch. For most founders choosing a server, Qdrant is the answer.
Weaviate — pick it for built-in hybrid search and modules#
Weaviate (BSD-3-Clause, on the v1.37 line in 2026) trades a little operational simplicity for batteries-included features. Its headline is hybrid search — combining vector similarity with keyword (BM25) scoring out of the box — which fixes the classic RAG failure where pure semantic search misses an exact term. It also ships a module ecosystem (vectorizers, rerankers, generative modules) that can vectorize your data for you.
If you'd rather not operate it, Weaviate Cloud is the managed route on AWS, GCP, and Azure. The gotcha: Weaviate is heavier to self-host than Qdrant — more concepts, more knobs, more memory — so you pay for those features in operational surface area. What it means / pick this if: you specifically want first-class hybrid search and modular vectorization, and you're willing to run (or pay to host) a more feature-dense system. If you don't need those, Qdrant is lighter for the same core job. For why hybrid retrieval matters, see our look at GraphRAG vs LightRAG vs Graphiti.
Milvus — only when you genuinely need billions#
Milvus is the heavyweight: Apache-2.0, a graduated LF AI & Data project, and with Milvus 3.0 (shipped July 2026) it went "lake-native," decoupling storage for very large corpora. It's built for billion-scale, distributed indexing across many nodes — the kind of scale where Qdrant or pgvector would strain. The managed version is Zilliz Cloud.
That power is also the warning. Milvus's distributed architecture has real moving parts, and running it well is a job. The gotcha: don't adopt Milvus early "to be safe." For a solo builder or small team, its operational weight is a cost you pay every day for scale you may not reach for years. What it means / pick this if: you actually have — or can clearly forecast — hundreds of millions to billions of vectors and need distributed indexing. If that's not you yet, it's the wrong tool, and you can migrate to it later.
Chroma — the fastest way to prototype#
Chroma (Apache-2.0) optimizes for developer experience. Its Python/JS API is the friendliest of the five, collections and metadata filtering are first-class, and you can be doing similarity search in a handful of lines. It runs embedded in your process or as a client-server, and Chroma Cloud launched in 2026, though it's still in preview as of mid-year.
The gotcha: Chroma is a prototyping and small-corpus champion, comfortable up to roughly a million vectors when it fits in memory, not a billion-scale production engine. Treat it as the place you start, not necessarily where you finish. What it means / pick this if: you're building a RAG feature and want the smoothest possible path from zero to working. If you never outgrow it, great; if you do, you'll know exactly which of the above to graduate to.
How to choose in 60 seconds#
Run down this list and stop at the first "yes":
- Already running Postgres? Use pgvector. Don't add a service you don't need.
- Want a dedicated engine with minimal ops? Use Qdrant (self-host one container, or Qdrant Cloud).
- Need built-in hybrid search and vectorizer modules? Use Weaviate.
- Genuinely at billions of vectors / distributed? Use Milvus.
- Just prototyping and want the nicest API? Use Chroma.
And if you're one person shipping a small RAG feature, ask whether you need a server at all — an embedded store may be simpler and cheaper. We compared those in sqlite-vec vs LanceDB vs Chroma, and the answer there, like here, is usually the boring one that adds the least to your stack. Whatever retrieval you build on top, the quality of your chunks matters more than the engine — see Docling vs Unstructured vs LlamaParse for getting the inputs right.
