Tag Archives: myvector

v1.26.3

MyVector v1.26.3: Maintenance, CI, and Readiness for MySQL 9.7


In my recent series on Scoped Vector Search, we looked at the query patterns that make vector search a first-class citizen in MySQL. While the logic for those searches is now established, the infrastructure supporting them requires constant attention as the MySQL ecosystem moves toward its new release model.

Today, I’m announcing MyVector v1.26.3. This is a foundational release focused on environment compatibility and CI/CD robustness.

What’s in v1.26.3?

This release ensures that MyVector remains stable and buildable across the shifting landscape of MySQL Innovation and LTS releases.

  • MySQL 8.4 & 9.6 Compatibility: We’ve updated the component sources and build logic to align with the headers and requirements for MySQL 8.4 (LTS) and the 9.6 Innovation release.
  • Ready for 9.7: The build system has been adapted to handle the upcoming 9.7 release, ensuring that users can transition to the next Innovation branch without delay.
  • Modernized Release Workflow: We’ve bumped our GitHub Actions (softprops/action-gh-release) from v1 to v2. While invisible to the user, this ensures our release pipeline remains secure and compatible with the latest GitHub runner environments.

Think of v1.26.3 as the “maintenance and readiness” layer that ensures the high-performance HNSW search you rely on continues to compile and run perfectly on the newest versions of MySQL.

Looking Ahead: The Architecture Pivot (PR #76)

While v1.26.3 keeps us current, the real excitement is happening in the lab.

There is a fundamental architecture change currently in development under Component migration (8.4–9.6) and release workflow update.

Unlike the compatibility fixes in today’s release, PR #76 is a structural overhaul. We are re-engineering how the plugin interacts with the MySQL core. This shift is designed to move MyVector closer to a full Component Architecture, which will eventually offer better lifecycle management and even deeper integration with MySQL’s internal services.

This is a significant pivot in how MyVector is built, and it will set the stage for the next generation of vector performance and observability.

Summary

v1.26.3 is the stable, verified update you need for today’s MySQL 8.4/9.6 environments and tomorrow’s 9.7 upgrade. Meanwhile, work continues on the architectural evolution that will define the future of the project.

Scoped Vector Search with the MyVector Plugin for MySQL – Part I


Semantic Search with SQL Simplicity and Operational Control

Introduction

Vector search is redefining how we work with unstructured and semantic data. Until recently, integrating it into traditional relational databases like MySQL required external services, extra infrastructure, or awkward workarounds. That changes with the MyVector plugin — a native vector indexing and search extension purpose-built for MySQL.

Whether you’re enhancing search for user-generated content, improving recommendation systems, or building AI-driven assistants, MyVector makes it possible to store, index, and search vector embeddings directly inside MySQL — with full support for SQL syntax, indexing, and filtering.

What Is MyVector?

The MyVector plugin adds native support for vector data types and approximate nearest neighbor (ANN) indexes in MySQL. It allows you to:

  • Define VECTOR(n) columns to store dense embeddings (e.g., 384-dim from BERT)
  • Index them using INDEX(column) VECTOR, which builds an HNSW-based structure
  • Run fast semantic queries using distance functions like L2_DISTANCE, COSINE_DISTANCE, and INNER_PRODUCT
  • Use full SQL syntax to filter, join, and paginate vector results alongside traditional columns

By leveraging HNSW, MyVector delivers millisecond-level ANN queries even with millions of rows — all from within MySQL.


Most importantly, it integrates directly into your existing MySQL setup—there is no new stack, no sync jobs, and no third-party dependencies.


Scoped Vector Search: The Real-World Requirement

In most production applications, you rarely want to search across all data. You need to scope vector comparisons to a subset — a single user’s data, a tenant’s records, or a relevant tag.

MyVector makes this easy by combining vector operations with standard SQL filters.

Under the Hood: HNSW and Query Performance

MyVector uses the HNSW algorithm for vector indexing. HNSW constructs a multi-layered proximity graph that enables extremely fast approximate nearest neighbor search with high recall. Key properties:

  • Logarithmic traversal through layers reduces search time
  • Dynamic index support: you can insert/update/delete vectors and reindex as needed
  • Configurable parameters like M and ef_search allow tuning for performance vs. accuracy

Under the Hood: HNSW and Query Performance

MyVector uses the HNSW algorithm for vector indexing. HNSW constructs a multi-layered proximity graph that enables extremely fast approximate nearest neighbor search with high recall. Key properties:

  • Fast ANN queries without external services
  • Scoped filtering before vector comparison
  • Logarithmic traversal through layers reduces search time
  • Dynamic index support: you can insert/update/delete vectors and reindex as needed
  • Configurable parameters like M and ef_search allow tuning for performance vs. accuracy

What’s Next

This post introduces the foundational concept of scoped vector search using MyVector and HNSW. In Part II, we’ll walk through practical schema design patterns, embedding workflows, and hybrid search strategies that combine traditional full-text matching with deep semantic understanding — using nothing but SQL.