By Christian Garcia-Arellano, Zach Hoggard and Chris Stojanovski

The arrival of vector indexing in Db2 12.1.5 marks an important milestone in bringing speed to the AI and semantic search capabilities for Db2 users. Throughout the Early Access Program, we introduced the fundamentals of vector indexing and demonstrated how query-time controls can help balance recall and latency. Now that the feature is generally available, it's time to focus on getting the most out of it. In this blog, we explore two of the most important factors in achieving top-tier performance: vector compression tuning and efficient index construction.

While query-time parameters like SEARCH_LIST_SIZE and SEARCH_BEAM_WIDTH (covered in our previous blog Understanding the Search Accuracy vs Speed Trade Off) allow you to dynamically adjust the speed-accuracy balance, the decisions you make at index creation time establish the foundation upon which those query optimizations operate. Specifically, the compression ratio you choose for the compressed vectors table directly impacts both memory requirements and search accuracy, while the build-time resource settings determine how efficiently you can construct and maintain indexes at scale.

This blog addresses two fundamental questions for production deployments:

1. How do you optimize vector compression to balance memory footprint with search accuracy?
2. How do you configure index builds to complete efficiently, even for datasets with tens of millions of vectors?

Understanding these aspects is essential for DBAs and architects planning vector index deployments with Db2, as they directly affect system requirements and how that relates to overall vector search performance.

Vector Compression: The Foundation of Search Performance

The efficiency of the Db2 vector index search algorithm hinges on a critical architectural decision made at index creation time: how aggressively to compress the vectors in the compressed vectors table. This decision directly impacts both the memory footprint of the index and the accuracy of distance estimates during search, making it one of the most important tuning parameters for balancing performance and recall.

As we described in our previous blog on search accuracy trade-offs, the search algorithm operates in two phases. During each iteration, it rapidly evaluates SEARCH_BEAM_WIDTH (or W, that has a default value of 2) candidates using compressed distance calculations from the compressed vectors table, then loads full-precision vectors from the graph table only for the most promising candidates. The speed of these compressed evaluations depends entirely on the compressed vectors being cached in memory—any disk I/O during this phase would severely degrade query latency. This is a key differentiator of Db2’s DiskANN based vector index, as it significantly reduces the runtime memory requirements when compared with other graph-based implementations, like HNSW, that require the full graph in memory to perform. At the same time, the accuracy of the compressed distance estimates determines how effectively the algorithm identifies promising candidates, directly affecting recall.

The compression ratio thus represents a fundamental trade-off: more compression reduces runtime memory requirements, but at the cost of less accurate distance estimates and potentially lower recall. Less compression preserves more information for accurate distance estimates but increases memory requirements, potentially preventing full caching in memory constrained environments.

Controlling Compression Ratio with PCT_COMP_VECT_SIZE

Because full caching of the compressed vectors is essential for performance, Db2 allows you to control the compression ratio at index creation time through the PCT_COMP_VECT_SIZE parameter. This parameter defines the compressed vector size as a percentage of the full vector size, enabling you to balance memory footprint against search accuracy.

The syntax for specifying this parameter during index creation is:

CREATE VECTOR INDEX index_name

   ON table_name(vector_column)

   WITH DISTANCE distance_metric

   PCT_COMP_VECT_SIZE percent_value

The default value of 5 percent provides a good starting point for most workloads, offering substantial memory savings while maintaining reasonable distance estimate accuracy. For example, with 768-dimensional FLOAT32 vectors (3,072 bytes per vector), a 5% compression ratio results in compressed vectors of approximately 154 bytes—a 20× reduction in size.

Impact on Search Performance

The PCT_COMP_VECT_SIZE parameter affects search performance through two interconnected mechanisms:

