4 min read - Vector Databases: Architecture Trade-offs for AI Retrieval

Vector search is useful when an application needs to retrieve items by similarity rather than exact keywords. That does not make a vector database the automatic foundation of every AI application. The choice depends on retrieval quality, filters, access control, update behaviour and the team's ability to operate another data system.

Older versions of this article discussed venture funding and vendor valuations. Those figures did not help an engineering decision and became stale, so they have been removed.

What a vector database stores

An embedding model converts an item, such as a passage or image, into a numerical vector. A vector search engine compares a query vector with stored vectors and returns nearby candidates according to a distance function. Many systems also store structured metadata alongside the vector so the application can filter results.

The vector is not the source document and does not explain why two items are close. Keep the source content, stable identifiers, model version and access-control attributes outside or alongside the index so results remain traceable.

The architecture questions that matter

Retrieval quality

Define a representative set of queries and relevant results before tuning an index. Measure recall and ranking quality for the user task. Approximate nearest-neighbour parameters trade search work, memory and recall; there is no vendor-independent setting that is best for every corpus.

Filters and permissions

Similarity alone is rarely enough. A result may be semantically relevant but belong to another tenant, region or permission group. Apply authorisation before content reaches the model and test that filters cannot be bypassed through alternate query paths.

Qdrant's documentation, for example, describes vectors plus JSON payloads and filter conditions. That is a product fact about Qdrant, not evidence that its filtering model is right for a particular application.

Updates and deletion

Document how an edit, revoked permission or deletion propagates from the system of record to the index. Test stale records and partial failures. A retrieval system that cannot honour deletion reliably creates a governance problem even if its search demo is accurate.

Operations

Estimate corpus growth, query concurrency, backup and restore, re-indexing time, observability and failure recovery. Managed and self-hosted products distribute this work differently. Compare the full operating responsibility from the first API call through recovery.

When an existing database may be enough

If the application already uses a database with a supported vector extension and the corpus is modest, adding vector search there may reduce operational complexity. A specialised engine may be justified when measurements show that scale, filtering, latency or retrieval features exceed that design.

Run the same evaluation set against both options. Measure query latency alongside ingestion, permission updates and recovery.

A practical evaluation record

For each candidate, retain:

• product and version tested;
• embedding model and version;
• corpus size and representative query set;
• relevance method and results;
• filter and tenant-isolation tests;
• update and deletion delay;
• resource use under the expected load;
• backup, restore and failure findings;
• licence, hosting and support assumptions reviewed on that date.

This evidence survives marketing changes. Funding announcements and claims about a “market leader” do not.

Choose from measured constraints

A vector database is an indexing component, not an AI strategy. Select it when a tested retrieval need justifies the additional system, and keep the original content and permissions authoritative. If keyword search, relational filters or an existing database meet the requirement, the simpler architecture may be the stronger one.

Primary sources

• Qdrant overview of vector search, reviewed 27 August 2026
• Qdrant filtering documentation, reviewed 27 August 2026