Vector database

A vector database stores embeddings and answers one central question fast: which stored vectors are closest to this one? Comparing a query against every vector works for small collections, but at scale these systems use approximate nearest neighbor indexes, such as HNSW, that trade a little accuracy for a lot of speed.

The category is broad. Dedicated vector databases exist, many search engines and general databases have added vector support, and the pgvector extension brings vectors to Postgres. For most products, the deciding factors aren't raw vector speed but practical ones: whether you can filter by workspace and permissions in the same query, keep vectors in sync with source data, and avoid running another system.

The common mistake is choosing on benchmark numbers before you need to. If your data already lives in Postgres and your collection is in the thousands or low millions of items, adding vectors there is often the simplest correct choice. Move to a dedicated engine when you have a measured reason, such as scale, latency, or built-in features you would otherwise build yourself.

Whatever you choose, metadata filtering for tenant isolation is non-negotiable in a multi-tenant app.