• Larger PCT_COMP_VECT_SIZE values (e.g., 10-20%) reduce compression, resulting in more accurate distance estimates during the candidate filtering phase. This improved fidelity helps the search algorithm identify the true nearest neighbors more reliably, leading to higher recall. The compressed vectors retain more information about the original vector's structure, making the approximate distance calculations more representative of the true distances. However, the larger compressed vectors consume more memory, which may prevent full caching of the compressed vectors table in memory-constrained environments or for very large datasets. 
• Conversely, smaller values (e.g., 2-5%) maximize compression and minimize memory footprint, making it easier to cache the entire compressed vectors table in the buffer pool. This ensures that all compressed distance calculations are satisfied from memory, maintaining low query latency even for large datasets. However, aggressive compression may reduce the fidelity of distance estimates, potentially causing the algorithm to overlook true nearest neighbors during the candidate filtering phase and reducing recall.

Looking at a real-world example

As in our previous blog, we return to the Entity Customer dataset. In this experiment, we evaluated the impact of reducing the vector compression ratio by increasing PCT_COMP_VECT_SIZE from its default value of 5% to 15%. We then measured the resulting changes in both query performance and recall.

The test was conducted using a dataset containing one million vectors, which would require approximately 3 GB of memory if fully cached. With the default compression setting, the vector index consumed approximately 153 MB of memory, while the 15% setting increased memory usage to 460 MB. Our test environment for this is the same we used before: an AWS instance with 16 CPU cores, and locally attached NVMe storage for high-throughput disk I/O for all tablespaces and transaction logs.

As shown in the results, tripling the memory allocated to compressed vectors improved query performance by 8%, while recall changed by less than 1%. For workloads where query latency is a priority and additional memory is available, increasing PCT_COMP_VECT_SIZE can provide a straightforward way to improve vector search performance. 

Managing Caching of the Compressed Vectors

As discussed earlier, compressed vectors are stored in a separate system table that forms part of the vector index structure, and to achieve optimal query performance, this table should be fully resident in memory, as it is accessed extensively during graph traversal. Keeping compressed vectors in memory minimizes I/O and reduces the need to access the graph table portion of the index, resulting in faster query execution.

Db2 provides explicit control over the placement and caching characteristics of this table through the COMPRESSED VECTORS IN clause. This clause allows you to specify a dedicated tablespace for the compressed vectors table when the vector index is created:

CREATE VECTOR INDEX index_name

   ON table_name(vector_column)

   WITH DISTANCE distance_metric

   PCT_COMP_VECT_SIZE percent_value

   COMPRESSED VECTORS IN tablespace_name

By placing the compressed vectors table in its own tablespace, you can associate it with a dedicated buffer pool sized specifically to accommodate the entire table. This separation gives you fine-grained control over memory allocation and ensures that compressed vector lookups during the iterative search are always satisfied from memory, eliminating disk I/O during the critical candidate filtering phase.

To implement this strategy effectively:

1.  Calculate the compressed vectors table size:

compressed_size = num_vectors × vector_dimensions ×

bytes_per_element × 

(PCT_COMP_VECT_SIZE / 100) 

2.  Create a dedicated tablespace and buffer pool using that size as reference for sizing the buffer pool:

CREATE BUFFERPOOL vec_comp_bp SIZE 10000 

PAGESIZE 32K; 

CREATE TABLESPACE vec_comp_ts PAGESIZE 32K 

BUFFERPOOL vec_comp_bp; 

3.  Create the index with the dedicated tablespace: 

   CREATE VECTOR INDEX entity_customer_vec_idx

      ON entity_customer(embedding_vector)

      WITH DISTANCE EUCLIDEAN

      PCT_COMP_VECT_SIZE 5

      COMPRESSED VECTORS IN vec_comp_ts

4.  Monitor buffer pool hit ratios to verify full caching:

   SELECT BP_NAME, POOL_DATA_L_READS, POOL_DATA_P_READS,

          DECIMAL((1 - (FLOAT(POOL_DATA_P_READS) /

          FLOAT(POOL_DATA_L_READS))) * 100, 5, 2) AS HIT_RATIO

   FROM TABLE(MON_GET_BUFFERPOOL('',-2))

   WHERE BP_NAME = 'VEC_COMP_BP'

