Databricks aduce căutare full-text și vectorială în Lakebase Postgres

Databricks pe 28 septembrie 2026, a introdus Lakebase Search, un motor de căutare încorporat pentru baza de date Lakebase Postgres, livrat prin două extensii: lakebasevector pentru căutare aproximativă a celui mai apropiat vecin și lakebasetext pentru căutare full-text BM25. Ambele extensii sunt disponibile în mod general pe AWS și Azure.

Extensiile permit dezvoltatorilor să execute căutare semantică, pe cuvinte cheie și hibridă direct în Postgres, alături de datele operaționale. Databricks a declarat că sistemele OLTP tradiționale nu au fost concepute pentru cerințele de căutare ale agenților AI, care necesită recuperare cu latență scăzută și acuratețe ridicată și adesea efectuează căutări paralele masive, iar rezolvarea acestei probleme până în prezent a însemnat atașarea unui motor de căutare independent la baza de date principală printr-un pipeline ETL. Compania a afirmat că a construit Lakebase Search pe baza feedback‑ului de la sute de clienți beta.

Rezultatele benchmark și implementarea Conexiom

Databricks a declarat că lakebase_vector oferă dublul debitului sistemului următor pe benchmark-ul VectorDBBench 100M, care folosește setul de date LAION, și că este de patru ori mai ieftin decât un furnizor cloud de Postgres care utilizează pgvector, înainte de economiile suplimentare generate de scalarea automată. Compania a raportat o latență P99 de 71 de milisecunde la 97 % recall, ceea ce înseamnă că motorul a recuperat cu succes vecinii cei mai apropiați 97 % din timp, și a remarcat că pgvector și DiskANN au fost testate doar pe o singură instanță mare.

Databricks a raportat, de asemenea, un rezultat al unui client, Conexiom, care rulează căutare hibridă BM25 peste peste 100 de milioane de rânduri, la jumătate din amprenta de calcul a configurației sale anterioare cu pgvector. Costurile de infrastructură ale Conexiom au scăzut de trei ori, iar debitul a crescut de cinci ori în raport cu pgvector, a declarat compania.

„Lakebase Search ne oferă un nivel complet nou de scalabilitate față de pgvector și deblochează BM25 în aceeași bază de date fără servere”, a declarat Jordan Voves, arhitect AI/ML la Conexiom. „Utilizăm Lakebase pentru a conecta datele la agenții noștri la scară largă.”

Limitele pgvector din spatele designului

Databricks a declarat că pgvector este cea mai instalată extensie în Lakebase Postgres și a descris trei puncte de durere recurente observate la clienții care o rulează la scară.

Primul este costul, care scalează cu volumul de date, nu cu utilizarea. pgvector păstrează indexul său HNSW în memoria bazei de date și, deoarece căutarea HNSW se bazează pe traversarea aleatorie a graficului, performanța scade cu un factor de 10 până la 50 odată ce indexul se varsă pe disc și interogările devin lanțuri de citiri aleatorii. Un vector float32 de 768 de dimensiuni ocupă aproximativ 3,3 kilobyți de memorie odată ce legăturile graficului și supraîncărcarea Postgres sunt incluse, astfel că un index peste 100 de milioane de rânduri necesită aproximativ 330 de gigabytes de RAM pentru a rămâne rezident, provisionat integral indiferent dacă interogările îl accesează sau nu.

Al doilea este întreținerea indexului. Când o construcție s-a varsat pe disc, un index pgvector a durat aproape 50 de ore pentru a fi construit pe o instanță cloud standard, a declarat Databricks, iar scrierile suferă de același blocaj deoarece inserarea unui vector necesită traversare aleatorie și modificarea mai multor straturi ale graficului. Deoarece HNSW nu are rebalansare globală, recuperarea calității căutării înseamnă rularea unui REINDEX complet, o operație care blochează tabelul și oprește scrierile în producție.

