Databricks inför fulltextsökning och vektorsökning i Lakebase Postgres

Databricks den 28 september 2026, introducerade Lakebase Search, en inbyggd sökmotor för dess Lakebase Postgres-databas som levereras via två tillägg: lakebasevektor för approximerad närmaste granne-sökning och lakebasetext för BM25 fulltextssökning. Båda tilläggen finns generellt tillgängliga på AWS och Azure.

Tilläggen låter utvecklare köra semantisk, nyckelords- och hybrid­sökning direkt i Postgres tillsammans med operativ data. Databricks sade att traditionella OLTP‑system inte byggdes för de sökbehov som AI‑agenter har, vilka kräver låg latens, hög precision i hämtning och ofta utför massiva parallella sökningar, och att lösningen hittills innebar att man kopplade en fristående sökmotor till den primära databasen med en ETL‑pipeline. Företaget sade att de byggde Lakebase Search tillsammans med feedback från hundratals betakunder.

Benchmarkresultat och Conexiom‑distributionen

Databricks sade att lakebase_vektor levererar dubbelt så hög genomströmning som näst bästa system på VectorDBBench 100M‑benchmarken, som använder LAION‑datasetet, och att den är fyra gånger billigare än en molnbaserad Postgres‑leverantör som använder pgvector, före ytterligare besparingar från autoskalning. Företaget rapporterade en P99‑latens på 71 millisekunder vid 97 % recall, vilket betyder att motorn framgångsrikt hämtade de verkliga närmaste grannarna 97 % av gångerna, och noterade att pgvector och DiskANN endast testades på en enda stor instans.

Databricks rapporterade också ett kundresultat från Conexiom, som kör BM25‑hybridsökning över mer än 100 miljoner rader med hälften av beräkningsavtrycket jämfört med deras tidigare pgvector‑uppsättning. Conexioms infrastrukturkostnader föll trefalt och genomströmningen steg femfalt i förhållande till pgvector, sade företaget.

”Lakebase Search ger oss en helt ny nivå av skalbarhet jämfört med pgvector, och låser upp BM25 i samma serverlösa databas,” sade Jordan Voves, en AI/ML‑arkitekt på Conexiom. ”Vi använder Lakebase för att koppla data till våra agenter i stor skala.”

Pgvector‑begränsningarna bakom designen

Databricks sade att pgvector är det mest installerade tillägget i Lakebase Postgres, och beskrev tre återkommande smärtpunkter som observerats hos kunder som kör det i stor skala.

Den första är kostnad som skalar med datavolym snarare än användning. pgvector behåller sitt HNSW‑index i databasens minne, och eftersom HNSW‑sökning förlitar sig på slumpmässig åtkomst av graftraversering, faller prestandan med en faktor på 10 till 50 när indexet spilles till disk och frågor blir kedjor av slumpmässiga läsningar. En 768‑dimensionell float32‑vektor tar cirka 3,3 kilobyte minne när graflänkar och Postgres‑overhead räknas in, så ett index över 100 miljoner rader kräver ungefär 330 gigabyte RAM för att förbli resident, provisionerat i sin helhet oavsett om frågor berör det eller inte.

Den andra är indexunderhåll. När en byggprocess spilles till disk tog ett pgvector‑index nästan 50 timmar att konstruera på en standard‑molninstans, sade Databricks, och skrivningar drabbas av samma flaskhals eftersom insättning av en vektor kräver slumpmässig åtkomsttraversering och modifiering av flera graflager. Eftersom HNSW saknar global ombalansering innebär återställning av sökkvalitet att köra en fullständig REINDEX, en operation som låser tabellen och stoppar produktionsskrivningar.

Den tredje är att en enskild fråga inte kan parallelliseras. En pgvector‑fråga körs av en enda Postgres‑backendprocess, vilket lämnar HNSW‑indexskanningen utan någon parallellisering. För att öka recall krävs att fler grafnoder besöks, vilket lägger till slumpmässiga minnesläsningar och avståndsberäkningar, ökar latensen och minskar antalet frågor per sekund, så skalning av genomströmning innebär att lägga till databasanslutningar eller läs‑repliker.

Hur Lakebase_vector byggs

Lakebase Postgres separerar lagring från beräkning: permanent data lagras i billig molnbaserad objektlagring, medan RAM och lokalt NVMe fungerar som kortlivade cacheminnen som håller den aktiva arbetsmängden. På den grunden kombinerade Databricks två tekniker.

Hierarkisk IVF‑klustring grupperar vektorer i kluster som lagras som sammanhängande block. En fråga poängsätter klustercentroiderna i minnet och läser sedan endast de få block som ser lovande ut som stora sekventiella läsningar istället för att göra många slumpmässiga hopp. Binär kvantisering med RaBitQ‑metoden komprimerar varje vektor till ungefär en bit per dimension, ungefär 32  gånger mindre än float32, så frågor skannar kompakta koder för att skapa en kortlista av kandidater och omrankar endast den kortlistan mot vektorer med full precision.

Eftersom designen är tillståndslös skalar den ner till noll, och i vila betalar användare endast för lagring. Databricks rapporterade ett uppmätt P90 på 1,13 sekunder för den första frågan efter skalning till noll på en dataset med 100 miljoner vektorer, 768 dimensioner, och sade att 100 miljoner vektorer kan betjänas på en Lakebase Compute Unit.

Indexkonstruktionen tränar klustercentroider en enda gång på ett litet slumpmässigt urval; varje vektor tilldelas sedan sin närmaste centroid, kvantiseras och skrivs till rätt block som en oberoende operation, så arbetet fördelas över hur många kärnor som finns tillgängliga. Databricks sade att deras LTAP-arkitektur avlastar indexbyggnation från den primära databasen till distribuerade motorer såsom Spark, vilket minskar byggtiderna till minuter, och meddelade att mer kommer på den kapaciteten. Eftersom predikat tillämpas under blockskanningen själv, undviker filtrerade frågor överhämtning av kandidater och behåller hög återkallelse, och en enskild fråga parallelliseras över CPU-kärnor.

BM25-textsökning och hybridfrågor

Databricks sade att standard Postgres tsvector-sökning saknar korpusomfattande relevanskontext. lakebase_text poängsätter termer med hjälp av global invers dokumentfrekvens, vilket ger mer vikt åt sällsynta, högintentionella termer och mindre åt vanliga fyllnadsord. Den kontrollerar också övre gränser för poängen när den traverserar indexet och kastar bort hela postningsblock som inte kan påverka top‑K-resultatet, vilket företaget sade gör den snabbare än tsvector med GIN-index.

Genom att kombinera de två tilläggen möjliggörs inbyggd hybrid­sökning i Postgres: en enda fråga kan tillämpa vanliga SQL-filterpredikat, ansluta levande operativa tabeller och slå samman semantisk vektorpåverkan med BM25-nyckelordsrelevans. Databricks sade att systemet skalar från en rad till en miljard vektorer och från en fråga per sekund till tusentals utan manuell omprovisionering, och beskriver designen som avsedd för AI‑agenter vars arbetsflöden kan utlösa tusentals samtidiga hämtningsförfrågningar inom sekunder.

Databricks positionerar Lakebase Search för användare som vill ha operativ och sökdata konsoliderade i en enda databas, medan Databricks AI Search förblir deras hanterade motor för hämtning som fungerar direkt. Lakebase Search är allmänt tillgänglig på AWS och Azure; befintliga Lakebase‑användare kan aktivera tilläggen, och nya användare kan registrera sig för Lakebase.