Databricks brengt full‑text‑ en vectorzoekopdrachten naar Lakebase Postgres

Databricks op 28 september 2026 introduceerde Lakebase Search, een ingebouwde zoekmachine voor zijn Lakebase Postgres-database, geleverd via twee extensies: lakebasevector voor benaderende nearest neighbor-zoekopdrachten en lakebasetekst voor BM25 full‑text‑zoekopdrachten. Beide extensies zijn algemeen beschikbaar op AWS en Azure.

De extensies stellen ontwikkelaars in staat om semantisch, trefwoord- en hybride zoekopdrachten direct binnen Postgres uit te voeren naast operationele gegevens. Databricks zei dat traditionele OLTP‑systemen niet zijn gebouwd voor de zoekbehoeften van AI agents, die lage latentie, hoge nauwkeurigheid en vaak massale parallelle zoekopdrachten vereisen, en dat het oplossen hiervan tot nu toe betekende dat men een zelfstandige zoekmachine aan de primaire database koppelde via een ETL‑pipeline. Het bedrijf zei dat het Lakebase Search heeft gebouwd op basis van feedback van honderden bètagebruikers.

Benchmarkresultaten en de Conexiom-implementatie

Databricks zei dat lakebase_vector twee keer de doorvoer levert van het op één na beste systeem in de VectorDBBench 100M‑benchmark, die de LAION‑dataset gebruikt, en dat het vier keer goedkoper is dan een cloud‑Postgres‑leverancier die pgvector gebruikt, vóór extra besparingen door autoscaling. Het bedrijf rapporteerde een P99‑latentie van 71 milliseconden bij 97 % recall, wat betekent dat de engine de echte dichtstbijzijnde buren 97 % van de tijd succesvol heeft opgehaald, en merkte op dat pgvector en DiskANN alleen op één grote instantie waren getest.

Databricks rapporteerde ook een klantresultaat van Conexiom, dat BM25‑hybride zoekopdrachten uitvoert over meer dan 100 miljoen rijen met de helft van de rekencapaciteit van zijn eerdere pgvector‑configuratie. De infrastructuurkosten van Conexiom daalden tot een derde en de doorvoer steeg tot vijf keer zo hoog ten opzichte van pgvector, zei het bedrijf.

“Lakebase Search geeft ons een geheel nieuw schaalbaarheidsniveau ten opzichte van pgvector, en maakt BM25 mogelijk in dezelfde serverloze database”, zei Jordan Voves, AI/ML‑architect bij Conexiom. “We gebruiken Lakebase om gegevens op schaal met onze agents te verbinden.”

De Pgvector-beperkingen achter het ontwerp

Databricks zei dat pgvector de meest geïnstalleerde extensie is in Lakebase Postgres, en beschreef drie terugkerende pijnpunten die werden waargenomen bij klanten die het op schaal gebruiken.

De eerste is een kostenstructuur die schaalt met het datavolume in plaats van met het gebruik. pgvector houdt zijn HNSW-index in het databasesgeheugen, en omdat HNSW‑zoekopdrachten afhankelijk zijn van willekeurige graftraversals, daalt de prestaties met een factor 10 tot 50 zodra de index naar schijf uitloopt en query’s veranderen in ketens van willekeurige leesbewerkingen. Een 768-dimensionale float32‑vector neemt ongeveer 3,3 kilobyte geheugen in beslag zodra grafkoppelingen en Postgres‑overhead zijn meegerekend, dus een index over 100 miljoen rijen vereist ongeveer 330 gigabyte RAM om resident te blijven, volledig geprovisioneerd ongeacht of query’s deze aanspreken.

Het tweede is indexonderhoud. Wanneer een bouwproces naar schijf uitliep, kostte een pgvector-index bijna 50 uur om te bouwen op een standaard cloud‑instance, zei Databricks, en schrijfbewerkingen lijden onder dezelfde bottleneck omdat het invoegen van een vector willekeurige traversals en wijziging van meerdere graflagen vereist. Aangezien HNSW geen globale herbalancering heeft, betekent het herstellen van zoekkwaliteit het uitvoeren van een volledige REINDEX, een operatie die de tabel vergrendelt en productie‑schrijfbewerkingen stopt.