Al treilea este că o singură interogare nu poate fi paralelizată. O interogare pgvector este executată de un singur proces backend al Postgres, lăsând scanarea indexului HNSW fără nicio paralelizare. Creșterea recall‑ului necesită vizitarea unui număr mai mare de noduri ale graficului, ceea ce adaugă citiri aleatorii de memorie și comparații de distanță, crescând latența și reducând numărul de interogări pe secundă, astfel că scalarea debitului înseamnă adăugarea de conexiuni la baza de date sau replici de citire.

Cum este construit Lakebase_vector

Lakebase Postgres separă stocarea de calcul: datele permanente se află în stocarea de obiecte în cloud cu cost redus, în timp ce RAM și NVMe local servesc ca cache‑uri pe termen scurt care păstrează setul de lucru activ. Pe această bază, Databricks a combinat două tehnici.

Clusterele ierarhice IVF grupează vectorii în clustere stocate ca blocuri contigue. O interogare evaluează centroidurile clusterelor în memorie, apoi citește doar câteva blocuri care par promițătoare ca lecturi secvențiale mari, în loc să facă numeroase salturi aleatorii. Cuantizarea binară, utilizând metoda RaBitQ, comprimă fiecare vector la aproximativ un bit pe dimensiune, aproximativ 32 de ori mai mic decât float32, astfel că interogările scanează coduri compacte pentru a crea o listă scurtă de candidați și reordonă doar acea listă scurtă în raport cu vectorii de precizie completă.

Deoarece designul este fără stare, se scalează la zero, iar în repaus utilizatorii plătesc doar pentru stocare. Databricks a raportat un P90 măsurat de 1,13 secunde pentru prima interogare după scalarea la zero pe un set de date de 100 de milioane de vectori, cu 768 de dimensiuni, și a declarat că 100 de milioane de vectori pot fi serviți pe o singură Lakebase Compute Unit.

Construcția indexului antrenează centriidele clusterului o singură dată pe un eșantion aleator mic; fiecare vector este apoi atribuit celui mai apropiat centroid, cuantificat și scris în blocul corespunzător ca o operație independentă, astfel încât munca se distribuie pe oricâte nuclee sunt disponibile. Databricks a declarat că arhitectura sa LTAP descarcă crearea indexurilor din baza de date principală către motoare distribuite precum Spark, reducând timpul de construire la minute și a afirmat că vor urma îmbunătățiri ale acestei funcționalități. Deoarece predicatele sunt aplicate în timpul scanării blocului, interogările filtrate evită supra‑preluarea candidaților și mențin un nivel ridicat de recall, iar o singură interogare se paralelizează pe nuclee CPU.

Căutare text BM25 și interogări hibride

Databricks a declarat că căutarea standard Postgres tsvector nu dispune de context de relevanță la nivel de corpus. lakebase_text evaluează termeni utilizând frecvența inversă globală a documentelor, acordând o pondere mai mare termenilor rari, cu intenție ridicată, și mai mică cuvintelor de umplutură comune. De asemenea, verifică limitele superioare ale scorului în timpul traversării indexului, eliminând blocuri de postări întregi care nu pot influența rezultatul top‑K, ceea ce, potrivit companiei, îl face mai rapid decât tsvector cu indexuri GIN.

Combinarea celor două extensii permite căutarea hibridă nativă în interiorul Postgres: o singură interogare poate aplica predicate de filtrare SQL obișnuite, poate alătura tabele operaționale în timp real și poate combina scorarea vectorială semantică cu relevanța cuvintelor cheie BM25. Databricks a afirmat că sistemul se scalează de la un rând la un miliard de vectori și de la o interogare pe secundă la mii, fără reconfigurare manuală, descriind designul ca destinat agenților AI ale căror fluxuri de lucru pot declanșa mii de cereri de recuperare concurente în câteva secunde.

Databricks poziționează Lakebase Search pentru utilizatorii care doresc date operaționale și de căutare consolidate într-o singură bază de date, în timp ce Databricks AI Search rămâne motorul său gestionat pentru recuperare, funcțional imediat. Lakebase Search este disponibil în mod general pe AWS și Azure; utilizatorii existenți Lakebase pot activa extensiile, iar noii utilizatori se pot înscrie la Lakebase.