Databricks tuo täystekstihaku- ja vektorihakuominaisuudet Lakebase Postgresiin

Databricks 28. syyskuuta 2026 esitteli Lakebase Searchin, sisäänrakennetun hakukoneen sen Lakebase Postgres -tietokannalle, joka toimitetaan kahden laajennuksen kautta: lakebase_vector likimääräiseen lähimmän naapurin hakuun ja lakebase_text BM25‑täystekstihakua varten. Molemmat laajennukset ovat yleisesti saatavilla AWS:ssä ja Azuressa.

Laajennukset antavat kehittäjille mahdollisuuden suorittaa semanttista, avainsanapohjaista ja hybridi­hakua suoraan Postgresissa operatiivisten tietojen rinnalla. Databricks totesi, että perinteiset OLTP‑järjestelmät eivät ole suunniteltuja tekoälyagenttien hakutarpeisiin, jotka vaativat matalaa viivettä, tarkkaa hakutulosta ja usein massiivisia rinnakkaishakuja, ja että tähän asti ratkaisu on tarkoittanut erillisen hakukoneen liittämistä ensisijaiseen tietokantaan ETL‑putken avulla. Yritys kertoi rakentaneensa Lakebase Searchin satojen beta‑asiakkaiden palautteen pohjalta.

Suorituskykyvertailun tulokset ja Conexiom‑asennus

Databricks sanoi, että lakebase_vector tarjoaa kaksinkertaisen läpimenon seuraavaksi parhaaseen järjestelmään verrattuna VectorDBBench 100M -vertailussa, jossa käytetään LAION‑aineistoa, ja on neljä kertaa halvempi kuin pilvipostgresin toimittaja, joka käyttää pgvectoria, ennen lisäsäästöjä automaattisesta skaalaamisesta. Yritys raportoi P99‑viiveen olevan 71 millisekuntia 97 %:n recall-arvolla, mikä tarkoittaa, että moottori onnistui hakemaan todelliset lähimmät naapurit 97 %:ssa tapauksista, ja totesi, että pgvector ja DiskANN testattiin vain yhdellä suurella instanssilla.

Databricks raportoi myös asiakastuloksen Conexiomilta, joka suorittaa BM25‑hybridihakua yli 100 miljoonalla rivillä käyttäen vain puolta aiemman pgvector‑asennuksen laskentatehosta. Conexiomin infrastruktuurikustannukset vähenivät kolmasosaan ja läpimeno nousi viidenkertaiseksi pgvectoriin verrattuna, yritys kertoi.

„Lakebase Search tarjoaa meille aivan uuden tason skaalautuvuutta pgvectoriin verrattuna ja avaa BM25:n samassa serverittömässä tietokannassa“, sanoi Jordan Voves, AI/ML‑arkkitehti Conexiomissa. „Käytämme Lakebasea yhdistämään dataa agenteihimme laajassa mittakaavassa.“

Pgvector‑rajoitukset suunnittelun taustalla

Databricks kertoi, että pgvector on eniten asennettu laajennus Lakebase Postgresissa, ja se kuvasi kolme toistuvaa kipupistettä, joita asiakkaat ovat havainneet sen skaalautuvassa käytössä.

Ensimmäinen on kustannus, joka skaalautuu datamäärän mukaan eikä käytön mukaan. pgvector pitää HNSW‑indeksinsä tietokannan muistissa, ja koska HNSW‑haku perustuu satunnaispääsyyn graafin läpikäynnissä, suorituskyky heikkenee 10–50‑kertaisesti, kun indeksi vuotaa levylle ja kyselyt muuttuvat satunnaisten lukutoimintojen ketjuiksi. 768‑dimensioinen float32‑vektori vie noin 3,3 kilotavua muistia, kun graafiyhteydet ja Postgres‑ylikuorma otetaan huomioon, joten 100 miljoonan rivin indeksi vaatii noin 330 gigatavua RAM-muistia pysyäkseen muistissa, varattuna kokonaisuudessaan riippumatta siitä, koskettavatko kyselyt sitä vai eivät.

Toinen on indeksin ylläpito. Kun indeksin rakentaminen vuoti levylle, pgvector‑indeksin rakentaminen kesti lähes 50 tuntia tavallisella pilvi‑instanssilla, Databricks kertoi, ja kirjoitukset kärsivät samasta pullonkaulasta, koska vektorin lisääminen vaatii satunnaispääsyn läpikäynnin ja useiden graafikerrosten muokkauksen. Koska HNSW:ssä ei ole globaalia tasapainotusta, hakutuloksen palauttaminen edellyttää täyttä REINDEX‑toimenpidettä, joka lukitsee taulun ja pysäyttää tuotantokirjoitukset.

