Databricks porta la ricerca full-text e vettoriale a Lakebase Postgres

Databricks il 28 settembre 2026, ha introdotto Lakebase Search, un motore di ricerca integrato per il suo database Lakebase Postgres fornito tramite due estensioni: lakebasevector per la ricerca di vicini più prossimi approssimativa e lakebasetext per la ricerca full-text BM25. Entrambe le estensioni sono generalmente disponibili su AWS e Azure.

Le estensioni consentono agli sviluppatori di eseguire ricerche semantiche, basate su parole chiave e ibride direttamente all’interno di Postgres insieme ai dati operativi. Databricks ha dichiarato che i tradizionali sistemi OLTP non sono stati progettati per le esigenze di ricerca degli agenti IA, i quali richiedono recupero a bassa latenza e alta precisione e spesso eseguono ricerche massivamente parallele, e che risolvere questo problema fino a ora significava collegare un motore di ricerca autonomo al database primario tramite una pipeline ETL. L’azienda ha affermato di aver costruito Lakebase Search accanto al feedback di centinaia di clienti beta.

Risultati del benchmark e implementazione Conexiom

Databricks ha affermato che lakebase_vector offre il doppio del throughput rispetto al sistema successivo migliore nel benchmark VectorDBBench 100M, che utilizza il dataset LAION, ed è quattro volte più economico rispetto a un fornitore cloud di Postgres che utilizza pgvector, prima dei risparmi aggiuntivi derivanti dall’autoscaling. L’azienda ha riportato una latenza P99 di 71 millisecondi al 97% di recall, il che significa che il motore ha recuperato correttamente i veri vicini più prossimi il 97% delle volte, e ha osservato che pgvector e DiskANN sono stati testati solo su una singola grande istanza.

Databricks ha inoltre riportato un risultato cliente da Conexiom, che esegue ricerche ibride BM25 su più di 100 milioni di righe con metà dell’impronta computazionale della sua precedente configurazione pgvector. I costi infrastrutturali di Conexiom sono diminuiti di tre volte e il throughput è aumentato di cinque volte rispetto a pgvector, ha dichiarato l’azienda.

“Lakebase Search ci offre un nuovo livello di scalabilità rispetto a pgvector e sblocca BM25 nello stesso database serverless,” ha dichiarato Jordan Voves, architetto AI/ML presso Conexiom. “Utilizziamo Lakebase per collegare i dati ai nostri agenti su larga scala.”

I limiti di Pgvector dietro il design

Databricks ha affermato che pgvector è l’estensione più installata in Lakebase Postgres e ha descritto tre problemi ricorrenti osservati dai clienti che lo utilizzano su larga scala.

Il primo è il costo, che scala con il volume dei dati piuttosto che con l’uso. pgvector conserva il suo indice HNSW nella memoria del database e, poiché la ricerca HNSW si basa su una traversata casuale del grafo, le prestazioni diminuiscono di un fattore tra 10 e 50 non appena l’indice si riversa su disco e le query diventano catene di letture casuali. Un vettore float32 a 768 dimensioni occupa circa 3,3 kilobyte di memoria includendo i collegamenti del grafo e l’overhead di Postgres, quindi un indice su 100 milioni di righe richiede circa 330 gigabyte di RAM per rimanere residente, provisionato interamente indipendentemente dal fatto che le query lo tocchino o meno.

Il secondo è la manutenzione dell’indice. Quando una costruzione si è riversata su disco, un indice pgvector ha impiegato quasi 50 ore per essere costruito su un’istanza cloud standard, ha affermato Databricks, e le scritture subiscono lo stesso collo di bottiglia perché l’inserimento di un vettore richiede una traversata casuale e la modifica di diversi livelli del grafo. Poiché HNSW non prevede un riequilibrio globale, ripristinare la qualità della ricerca significa eseguire un REINDEX completo, un’operazione che blocca la tabella e interrompe le scritture di produzione.

