Vector Databases and Retrieval Infrastructure

What it is

An embedding is a list of numbers that represents a piece of content. Items with similar meaning have vectors that are close together, so a search for the nearest vectors is a search by meaning.

Search can be exact or approximate. Approximate indexes are faster on large collections and return most, not all, of the true nearest items.

The capability comes in two forms: specialist vector stores, and vector types added to general-purpose databases. An open-source extension provides it for PostgreSQL, and a native vector type is documented for SQL Server 2025 and Azure SQL.

Why it matters

Retrieval is how an AI application is given an organisation's own content. The quality of what is retrieved bounds the quality of the answer.

If vector search is a feature of a database already in use, the case for running a separate specialist store narrows. DII has verified that the feature is available; it has not read evidence of how widely enterprises use it.

The problem it addresses

DII editorial view

Keyword search does not find content that says the same thing in different words, and a language model knows nothing of an organisation's documents unless they are supplied to it. Vector search retrieves content by meaning. The open question is where it should run.

Business and organisational relevance

DII editorial view

The decision is usually whether to add a specialist system or use a feature of a database already in service. That is a question of cost, skills and who secures it, as much as of performance.

Practical use cases

• Retrieval of documents to ground an AI answer
• Semantic search over text
• Similarity matching, such as near-duplicate detection

Benefits and opportunities

• Search by meaning, not only by keyword
• Where it is a feature of an existing database, existing access control and operations apply

Risks, limitations and dependencies

• Approximate indexes trade recall for speed; results are not exact
• Embeddings depend on the model that made them; changing the model means re-embedding
• Product limits apply: for example, one vendor documents limits on dimensions and unsupported features for its vector type

Prerequisites for adoption

DII editorial view

• Content that is classified and has access rules to inherit
• A chosen embedding model, and a plan for when it changes
• A way to measure recall on your own content

Implementation considerations

• Start with the database you already run. Check whether its vector support meets the need before adding a new system to operate and secure.
• Treat embeddings as derived data. They should carry the classification and access rules of the content they were made from.
• Plan for the model to change. Embeddings from one model are not comparable with those from another; a change means re-embedding.
• Test recall, not only speed. Approximate search can miss relevant items. Measure it on your own content.

The DII Radar assessment

Catalogue status

Not yet assessed. DII has not published a Radar assessment for Vector Databases and Retrieval Infrastructure. It is listed in the catalogue so that it can be explained. No relevance, direction, strategic impact or enterprise adoption is given for it, and it is not plotted on the Radar.

What to consider next

DII editorial view

• Check whether the database you already run meets the need
• Treat embeddings as derived data, with the classification of their source
• Test recall, not only speed