Vector Databases: What They Are and When You Need One

What is a vector database?

A vector database keeps embeddings in a high-dimensional space and, given a query vector, returns the closest ones. A traditional database, by contrast, locates records by exact match: the user with this email, the orders from this date. If you are not yet sure how those vectors are produced, start with embeddings; to see why searching by meaning changes the experience, read semantic search.

To be fast, the database usually implements approximate nearest neighbor algorithms. Exact search compares the query with every vector, and its cost grows with the number of points and dimensions. Approximate search accepts a result very close to the best one, though not always the best, in exchange for speed and lower memory use.

Common techniques include HNSW graphs, locality-sensitive hashing, product quantization and inverted files. HNSW, described by Malkov and Yashunin in 2016, organizes the index as layers of proximity graphs: a search starts in the upper layers with long jumps and descends to the dense layers. Its authors report that it outperforms earlier open-source approaches that use only vectors and that it scales logarithmically.

Which products exist and how do they differ?

There are two families. Some databases were built for vectors; others are extensions or features of a database you may already use. According to their official documentation as of November 2026:

There is no universal winner: each one solves a different point between simplicity and scale. Performance and price figures change fast and depend on your data, so do not use them to choose: test the options with your own collection.

Why does this matter to a designer?

Because the vector database decides what the user finds and what the model receives:

• “Similar” results. Approximate search does not guarantee the exact best result. That can explain why a relevant item appears in fourth place.
• Latency. Search is fast, but it adds to the time of each answer in a RAG assistant. Show it as a visible step if it is slow.
• Filters. A user who searches “2026 brand team documents” needs similarity combined with exact filters. pgvector’s documentation warns that, with approximate indexes, the filter is applied after the index is scanned: with HNSW’s default ef_search of 40 and a filter that matches 10% of rows, a query would return about 4 rows on average instead of the number you asked for. Qdrant, by contrast, describes its payload index as extending the HNSW graph so filtering happens during the search. The design consequence is real: a results screen can end up almost empty because of a filter the database handles poorly.
• Permissions and customers. If several customers share a database, their data must be kept apart. Pinecone uses namespaces for this; in other databases it is solved with metadata and filters. A mistake here shows one user another customer’s documents.
• Updates. When a document changes, its embedding must be recalculated. Users expect a correction to show up quickly; design for that.

When do you NOT need one?

When the collection is small. A few hundred documents fit in memory and can all be compared with the query without trouble. Chroma, for example, can start in memory on your machine, although its own documentation warns that data is lost when the program ends.

A dedicated database is also unnecessary if your current relational database already has a vector extension and the volume is moderate: adding new technology has an operational cost. If your team already uses PostgreSQL, pgvector lets you store vectors in the same row as the rest of your data. To understand that kind of database, read databases for designers.

And if the query depends on identifiers or exact rules, a traditional database with indexes remains the right tool.

How do you decide?

1. Count your vectors: hundreds, thousands, millions. The order of magnitude changes the answer.
2. Set the target latency for your feature.
3. Define the filters you need, by date, user, language or permissions, and check how the product handles them with an approximate index.
4. Review what you already use: if your current database supports vectors with filters, start there.
5. Test quality with real cases before comparing engines, because the best database does not fix a poor embedding. If you are building an answer assistant, also see how context is retrieved in RAG.

Example

Illustrative example: a design studio has 6,000 fragments of user research. The internal assistant searches by similarity and filters by project and date. At first the team installs a dedicated database, but the volume is low and maintaining it is not worth the effort. It moves to a vector extension in the database the projects already use. When testing a very restrictive project filter, the list returns few results: the designer spots it in testing and asks engineering to review the filter configuration with the index. The designer defines the filter interface as part of the product, not as a technical detail.

Common mistakes

• Installing a dedicated vector database for a collection of one hundred documents.
• Forgetting that approximate search can miss the exact best result.
• Not testing filters with an approximate index and finding out late that they return few results.
• Mixing embeddings from different models in the same collection.
• Not planning reindexing when documents or the embedding model change.
• Designing filters after building the index, when they should have shaped its structure.

Sources

• Vector database, Wikipedia
• Nearest neighbor search, Wikipedia
• Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs (arXiv:1603.09320)
• pgvector: repository and documentation on GitHub
• Qdrant: documentation overview
• Pinecone: documentation overview
• Weaviate: documentation
• Chroma: getting started