Percona Server for MySQL 9.7 gets DISTANCE() for native vector similarity

Percona released, in Percona Server for MySQL 9.7.2-2, the functions DISTANCE() and VECTOR_DISTANCE(), which calculate similarity between vectors directly in SQL. The announcement, published on the company's blog, closes an annoying gap: MySQL already had the VECTOR type (with TO_VECTOR() and FROM_VECTOR()) since version 9.7, but was missing the piece that turns an embeddings column into something queryable by proximity. Without this function, developers stored embeddings in MySQL and needed another system, a dedicated vector DB such as Pinecone, Qdrant, or pgvector on Postgres, just to perform similarity search.

What exactly was added

DISTANCE(vector1, vector2, metric) takes two values of type VECTOR (or literals converted via TO_VECTOR()) and a fixed metric string, and returns a DOUBLE with the distance score. VECTOR_DISTANCE() is just a synonym, with identical behavior. Five metrics are supported: EUCLIDEAN, EUCLIDEAN_SQUARED, MANHATTAN, COSINE, and DOT. This is already more than native MySQL itself offers: Oracle's implementation, available only on HeatWave MySQL running on OCI, covers only COSINE, DOT, and EUCLIDEAN, and it doesn't exist in either the Community or the Commercial edition of standard MySQL. Percona is, in practice, bringing to any infrastructure, on-premises, another cloud, bare metal, a feature that today is vendor lock-in to a single platform.

Two of these metrics deserve attention from anyone already working with production embeddings. EUCLIDEAN_SQUARED produces the same ranking as EUCLIDEAN, but skips the square root, useful in ORDER BY when only relative position matters, not the absolute value. And DOT inverts the usual convention for the dot product: since the industry tends to multiply by -1 and flip the scale, here smaller values also mean higher similarity, keeping consistency with the other four metrics. It's worth reading the documentation carefully before choosing: the right metric depends on how the embedding model was trained. Most modern models, such as OpenAI's and Cohere's, were trained with cosine similarity, so COSINE is the safe default. If the vector carries magnitude information, as in non-normalized numeric features, EUCLIDEAN tends to be more appropriate.

Usage example

The typical flow starts with a table that already stores the embedding alongside the relational data:

CREATE TABLE products (
 id INT PRIMARY KEY,
 name VARCHAR(255),
 embedding VECTOR(1536)
);

INSERT INTO products VALUES
 (1, 'Product A', TO_VECTOR('[0.1, 0.2, 0.3, ...]')),
 (2, 'Product B', TO_VECTOR('[0.15, 0.25, 0.35, ...]'));

The similarity query is embedded right in the SELECT, with no external call to any other service:

SELECT id, name,
 DISTANCE(embedding, TO_VECTOR('[0.12, 0.22, 0.32, ...]'), 'EUCLIDEAN') AS score
FROM products
ORDER BY score
LIMIT 5;

The result is ordered by score, from closest to farthest. This is the kind of query that a RAG (retrieval-augmented generation) team today builds against a separate vector DB, just to retrieve the most relevant text chunks before sending the prompt to the language model. With DISTANCE(), this retrieval happens in the same relational database that already stores product, user, order, or whatever else, which eliminates data synchronization between two systems and simplifies the architecture design for anyone starting to put semantic search into production.

SIMD under the hood

The most interesting engineering aspect of the announcement is how Percona achieved acceptable performance without yet having an approximate search index. The implementation detects the available SIMD instruction set on the CPU at startup, and automatically picks the best tier: SSE4.2 on x86_64 or NEON on aarch64 give 2x to 3x over scalar execution; AVX2 reaches 4x-6x; AVX-512F, when available, promises 8x to 12x; and SVE2 covers ARM with scalable-width vectors. This avoids compiling a fixed binary per target architecture (the -march=native approach), which would be unfeasible for a product distributed across multiple platforms. Small vectors, with fewer than 16 dimensions, use the 128-bit tier because the cost of setting up larger registers outweighs the gain; large vectors, like the 1536 dimensions in OpenAI's example, automatically use the widest tier available. The kernels also always use unaligned memory reads, because VECTOR columns have no guaranteed cache-line alignment and modern CPUs don't penalize this kind of access when the data is already in cache.

What's still missing: without an index, it's a full table scan

Here's the point that separates enthusiasm from responsible production use. DISTANCE() is a scalar function: it calculates the distance between two vectors and returns a number, period. A query like ORDER BY DISTANCE(...) LIMIT k over a large table runs in O(n): the database calls the function for every row and then sorts. It's exact and accelerated by SIMD per row, but it doesn't scale the way an HNSW (Hierarchical Navigable Small World) or IVF (Inverted File) index would. Percona itself is direct about this in the announcement: ANN indexing is missing, and it's the next item on the roadmap. Without an approximate search index, finding the 10 nearest neighbors in a table of 1 million vectors means scanning the million rows on every query, something that gets expensive fast as the table grows.

When it's worth using this now

For small or medium catalogs, a few tens of thousands of rows, DISTANCE() already solves semantic search without bringing another system into the architecture, and it still delivers an exact result, not an approximate one, which can be preferable in domains where precision matters more than raw speed. For bases with millions of embeddings requiring millisecond latency, the indexing piece is still missing: a dedicated vector DB or Oracle's HeatWave (which already has ANN) remain the more sensible choice until Percona delivers HNSW or IVF in Server for MySQL. It's worth following the roadmap: the company explicitly asks for feedback on which indexing strategies and embedding-model integrations to prioritize, so the feature should evolve quickly in upcoming versions.