// 8 picks · reviewed August 2026
The Best Open Source Vector Databases in 2026
Every team building RAG or semantic search eventually asks the same question: do I bolt vector search onto something I already run, or bring in a system built for it. The honest answer depends on scale, filtering needs, and how much operational surface you're willing to own — because every one of these has a real weak spot, not just a missing feature checklist.
The picks below range from a Postgres extension to a Yahoo-scale search platform. Read the takes for what breaks, not just what ships.
How we picked these
Every repo here was read and assessed on its own before it was considered for this page: we pull the README, the directory layout and a key source file, and write the assessment from those rather than from the project's own marketing. Candidates for this list came from a full-text and topic search over the 88 reviewed repositories that matched this category. Anything with no commit in the last 12 months was cut, as were link collections, tutorials and boilerplates; the floor for inclusion was 500 stars. The ordering is a judgement call about who should pick what, not a ranking by stars. finds.dev is independent of every project listed here: nobody paid for a place on this page, there are no affiliate or referral links on it, and we have no commercial relationship with any of them. That is the point of writing down what each one is bad at as well as what it is good at.
// 1 of 8
★ 44,744 · Go · Apache-2.0 · updated Jun 2026
large-scale, cloud-native deployments needing distributed ANN search
Milvus is the one to reach for if you're actually operating at hundreds of millions to billions of vectors and need to scale query and data nodes independently. The index breadth — HNSW, IVF, DiskANN, GPU-accelerated CAGRA — is unmatched among the picks here, and native BM25 hybrid search saves you from bolting on Elasticsearch.
The cost is the dependency stack: Kubernetes, etcd, MinIO, Pulsar, all before your first vector lands. Compared to Qdrant or pgvector, this is enormous overkill if you're under a few hundred million vectors, and building from source means keeping Go, C++, CMake, and Python in lockstep.
Schema changes are also unusually rigid — altering vector dimensions means dropping and recreating collections, and Milvus Lite behaves differently enough from the full cluster that moving from local dev to production has real friction.
View on GitHub → Our full take →
// 2 of 8
★ 32,024 · Rust · Apache-2.0 · updated Jun 2026
teams wanting a fast Rust-based engine with strong filtering support
Qdrant is the pick if filtering quality matters as much as raw ANN speed — its payload predicates actually influence HNSW traversal instead of post-filtering results, which is rarer than it should be. The Rust implementation gives it genuine performance headroom over Milvus and Chroma, and sparse+dense+multivector support in one query is a real edge for ColBERT-style retrieval.
But you're on your own for embeddings; there's no built-in generation like Weaviate's module system, so smaller teams take on an extra service just to get from text to vectors.
The default Docker setup is unauthenticated and wide open, a detail buried in the docs rather than surfaced at quickstart. And like Milvus, changing vector dimensions or distance metrics means recreating the collection — there's no in-place migration path.
View on GitHub → Our full take →
// 3 of 8
★ 16,322 · Go · BSD-3-Clause · updated Jun 2026
developers wanting hybrid object+vector storage with built-in modules
Weaviate makes sense if you want one database holding both structured objects and vectors, with hybrid BM25+ANN search as a native feature rather than something you build yourself. The vectorizer module system is genuinely convenient — swap OpenAI for Cohere without touching application code — and multi-tenancy is handled at the shard level, which matters for SaaS.
The catch is GraphQL as the primary query interface: it's a poor fit for a database, forcing you to learn a Weaviate-specific dialect instead of something transferable. The gRPC API is better but thinly documented.
And the 'open source' framing oversells what self-hosting gets you — real HA setups push you toward Weaviate Cloud, resharding an underprovisioned collection is painful, and each vectorizer module is its own sidecar with its own cold-start latency in dev.
View on GitHub → Our full take →
// 4 of 8
★ 28,611 · Rust · Apache-2.0 · updated Jun 2026
quick prototyping and lightweight AI app integration
Chroma is the fastest path from zero to a working prototype — four methods, in-memory, no infrastructure, and a hybrid search story that's more complete than most self-hosted alternatives at this simplicity level.
The seams show once you leave prototyping. The Python-first history means the Rust core, Go log service, and Python API are stitched together in ways that make distributed mode harder to run than the README suggests, and telemetry is on by default — you have to know the environment variable to turn PostHog reporting off.
The bigger tell is where the project's attention is going: the hosted Chroma Cloud is getting the investment, the self-hosted Kubernetes path has lagged, and auth for the OSS server is thin, with no RBAC below the database level.
View on GitHub → Our full take →
// 5 of 8
★ 21,694 · C · NOASSERTION · updated Jun 2026
teams already on Postgres who want vector search without a new system
If you're already running Postgres, pgvector is the obvious first move — the HNSW implementation is solid, migrations across versions actually work, and the test coverage on a C extension is unusually serious.
The 2,000-dimension limit on float32 HNSW is the thing that'll bite you: OpenAI's text-embedding-3-large is 3,072 dimensions, forcing you into halfvec or binary quantization with real recall tradeoffs. Filtered ANN search is also fundamentally awkward here — there's no pre-filtering at the index level, so high-selectivity filters can scan most of the graph anyway.
Compared to purpose-built stores like Qdrant or Milvus, you're also managing maintenance_work_mem manually during index builds with no automatic fallback, and there's no story at all for multi-vector, ColBERT-style retrieval.
View on GitHub → Our full take →
// 6 of 8
★ 10,612 · HTML · Apache-2.0 · updated Jun 2026
embedded, multimodal retrieval without running a separate server
LanceDB is the pick for embedded, multimodal use — no server, data lives directly in S3 or on disk, and you get versioning and time-travel queries for free through the Lance format. The hybrid vector+BM25+SQL query support is well-built, not an afterthought.
The repo's listed primary language, HTML, is a tell: the real Rust core lives in a separate `lance` repo, so debugging anything deep means chasing two repositories and their version pins in tandem.
Index build performance on large datasets leans hard on GPU to stay practical, multi-writer setups on the same path can corrupt data with the docs underplaying the risk, and the managed cloud upsell is pushed hard enough to create real tension with what's easy to self-host.
View on GitHub → Our full take →
// 7 of 8
★ 26,003 · C++ · GPL-3.0 · updated Jun 2026
developers wanting fast typo-tolerant search plus vector capabilities
Typesense is the right call if search-quality features — typo tolerance, faceting — matter as much as vector similarity, and you want a single binary with no JVM tax. The feature list, including built-in ONNX embedders and Raft clustering, is unusually complete for a young C++ codebase.
The GPL license on the server binary is the real blocker for anyone shipping it embedded in a commercial product — the FAQ's reassurance amounts to 'talk to a lawyer.'
Everything lives in RAM by design, so a 28-million-record dataset needs 14GB just for the index, with no disk-based tier once you outgrow it. The .NET client is community-maintained and lags the official ones, and changing a field's type on an existing collection means a full re-index.
View on GitHub → Our full take →
// 8 of 8
★ 7,017 · Java · Apache-2.0 · updated Jul 2026
enterprises needing large-scale hybrid search and ranking at massive scale
Vespa is for teams that need ranking models running inside the query path — ONNX, XGBoost, LightGBM re-ranking alongside lexical and vector search in one system — and who have already outgrown the idea of composing five separate services to get there. Daily releases from main and a public factory build pipeline show a level of active engineering the other picks don't match.
That power comes with an operational footprint closer to a distributed system than a database: C++ and Java components, OSGi bundles, a bespoke config server, AlmaLinux as the supported host.
The query language, ranking expressions, and schema definitions are all Vespa-specific, and the docs assume you already think in distributed-search terms. If what you actually need is 'give me vector similarity search,' Vespa is a lot more system than you asked for, and self-hosting without real infrastructure discipline pushes you straight to Vespa Cloud.
View on GitHub → Our full take →
Questions people ask
Should I just use pgvector if I'm already on Postgres?
If your dimensions fit under 2,000 and your filters aren't highly selective, yes — you avoid a whole new system. Once you need 3,072-dim embeddings or heavy pre-filtered ANN search, you'll feel the architecture's limits fast.
What's the difference between Milvus and Qdrant in practice?
Milvus gives you more index algorithms and native sparse+dense hybrid search but demands Kubernetes, etcd, and Pulsar to run distributed. Qdrant is lighter to operate and has better filter-aware HNSW traversal, but you bring your own embeddings and the default Docker setup ships wide open.
Is Chroma good enough for production?
For prototyping, yes — the API is genuinely four methods and just works. For production distributed deployments, the seams between the Python layer, Go log service, and Rust core show, and the project's energy is visibly shifting toward its hosted cloud.
When does Vespa make sense over the others?
When you need ranking models running inside the query path alongside lexical and vector search, and you have the operational maturity to run a real distributed system. If 'I just need similarity search' describes you, Vespa's learning curve will feel disproportionate.
None of these is free of tradeoffs, and the tradeoffs are exactly what determines which one you should run. If you want notes like this without hunting for them, the weekly email covers picks like these as they change.
Get finds like these weekly →