A hit ratio approaching 100% confirms that the compressed vectors table is fully cached, ensuring optimal query performance.

Controlling Resources at Build Time for Efficient Index Construction 

Up to this point in this blog series, we have focused primarily on query-time behavior—how to execute similarity searches efficiently and tune the speed-accuracy trade-off. But for many teams, especially DBAs responsible for production deployments, another critical question emerges: what does it take to build these indexes efficiently?

Vector index construction is fundamentally different from traditional B-tree index creation. Building the graph structure requires iteratively adding vectors, computing distances to establish neighbor relationships, and potentially restructuring portions of the graph to maintain its navigability properties. For large datasets with millions of vectors, this process can be time-consuming and resource-intensive, directly impacting deployment timelines, maintenance windows, and operational agility.

This is where the CREATE VECTOR INDEX build-time options become essential, particularly BUILD_PARALLELISM and BUILD_MEM_BUDGET. These settings influence how much parallel work Db2 can perform during index creation and how much memory is available for the build process, directly affecting construction time and resource utilization.

BUILD_PARALLELISM: Leveraging Multiple Cores

The BUILD_PARALLELISM parameter controls the degree of parallelism used during index construction. Vector index building involves computationally intensive operations—distance calculations, graph traversals, and neighbor list updates—that can benefit significantly from parallel execution across multiple CPU cores. By default, this value is automatically determined based on the number of available CPUs. In shared environments, however, administrators may choose to tune BUILD_PARALLELISM to control the impact of index creation on other workloads. Since vector index construction is highly CPU-intensive, the selected level of parallelism will generally drive CPU utilization roughly in proportion to the number of worker threads employed.

The syntax for specifying build parallelism is:

CREATE VECTOR INDEX index_name

   ON table_name(vector_column)

   WITH DISTANCE distance_metric

   BUILD_PARALLELISM num_threads

BUILD_MEM_BUDGET: Managing Memory During Construction

The BUILD_MEM_BUDGET parameter specifies the amount of memory (in gigabytes) allocated for index construction. This memory is used for caching vectors, maintaining intermediate graph structures, and buffering I/O operations during the build process. This memory is allocated from the UTIL_HEAP, so a corresponding amount of memory should be available from this heap to ensure that the specified budget is available for the index construction.

The syntax for specifying the memory budget is:

CREATE VECTOR INDEX index_name

   ON table_name(vector_column)

   WITH DISTANCE distance_metric

   BUILD_MEM_BUDGET memory_gb

Larger memory budgets (e.g., 16-64 GB) can significantly accelerate index construction by reducing disk I/O and enabling more efficient in-memory processing of graph structures. However, you must balance this against available system memory and other database memory consumers.

Importantly, the BUILD_MEM_BUDGET does not need to accommodate the entire dataset. The index construction algorithm is designed to work efficiently even when the memory budget is a fraction of the total dataset size, using disk-based processing with intelligent caching strategies.

Real-World Build Performance: Scaling to 50 Million Vectors

To demonstrate the practical impact of these build-time parameters, we conducted index construction tests on a realistic high-performance environment (16 cores, 128 GB of total memory, and locally attached NVMe drives). The results illustrate that with appropriate resource allocation, Db2 can build vector indexes efficiently even at large scale. For these tests, we used again the Entity Customer data set, this time varying the number of vectors from 5 to 50 million. To ensure that the comparison was fair, we used the same level of parallelism (8 cores out of the 16 cores available), and always 32 GB of build memory budget. 

The results demonstrate several key insights:

