La recherche vectorielle de Laravel prend désormais en charge MariaDB

Laravel 13 permet aux développeurs d'exécuter des requêtes de recherche vectorielle natives sur MariaDB, ajoutant ainsi des capacités de recherche sémantique à l'écosystème Laravel sans imposer de passage à PostgreSQL.

Ce nouveau support remplace l'ancienne implémentation du framework, limitée à PostgreSQL, de sorte que la méthode familière whereVectorSimilarTo fonctionne désormais directement avec une connexion MariaDB. Si vous développez des moteurs de recommandation, des outils de similarité de documents ou toute fonctionnalité reposant sur la logique du « plus proche voisin » (nearest-neighbor), ce changement élimine un point de friction majeur.

Pourquoi ce changement est important

Auparavant, le query builder de Laravel détectait les besoins de recherche vectorielle via un test instanceof qui ne reconnaissait que les connexions PostgreSQL. Cette approche liait la fonctionnalité à un seul pilote et parsemait la base de code de conditionnels spécifiques à la base de données.

La version 13 déplace la logique dans la couche de grammaire (grammar layer) et ajoute deux méthodes spécifiques au pilote :

  • supportsVectorDistance() – indique à Laravel si la connexion actuelle peut calculer des distances vectorielles.
  • compileVectorDistanceExpression() – construit le fragment SQL qui effectue le calcul.

En confiant ces responsabilités à chaque pilote, le framework abandonne le « hack » de vérification de type et ouvre la voie à de futures extensions. Ajouter le support d'une autre base de données signifie désormais implémenter quelques méthodes de pilote plutôt que de disperser des blocs conditionnels.

MariaDB bénéficie des fonctions natives, contrairement à MySQL

MariaDB est livré avec des fonctions vectorielles natives. Le MySQL standard en est dépourvu, à moins d'utiliser une offre cloud spécialisée qui ajoute des extensions d'IA.

Laravel évite délibérément de calculer la similarité côté PHP. Calculer des vecteurs en PHP briserait la pagination et ralentirait l'application sans prévenir. Renvoyer une erreur lorsque le pilote ne peut pas gérer l'opération offre un mode de défaillance plus sûr.

Ce que les utilisateurs de MySQL peuvent faire dès maintenant

Si votre stack utilise du MySQL classique, trois options réalistes s'offrent à vous :

  1. Migrer vers MariaDB – un remplacement direct pour la plupart des charges de travail MySQL qui vous offre un support vectoriel natif tout en conservant le même écosystème.
  2. Ajouter un service de recherche dédié – faire tourner une instance PostgreSQL légère aux côtés de MySQL uniquement pour les requêtes de similarité.
  3. S'en passer – la recherche sémantique est optionnelle pour de nombreuses applications ; si le bénéfice ne l'emporte pas sur le coût opérationnel, rester sur MySQL peut être le choix pragmatique.

Chaque option comporte des compromis en termes de complexité opérationnelle, de latence et de maintenance. La décision dépend de la place centrale qu'occupe la recherche vectorielle dans la proposition de valeur de votre produit.

Leçons pour la conception d'API

Le changement apporté par Laravel illustre un principe de conception plus large : éviter de parsemer des vérifications spécifiques à la base de données dans la logique métier principale. Lorsqu'une fonctionnalité dépend des capacités d'un moteur particulier, encapsulez cette dépendance derrière une interface de pilote. La nouvelle approche basée sur la grammaire fait précisément cela, préparant le framework à de futures extensions sans avoir à modifier le query builder central.

Les développeurs qui créent leurs propres packages devraient en prendre note. Si vous trouvez des vérifications instanceof pour un type de base de données au sein de votre couche de service, transférez cette responsabilité au pilote ou à un adaptateur dédié. Cela permet de garder l'API publique propre et de pérenniser votre code.