Databricks tuo täystekstihaku- ja vektorihakuominaisuudet Lakebase Postgresiin

Databricks 28. syyskuuta 2026, esitteli Lakebase Search, sisäänrakennettu hakukone sen Lakebase Postgres -tietokannalle, toimitettu kahden laajennuksen kautta: lakebasevektori likimääräiseen lähimmän naapurin hakuun ja lakebasetext BM25-täystekstihakua varten. Molemmat laajennukset ovat yleisesti saatavilla AWS:ssä ja Azure:ssa.

Lisäosat antavat kehittäjille mahdollisuuden suorittaa semanttista, avainsana- ja hybridihakua suoraan Postgresin sisällä operatiivisten tietojen ohella. Databricks totesi, että perinteiset OLTP-järjestelmät eivät ole suunniteltu AI-agenttien hakutarpeisiin, jotka vaativat alhaista viivettä, tarkkaa hakutulosta ja usein suorittavat massiivisia rinnakkaishakuja, ja että tähän asti ratkaisun löytäminen merkitsi erillisen hakukoneen liittämistä ensisijaiseen tietokantaan ETL-putken avulla. Yritys kertoi rakentaneensa Lakebase Searchin satojen beta-asiakkaiden palautteen perusteella.

Vertailutulokset ja Conexiom-julkaisun käyttöönotto

Databricks sanoi, että lakebase_vektori tarjoaa kaksinkertaisen läpimenon seuraavasta parhaasta järjestelmästä VectorDBBench 100M -vertailussa, jossa käytetään LAION-datasettiä, ja että se on neljä kertaa edullisempi kuin pilvipalvelun Postgres-toimittaja, joka käyttää pgvectoria, ennen lisäsäästöjä automaattisesta skaalaamisesta. Yritys raportoi P99‑viiveen olevan 71 millisekuntia 97 % palautusasteella, mikä tarkoittaa, että moottori palautti todelliset lähimmät naapurit 97 %:ssa ajankohdista, ja totesi, että pgvector ja DiskANN testattiin vain yhdellä suurella instanssilla.

Databricks raportoi myös asiakastuloksen Conexiomilta, joka suorittaa BM25-hybridihakua yli 100 miljoonan rivin yli puolella aiemman pgvector-asetuksen laskentakuormalla. Conexiomin infrastruktuurikustannukset vähenivät kolminkertaisiksi ja läpimeno kasvoi viidinkertaiseksi pgvectoriin verrattuna, yritys kertoi.

“Lakebase Search antaa 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ääksemme tiedot agenteihimme mittakaavassa.”

Pgvectorin rajoitukset suunnittelun takana

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

Ensimmäinen on kustannus, joka kasvaa 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äyntiin, suorituskyky heikkenee 10‑50‑kertaiseksi, kun indeksi vuotaa levylle ja kyselyt muuttuvat satunnaisten lukujen ketjuiksi. 768‑dimensioinen float32‑vektori vie noin 3,3 kilotavua muistia, kun graafiyhteydet ja Postgresin yläkuorma sisällytetään, joten 100 miljoonan rivin indeksi vaatii noin 330 gigatavua RAM-muistia pysyäkseen asennettuna, varattuna kokonaisuudessaan riippumatta siitä, koskettavatko kyselyt sitä vai eivät.

Toinen on indeksin ylläpito. Kun rakennus vuoti levylle, pgvector-indeksi kesti lähes 50 tuntia rakentaakseen standardilla pilvi-instanssilla, Databricks totesi, ja kirjoitukset kärsivät samasta pullonkaulasta, koska vektorin lisääminen vaatii satunnaispääsyn läpikäyntiä ja useiden graafikerrosten muokkaamista. Koska HNSW:ssä ei ole globaalia tasapainotusta, hakutarkkuuden palauttaminen edellyttää täyttä REINDEX‑toimintoa, joka lukitsee taulun ja pysäyttää tuotantokirjoitukset.

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

Miten Lakebase_vector rakennetaan

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 peräkkäisinä lohkoina. Kysely arvioi klusterikeskipisteet muistissa, ja lukee sitten vain ne muutaman lohkon, jotka vaikuttavat lupaavilta suurina peräkkäisinä lukuina sen sijaan, että tehtäisiin monia satunnaisia hyppyjä. Binäärikvanttaus RaBitQ-menetelmällä pakkaa jokaisen vektorin noin yhdeksi bittiksi per dimensio, noin 32‑kerta pienemmäksi kuin float32, joten kyselyt skannaavat tiiviit koodit ehdokkaiden lyhytlistaukseen ja uudelleenarvioivat vain tuon lyhytlistan täysprecisiossa olevia vektoreita.

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 skaalauksen nollaan jälkeen 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ä satunnaisotannalla; jokainen vektori liitetään sitten lähimpään keskipisteeseen, kvantoidaan ja kirjoitetaan sopivaan lohkoon itsenäisenä operaatioina, jolloin työ jakautuu kaikkien käytettävissä olevien ytimien kesken. Databricks kertoi, että sen LTAP-arkkitehtuuri siirtää indeksinrakennukset ensisijaisesta tietokannasta hajautettuihin moottoreihin, kuten Spark, mikä lyhentää rakennusaikoja minuuteiksi, ja lisäsi, että tähän kykyyn on tulossa lisää. Koska predikaatit toteutetaan lohkon skannauksen aikana, suodatetut kyselyt välttävät liiallista hakuehdokkaiden noutamista ja pitävät palautuskyvyn korkean, ja yksi kysely rinnakkaistuu CPU-ytimien yli.

BM25-tekstihaku ja hybridikyselyt

Databricks kertoi, että tavallinen Postgres‑tsvector‑haku puuttuu koko korpuksen merkityksellinen konteksti. lakebase_text pisteyttää termit globaalin käänteisen dokumenttitiheyden perusteella, antaen enemmän painoarvoa harvinaisille, korkean tarkoituksen termeille ja vähemmän yleisille täytesanoille. Se tarkistaa myös pistemaksimit rajan indeksiä kulkiessa, 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 hybridihakun Postgresissa: yksi kysely voi soveltaa tavallisia SQL‑suodatuspredikaatteja, liittää elävät operatiiviset taulut ja yhdistää semanttisen vektoripisteytyksen BM25‑avainsanan relevanssiin. Databricks kertoi, että järjestelmä skaalautuu yhdestä rivistä miljardiin vektoriin ja yhdestä kyselystä sekunnissa tuhansiin ilman manuaalista uudelleenasettamista, ja kuvailee suunnittelua tarkoitettuna 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 yhdistettynä yhteen tietokantaan, kun taas Databricks AI Search pysyy sen hallittuna hakumoottorina, joka toimii suoraan käyttöön. Lakebase Search on yleisesti saatavilla AWS:ssä ja Azure‑ympäristössä; nykyiset Lakebase‑käyttäjät voivat ottaa laajennukset käyttöön, ja uudet käyttäjät voivat rekisteröityä Lakebase‑palveluun.