Databricks introducerer fuldtekst- og vektorsøgning til Lakebase Postgres

Databricks den 28. september 2026, introducerede Lakebase Search, en indbygget søgemaskine til sin Lakebase Postgres-database leveret gennem to udvidelser: lakebasevektor for tilnærmet nærmeste nabo-søgning og lakebasetext for BM25 fuldtekst-søgning. Begge udvidelser er generelt tilgængelige på AWS og Azure.

Udvidelserne giver udviklere mulighed for at køre semantisk, nøgleords- og hybrid-søgning direkte i Postgres sammen med operationelle data. Databricks sagde, at traditionelle OLTP-systemer ikke var bygget til søgekravene fra AI‑agenter, som kræver lav latenstid, høj præcisions‑genfinding og ofte udfører massive parallelle søgninger, og at løsningen hidtil har betydet at tilknytte en selvstændig søgemaskine til den primære database med en ETL‑pipeline. Virksomheden sagde, at den byggede Lakebase Search sammen med feedback fra flere hundrede beta‑kunder.

Benchmarkresultater og Conexiom‑implementeringen

Databricks sagde, at lakebase_vektor leverer dobbelt så høj gennemstrømning som det næstbedste system på VectorDBBench 100M‑benchmarken, som bruger LAION‑datasættet, og at den er fire gange billigere end en cloud‑Postgres‑leverandør, der bruger pgvector, før yderligere besparelser fra autoskalering. Virksomheden rapporterede en P99‑latens på 71 millisekunder ved 97 % recall, hvilket betyder, at motoren med succes hentede de sande nærmeste naboer 97 % af tiden, og bemærkede, at pgvector og DiskANN kun blev testet på en enkelt stor instans.

Databricks rapporterede også et kunderesultat fra Conexiom, som kører BM25‑hybrid‑søgning over mere end 100 millioner rækker med halvdelen af beregningsfodaftrykket i forhold til deres tidligere pgvector‑opsætning. Conexioms infrastrukturomkostninger faldt trefold, og gennemstrømningen steg femfold i forhold til pgvector, sagde virksomheden.

“Lakebase Search giver os et helt nyt niveau af skalerbarhed i forhold til pgvector og låser op for BM25 i den samme serverløse database,” sagde Jordan Voves, AI/ML‑arkitekt hos Conexiom. “Vi bruger Lakebase til at forbinde data med vores agenter i stor skala.”

Pgvector‑begrænsningerne bag designet

Databricks sagde, at pgvector er den mest installerede udvidelse i Lakebase Postgres, og den beskrev tre tilbagevendende smertepunkter observeret hos kunder, der kører den i stor skala.

Den første er omkostninger, der skalerer med datavolumen snarere end med brug. pgvector holder sin HNSW‑indeks i database‑hukommelsen, og fordi HNSW‑søgning er afhængig af tilfældig graf‑traversering, falder ydeevnen med en faktor på 10 til 50, så snart indekset flyder over på disk, og forespørgsler bliver til kæder af tilfældige læsninger. En 768‑dimensional float32‑vektor optager omkring 3,3 kilobyte hukommelse, når graf‑links og Postgres‑overhead er medregnet, så et indeks over 100 millioner rækker kræver cirka 330 gigabyte RAM for at forblive resident, fuldt provisioneret uanset om forespørgsler berører det eller ej.

Den anden er indeksvedligeholdelse. Da en opbygning løb over på disk, tog et pgvector‑indeks næsten 50 timer at konstruere på en standard cloud‑instans, sagde Databricks, og skrivninger lider under den samme flaskehals, fordi indsættelse af en vektor kræver tilfældig adgangstraversering og ændring af flere graf‑lag. Da HNSW ikke har nogen global rebalancering, betyder genoprettelse af søgekvalitet, at man skal køre en fuld REINDEX, en operation der låser tabellen og stopper produktions‑skrivninger.

