Goal
The goal of this section is to evaluate the architectural approaches for implementing vector indexes in MySQL, compare their advantages and trade-offs, and converge on a design that integrates natively with InnoDB while preserving transactional consistency, scalability, reliability, and extensibility across vector indexing algorithms.
Study of existing approach/solution
Vector indexing can be implemented in MySQL using several architectural approaches. This task evaluates their advantages and trade-offs to converge on a design/architecture for native vector index support in MySQL.
Vector indexes can be implemented using several algorithms. At this stage, the focus is not on selecting a specific algorithm but on defining the architectural integration of vector indexing within InnoDB. IVF is being used as the initial reference algorithm to guide and validate the overall design.
Approaches being studied
Following are the 2 approaches which are being studied now
1. Vector index as any other secondary index using existing secondary index machinery in place
The vector index is implemented as an InnoDB-managed secondary index, rather than as an external search service or a full in-memory structure. It is associated with a base-table secondary index definition and stores a vector payload together with the clustered primary-key reference needed to locate the base row. The vector index has its own InnoDB page type and page layout, optimized for IVF metadata, centroids, and posting-list entries rather than B-tree ordering.
Like other InnoDB indexes, vector-index pages are read through the Buffer Pool, protected by page latches during modification, persisted by normal flushing, and recovered through redo logging. Inserts, updates, deletes, rollback, and purge are translated into localized changes to the relevant vector posting pages; the complete index is not loaded or rewritten for a single row change. Query execution selects relevant IVF lists, reads their pages through the Buffer Pool, and returns candidate primary-key references for normal MySQL row visibility checks and result processing. This keeps the storage, durability, transactional integration, and lifecycle management inside InnoDB while allowing vector-specific page formats and algorithms.
This approach is used in PoC done in oracle. PoC design details
2. Vector index as a sub-table
This proposal introduces native Approximate Nearest Neighbor (ANN) indexing within MySQL/InnoDB. It uses a disk-friendly, k-means tree-based architecture powered by ScaNN, avoiding the random I/O and memory constraints associated with graph-based indexes for datasets larger than memory.
Vector index data is stored in a hidden InnoDB sub-table and maintained synchronously with the base table. This design provides transactional consistency, MVCC visibility, read-your-own-writes behavior, rollback support, and crash recovery using existing InnoDB mechanisms. It also supports multiple distance measures, quantization, parallel index construction and search, persistent metadata, and operational observability.
The approach establishes reusable infrastructure for native vector DDL, DML, query execution, and storage while remaining extensible to future indexing algorithms such as HNSW. It enables MySQL to support scalable AI retrieval workloads without requiring a separate vector database.
This approach is used by Google. Google design details
Decision
TBD
Rationale
TBD
Goal
The goal of this section is to evaluate the architectural approaches for implementing vector indexes in MySQL, compare their advantages and trade-offs, and converge on a design that integrates natively with InnoDB while preserving transactional consistency, scalability, reliability, and extensibility across vector indexing algorithms.
Study of existing approach/solution
Vector indexing can be implemented in MySQL using several architectural approaches. This task evaluates their advantages and trade-offs to converge on a design/architecture for native vector index support in MySQL.
Vector indexes can be implemented using several algorithms. At this stage, the focus is not on selecting a specific algorithm but on defining the architectural integration of vector indexing within InnoDB. IVF is being used as the initial reference algorithm to guide and validate the overall design.
Approaches being studied
Following are the 2 approaches which are being studied now
1. Vector index as any other secondary index using existing secondary index machinery in place
The vector index is implemented as an InnoDB-managed secondary index, rather than as an external search service or a full in-memory structure. It is associated with a base-table secondary index definition and stores a vector payload together with the clustered primary-key reference needed to locate the base row. The vector index has its own InnoDB page type and page layout, optimized for IVF metadata, centroids, and posting-list entries rather than B-tree ordering.
Like other InnoDB indexes, vector-index pages are read through the Buffer Pool, protected by page latches during modification, persisted by normal flushing, and recovered through redo logging. Inserts, updates, deletes, rollback, and purge are translated into localized changes to the relevant vector posting pages; the complete index is not loaded or rewritten for a single row change. Query execution selects relevant IVF lists, reads their pages through the Buffer Pool, and returns candidate primary-key references for normal MySQL row visibility checks and result processing. This keeps the storage, durability, transactional integration, and lifecycle management inside InnoDB while allowing vector-specific page formats and algorithms.
This approach is used in PoC done in oracle. PoC design details
2. Vector index as a sub-table
This proposal introduces native Approximate Nearest Neighbor (ANN) indexing within MySQL/InnoDB. It uses a disk-friendly, k-means tree-based architecture powered by ScaNN, avoiding the random I/O and memory constraints associated with graph-based indexes for datasets larger than memory.
Vector index data is stored in a hidden InnoDB sub-table and maintained synchronously with the base table. This design provides transactional consistency, MVCC visibility, read-your-own-writes behavior, rollback support, and crash recovery using existing InnoDB mechanisms. It also supports multiple distance measures, quantization, parallel index construction and search, persistent metadata, and operational observability.
The approach establishes reusable infrastructure for native vector DDL, DML, query execution, and storage while remaining extensible to future indexing algorithms such as HNSW. It enables MySQL to support scalable AI retrieval workloads without requiring a separate vector database.
This approach is used by Google. Google design details
Decision
TBD
Rationale
TBD