Kolmas on se, että yksittäistä kyselyä ei voida rinnakkaistaa. pgvector‑kyselyn suorittaa yksi Postgres‑taustaprosessi, jättäen HNSW‑indeksin skannauksen ilman minkäänlaista rinnakkaisuutta. Recall-arvon nostaminen edellyttää useampien graafin solmujen käymistä läpi, mikä lisää satunnaisia muistilukuja ja etäisyysvertailuja, kasvattaa viivettä ja vähentää kyselyitä sekunnissa, joten läpimenon skaalaaminen edellyttää tietokantayhteyksien tai luku‑replikoiden lisäämistä.

Miten Lakebase_vector on rakennettu

Lakebase Postgres erottaa tallennuksen laskennasta: pysyvä data sijaitsee edullisessa pilvi‑objektitallennuksessa, kun taas RAM ja paikallinen NVMe toimivat lyhytikäisinä välimuisteina, jotka pitävät aktiivisen työjoukon. Tämän perustan päälle Databricks yhdisti kaksi tekniikkaa.

Hierarkkinen IVF‑klusterointi ryhmittelee vektorit klustereiksi, jotka tallennetaan yhtenäisinä lohkoina. Kysely arvioi klusterikeskipisteet muistissa, ja sen jälkeen lukee vain muutaman lupaavan lohkon suurina peräkkäisinä lukuina sen sijaan, että tekisi monta satunnaista hyppyä. Binäärikvanttaus RaBitQ‑menetelmällä pakkaa jokaisen vektorin noin yhdeksi bitiksi per dimensio, noin 32‑kertaisesti pienemmäksi kuin float32, joten kyselyt skannaavat tiiviitä koodeja luodakseen ehdokaslistan ja järjestävät uudelleen vain tämän listan täyden tarkkuuden vektoreihin nähden.

Koska suunnittelu on tilaton, se skaalautuu nollaan, ja lepotilassa käyttäjät maksavat vain tallennuksesta. Databricks raportoi mitatun P90‑arvon olevan 1,13 sekuntia ensimmäiselle kyselylle skaalautumisen jälkeen nollaan 100 miljoonan vektorin, 768‑dimensioisen tietoaineiston kanssa, ja totesi, että 100 miljoonaa vektoria voidaan palvella yhdellä Lakebase Compute Unitilla.

Indeksin rakentaminen kouluttaa klusterikeskipisteet kerran pienellä satunnaisotoksella; jokainen vektori liitetään sitten lähimpään keskipisteeseensä, kvantoidaan ja kirjoitetaan sopivaan lohkoon itsenäisenä operaationa, jolloin työ jakautuu kaikkien käytettävissä olevien ytimien kesken. Databricks kertoi, että sen LTAP-arkkitehtuuri siirtää indeksinrakennukset ensisijaisesta tietokannasta hajautetuille moottoreille, kuten Sparkille, mikä lyhentää rakennusaikoja minuuteiksi, ja lisätoimintoja on tulossa. Koska predikaatit toteutetaan lohkon skannauksen aikana, suodatetut kyselyt välttävät liiallisen hakutulosten noutamisen ja pitävät recall-arvon korkeana, ja yksi kysely rinnakkaistuu CPU-ytimien yli.

BM25-tekstihaku ja hybridikyselyt

Databricks kertoi, että tavallinen Postgres‑tsvector‑haku ei sisällä koko korpuksen relevanssikontekstia. lakebase_text pisteyttää termit käyttäen globaalia käänteistä dokumenttifrekvenssiä, antaen enemmän painoarvoa harvinaisille, korkean tarkoituksen termeille ja vähemmän yleisille täytesanoille. Se tarkistaa myös pistemäärän ylärajat indeksin läpikäynnin aikana, hyläten kokonaiset posting-lohkot, jotka eivät voi vaikuttaa top‑K‑tulokseen, mikä yrityksen mukaan tekee siitä nopeamman kuin tsvector GIN‑indekseillä.

Kahden laajennuksen yhdistäminen mahdollistaa natiivin hybridihaun Postgresissa: yksi kysely voi soveltaa tavallisia SQL‑suodatuspredikaatteja, liittää reaaliaikaisia operatiivisia tauluja ja yhdistää semanttisen vektoripisteytyksen BM25‑avainsanan relevanssiin. Databricks kertoi, että järjestelmä skaalautuu yhdestä rivistä miljardiin vektoriin ja yhdestä kyselystä sekunnissa tuhansiin ilman manuaalista resurssien uudelleenasettamista, ja kuvailee suunnittelun tarkoitettu olevan AI‑agenteille, joiden työnkulut voivat käynnistää tuhansia samanaikaisia hakupyyntöjä sekunneissa.

Databricks asettaa Lakebase Searchin käyttäjille, jotka haluavat operatiivisen ja hakudatan konsolidoituna yhdeksi tietokannaksi, kun taas Databricks AI Search pysyy sen hallinnoimana hakumoottorina, joka toimii heti käyttövalmiina. Lakebase Search on yleisesti saatavilla AWS:ssä ja Azure:ssa; nykyiset Lakebase‑käyttäjät voivat ottaa laajennukset käyttöön, ja uudet käyttäjät voivat rekisteröityä Lakebaseen.