• Memory efficiency: At the 50-million-vector scale, the dataset occupies approximately 143 GB of storage (50M vectors × 768 dimensions × 4 bytes per FLOAT32). Yet the build completed successfully with only a 32 GB memory budget—less than 25% of the dataset size. This demonstrates that strong build performance does not require the entire dataset to fit in memory. With the right storage environment (high-throughput NVMe) and appropriate build settings, Db2 can construct vector indexes efficiently through intelligent disk-based processing. 
• Parallelism benefits: The 8-way parallelism effectively utilized the available CPU cores, distributing the computational workload and reducing overall build time. For systems with more cores, higher parallelism settings could further accelerate construction. 
• Scalability: Index build time scales sub-linearly with dataset size, given a fixed amount of memory – 32 GB. While a 10× increase in dataset size (from 5 million to 50 million vectors) naturally requires more build time, the fixed amount of memory per thread (4 GB) gives significant more benefit to the smaller data sets, which results in the sub-linear performance.

These results have important practical implications for production deployments:

• Deployment planning: Understanding build times at your target scale allows you to plan deployment timelines and maintenance windows realistically. For datasets in the tens of millions of vectors, index construction may take hours rather than minutes, but it remains feasible within typical maintenance windows.
• Infrastructure requirements: You don't need to provision memory equal to your dataset size to build indexes efficiently. Instead, focus on providing adequate memory for the build process (e.g., 32-64 GB) and ensuring high-throughput storage (NVMe or equivalent) to support the disk-based processing.
• Incremental deployment: For very large datasets, consider building indexes on subsets of data first to validate performance characteristics, then scaling to the full dataset once you've optimized build parameters for your environment.

Tuning Strategy for Build-Time Parameters

Based on these insights, here's a practical approach to tuning build-time parameters:

1. Start with baseline settings:

• BUILD_PARALLELISM: Set to 50-75% of available CPU cores to leave headroom for concurrent operations. The default is AUTOMATIC and will use up to 50% of the CPU cores available. 
• BUILD_MEM_BUDGET: Start with 16-32 GB, depending on available system memory. The default is 1 GB, but given the allocations are out of the UTIL_HEAP, it is recommended that the setting of UTIL_HEAP is adjusted proportionally to the number of concurrent index builds and their build memory budgets.

2. Monitor build progress:

• Track build time and resource utilization (CPU, memory, I/O)
• Use Db2 monitoring tools to observe memory usage and I/O patterns during construction

3. Validate at target scale:

• Test index construction with representative dataset sizes
• Ensure build times fit within your maintenance window requirements
• Verify that resource utilization doesn't impact concurrent workloads

The key insight is that build-time performance is not just about waiting longer or shorter—it's an integral part of deployment planning, maintenance windows, and rollout strategy. By understanding and tuning these parameters, DBAs can ensure that vector index deployments integrate smoothly into existing operational processes.

Bringing It All Together: A Complete Tuning Strategy

Throughout this blog series, we've explored vector indexing in Db2 from multiple angles: the initial introduction and basic usage in our first blog, the query-time accuracy-speed trade-offs in our second blog, and now the index-time compression and build optimizations. Together, these form a comprehensive tuning strategy for production vector index deployments.

Here's how these pieces fit together:

• Index Creation Time:

1. 1. Choose PCT_COMP_VECT_SIZE based on your memory constraints and recall requirements (default: 5%)
   2. Allocate a dedicated tablespace and buffer pool for compressed vectors using COMPRESSED VECTORS IN
   3. Set BUILD_PARALLELISM to leverage available CPU cores (e.g., 8-16 threads)
   4. Configure BUILD_MEM_BUDGET based on available memory (e.g., 16-64 GB) and UTIL_HEAP size.
   5. Ensure high-throughput storage (NVMe or equivalent) for efficient disk-based processing

• Query Time:

1. 1. Start with default search parameters (SEARCH_LIST_SIZE=50, SEARCH_BEAM_WIDTH=2)
   2. Tune SEARCH_LIST_SIZE first if recall is insufficient (increase to 100-200)
   3. Adjust SEARCH_BEAM_WIDTH if needed for additional recall improvements (increase to 10-20)
   4. For latency-sensitive queries, reduce SEARCH_LIST_SIZE (decrease to 10-25) for K=10
   5. Monitor buffer pool hit ratios to ensure compressed vectors remain fully cached.

