Laravel Vector Search Now Supports MariaDB

Laravel 13 lets developers run native vector-search queries against MariaDB, adding semantic-search capabilities to the Laravel ecosystem without forcing a switch to PostgreSQL.

The new support replaces the framework’s earlier PostgreSQL-only implementation, so the familiar whereVectorSimilarTo method now works directly with a MariaDB connection. If you’re building recommendation engines, document-similarity tools, or any feature that relies on “nearest-neighbor” logic, the change removes a major friction point.

Why the shift matters

Laravel’s query builder previously detected vector-search needs with an instanceof test that only recognized PostgreSQL connections. That approach tied the feature to a single driver and littered the codebase with database-specific conditionals.

The 13 release moves the logic into the grammar layer and adds two driver-specific methods:

  • supportsVectorDistance() – tells Laravel whether the current connection can compute vector distances.
  • compileVectorDistanceExpression() – builds the SQL fragment that performs the calculation.

By assigning these responsibilities to each driver, the framework drops the “type-checking” hack and clears the way for future extensions. Adding support for another database now means implementing a couple of driver methods instead of scattering conditional blocks.

MariaDB gets the native functions, MySQL does not

MariaDB ships with native vector functions. Standard MySQL lacks them unless you use a specialized cloud offering that adds AI extensions.

Laravel deliberately avoids a PHP-side similarity calculation. Computing vectors in PHP would break pagination and slow the app without warning. Throwing an error when the driver cannot handle the operation provides a safer failure mode.

What MySQL users can do now

If your stack runs plain MySQL, you have three realistic paths:

  1. Migrate to MariaDB – a drop-in replacement for most MySQL workloads that gives you native vector support while keeping the same ecosystem.
  2. Add a dedicated search service – run a lightweight PostgreSQL instance alongside MySQL solely for similarity queries.
  3. Live without it – semantic search is optional for many applications; if the benefit does not outweigh the operational cost, staying on MySQL may be the pragmatic choice.

Each option carries trade-offs in operational complexity, latency, and maintenance overhead. The decision hinges on how central vector search is to your product’s value proposition.

Lessons for API design

The Laravel change illustrates a broader design principle: avoid sprinkling database-specific checks throughout core logic. When a feature depends on a particular engine’s capabilities, encapsulate that dependency behind a driver interface. The new grammar-based approach does exactly that, preparing the framework for future extensions without revisiting the core query builder.

Developers building their own packages should take note. If you find instanceof checks for a database type inside your service layer, move that responsibility to the driver or a dedicated adapter. It keeps the public API clean and future-proofs your code.