A vector database's one job is fast similarity search: given a query vector, find the handful of stored vectors closest to it, out of possibly millions, in milliseconds. Every option below does that job. Where they differ is operations, scale, and what else you get alongside the search itself.
The options, and who they're actually for
Chroma - the one to start with
Chroma is open-source, embeds directly into your Python process (no separate server required to get going), and is genuinely the fastest path from zero to a working prototype. It's the default choice for learning RAG and for small-to-mid projects where you don't yet know if you need anything more. The tradeoff is that it's less battle-tested at very large scale or under heavy concurrent production load than the dedicated options below.
Pinecone - managed, and built for production scale
Pinecone is a fully managed, cloud-hosted vector database - no infrastructure to run yourself, built specifically for production-scale similarity search with predictable low latency even at hundreds of millions of vectors. It's a strong default once you're past prototyping and want scale and reliability handled for you, at the cost of being a paid, closed-source service you don't control the internals of.
Weaviate - vector search plus built-in hybrid retrieval
Weaviate is open-source and available both self-hosted and managed, and its standout feature is strong built-in hybrid search - combining vector similarity with traditional keyword (BM25) search in one query, which matters a lot for queries containing exact terms (product codes, names, acronyms) that pure semantic search can miss. If hybrid search is a requirement rather than a nice-to-have, Weaviate is usually the first one worth evaluating.
pgvector - vector search inside Postgres you already run
pgvector is a Postgres extension that adds vector similarity search directly into a database you may already be running for everything else. The appeal is operational simplicity: one database, one set of backups, one place your application data and your vectors both live, with normal SQL joins available between them. It genuinely doesn't scale as gracefully as purpose-built vector databases once you're past a few million vectors, but for small-to-mid scale RAG bolted onto an existing Postgres-backed app, it removes an entire piece of infrastructure you'd otherwise have to run.
| Option | Hosting | Standout strength | Best fit |
|---|---|---|---|
| Chroma | Embedded / self-hosted | Fastest to get running | Prototypes, learning, small projects |
| Pinecone | Managed only | Production scale, low ops burden | Production apps that want scale handled for them |
| Weaviate | Self-hosted or managed | Built-in hybrid (keyword + vector) search | Queries that mix exact terms with semantic meaning |
| pgvector | Self-hosted (Postgres extension) | One database instead of two | Apps already running Postgres, small-to-mid scale |
What actually determines similarity: the metric
Every vector database needs a distance metric to define "closest." Cosine similarity (measuring the angle between two vectors, ignoring their magnitude) is the default for most text embedding models and the right starting choice unless your embedding model's documentation specifically recommends otherwise. Dot product and Euclidean distance are the other common options - the embedding model you use typically dictates which metric it was trained to work best with, so this is usually a five-minute lookup rather than a real decision.
The index type matters more than the vendor, past a certain scale
Under the hood, all of these use an approximate nearest neighbor (ANN) index rather than checking every single stored vector against your query - an exact search doesn't scale past a small dataset. The most common index type is HNSW (Hierarchical Navigable Small World), which trades a small amount of accuracy for a large amount of speed, and is the default in nearly every option above. Past a few million vectors, tuning this index's parameters matters more for latency and recall than which vendor's logo is on the product - another reason not to over-index on vendor choice before you actually have a scale problem.