Databricks introduserer fulltekstsøk og vektorsøk i Lakebase Postgres

Databricks den 28. september 2026, presenterte Lakebase Search, en innebygd søkemotor for sin Lakebase Postgres-database levert gjennom to utvidelser: lakebasevektor for tilnærmet nærmeste nabo-søk og lakebasetext for BM25 fulltekstsøk. Begge utvidelser er generelt tilgjengelige på AWS og Azure.

Utvidelsene lar utviklere kjøre semantisk, nøkkelord- og hybrid-søk direkte i Postgres sammen med operasjonelle data. Databricks sa at tradisjonelle OLTP-systemer ikke var bygget for søkekravene til AI-agenter, som krever lav latens, høy nøyaktighet i gjenfinning og ofte utfører massive parallelle søk, og at løsningen hittil har betydd å koble en frittstående søkemotor til den primære databasen med en ETL-pipeline. Selskapet sa at de bygde Lakebase Search sammen med tilbakemeldinger fra hundrevis av betakunder.

Benchmark-resultater og Conexiom-distribusjon

Databricks sa at lakebase_vektor leverer dobbelt så høy gjennomstrømning som det nest beste systemet på VectorDBBench 100M-benchmarken, som bruker LAION-datasettet, og at det er fire ganger billigere enn en sky-Postgres-leverandør som bruker pgvector, før ytterligere besparelser fra autoskalering. Selskapet rapporterte en P99-latens på 71 millisekunder ved 97 % recall, noe som betyr at motoren med suksess hentet de faktiske nærmeste naboene 97 % av gangene, og bemerket at pgvector og DiskANN kun ble testet på en enkelt stor instans.

Databricks rapporterte også et kunderesultat fra Conexiom, som kjører BM25-hybridsøk over mer enn 100 millioner rader med halv så stor beregningsfotavtrykk som deres tidligere pgvector-oppsett. Conexioms infrastrukturkostnader falt tre ganger og gjennomstrømningen økte fem ganger i forhold til pgvector, sa selskapet.

“Lakebase Search gir oss et helt nytt nivå av skalerbarhet sammenlignet med pgvector, og låser opp BM25 i den samme serverløse databasen,” sa Jordan Voves, en AI/ML-arkitekt hos Conexiom. “Vi bruker Lakebase for å koble data til våre agenter i stor skala.”

Pgvector-begrensningene bak designet

Databricks sa at pgvector er den mest installerte utvidelsen i Lakebase Postgres, og beskrev tre gjentakende smertepunkter observert hos kunder som kjører den i stor skala.

Den første er kostnad som skalerer med datavolum i stedet for bruk. pgvector holder sin HNSW-indeks i databasen minne, og fordi HNSW-søk er avhengig av tilfeldig tilgang til graftraversering, faller ytelsen med en faktor på 10 til 50 når indeksen flytter til disk og spørringer blir kjeder av tilfeldige lesinger. En 768-dimensjonal float32‑vektor tar omtrent 3,3 kilobyte med minne når graflenker og Postgres‑overhead er inkludert, så en indeks over 100 millioner rader krever omtrent 330 gigabyte RAM for å forbli resident, fullstendig tildelt uavhengig av om spørringer berører den eller ikke.

Den andre er indeksvedlikehold. Når en bygging flyttet til disk, tok en pgvector-indeks nesten 50 timer å konstruere på en standard sky‑instans, sa Databricks, og skrivinger lider av samme flaskehals fordi innsetting av en vektor krever tilfeldig tilgang til traversering og endring av flere graflag. Siden HNSW ikke har global rebalansering, betyr gjenoppretting av søkekvalitet å kjøre en full REINDEX, en operasjon som låser tabellen og stopper produksjonsskrivinger.

