To answer what is a vector database, one must look past marketing hype to the underlying data structures: systems engineered to store, index, and query mathematical representations of meaning called embeddings. While conventional relational databases match exact text strings, vector search calculates mathematical proximity across high-dimensional spaces to retrieve contextually relevant results. For enterprise teams building semantic search or Retrieval Augmented Generation (RAG) explained workflows, the architectural debate in 2026 centres on hardware footprint and complexity. Approximate nearest-neighbour indexes such as HNSW demand significant memory, which in turn encourages many teams to ask whether extending an existing PostgreSQL stack via pgvector could offer a lower operational burden than deploying and maintaining a dedicated vector platform.
View the data behind this chart
| Layer | Detail |
|---|---|
| Return Limit | Top k nearest neighbour rows specified by LIMIT |
| Target Query Vector | High-dimensional embedding generated from input text |
| Distance Function Operator | Selected metric: L2, inner product, cosine, or L1 |
| Target Embedding Column | Database column containing pre-calculated vectors |
| Relational Source Table | Underlying database table storing unified entity… |
What is a vector database? The core concept explained
In plain terms, a vector database stores embeddings—numeric representations of meaning—and uses similarity search to find the nearest vectors rather than exact keyword matches. It is an operational storage engine designed specifically to store, index, and query high-dimensional numeric arrays known as vector embeddings. In conventional relational databases, queries rely on structured filters or exact lexical matching—locating rows where an exact string or numerical range matches a query clause. In contrast, vector engines execute similarity search, calculating the spatial distance between a target query vector and stored data points to return the closest semantic neighbours.
As organisations deploy artificial intelligence across internal estates in 2026, unstructured information such as technical manuals, customer support tickets, transcripts, and operational documentation increasingly needs to be made accessible to machine learning models. For example, in semantic search or retrieval-augmented generation (RAG) across customer support tickets or product documentation, a vector database finds relevant materials based on meaning even when a search query uses different vocabulary. Vector databases provide the mathematical retrieval layer that underpins modern semantic search and generative AI pipelines, identifying conceptual overlap even when the query shares zero identical keywords with the stored corpus.
Understanding embeddings: The foundation of semantic search
Embeddings are dense arrays of numbers generated by machine learning models that encode the contextual meaning of unstructured data into a high-dimensional mathematical space. When text is processed through an embedding generation step—such as using an embedding() function before database ingestion—the model maps linguistic semantics into hundreds or thousands of floating-point values. Within this vector space, concepts with similar real-world meanings are placed in close proximity to one another.
It is critical to distinguish embedding generation from vector storage. Generation is an algorithmic inference step executed by an external machine learning model or an embedded database function. The database itself is responsible for persistent storage, indexing, and high-speed retrieval. Once unstructured data is converted into vectors, the database evaluates geometric distance using mathematical distance metrics, identifying the nearest records to serve downstream applications.
How vector databases work: Indexing and distance metrics
Vector retrieval relies on calculating the geometric separation between a target query vector and indexed vectors. Open-source extensions such as pgvector document support for six fundamental distance metrics: L2 distance (Euclidean distance), inner product, cosine distance, L1 distance (Manhattan distance), Hamming distance, and Jaccard distance. Selecting the appropriate metric depends directly on how the upstream embedding model normalised its vectors during training.
To execute a query, modern vector layers support two primary search modalities: exact nearest-neighbour search and approximate nearest-neighbour (ANN) search. In practical terms, exact search computes distances against all records in the table, which avoids approximation but becomes slower as datasets grow. In contrast, approximate nearest-neighbour search trades some recall for speed, allowing systems to navigate dense multi-dimensional graphs without calculating distances across every row. For larger workloads, approximate indexes such as HNSW are commonly used.
Building these indexes can incur substantial computational and memory overhead. Approximate nearest-neighbour indexes such as HNSW are often memory-hungry and can be expensive to build. This architectural reality was highlighted by AWS in Aurora's support for pgvector version 0.7.0, which specifically introduced parallelised HNSW index builds to mitigate heavy ingestion overheads.
- •L2 Distance (Euclidean): Measures straight-line spatial distance between coordinate points.
- •Cosine Distance: Evaluates the angular divergence between vectors, disregarding absolute magnitude.
- •Inner Product: Assesses projection alignment, frequently utilised for pre-normalised models.
- •Exact Search: Brute-force scanning across all entries, eliminating index build overhead at the expense of query latency.
- •Approximate Search (HNSW): Graph-based vector clustering that delivers low-latency retrieval while consuming substantial RAM.
The query lifecycle: Running similarity searches
In production environments, executing a vector query involves a structured sequence of operational parameters. As documented in Google Cloud's AlloyDB operational guidance, a standard similarity search requires five distinct inputs: the target table, the designated embedding column, the distance function, the target embedding vector, and the exact number of rows to return.
A common query pattern is to order by vector distance and use LIMIT to return the top k nearest neighbours. In PostgreSQL with pgvector, this entire workflow executes directly within standard SQL queries, enabling engineering teams to combine semantic proximity scoring with standard relational WHERE filters in a single execution plan.
Postgres with pgvector vs dedicated vector engines
The prevailing infrastructure dilemma for UK enterprises in 2026 is choosing between integrated relational vector extensions and dedicated vector platforms. The open-source pgvector extension brings semantic search directly into PostgreSQL, storing high-dimensional vectors in standard database tables alongside relational business data rather than in a separate system. This integrated approach allows organisations to avoid deploying and synchronising an independent vector service, making it simpler to combine vector search with existing relational tables, metadata filters, and joins.
However, hardware resources dictate where this approach reaches its limits. Because graph-based vector indexes like HNSW are memory-sensitive, mid-sized engineering teams should evaluate system sizing and memory headroom. Running large vector indexes inside PostgreSQL may require substantial host RAM to keep index pages and database buffers performing well. For modest datasets and retrieval workflows, pgvector is often enough; but as estates grow or latency and operational demands increase, a dedicated vector database may become worth evaluating.
View the data behind this chart
| Search Mode | Resource Profile | Operational… | |
|---|---|---|---|
| Exact Nearest Search | Brute Force Scan | Zero Index RAM Required | Full Recall But High… |
| HNSW Approximate Index | Graph-Based ANN | Heavy Memory & Build Cost | Fast Queries With Minor… |
| Parallelised HNSW… | Multi-Core Build | High CPU & Memory Spikes | Much faster builds (AWS… |
Hardware sizing, memory footprints, and UK infrastructure planning
For UK organisations operating under strict budgets and stringent compliance mandates, hardware provisioning for vector workloads requires disciplined capacity planning. Approximate nearest-neighbour indexes are often memory-sensitive, so moving too much of the working set to disk can hurt latency. When evaluating RAG infrastructure requirements, systems architects must size memory headroom not merely for the baseline vectors, but for the index graph overheads and concurrent query working memory.
When procuring storage solutions for AI and analytics, UK technology leaders must balance total cost of ownership against architectural complexity. For mid-sized UK firms, extending an existing, fully managed PostgreSQL estate using pgvector can help avoid additional proprietary vector service subscriptions, extra managed service complexity, and some separate data-transfer pipelines. Infrastructure teams should budget for sufficient memory headroom on host servers to maintain index performance while evaluating whether specific workloads actually demand dedicated vector hardware.
Data governance, security, and UK GDPR compliance
Data privacy and regulatory compliance represent a critical decision boundary for UK enterprises implementing vector-enabled retrieval systems. Storing embeddings in third-party hosted systems can create data residency and transfer considerations that need legal review.
Keeping vector storage inside an existing relational database can simplify governance and operational controls. Storing embeddings in PostgreSQL can let organisations reuse existing access controls, encryption, auditing, and retention processes.
Decision framework: When is pgvector enough?
Selecting between an integrated database extension and an independent vector platform should be dictated by data scale, team operational maturity, and query complexity rather than platform vendor marketing. Mid-market UK firms can avoid substantial overhead by following a pragmatic evaluation framework.
PostgreSQL with pgvector represents the optimal production default when the organisation already maintains a PostgreSQL operational footprint, requires relational joins between embeddings and transactional metadata, and operates within moderate dataset boundaries. A shift to a dedicated vector architecture is warranted only when vector ingestion rates saturate database worker pools, when latency targets require specialised distributed vector hardware, or when index memory footprints fundamentally destabilise core transactional database workloads.
Sources
Every figure in this article traces to the sources below.
- •pgvector GitHub Repository — Extension specifications and supported distance metrics
- •Google Cloud AlloyDB Documentation — Vector similarity search operational requirements
- •Google Cloud Architecture Guides — Semantic search mechanics and pgvector capabilities
- •AWS Database Blog — Amazon Aurora support for pgvector 0.7.0 and HNSW build parallelism