MySQL Now Has a Native VECTOR Type. Should You Drop pgvector For It?

If you’ve been reaching for Postgres specifically because you needed pgvector, that reason got weaker. MySQL’s 9.x series shipped a native VECTOR column type with built-in distance functions, no extension required. It doesn’t make pgvector obsolete, but it does remove the biggest argument for bringing a second database engine into a stack that’s otherwise entirely MySQL.

What MySQL actually shipped

A VECTOR column stores up to 16,383 entries, each a 4-byte single-precision float, with a default length of 2048 if you don’t specify one. That range comfortably covers the embedding dimensions most teams actually use: 768 for a lot of open embedding models, 1536 for OpenAI’s text-embedding-3-small, 1024 for several current alternatives. Creating one looks exactly like creating any other typed column:

CREATE TABLE documents (
  id INT PRIMARY KEY AUTO_INCREMENT,
  content TEXT,
  embedding VECTOR(1536) NOT NULL
);

Four functions do the actual work. STRING_TO_VECTOR() converts a string representation into the binary vector format MySQL stores. VECTOR_TO_STRING() does the reverse for reading values back out in a human-readable form. VECTOR_DIM() returns how many entries a given vector holds, useful for validating that embeddings from different model versions haven’t gotten mixed into the same column. DISTANCE() computes similarity between two vectors using a specified metric, cosine distance being the one most semantic search workloads reach for:

SELECT id, content,
       DISTANCE(embedding, STRING_TO_VECTOR(:query_vector), 'cosine') AS similarity
FROM documents
ORDER BY similarity
LIMIT 10;

That’s the entire API surface for basic semantic search. No extension to install, no separate package to track across major-version upgrades, no CREATE EXTENSION vector step that someone forgets to run on a new environment.

Where this actually changes a decision

The honest comparison isn’t “MySQL vector search vs pgvector,” feature for feature, it’s “does this remove a reason you were avoiding MySQL.” For a lot of teams, it does. If your application data already lives in MySQL because that’s what your ORM, your hosting provider, or your existing team’s expertise defaults to, and you’re adding a modest semantic search feature, a document similarity lookup, a “related items” feature, a basic RAG retrieval step, standing up a second database engine just to get vector storage was always a heavier decision than the feature justified. Now it doesn’t have to be one.

Factor	MySQL native VECTOR	Postgres + pgvector
Setup	Built in, no extension	CREATE EXTENSION vector
Max entries per vector	16,383	No hard cap, practically similar range
Index types	Fewer, newer	HNSW, IVFFlat, longer track record
Operational overhead	None beyond the DB itself	One more extension to patch and track
Production maturity	New as of the 9.x series	Years of production use at scale
Right fit	Modest vector workloads on an existing MySQL stack	Large-scale, tuning-sensitive vector search

Where pgvector still wins

Scale and index maturity are the real gap, not raw capability. pgvector’s HNSW index has been in production across a large number of RAG and semantic search deployments long enough that its failure modes, tuning parameters, and performance characteristics under real load are well understood. MySQL’s vector indexing is newer, and “newer” in database infrastructure means fewer people have hit its edge cases yet, not that it’s worse in principle. If your semantic search workload is large enough that index build time, recall tuning, and query latency under concurrent load are things you’re actively managing, pgvector remains the safer default in 2026, and that’s likely to stay true for at least another release cycle or two before MySQL’s implementation accumulates the same depth of production experience.

We’ve covered pgvector’s role in a Postgres-based semantic search stack in more depth if that’s the scale you’re building for. The two aren’t mutually exclusive answers to the same question, they’re answers to different questions: “what’s the lowest-friction way to add vector search to what I already run” versus “what’s the most production-proven option at real scale.”

What to actually do

If you’re starting a new project and picking a database from scratch specifically because you think you’ll need vector search, that calculus hasn’t changed enough to override other factors, pick the database that fits your team’s operational experience and your application’s other needs, then add vector search to it. If you’re already running MySQL and were contemplating standing up Postgres solely for pgvector, that’s the decision this actually affects: you likely don’t need to anymore for a modest workload. And if you’re already deep into a Postgres-based RAG pipeline with tuned HNSW indexes, there’s no case here for switching. The database that’s already working for you at scale is still the right one; this just closes a gap that used to force a choice nobody wanted to make for a feature that didn’t warrant it.