Het derde is dat een enkele query niet kan worden geparalleliseerd. Een pgvector‑query wordt uitgevoerd door één Postgres‑backend‑proces, waardoor de HNSW-indexscan geen parallelisatie krijgt. Het verhogen van recall vereist het bezoeken van meer grafknooppunten, wat willekeurige geheugentoegang en afstandsvergelijkingen toevoegt, de latentie verhoogt en het aantal queries per seconde verlaagt, dus het opschalen van de doorvoer betekent het toevoegen van database‑verbindingen of read‑replicaties.

Hoe Lakebase_vector wordt gebouwd

Lakebase Postgres scheidt opslag van compute: permanente gegevens staan in goedkope cloud‑objectopslag, terwijl RAM en lokale NVMe dienen als kort‑levende caches die de actieve werkset bevatten. Op basis van die fundering combineerde Databricks twee technieken.

Hiërarchische IVF‑clustering groepeert vectoren in clusters die worden opgeslagen als aaneengesloten blokken. Een query beoordeelt de clustercentroiden in het geheugen en leest vervolgens alleen de weinige blokken die veelbelovend lijken als grote sequentiële reads in plaats van vele willekeurige sprongen. Binaire kwantisatie, met de RaBitQ‑methode, comprimeert elke vector tot ongeveer één bit per dimensie, ruwweg 32 keer kleiner dan float32, zodat query’s compacte codes scannen om kandidaten te shortlistten en alleen die shortlist opnieuw rangschikken tegen vectoren met volledige precisie.

Omdat het ontwerp stateless is, schaalt het naar nul, en in rust betalen gebruikers alleen voor opslag. Databricks meldde een gemeten P90 van 1,13 seconden voor de eerste query na schaal‑naar‑nul op een dataset van 100 miljoen vectoren, 768 dimensies, en zei dat 100 miljoen vectoren kunnen worden bediend op één Lakebase Compute Unit.

Indexconstructie traint de clustercentroiden één keer op een kleine willekeurige steekproef; elke vector wordt vervolgens toegewezen aan zijn dichtstbijzijnde centroid, gekwantiseerd en geschreven naar het juiste blok als een onafhankelijke bewerking, zodat het werk zich verspreidt over zoveel cores er ook beschikbaar zijn. Databricks zei dat zijn LTAP-architectuur indexbouwt van de primaire database ontlast naar gedistribueerde engines zoals Spark, waardoor bouwtijden tot minuten worden teruggebracht, en gaf aan dat er meer op die functionaliteit aankomt. Omdat predicaten tijdens de blokscan zelf worden toegepast, vermijden gefilterde queries het overmatig ophalen van kandidaten en blijft de recall hoog, en een enkele query wordt parallel uitgevoerd over CPU-cores.

BM25-tekstzoekopdracht en hybride queries

Databricks zei dat de standaard Postgres‑tsvector‑zoekopdracht geen corpus‑brede relevantiecontext biedt. lakebase_text scoort termen met behulp van globale inverse documentfrequentie, waardoor zeldzame, hoog‑intentionele termen zwaarder wegen en veelvoorkomende stopwoorden minder. Het controleert ook de bovengrens van de score terwijl het de index doorloopt, en discardeert volledige posting‑blokken die de top‑K‑uitkomst niet kunnen beïnvloeden, wat het bedrijf aangeeft sneller te zijn dan tsvector met GIN‑indexen.

Het combineren van de twee extensies maakt native hybride zoekopdrachten binnen Postgres mogelijk: een enkele query kan gewone SQL‑filterpredicaten toepassen, live operationele tabellen joinen en semantische vectorscoring combineren met BM25‑keyword‑relevantie. Databricks meldde dat het systeem schaalt van één rij tot één miljard vectors en van één query per seconde tot duizenden zonder handmatige herprovisionering, en beschrijft het ontwerp als bedoeld voor AI‑agents die binnen seconden duizenden gelijktijdige retrieval‑verzoeken kunnen triggeren.

Databricks positioneert Lakebase Search voor gebruikers die operationele en zoekdata willen consolideren in één enkele database, terwijl Databricks AI Search zijn beheerde engine blijft voor retrieval die direct werkt. Lakebase Search is algemeen beschikbaar op AWS en Azure; bestaande Lakebase‑gebruikers kunnen de extensies inschakelen, en nieuwe gebruikers kunnen zich aanmelden voor Lakebase.