Every time someone asks me "which vector DB should I use for RAG," I want to fire back with: how much data do you have, how many people maintain it, and is your budget zero or infinite? Answer those and the choice mostly makes itself. Reality is most people just open GitHub, sort by stars, and copy the top result-then hit production and step in mud. This piece skips the fluff and puts Milvus, Qdrant, Weaviate, Chroma, and pgvector on one table, reviewed with real data, then gives conclusions by scenario.
Two disclaimers up front: first, star counts are as of 2026-07-29 and move in real time-don't treat them as gospel. Second, the performance comparisons below are representative, not personally benchmarked. I'm citing each project's official description and community consensus, not numbers I ran on the same machine. Use this as a starting point for your decision, not the finish line.
1. Why Vector Databases Suddenly Became a "Must-Have"
This starts with RAG. Large models can't remember your private documents or browse in real time. The only reliable approach is to chunk your docs, embed them into vectors, stuff them into a store that can do similarity search, retrieve the relevant ones, and feed them into the prompt. That store is the vector database.
You quickly find that traditional Elasticsearch or Postgres full-text search can't do this job-they're bad at approximate nearest neighbor (ANN) search in high-dimensional space. So purpose-built vector databases emerged. Milvus, Qdrant, Weaviate, Chroma all took this road. pgvector took another: instead of starting fresh, add an extension to Postgres so it can do vector search too.
The core tension in selection isn't "which is strongest." It's "do you want to run a separate service just for vector search." Cut along that line and the five options split into two camps.
2. Five-Way Review: Let the Data Talk
Here's the hard data. Stars as of 2026-07-29, moving in real time; activity judged by recent pushes-all five are actively maintained.
| Project | Stars | Language | License | Deployment | Scale | Official Description |
|---|---|---|---|---|---|---|
| Milvus | 45,408 | Go | Apache-2.0 | Standalone service (cloud-native) | Ultra-large scale | High-performance cloud-native vector DB for scalable ANN search |
| Qdrant | 33,640 | Rust | Apache-2.0 | Standalone service | Mid-to-large | High-performance large-scale vector DB and search engine |
| Weaviate | 16,656 | Go | BSD-3-Clause | Standalone service | Mid-scale | Stores objects and vectors, vector search + structured filtering |
| Chroma | 28,900 | Rust | Apache-2.0 | Embedded / standalone | Lightweight start | AI search infrastructure, lightweight and easy |
| pgvector | 22,385 | C | NOASSERTION | Postgres extension | Small-to-mid | Open-source vector similarity search extension for Postgres |
A few things in this table deserve a second look.
Star ranking doesn't equal capability ranking. Milvus leads at 45K stars, but its positioning targets ultra-large scale from the start-part of that star count is first-mover advantage plus the Chinese community base. Chroma at 28.9K beats Weaviate largely because it caught the first wave of the AI-app explosion: when developers first started playing with LangChain, Chroma was the default in tutorials, with a barrier so low that pip install gets you running.
On language, Qdrant and Chroma both chose Rust. Not a coincidence. Vector search is compute-intensive; Rust's zero-cost abstractions and memory safety translate directly into throughput and latency wins in this scenario. Milvus and Weaviate went with Go, leaning toward engineering and cloud-native ecosystems. pgvector is written in C because it runs as an extension inside the Postgres process-it has to be close to the kernel.
On licenses, four are Apache-2.0 or BSD-3-Clause-commercially friendly, permissive. But pgvector is tagged NOASSERTION-GitHub couldn't auto-detect a clear open-source license. I checked the repo root and the actual license is PostgreSQL License (BSD-like), but GitHub didn't flag it as standard SPDX. Key point: if your company legal team is strict, the NOASSERTION tag alone will trigger a compliance review. Don't let this surface the week before launch.
3. Breakdown: Who Fits What Job
Data is the skeleton; scenarios are the flesh. Below I match "who you are, what you're doing"-the questions I actually ask when selecting.
Ultra-large-scale production: Milvus
Milvus is officially positioned as a "high-performance cloud-native vector DB for scalable ANN search." In plain terms: it's built for hundred-million-plus vectors, horizontal scaling, and production environments. It supports multiple index types, has a storage-compute separation architecture, and can mount S3 as a storage backend.
The cost? Operations. Milvus isn't a pip install deal. A full deployment involves etcd, MinIO, Pulsar, and a pile of dependencies-even with Docker Compose you're looking at a dozen-plus containers. A small team running Milvus may spend more on ops than on product code. Ask yourself before choosing: is your vector volume really at the hundred-million or billion level? If not, it's overkill.
Rust performance: Qdrant
Qdrant's official description: "high-performance large-scale vector DB and vector search engine." Written in Rust, good single-node throughput and memory footprint, clean API design, and a genuinely useful filtering feature. 33K stars, actively maintained-the most frequently mentioned alternative to Milvus in the standalone vector-DB space.
Qdrant's sweet spot is mid-to-large scale, teams that want single-node performance and don't want to deal with Milvus's component zoo. One binary and it runs-much lighter than Milvus. But since it doesn't have pgvector's trick of parasitizing an existing Postgres, it's still a separate service to operate. If your ops capacity can only feed one database, Qdrant is among the best value in standalone vector DBs.
Hybrid search: Weaviate
Weaviate's official pitch: "stores objects and vectors, vector search + structured filtering." That one line nails its differentiator: it doesn't just store vectors, it stores the objects themselves. You can do vector similarity search while stacking structured filters-"find documents most similar to this passage, but only those published after 2025 and tagged tech."
This kind of hybrid search is extremely practical in RAG, because pure vector search often recalls semantically similar but completely off-topic results. A metadata filter layer dramatically improves recall quality. Weaviate sits at 16K stars-lower than the top two-but its positioning was never about extreme scale; it's about being feature-complete and integrated. If your RAG pipeline is sensitive to recall quality and you don't want to bolt a filtering layer onto your application code, Weaviate deserves an early look.
Lightweight start: Chroma
Chroma's official description boils down to: lightweight and easy. It positions itself as AI search infrastructure, but the real weapon is developer experience: pip install chromadb, a few lines of code, and it runs locally. No server, no dependencies. A solid chunk of its 28.9K stars came from developers onboarded by LangChain tutorials.
When is Chroma the right call? Prototyping, demos, personal projects, early RAG experiments. Its embedded mode can run in the same process as your data-no service to start. But its production maturity and large-scale capability aren't in the same league as Milvus or Qdrant. My advice: use Chroma to validate the idea. Once you hit production with millions of vectors, seriously consider migrating.
Already on Postgres: pgvector
pgvector is the one parasitic option-it's not a standalone database, it's a Postgres extension. Official description: open-source vector similarity search extension for Postgres. No new component, no new service to feed: CREATE EXTENSION vector and your Postgres can do vector search.
The appeal is obvious: if you're already on Postgres for business data, one extension lets the same database do both relational queries and vector search, with near-zero added ops. 22K stars show how many teams this resonates with. But pgvector has a clear ceiling-its ANN indexes lag noticeably behind purpose-built vector DBs in throughput and recall speed at the ten-million-plus vector scale. Its sweet spot is small-to-mid scale, heavy existing Postgres dependency, and no appetite for new infrastructure. Past that scale, it's no longer optimal.
4. Decision Tree: Decide in Three Minutes
Here's a decision tree you can follow. Ask in order:
- Are you already on Postgres? Yes, pgvector first; fine up to about a million vectors. No, next.
- Is your vector volume at ten-million or hundred-million scale? Yes, Milvus. This is its home turf. No, next.
- Do you value single-node performance and a Rust stack? Yes, Qdrant. No, next.
- Do you need hybrid vector plus structured search, stored together? Yes, Weaviate. No, next.
- Are you prototyping, doing a personal project, or just starting out? Yes, Chroma. Get the pipeline running first.
This won't cover every edge case, but it eliminates 80% of wrong choices. The remaining 20% of indecision usually means the requirements themselves aren't clear-like wanting both lightweight and billion-scale. Those have-it-both-ways wishes usually end up with neither done well.
5. Pitfalls: Ops, License, Managed vs Self-hosted
Three traps to flag separately-these are where pre-launch teams most often faceplant.
First, ops cost. Of the five, Milvus is heaviest to operate-a full deployment needs etcd plus MinIO plus Pulsar as a set. Go straight to ZillizCloud (official managed) or a K8s operator; don't hand-roll it. Qdrant and Weaviate sit in the middle: single binary or container runs, but production still needs monitoring and backups. Chroma is lightest-embedded mode is zero-ops, but production should switch to client-server mode. pgvector's ops cost is your Postgres ops cost-the database you're already feeding; adding an extension barely adds load.
Second, the NOASSERTION license. As mentioned, pgvector's GitHub license tag is NOASSERTION, though the repo actually uses the PostgreSQL License. If your company has a strict compliance pipeline, this tag will get flagged by legal tooling. The four Apache and BSD projects are all commercially friendly-safe to use in commercial products. pgvector isn't unusable; it just needs one extra confirmation step.
Third, managed vs self-hosted. This is a more upstream decision than "which one." If your core business isn't running databases, managed saves you ops headcount that far exceeds the subscription cost. Milvus has ZillizCloud, Qdrant has Qdrant Cloud, Weaviate has Weaviate Cloud, and pgvector is pre-installed on nearly every managed Postgres (Supabase, Neon, RDS). Chroma has fewer managed options, another reason it fits the early stage better. A simple test: if your vector DB going down would break the business and you don't have a dedicated DBA, managed is the safer call.
6. My Take
One honest line: none of these five is "best"-only "best fit." Milvus isn't right for you just because it has 45K stars, and pgvector isn't lesser because it has fewer. The key to selection is always the same: nail down your scale, ops capacity, tech stack, and budget first, then come back and match.
If you want the safest opening move: start with Chroma to get the RAG pipeline running and validate business logic. When data grows and you're already on Postgres, move to pgvector. If you need a standalone service, pick Qdrant. If you're truly heading to hundred-million scale, then bring in Milvus. This path isn't the fastest, but it lets you spend each stage focused on the business logic that actually creates differentiation, not on infrastructure. A vector DB is the foundation of RAG, but no matter how good the foundation, whether you build a shack or a skyscraper on top depends on what you do with it-not on how strong the foundation is by itself.
References
- Milvus: https://github.com/milvus-io/milvus
- Qdrant: https://github.com/qdrant/qdrant
- Weaviate: https://github.com/weaviate/weaviate
- Chroma: https://github.com/chroma-core/chroma
- pgvector: https://github.com/pgvector/pgvector