Vector databases, compared for builders

The short version

A vector database stores embeddings and finds the nearest ones fast. That's the whole pitch — but "fast nearest-neighbor search" now comes in four flavors, and picking the wrong one is a painful migration later. The good news: for most teams, the choice matters less than the marketing suggests.

The four options

Dedicated vector databases (Pinecone, Weaviate, Qdrant, Milvus, Chroma) exist for one job and do it well: filtered vector search at scale, with managed hosting if you don't want to think about it. Pick one when vectors are the core of your product and you'll outgrow a sidecar.

Postgres with pgvector is the pragmatic default for everyone else. You already run Postgres; one extension gives you HNSW indexes, and your vectors live next to your relational data — no sync jobs, no second source of truth. Up to low-millions of vectors, it's genuinely competitive. The main cost is operational: you're now tuning a database for two workloads.

Search engines (Elasticsearch, OpenSearch) make sense when keyword search is already your world and vectors are an addition. Their hybrid dense+sparse support is mature, and your team already knows the tooling.

In-process libraries (FAISS, usearch, hnswlib) are for the latency-obsessed: no network hop, microsecond queries. You own persistence, replication, and every operational headache that comes with it.

What actually differentiates them

Forget benchmark charts for a moment. In practice, teams choose on:

• Filtering. "Vectors similar to X, but only docs from tenant Y updated this month" — metadata filtering quality varies wildly. Test your actual filter patterns, not toy queries.
• Hybrid search. If your data has SKUs, error codes, or names, you need BM25+vector fusion. Some engines do this natively; others make you glue it together.
• Operational burden. Managed Pinecone vs. self-hosted Milvus is a lifestyle choice as much as a technical one.
• Scale cliff. Everything is fast at 100k vectors. Ask what happens at 50M, and what it costs.

Rule of thumb: start with pgvector if you have Postgres. Migrate to a dedicated engine when filtered-search latency — not a benchmark — forces you to.