Choosing a Vector Store
pgvector, dedicated vector databases, and managed search services compared — with a clear default for most apps and the signals that you've outgrown it.
Once you have embeddings, you need somewhere to put them and a fast way to find the nearest ones. The vector store category is crowded: Postgres extensions, purpose-built vector databases, search engines that added vectors, and serverless options. Most of their marketing implies your app needs one of them to be "AI-ready."
Most apps don't need anything new. This lesson gives you a clear default (pgvector in the Postgres you already run), explains what dedicated vector databases and managed search services actually add, and lists the concrete signals that you've outgrown the default. You'll also see how to keep the decision reversible, so you can start simple without painting yourself into a corner.
What a vector store actually does
Strip away the branding and every vector store does the same five jobs. Evaluate options against these, not against feature lists:
- Stores vectors next to an ID and metadata. Metadata is the plain data you filter on: workspace, language, document type, publish state, permissions.
- Finds nearest neighbors fast. Comparing a query against every stored vector (a brute-force or exact search) is fine for a few tens of thousands of vectors. Beyond that you need an approximate nearest neighbor (ANN) index, a data structure that finds almost the closest vectors while looking at a small fraction of them.
- Filters while searching. "Nearest articles in this workspace, in this language, that are published." Filtering is where vector stores differ most and where naive setups lose results.
- Handles writes. Inserts, updates, and deletes, ideally visible to queries immediately.
- Combines with keyword search. Pure vector search misses exact codes and names, so you'll want full-text search alongside it (the subject of Hybrid Search).
The ANN trade-off in one paragraph
ANN indexes trade a little accuracy for a lot of speed. The most common one, HNSW (Hierarchical Navigable Small World), builds a layered graph where each vector links to its near neighbors, then walks the graph from a starting point toward the query. It's fast and accurate but memory-hungry, and building it on millions of vectors takes time. IVF-style indexes (inverted file) instead cluster vectors into lists and search only the closest few lists; they build faster and use less memory but need tuning and periodic rebuilding as data shifts. Every engine exposes knobs that trade recall (did we find the true nearest neighbors?) against latency. You don't need to master them on day one, but you should know they exist, because "search got slightly worse after we added data" is often an index setting, not an embedding problem.