Vector indexes

Vector indexes extend the Db2 VECTOR data type and the associated similarity search capabilities by adding native, index-based acceleration for approximate similarity lookups on high-dimensional vectors.

While the VECTOR data type and brute-force similarity search capability debuted in Db2® 12.1.2, vector indexes greatly improve performance at scale, especially when working with large collections of embeddings.
Note: Vector index support is available in Db2 12.1.5 and later.

Advanced search and indexing capabilities

Vector indexes benefit AI and machine learning workloads that rely on vector comparisons. Vector indexes provide the following enhancements to Db2:

  • Semantic search.
  • Recommendations and personalization.
  • Image and document matching.
  • Embedding-driven classification.

Specialized indexing

The Db2 VECTOR search feature uses a brute-force approach. It works well for small datasets or when queries limit the search space. However, interactive and high-volume scenarios—such as semantic search, retrieval-augmented generation, or fraud detection—typically issue multiple similarity queries and operate over very large datasets. These workloads require faster ways to locate relevant vectors without scanning everything.

Modern embeddings are large, often between 768 and 1500 dimensions. Regular searching in such high-dimensional spaces can negatively affect your vector operations:

  • Exponentially growing search areas.
  • Sparse data distribution even at massive scale.
  • High per-query computational cost.

Traditional indexing techniques degrade rapidly under these conditions and become slower than brute force. Specialized vector indexes are essential to overcome these challenges.

Approximate similarity search

Conventional indexing structures were originally optimized for low-dimensional spatial data. When extended to hundreds or thousands of dimensions, they become inefficient. To address this, a new class of indexing methods trades perfect accuracy for speed—these are known as Approximate Nearest Neighbor (ANN) structures.

ANN structures focus on retrieving close-enough matches rather than exhaustive exact neighbors. The resulting performance gains are substantial and typically acceptable for most AI-driven use cases. Accuracy is measured using RECALL, which indicates how many true nearest neighbors are returned.

For more information, see ANN index implementation.

Similarity searches with vector indexes

A similarity search query with an available vector index has four stages:
  1. Index selection: The optimizer determines whether to use the vector index based on the distance metric in your query, available statistics, and whether you specified APPROX or EXACT in the fetch clause.
  2. Approximate search: If using the index, Db2 runs a graph traversal, starting from entry points and following edges to find candidate vectors. The compressed vectors table is consulted first for fast filtering, then full vectors are retrieved for final ranking.
  3. Journal consultation: Newly inserted vectors in the insert journal are also searched to ensure complete results.
  4. Result merging: Results from both the graph and the insert journal are merged and ranked by distance to return the top-K matches.
You can control search behavior using the APPROX and EXACT keywords in your queries. When neither is specified, Db2 defaults to approximate search if a suitable index exists, or exact (brute-force) search otherwise.

Performance considerations

Vector indexes deliver substantial performance improvements for large-scale similarity search. They can efficiently handle datasets ranging from millions to billions of vectors, with typical queries completing in milliseconds rather than seconds. The disk-backed design supports datasets larger than available RAM, making it practical for production workloads without requiring massive memory resources. Additionally, Product Quantization compression reduces storage requirements while enabling faster initial filtering during search operations.

However, these performance gains come with important trade-offs. Vector indexes return approximate nearest neighbors rather than guaranteed exact matches, typically achieving 90% or higher recall. As the insert journal accumulates new vectors, query performance gradually degrades, requiring periodic index recreation to maintain optimal speed. Initial index creation can take considerable time for large datasets, and the auxiliary tables consume additional disk space beyond the base table storage.

When evaluating whether to use vector indexes, consider both the performance benefits for your query workload and the operational overhead of maintaining the index structure over time.

Restrictions

The following restrictions apply to the use of the vector index object in Db2 12.1.5:
  • Before using VECTOR indexes, review the usage notes and restrictions in CREATE VECTOR INDEX statement.
  • If a table has a vector index defined with either the IN <table-space-name> clause or the COMPRESSED VECTORS IN <table-space-name> clause, a table space rollforward operation might not validate that all required table spaces are included. In the Db2 12.1.5 release, the rollforward utility does not consider the table space that is specified in either of these clauses when determining the completeness of the table space list. As a result, the operation might proceed without returning error SQL4906N, even when the table space list is incomplete. To avoid inconsistent recovery results, you must include all of the following table spaces explicitly in the rollforward operation:
    • The table space of the base table.
    • The table space that is specified by the IN <table-space-name> clause, if used.
    • The table space that is specified by the COMPRESSED VECTORS IN <table-space-name> clause, if used.
    Failure to include all required table spaces can result in an inconsistent state after rollforward.