Databricks brengt full‑text- en vectorzoekopdrachten naar Lakebase Postgres

Databricks heeft op 28 september 2026 Lakebase Search geïntroduceerd, een ingebouwde zoekmachine voor zijn Lakebase Postgres-database die wordt geleverd via twee extensies: lakebase_vector voor benaderende nearest neighbor-zoekopdrachten en lakebase_text voor BM25 full‑text-zoekopdrachten. Beide extensies zijn algemeen beschikbaar op AWS en Azure.

De extensies stellen ontwikkelaars in staat om semantische, trefwoord‑ en hybride zoekopdrachten rechtstreeks binnen Postgres uit te voeren naast operationele gegevens. Databricks zei dat traditionele OLTP‑systemen niet zijn ontworpen voor de zoekvereisten van AI‑agenten, 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 meldde dat het Lakebase Search heeft gebouwd op basis van feedback van honderden bètaklanten.

Benchmarkresultaten en de Conexiom-implementatie

Databricks zei dat lakebase_vector twee keer de doorvoersnelheid van het op één na beste systeem levert op de VectorDBBench 100M‑benchmark, die de LAION‑dataset gebruikt, en vier keer goedkoper is dan een cloud‑Postgres‑leverancier die pgvector gebruikt, vóór extra besparingen door autoscaling. Het bedrijf meldde 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 meldde 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. Volgens het bedrijf daalden de infrastructuurkosten van Conexiom tot een derde en steeg de doorvoersnelheid tot het vijfvoud ten opzichte van pgvector.

“Lakebase Search geeft ons een geheel nieuw schaalbaarheidsniveau ten opzichte van pgvector en maakt BM25 beschikbaar in dezelfde serverless database,” zei Jordan Voves, een AI/ML‑architect bij Conexiom. “We gebruiken Lakebase om gegevens op schaal met onze agenten 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 bij klanten werden waargenomen die het op schaal gebruiken.

Het eerste is kosten die schalen met het datavolume in plaats van met gebruik. pgvector houdt zijn HNSW‑index in het geheugen van de database, en omdat HNSW‑zoekopdrachten afhankelijk zijn van willekeurige graaftraversals, dalen de prestaties met een factor 10 tot 50 zodra de index naar schijf uitloopt en queries veranderen in ketens van willekeurige reads. Een 768‑dimensionale float32‑vector neemt ongeveer 3,3 kilobyte geheugen in beslag zodra graafkoppelingen 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 queries deze aanspreken.

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

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

Hoe Lakebase_vector is gebouwd

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

Hiërarchische IVF‑clustering groepeert vectoren in clusters die worden opgeslagen als aaneengesloten blokken. Een query beoordeelt de clustercentroïden in het geheugen en leest vervolgens alleen de enkele 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 queries compacte codes scannen om kandidaten te shortlistten en alleen die shortlist opnieuw rangschikken tegen full‑precision vectoren.

Omdat het ontwerp stateless is, schaalt het naar nul en betalen gebruikers in rust alleen voor opslag. Databricks rapporteerde een gemeten P90 van 1,13 seconden voor de eerste query na schaal‑naar‑nul op een dataset van 100 miljoen vectoren van 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 indexbouw verplaatst van de primaire database naar gedistribueerde engines zoals Spark, waardoor de bouwtijd tot enkele minuten wordt teruggebracht, en gaf aan dat er meer op die mogelijkheid volgt. Omdat predicaten worden toegepast tijdens de blokscan zelf, vermijden gefilterde query’s het overmatig ophalen van kandidaten en behouden ze een hoge recall, en paralleliseert een enkele query over CPU-cores.

BM25-tekstzoekopdrachten en hybride query’s

Databricks zei dat de standaard Postgres tsvector-zoekopdracht geen corpusbrede relevantiecontext heeft. lakebase_text kent scores toe aan termen met behulp van de globale inverse documentfrequentie, waardoor zeldzame, hoogintentionele termen meer gewicht krijgen en veelvoorkomende stopwoorden minder. Het controleert ook de bovengrenzen van scores terwijl het de index doorloopt, en verwijdert volledige postingblokken die de top‑K-uitkomst niet kunnen beïnvloeden, wat het bedrijf zei dat het sneller maakt 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 vectorscores combineren met BM25‑keywordrelevantie. Databricks zei 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‑agenten waarvan de workflows duizenden gelijktijdige opvrage‑verzoeken binnen enkele seconden kunnen activeren.

Databricks positioneert Lakebase Search voor gebruikers die operationele en zoekdata in één enkele database willen consolideren, terwijl Databricks AI Search zijn beheerde engine voor retrieval blijft 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.