La ricerca vettoriale di Laravel ora supporta MariaDB
Laravel 13 consente agli sviluppatori di eseguire query di ricerca vettoriale nativa su MariaDB, aggiungendo capacità di ricerca semantica all'ecosistema Laravel senza forzare il passaggio a PostgreSQL.
Il nuovo supporto sostituisce la precedente implementazione del framework limitata a PostgreSQL, quindi il familiare metodo whereVectorSimilarTo ora funziona direttamente con una connessione MariaDB. Se stai costruendo motori di raccomandazione, strumenti di similarità dei documenti o qualsiasi funzionalità che si basi sulla logica del "vicino più prossimo" (nearest-neighbor), questo cambiamento elimina un importante punto di attrito.
Perché questo cambiamento è importante
Il query builder di Laravel precedentemente rilevava le necessità di ricerca vettoriale tramite un test instanceof che riconosceva solo le connessioni PostgreSQL. Tale approccio legava la funzionalità a un singolo driver e disseminava il codice di condizionali specifici per il database.
La versione 13 sposta la logica nel livello della grammatica (grammar layer) e aggiunge due metodi specifici per il driver:
supportsVectorDistance()– indica a Laravel se la connessione corrente può calcolare le distanze vettoriali.compileVectorDistanceExpression()– costruisce il frammento SQL che esegue il calcolo.
Assegnando queste responsabilità a ciascun driver, il framework abbandona il trucco del "controllo del tipo" (type-checking) e apre la strada a future estensioni. Aggiungere il supporto per un altro database significa ora implementare un paio di metodi del driver invece di disperdere blocchi condizionali.
MariaDB riceve le funzioni native, MySQL no
MariaDB include funzioni vettoriali native. Il MySQL standard ne è privo, a meno di non utilizzare un'offerta cloud specializzata che aggiunga estensioni AI.
Laravel evita deliberatamente il calcolo della similarità lato PHP. Calcolare i vettori in PHP interromperebbe la paginazione e rallenterebbe l'app senza preavviso. Generare un errore quando il driver non può gestire l'operazione fornisce una modalità di errore più sicura.
Cosa possono fare ora gli utenti MySQL
Se il tuo stack utilizza MySQL standard, hai tre strade percorribili:
- Migrare a MariaDB – un sostituto immediato (drop-in replacement) per la maggior parte dei carichi di lavoro MySQL che offre il supporto vettoriale nativo mantenendo lo stesso ecosistema.
- Aggiungere un servizio di ricerca dedicato – eseguire un'istanza leggera di PostgreSQL accanto a MySQL esclusivamente per le query di similarità.
- Vivere senza – la ricerca semantica è opzionale per molte applicazioni; se il beneficio non supera il costo operativo, rimanere su MySQL potrebbe essere la scelta pragmatica.
Ogni opzione comporta compromessi in termini di complessità operativa, latenza e costi di manutenzione. La decisione dipende da quanto la ricerca vettoriale sia centrale nella proposta di valore del tuo prodotto.
Lezioni per il design delle API
Il cambiamento di Laravel illustra un principio di progettazione più ampio: evitare di disseminare controlli specifici per il database all'interno della logica principale. Quando una funzionalità dipende dalle capacità di un motore particolare, incapsula tale dipendenza dietro un'interfaccia del driver. Il nuovo approccio basato sulla grammatica fa esattamente questo, preparando il framework per future estensioni senza dover rivisitare il query builder principale.
Gli sviluppatori che creano i propri pacchetti dovrebbero prenderne nota. Se trovi controlli instanceof per un tipo di database all'interno del tuo service layer, sposta quella responsabilità al driver o a un adattatore dedicato. Questo mantiene l'API pubblica pulita e rende il codice pronto per il futuro.