Den tredje er, at en enkelt forespørgsel ikke kan paralleliseres. En pgvector‑forespørgsel udføres af én Postgres‑backend‑proces, så HNSW‑indeksskanningen forbliver uden parallelisering. For at øge recall kræves besøg på flere graf‑noder, hvilket tilføjer tilfældige hukommelses‑læsninger og afstandssammenligninger, øger latensen og reducerer forespørgsler pr. sekund, så skalering af gennemstrømning betyder at tilføje databaseforbindelser eller læse‑replikationer.

Hvordan Lakebase_vector er bygget

Lakebase Postgres adskiller lager fra beregning: permanent data ligger i billig cloud‑objektlager, mens RAM og lokal NVMe fungerer som kortvarige cache‑lag, der holder det aktive arbejds‑sæt. På dette grundlag kombinerede Databricks to teknikker.

Hierarkisk IVF‑klustering grupperer vektorer i klynger, der gemmes som sammenhængende blokke. En forespørgsel scorer klynge‑centroider i hukommelsen og læser derefter kun de få blokke, der ser lovende ud, som store sekventielle læsninger i stedet for mange tilfældige hop. Binær kvantisering, ved brug af RaBitQ‑metoden, komprimerer hver vektor til omkring én bit per dimension, cirka 32 gange mindre end float32, så forespørgsler scanner kompakte koder for at udvælge kandidater og kun omrangere den udvalgte liste mod fuldpresisions‑vektorer.

Da designet er tilstandsløst, skalerer det til nul, og i hvile betaler brugerne kun for lager. Databricks rapporterede en målt P90 på 1,13 sekunder for den første forespørgsel efter scale‑to‑zero på et datasæt med 100 millioner vektorer, 768 dimensioner, og sagde, at 100 millioner vektorer kan betjenes på én Lakebase Compute Unit.

Indeksopbygning træner klyngecentroider én gang på en lille tilfældig prøve; hver vektor tildeles derefter sin nærmeste centroid, kvantiseres og skrives til den relevante blok som en uafhængig operation, så arbejdet fordeles på så mange kerner, der er tilgængelige. Databricks sagde, at deres LTAP-arkitektur flytter indeksbygning fra den primære database til distribuerede motorer såsom Spark, hvilket reducerer byggetiden til minutter, og de meddelte, at der kommer mere på den funktionalitet. Da prædikater anvendes under selve blokscanningen, undgår filtrerede forespørgsler over‑hentning af kandidater og bevarer høj recall, og en enkelt forespørgsel parallelliseres på tværs af CPU‑kerner.

BM25-tekstssøgning og hybride forespørgsler

Databricks sagde, at standard Postgres‑tsvector‑søgning mangler korpus‑omfattende relevanskontekst. lakebase_text scorer termer ved hjælp af global invers dokumentfrekvens, hvilket giver mere vægt til sjældne, høj‑intention termer og mindre til almindelige fyldord. Den tjekker også øvre grænser for score, mens den traverserer indekset, og forkaster hele posting‑blokke, der ikke kan påvirke top‑K‑resultatet, hvilket ifølge virksomheden gør den hurtigere end tsvector med GIN‑indekser.

Kombinationen af de to udvidelser muliggør indbygget hybrid søgning i Postgres: en enkelt forespørgsel kan anvende almindelige SQL‑filter‑prædikater, join live operationelle tabeller og sammenlægge semantisk vektorscorering med BM25‑nøgleordsrelevans. Databricks sagde, at systemet skalerer fra én række til én milliard vektorer og fra én forespørgsel pr. sekund til tusinder uden manuel gen‑provisionering, og beskriver designet som beregnet til AI‑agenter, hvis arbejdsgange kan udløse tusinder af samtidige hentningsanmodninger inden for sekunder.

Databricks positionerer Lakebase Search for brugere, der ønsker operationelle og søgedata konsolideret i en enkelt database, mens Databricks AI Search forbliver deres administrerede motor til hentning, der fungerer ud af boksen. Lakebase Search er generelt tilgængelig på AWS og Azure; eksisterende Lakebase‑brugere kan aktivere udvidelserne, og nye brugere kan tilmelde sig Lakebase.