Den tredje er at en enkelt spørring ikke kan parallelliseres. En pgvector‑spørring kjøres av én Postgres‑backend‑prosess, noe som etterlater HNSW‑indeksskanningen uten noen parallellisering. Økt recall krever at flere grafnoder besøkes, noe som legger til tilfeldige minne‑lesinger og avstandssammenligninger, øker latensen og reduserer spørringer per sekund, så skalering av gjennomstrømning betyr å legge til database‑tilkoblinger eller lesereplikas.

Hvordan Lakebase_vector er bygget

Lakebase Postgres skiller lagring fra beregning: permanent data ligger i lavkost‑skyobjektlagring, mens RAM og lokal NVMe fungerer som kortvarige hurtiglagre som holder det aktive arbeidssettet. På toppen av dette grunnlaget kombinerte Databricks to teknikker.

Hierarkisk IVF‑klustering grupperer vektorer i klynger lagret som sammenhengende blokker. En spørring scorer klynge‑sentroidene i minnet, og leser deretter kun de få blokkene som ser lovende ut som store sekvensielle lesinger i stedet for å gjøre mange tilfeldige hopp. Binær kvantisering, ved bruk av RaBitQ‑metoden, komprimerer hver vektor til omtrent én bit per dimensjon, omtrent 32 ganger mindre enn float32, slik at spørringer skanner kompakte koder for å lage en kortliste over kandidater og kun rangere den kortlisten mot full‑presisjonsvektorer.

Fordi designet er tilstandsløst, skalerer det til null, og i hvile betaler brukerne kun for lagring. Databricks rapporterte en målt P90 på 1,13 sekunder for den første spørringen etter scale‑to‑zero på et datasett med 100 millioner vektorer, 768‑dimensjonal, og sa at 100 millioner vektorer kan betjenes på én Lakebase Compute Unit.

Indeksbygging trener klyngesentroidene én gang på et lite tilfeldig utvalg; hver vektor blir deretter tildelt sin nærmeste centroid, kvantisert og skrevet til den aktuelle blokken som en uavhengig operasjon, slik at arbeidet fordeles over så mange kjerner som er tilgjengelige. Databricks sa at LTAP‑arkitekturen deres avlaster indeksbygging fra hoveddatabasen til distribuerte motorer som Spark, og reduserer byggetiden til minutter, og sa at mer kommer på den funksjonaliteten. Fordi predikater anvendes under selve blokk‑skanningen, unngår filtrerte spørringer overhenting av kandidater og holder oppkallingsgraden høy, og en enkelt spørring parallelliseres over CPU‑kjerner.

BM25-tekstsøk og hybride spørringer

Databricks sa at standard Postgres tsvector‑søk mangler kontekst for relevans på tvers av korpuset. lakebase_text gir poeng til termer ved hjelp av global invers dokumentfrekvens, og gir mer vekt til sjeldne, høyintensitets termer og mindre til vanlige fyllord. Den sjekker også øvre poenggrenser mens den traverserer indeksen, og forkaster hele posting‑blokker som ikke kan påvirke top‑K‑resultatet, noe selskapet sa gjør det raskere enn tsvector med GIN‑indekser.

Kombinasjonen av de to utvidelsene gjør det mulig med innebygd hybrid søk i Postgres: en enkelt spørring kan anvende vanlige SQL‑filterpredikater, slå sammen levende operasjonelle tabeller, og kombinere semantisk vektorscorering med BM25‑nøkkelordrelevans. Databricks sa at systemet skalerer fra én rad til én milliard vektorer og fra én spørring per sekund til tusenvis uten manuell omfordeling, og beskriver designet som ment for AI‑agenter hvis arbeidsflyter kan utløse tusenvis av samtidige hente‑forespørsler innen sekunder.

Databricks posisjonerer Lakebase Search for brukere som ønsker operasjonelle og søkedata konsolidert i én enkelt database, mens Databricks AI Search forblir deres administrerte motor for gjenfinning som fungerer umiddelbart. Lakebase Search er generelt tilgjengelig på AWS og Azure; eksisterende Lakebase‑brukere kan aktivere utvidelsene, og nye brukere kan registrere seg for Lakebase.