Vector Database

Traditional databases excel at exact lookups: find the customer with this ID, the policy with this number, the transaction on this date. But the questions that matter most in compliance and operations are fuzzy: find every document related to this regulatory theme, every complaint similar to this one. A vector database stores numerical representations of meaning and retrieves by similarity, not by exact match.

What is a vector database?

A vector database is a storage system optimised for embedding vectors: high-dimensional numerical arrays that represent the meaning of text, images, or other content. Unlike a relational database that matches rows by column values, a vector database finds the nearest neighbours to a given vector, returning the most semantically similar items from a collection of millions.

The core operation is approximate nearest neighbour (ANN) search. Given a query vector (say, the embedding of a new regulatory notice), the database returns the 10 or 100 stored vectors closest to it, along with their associated metadata: the document title, the source, the date, the classification. The "approximate" matters. Exact nearest neighbour search in high-dimensional space is prohibitively slow. ANN algorithms trade a small amount of accuracy for orders-of-magnitude speed improvement, typically returning correct results 95 to 99 per cent of the time.

Purpose-built vector databases (Pinecone, Weaviate, Qdrant, Milvus) have emerged alongside vector extensions for existing databases (PostgreSQL with pgvector, Redis with vector search). The choice between a purpose-built system and an extension to your existing database depends on scale, latency requirements, and how central vector search is to your application.

The landscape

The vector database market barely existed before 2021. By 2024, purpose-built vendors had collectively raised over two billion dollars in funding. This reflects the explosion in retrieval-augmented generation applications, where a vector database serves as the knowledge store that grounds a language model's responses in organisational data.

For regulated institutions, the deployment model matters as much as the technology. A cloud-hosted vector database means your document embeddings (and the metadata associated with them) reside on a third party's infrastructure. The FCA's operational resilience framework and the PRA's outsourcing expectations apply. Self-hosted options (pgvector, Qdrant, Milvus) keep the data on your own infrastructure but require your team to manage the system.

The integration pattern is settling. Most enterprise deployments use a vector database as one component in a broader pipeline: documents are chunked, embedded, stored in the vector database, and retrieved at query time to provide context to a language model. The vector database does not replace your document management system. It sits alongside it, providing a semantic access layer over content that already exists in your DMS, SharePoint, or compliance archive.

How AI changes this

The primary use case in financial services is powering semantic search over internal knowledge. A compliance officer searching for "how do we handle PEP screening for corporate customers" gets results from policy documents, past case decisions, and regulatory correspondence, even if none of those documents use those exact words. This replaces the Boolean search that most institutions still rely on, where missing a keyword means missing the document.

RAG applications depend on vector databases for retrieval quality. When a relationship manager asks an AI assistant about a client's exposure to a particular sector, the vector database retrieves the relevant sections from research reports, portfolio records, and risk assessments. The accuracy of the final answer is bounded by the accuracy of the retrieval. A poorly configured vector database produces irrelevant context, which produces wrong answers that look right.

Anomaly detection in unstructured data becomes possible. By embedding and storing every customer complaint, regulatory notice, or market commentary, you can identify emerging themes before they appear in structured reports. A cluster of complaints whose embeddings are distant from any existing category may signal a new type of issue that your classification taxonomy hasn't captured yet.

What to know before you start

You probably don't need a purpose-built vector database to start. If your corpus is under a million documents and your latency requirements are moderate (under 500 milliseconds), pgvector on your existing PostgreSQL instance will serve the purpose. Purpose-built vector databases justify their operational overhead at scale: tens of millions of vectors, sub-50-millisecond latency, or complex filtering requirements.

Metadata filtering is essential for access control. In a financial institution, not every user should see every document. Your vector database must support filtering by metadata (classification level, department, client sensitivity) at query time, not post-retrieval. Returning a restricted document to the retrieval pipeline and then filtering it out wastes compute and risks information leakage through the language model's response.

Index maintenance is an ongoing cost. As documents are added, updated, or retired, the vector index must be kept in sync. Stale embeddings are worse than no embeddings: they return outdated information with high confidence. Build automated pipelines that re-embed updated documents and remove embeddings for deleted ones. Treat the vector index as a living system, not a one-time build.

Start by embedding the corpus that gets the most internal search queries and the worst search results today. For most financial institutions, that is either the compliance policy library or the document intelligence archive. Build a retrieval interface, measure search quality with the actual users, and iterate before expanding to other document collections.