• Operational Monitoring:

1. 1. Track query latency and recall metrics to validate performance.
   2. Monitor buffer pool hit ratios for the compressed vectors table space and buffer pool.
   3. Observe resource utilization during index builds to optimize future constructions.
   4. Use Db2's monitoring tools to identify performance bottlenecks.

This holistic approach ensures that your vector index deployment achieves production-grade performance across all dimensions: efficient construction, optimal memory utilization, and fast, accurate queries.

Conclusion

Achieving top performance with Db2 vector indexes requires attention to both query-time and index-time optimizations. While the query-time parameters we discussed in our previous blog (SEARCH_LIST_SIZE and SEARCH_BEAM_WIDTH) provide dynamic control over the speed accuracy trade-off, the decisions you make at index creation time—compression ratio, buffer pool allocation, and build resource configuration—establish the foundation upon which those query optimizations operate.

The vector compression ratio (PCT_COMP_VECT_SIZE) represents a fundamental trade-off between memory footprint and search accuracy. By understanding this trade-off and leveraging dedicated tablespaces and buffer pools for the compressed vectors table, you can ensure that the critical candidate filtering phase operates entirely from memory, delivering the low-latency performance that makes approximate nearest-neighbor search practical at scale.

Similarly, the build-time resource parameters (BUILD_PARALLELISM and BUILD_MEM_BUDGET) determine how efficiently you can construct and maintain indexes, directly impacting deployment timelines and operational agility. As we demonstrated with our 50-million-vector test case, Db2 can build vector indexes efficiently even when the memory budget is a fraction of the dataset size, provided you have appropriate storage infrastructure and build configuration.

Together with the query-time tuning strategies from our previous blog, these index-time optimizations provide a complete toolkit for deploying vector indexes in production environments. Whether you're building customer intelligence applications like the Entity Customer workload we explored previously, or implementing semantic search, recommendation systems, or RAG applications, these tuning strategies will help you achieve the performance and accuracy your use case requires.

We encourage you to experiment with these parameters in your own deployments and share your feedback as we continue to refine the vector indexing capability toward general availability. The Early Access Program provides an opportunity to influence the feature's evolution based on real-world production requirements.

For more information about the Db2 vector index and to participate in the Early Access Program, visit the Db2 LUW Early Access program page.

About the Authors

Christian Garcia-Arellano is STSM and Db2 OLTP Architect at the IBM Toronto Lab and has a MSc in Computer Science from the University of Toronto. Christian has been working in various DB2 Kernel development areas since 2001. Initially Christian worked on the development of the self-tuning memory manager (STMM) and led various of the high availability features for DB2 pureScale that make it the industry leading database in availability. More recently, Christian was one of the architects for Db2 Event Store, and the leading architect of the Native Cloud Object Storage feature in Db2 Warehouse. Christian can be reached at cmgarcia@ca.ibm.com .

Zach Hoggard is a Senior Software Developer for IBM Db2 in the IBM Data & AI organization at the IBM Canada Lab. Zach has over 12 years of Db2 Kernel development experience and his areas of expertise are the Buffer Pool and Storage Manager components of Db2 but also has extensive experience with all Db2 Kernel components. Zach has strong interest in Db2 problem determination as well as Db2 system design in the Kernel area. Zach is an IBM Certified Database Associate for Db2 v11.1 and v10.5 and holds a bachelor’s degree in software engineering from Western University in London, Ontario, Canada.

Chris Stojanovski is an Advisory Software Developer for IBM Db2 in the IBM Data & AI organization at the IBM Canada Lab. Chris has been with IBM for five years, contributing primarily to the Index Manager team while also working with Data Management Services and XML. As a member of the Db2 Kernel team, he is passionate about expanding his knowledge of database internals and system architecture. Chris holds a Bachelor of Computer Science from the University of Waterloo, a Bachelor of Business from Wilfrid Laurier University, and a master’s in computer science from Western University.

#Db2 #Db2Warehouse #AI #vector