Tag Archives: hnsw

MyVector v1.26.9: Keeping Up With MySQL Innovation

MySQL 26.7 Innovation Support Lands


September 22, 2026 · ⁠GitHub Release

MySQL just changed the rules.

With MySQL 26.7, Oracle has moved to a new calendar-based versioning model for Innovation releases. For MyVector, that means one thing:

We need to keep up.

MyVector v1.26.9 adds MySQL 26.7 Innovation support, but the more interesting story is what happened beneath the surface.

This release puts the Component architecture introduced in v1.26.5 through a much more serious test.

From architecture to reliability

When we introduced the MySQL Component architecture in v1.26.5, the goal was straightforward: build MyVector in the direction MySQL itself is taking.

Now we are testing what happens when things don’t go perfectly.

v1.26.9 adds proper Component lifecycle testing, including installation, uninstallation, failed removal, and deinitialization rollback.

Because installing something is easy.

Installing, removing, failing, restarting, and recovering correctly is the real test.

HNSW gets harder to kill

There is also some important HNSW work in this release.

A number of failure paths around HNSW index creation and persistence have been fixed, including a case where an index build could crash mysqld.

That obviously isn’t acceptable.

We also fixed configuration handling so type=hnsw is correctly honored, and persistence failures are now surfaced instead of disappearing silently.

If MyVector cannot save an index, you should know about it.

Does it survive a restart?

This became an explicit test in v1.26.9.

It is one thing to create an index and run a vector search.

It is another thing to restart MySQL and have that index come back.

The new lifecycle tests verify that persisted indexes are actually reloaded from disk.

That is an important distinction as MyVector moves from an interesting MySQL extension toward something people can consider for real workloads.

The release process got better too

v1.26.9 also expands the testing and release pipeline around:

  • MySQL 26.7 compatibility
  • Component lifecycle
  • HNSW
  • Persistent indexes
  • Online updates
  • Stress testing
  • Stanford dataset smoke tests
  • Benchmark failure detection
  • Docker builds

What’s next?

The original MyVector idea hasn’t changed:

Why move your data to another database just because your application needs vector search?

The answer is becoming more interesting as MySQL evolves.

With MyVector, the goal is to bring:

SQL + transactional data + vector search + full-text search + AI workloads

into the same database environment.

MySQL 26.7 brings a new Innovation release.

MyVector 1.26.9 makes sure we’re ready to follow it.

v1.26.5 was about introducing the Component architecture.

v1.26.9 is about proving it.

Get MyVector

⁠MyVector v1.26.9

⁠GitHub Repository

⁠Documentation

MyVector is open source. Feedback, issues, benchmarks, and contributions are welcome.

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.