How to choose a vector database

A vector database stores embeddings — numeric representations of text, images or other content — and finds the ones nearest to a query vector. That single capability underpins retrieval-augmented generation, semantic search, recommendation and anomaly detection. If your application never needs to answer "what is similar to this," you do not need one: a full-text index or a relational query will do the job more cheaply. If it does, the products on the market differ less in raw search quality — most now support the same handful of approximate nearest-neighbor algorithms — and more in who operates the system, at what scale, and what else it does besides similarity search.

Decide whether you need a separate database at all

The first fork in the road is not between vector databases but between adding one and not. If your data already lives in PostgreSQL and your similarity workload is moderate — thousands to low millions of vectors, not billions — pgvector adds a vector type and index directly to a database you already run, backed up and secured. You keep one system, one set of transactions, and one place joins happen. The trade-off is scale and specialized performance: pgvector is not tuned the way a purpose-built engine is, and very large or very high-QPS workloads will eventually outgrow it. Many teams start here and move to a dedicated store only when they can point to a specific limit they hit.

Managed cloud or something you operate

Once you decide a dedicated store is worth it, deployment is the decision that eliminates the most options fastest.

• Cloud-only, fully managed. Pinecone runs on AWS, GCP and Azure with no self-hosted edition; you cannot bring it in-house later. Zilliz Cloud is the managed version of Milvus, built by Milvus's original creators, and shares the same engine as the open-source project — so a team can start managed and move to self-hosted Milvus later without a rewrite, or the reverse.
• Open source, self-host or managed. Qdrant, Weaviate, Milvus, Chroma and Vespa can all run on your own infrastructure via Docker or Kubernetes, and most also sell a managed cloud version of the same engine. This is the flexible middle: no licence fee to self-host, and an exit from the vendor's cloud without a migration.
• Embedded, no server. LanceDB and Chroma's local mode run in-process, reading and writing straight to disk or object storage, with nothing to keep running between requests. This suits development and small production workloads where standing up a cluster is overhead you do not want yet.

If data residency or a no-vendor-lock-in requirement is non-negotiable, that alone rules out Pinecone and narrows the field to the self-hostable options.

Match the engine to your scale

Vector databases are not interchangeable at the extremes. Milvus and Vespa are built and tuned for billion-scale collections, with storage and compute that scale independently and a choice of index types per collection — the right end of the market for a team indexing a large, constantly growing corpus. Pinecone, Qdrant and Weaviate comfortably serve the far more common range of a few million to low hundreds of millions of vectors with less operational tuning required. Chroma and LanceDB are aimed lower still: fast to start, and a common early choice before a team outgrows them and migrates to a larger-scale store. Buying capacity you do not need mainly costs you complexity, not just money — a self-hosted cluster tuned for billions of vectors requires more operational attention than most projects with a few million ever will.

Decide whether you need more than similarity search

Plain vector similarity answers "what's semantically closest," but production search usually needs to combine that with exact filters and, often, keyword matching.

• Filtering. Qdrant built its reputation on combining approximate nearest-neighbor search with rich payload filtering — narrowing by price, category or permission in the same query as the similarity search. Every mainstream vector database now supports metadata filtering to some degree; the differences are in performance under filtered queries at scale, which is worth testing on your own data rather than trusting a benchmark.
• Hybrid vector + keyword search. Weaviate and Vespa build hybrid (dense vector plus BM25 keyword) search in natively. Milvus supports combining dense and sparse vectors. If your users sometimes search for exact terms — a product SKU, a person's name — pure vector similarity alone will disappoint them; a hybrid-capable store, or a keyword index run alongside the vector one, closes that gap.
• Custom ranking beyond similarity. Vespa goes further, combining vector search, keyword search and multi-phase machine-learned ranking in one query — built for e-commerce search and recommendation, where relevance depends on more than distance. That flexibility comes with more modeling and operational investment than a simpler vector-only store.

Weigh open source against commercial

Every product here except Pinecone and Zilliz Cloud is open source, but "open source" is not the same as "free to run." Self-hosting Milvus or Vespa at scale means Kubernetes expertise, index tuning, and someone on call — real cost, just paid in engineering time rather than a subscription. A managed cloud tier of the same open-source engine (Qdrant Cloud, Weaviate Cloud, Zilliz Cloud, Vespa Cloud) buys back that time at a price, and because it typically runs the same core engine, moving between self-hosted and managed later is more realistic than switching to a different product entirely.

How pricing scales

None of these products price the same way, and none of it belongs on a shortlist page — check the profile for current figures. In general: managed cloud tiers bill by a mix of storage, writes, queries and compute (Pinecone, Zilliz Cloud, and the cloud tiers of Qdrant, Weaviate and Chroma); self-hosted open source has no licence fee, so your cost is infrastructure and headcount; and several products offer a free tier or free-forever small cluster meant for evaluation and low-volume production, not a permanent deployment. Model your cost at the vector count and query volume you expect in a year, not the pilot — vector database bills are usually driven by storage and query volume together, and both grow with adoption.

A shortlist by situation

• Already on Postgres, moderate scale: pgvector.
• Prototyping a RAG app, want the shortest path to something working: Chroma.
• Multimodal data (images, audio, video alongside embeddings), want to avoid a second data copy: LanceDB.
• Production RAG or semantic search, want zero infrastructure to run: Pinecone.
• Want the flexibility to self-host or go managed on the same engine, with strong filtering: Qdrant.
• Need native hybrid vector + keyword search out of the box: Weaviate.
• Billion-scale collections, want full control over infrastructure: Milvus.
• Want Milvus's scale without operating the cluster: Zilliz Cloud.
• Search or recommendation product needing custom relevance ranking, not just similarity: Vespa.

Questions to ask in a trial

1. What is query latency at the filter selectivity we actually use, not an unfiltered benchmark?
2. What happens to recall and latency when the index does not fit in memory?
3. How does re-indexing or a schema change affect a live collection — downtime, or a rolling rebuild?
4. What does the managed tier cost at our projected vector count and QPS in twelve months, not today?
5. Can we export our data and self-host the same engine if we later need to leave the managed service?
6. How is multi-tenancy handled — one collection per customer, or shared with metadata isolation?

Common mistakes

Choosing based on a benchmark run on someone else's data and query pattern, rather than your own filters and vector dimensionality. Picking billion-scale infrastructure for a collection that will hold a few million vectors for years. Treating an open-source licence as meaning the total cost is zero — self-hosting has a real, ongoing engineering cost. And building a RAG pipeline around whichever vector database a tutorial used, without checking whether your latency, filtering or hybrid-search needs actually match it.

See Pinecone vs Weaviate and Milvus vs Qdrant for two direct match-ups, and browse every tool in this category.