Il terzo è che una singola query non può essere parallelizzata. Una query pgvector viene eseguita da un unico processo backend di Postgres, lasciando la scansione dell’indice HNSW senza alcuna parallelizzazione. Incrementare il recall richiede di visitare più nodi del grafo, il che aggiunge letture di memoria casuali e confronti di distanza, aumentando la latenza e riducendo le query al secondo, quindi scalare il throughput significa aggiungere connessioni al database o repliche di lettura.

Come è costruito Lakebase_vector

Lakebase Postgres separa lo storage dal calcolo: i dati permanenti risiedono in uno storage di oggetti cloud a basso costo, mentre RAM e NVMe locale fungono da cache a breve termine che mantengono il set di lavoro attivo. Su questa base, Databricks ha combinato due tecniche.

Il clustering gerarchico IVF raggruppa i vettori in cluster memorizzati come blocchi contigui. Una query valuta i centroidi dei cluster in memoria, quindi legge solo i pochi blocchi che sembrano promettenti come grandi letture sequenziali invece di effettuare molti salti casuali. La quantizzazione binaria, usando il metodo RaBitQ, comprime ogni vettore a circa un bit per dimensione, circa 32 volte più piccolo del float32, così le query scansionano codici compatti per creare una lista ristretta di candidati e riordinarla solo contro i vettori a piena precisione.

Poiché il design è senza stato, scala a zero e, a riposo, gli utenti pagano solo per lo storage. Databricks ha segnalato un P90 misurato di 1,13 secondi per la prima query dopo lo scaling a zero su un dataset di 100 milioni di vettori a 768 dimensioni, e ha affermato che 100 milioni di vettori possono essere serviti su un’unica Lakebase Compute Unit.

La costruzione dell’indice addestra i centroidi del cluster una sola volta su un piccolo campione casuale; ogni vettore viene quindi assegnato al suo centroide più vicino, quantizzato e scritto nel blocco appropriato come operazione indipendente, così il lavoro si distribuisce su tutti i core disponibili. Databricks ha dichiarato che la sua architettura LTAP sposta la creazione degli indici dal database principale verso motori distribuiti come Spark, riducendo i tempi di costruzione a minuti, e ha aggiunto che arriveranno ulteriori miglioramenti a questa funzionalità. Poiché i predicati vengono applicati durante la scansione del blocco stesso, le query filtrate evitano il recupero eccessivo di candidati e mantengono un alto richiamo, e una singola query viene parallelizzata sui core CPU.

Ricerca Testuale BM25 e Query Ibride

Databricks ha affermato che la ricerca standard tsvector di Postgres manca di un contesto di rilevanza a livello di corpus. lakebase_text assegna punteggi ai termini utilizzando la frequenza inversa globale dei documenti, conferendo maggiore peso a termini rari e ad alta intenzione e meno a parole comuni di riempimento. Inoltre verifica i limiti superiori del punteggio mentre attraversa l’indice, scartando interi blocchi di posting che non possono influenzare il risultato top‑K, cosa che, secondo l’azienda, lo rende più veloce rispetto a tsvector con indici GIN.

La combinazione delle due estensioni consente una ricerca ibrida nativa all’interno di Postgres: una singola query può applicare i normali predicati di filtro SQL, unire tabelle operative in tempo reale e fondere il punteggio dei vettori semantici con la rilevanza delle parole chiave BM25. Databricks ha dichiarato che il sistema scala da una riga a un miliardo di vettori e da una query al secondo a migliaia senza dover riprovisionare manualmente, descrivendo il design come destinato ad agenti IA i cui flussi di lavoro possono generare migliaia di richieste di recupero concorrenti in pochi secondi.

Databricks posiziona Lakebase Search per gli utenti che desiderano dati operativi e di ricerca consolidati in un unico database, mentre Databricks AI Search rimane il suo motore gestito per il recupero pronto all’uso. Lakebase Search è generalmente disponibile su AWS e Azure; gli utenti Lakebase esistenti possono abilitare le estensioni e i nuovi utenti possono iscriversi a Lakebase.