{"slug": "laravel-s-native-vector-search-now-speaks-mariadb-plain-mysql-is-still-left-out", "title": "Laravel's Native Vector Search Now Speaks MariaDB — Plain MySQL Is Still Left Out", "summary": "Laravel's native vector search, previously limited to PostgreSQL with pgvector, now supports MariaDB through a refactoring that moves vector distance logic from the connection class to the grammar. The change, merged in PR #61250, adds methods like whereVectorSimilarTo for MariaDB, but plain MySQL remains unsupported due to lack of native vector functions outside HeatWave.", "body_md": "*Originally published on [my blog](https://gabrielepieretti.dev/blog-en/laravel-vector-search-mariadb-mysql/).*\n\nOn August 20, PR [#61250](https://github.com/laravel/framework/pull/61250) was merged into Laravel's 13.x branch, bringing the query builder's native vector search — `whereVectorSimilarTo` and friends — to MariaDB. Until then it was PostgreSQL-with-pgvector only. I care about this for two reasons: I spent eleven years building business software on Laravel and MySQL, and the *way* the PR is written is a small lesson in driver design worth more than the feature itself. There's a third, less cheerful reason too: if your projects run on plain MySQL, as most of my older ones do, you're still left out — and not because anyone was lazy.\n\nLaravel 13 ships four methods for working with embeddings straight from the query builder: `whereVectorSimilarTo`, `whereVectorDistanceLessThan`, `orderByVectorDistance` and `selectVectorDistance`. The idea is the usual one: you write the query in fluent PHP, the framework compiles it into the right SQL for your database.\n\nExcept that until mid-August, \"your database\" meant exactly one. Inside `Query\\Builder` sat a hand-written `instanceof PostgresConnection` check, and the distance SQL itself — pgvector's `<=>` operator — was inlined right there in the builder rather than living in the driver's grammar. It worked, but it was the classic kind of debt you don't notice until somebody tries to add a second database.\n\nThe refactoring is small and clean. The question \"does this driver know how to compute vector distances?\" moves from the connection class to the grammar, via a pair of methods — `supportsVectorDistance()` and `compileVectorDistanceExpression($column)` — that each driver can override. It's the same pattern Laravel has used for years for `compileRandom()` or savepoint support: a base implementation on the grammar, per-driver overrides.\n\nWith the question in the right place, adding MariaDB becomes almost trivial: its grammar compiles the distance into `vec_distance_cosine()`, the native function MariaDB has shipped since 11.7 Community (11.4.5-3 on Enterprise), alongside a real `VECTOR` column type. The schema side — `typeVector()` and vector indexes — already existed from an earlier PR; only the query side was missing. Five days later a [follow-up, #61337](https://github.com/laravel/framework/pull/61337), landed with an SQL fix and an `AsVector` Eloquent cast.\n\nThis is what I take home as someone who designs APIs, even before wearing the user hat: the moment you catch yourself writing `instanceof SomethingConnection` outside the driver, the feature is living in the wrong place. You'll ship the first database either way; it's the second one that hands you the bill.\n\nAnd my MySQL-based systems? Nothing. `whereVectorSimilarTo()` on a standard MySQL connection still throws a `RuntimeException` — the PR merely updated the message to mention MariaDB. The reason isn't Laravel: MySQL Community and Enterprise, in the standard binaries, have no native vector distance function. `DISTANCE()` and `VECTOR_DISTANCE()` exist only on HeatWave (so, on OCI) and on MySQL AI. If you're not on Oracle's cloud, there is no SQL to compile.\n\nJust as interesting is what the PR *refused* to do: a PHP-side fallback that fetches rows and computes similarity in memory. It would have been convenient to announce and disastrous to use — it would silently break the semantics of `limit()` and pagination, and change the performance contract of the query without telling anyone. Letting the exception fly is the honest choice: a clear error today beats a mysterious slowdown in production six months from now.\n\nFor an existing MySQL application that wants semantic search — matching \"frizz treatment\" when the user types \"puffy hair\", say — I see three options today, in my order of preference:\n\nFor new projects the question settles itself: when I picked Postgres for [Miraviso](https://miraviso.it), vectors weren't even on my radar, but this is exactly the kind of dividend a conservative database choice keeps paying. And the flip side is worth stating too: none of these queries help you with data you encrypt client-side. Miraviso's sensitive notes — the ones the server [stores as envelopes it cannot open](https://gabrielepieretti.dev/blog-en/sealed-envelopes-sensitive-data-saas/) — can never end up in a server-side vector index: you can't embed text you can't read. It's a useful reminder that semantic search is a data processing operation like any other, and deserves the same care in deciding.\n\nThe refactoring opens a wider door than the single feature: now that distance compilation lives in the grammar, adding a driver or a different metric is a small PR, not open-heart surgery on the builder. There's already a proposal to make the distance metric configurable (cosine, euclidean) instead of assumed. That direction looks right to me: a query builder that treats vectors as a driver capability, declared by the grammar, exactly like the rest of its SQL. Meanwhile, those of us on plain MySQL at least get an error message that tells the truth.", "url": "https://wpnews.pro/news/laravel-s-native-vector-search-now-speaks-mariadb-plain-mysql-is-still-left-out", "canonical_source": "https://dev.to/gabbrowick/laravels-native-vector-search-now-speaks-mariadb-plain-mysql-is-still-left-out-i2p", "published_at": "2026-09-08 16:13:32+00:00", "updated_at": "2026-09-08 16:25:29.779853+00:00", "lang": "en", "topics": ["developer-tools", "machine-learning"], "entities": ["Laravel", "MariaDB", "MySQL", "PostgreSQL", "pgvector", "HeatWave", "Oracle", "Miraviso"], "alternates": {"html": "https://wpnews.pro/news/laravel-s-native-vector-search-now-speaks-mariadb-plain-mysql-is-still-left-out", "markdown": "https://wpnews.pro/news/laravel-s-native-vector-search-now-speaks-mariadb-plain-mysql-is-still-left-out.md", "text": "https://wpnews.pro/news/laravel-s-native-vector-search-now-speaks-mariadb-plain-mysql-is-still-left-out.txt", "jsonld": "https://wpnews.pro/news/laravel-s-native-vector-search-now-speaks-mariadb-plain-mysql-is-still-left-out.jsonld"}}