Databricks přináší full‑textové a vektorové vyhledávání do Lakebase Postgres

Databricks 28. září 2026, zavedl Lakebase Search, vestavěný vyhledávací engine pro jeho databázi Lakebase Postgres dodávaný prostřednictvím dvou rozšíření: lakebasevektor pro aproximativní vyhledávání nejbližších sousedů a lakebasetext pro BM25 full‑textové vyhledávání. Obě rozšíření jsou obecně dostupná na AWS a Azure.

Rozšíření umožňují vývojářům spouštět sémantické, klíčové a hybridní vyhledávání přímo v Postgresu vedle provozních dat. Databricks uvedl, že tradiční systémy OLTP nebyly navrženy pro požadavky vyhledávání AI agentů, kteří vyžadují nízkou latenci, vysokou přesnost načítání a často provádějí masivní paralelní vyhledávání, a že řešení tohoto problému doposud znamenalo připojení samostatného vyhledávacího enginu k primární databázi pomocí ETL pipeline. Společnost uvedla, že Lakebase Search vybudovala na základě zpětné vazby od stovek beta zákazníků.

Výsledky benchmarku a nasazení v Conexiom

Databricks uvedl, že lakebase_vektor poskytuje dvojnásobnou propustnost oproti dalšímu nejlepšímu systému v benchmarku VectorDBBench 100M, který používá dataset LAION, a že je čtyřikrát levnější než poskytovatel cloudového Postgresu používající pgvector, před dalšími úsporami díky automatickému škálování. Společnost oznámila latenci P99 71 milisekund při 97 % recall, což znamená, že engine úspěšně získal skutečné nejbližší sousedy v 97 % případů, a poznamenala, že pgvector a DiskANN byly testovány pouze na jedné velké instanci.

Databricks také oznámil výsledek zákazníka Conexiom, který provozuje hybridní BM25 vyhledávání nad více než 100 miliony řádků při poloviční výpočetní zátěži oproti jeho dřívějšímu nastavení s pgvector. Náklady na infrastrukturu Conexiom klesly třikrát a propustnost vzrostla pětkrát ve srovnání s pgvector, uvedla společnost.

„Lakebase Search nám poskytuje zcela novou úroveň škálovatelnosti oproti pgvector a odemyká BM25 ve stejné serverless databázi,“ řekl Jordan Voves, AI/ML architekt ve společnosti Conexiom. „Používáme Lakebase k propojení dat s našimi agenty ve velkém měřítku.“

Limity pgvector v pozadí návrhu

Databricks uvedl, že pgvector je nejčastěji instalovaným rozšířením v Lakebase Postgres a popsal tři opakující se problémy, které zaznamenal u zákazníků používajících jej ve velkém měřítku.

Prvním je náklad, který roste s objemem dat spíše než s využitím. pgvector uchovává svůj HNSW index v paměti databáze a protože vyhledávání HNSW závisí na náhodném přístupu v grafu, výkon klesá o faktor 10 až 50, jakmile index přeteče na disk a dotazy se změní na řetězce náhodných čtení. 768‑dimenzionální float32 vektor zabírá přibližně 3,3 kB paměti po zahrnutí grafových odkazů a režie Postgresu, takže index nad 100 miliony řádků vyžaduje zhruba 330 GB RAM, která musí být plně přidělena, ať už jsou dotazy aktivní či ne.

Druhým je údržba indexu. Když se sestavení přetéklo na disk, pgvector index trval téměř 50 hodin při vytváření na standardní cloudové instanci, uvedl Databricks, a zápisy trpí stejným úzkým hrdlem, protože vložení vektoru vyžaduje náhodný přístup a úpravu několika vrstev grafu. Protože HNSW nemá globální vyvážení, obnovení kvality vyhledávání znamená spuštění úplného REINDEX, operace, která uzamkne tabulku a zastaví produkční zápisy.

Třetím je, že jediný dotaz nelze paralelizovat. Dotaz pgvector je prováděn jedním backendovým procesem Postgres, takže skenování HNSW indexu není paralelizováno. Zvýšení recall vyžaduje navštívení více uzlů grafu, což přidává náhodná čtení z paměti a porovnávání vzdáleností, zvyšuje latenci a snižuje počet dotazů za sekundu, takže škálování propustnosti znamená přidání databázových spojení nebo replik čtení.

Jak je postaven Lakebase_vector

Lakebase Postgres odděluje úložiště od výpočtů: trvalá data jsou uložena v nízkonákladovém cloudovém objektovém úložišti, zatímco RAM a lokální NVMe slouží jako krátkodobé cache, které drží aktivní pracovní sadu. Na této základně Databricks spojil dvě techniky.

Hierarchické IVF shlukování seskupuje vektory do klastrů uložených jako souvislé bloky. Dotaz ohodnotí centroidy klastrů v paměti a poté načte jen několik bloků, které vypadají slibně, jako velké sekvenční čtení místo mnoha náhodných skoků. Binární kvantizace pomocí metody RaBitQ komprimuje každý vektor na přibližně jeden bit na dimenzi, což je zhruba 32‑krát méně než float32, takže dotazy skenují kompaktní kódy k vytvoření shortlistu kandidátů a znovu řadí jen tento shortlist proti vektorům s plnou přesností.

Protože je návrh bezstavový, škáluje se na nulu a v klidu uživatelé platí jen za úložiště. Databricks uvedl měřený P90 1,13 sekundy pro první dotaz po scale‑to‑zero na datové sadě s 100 miliony vektorů, 768 dimenzemi, a uvedl, že 100 milionů vektorů může být obslouženo jednou Lakebase Compute Unit.

Vytváření indexu natrénuje centroidy klastru jednorázově na malém náhodném vzorku; každý vektor je pak přiřazen k nejbližšímu centroidu, kvantizován a zapsán do příslušného bloku jako samostatná operace, takže práce se rozprostře na všechny dostupné jádra. Databricks uvedl, že jeho architektura LTAP přesouvá vytváření indexů z primární databáze na distribuované enginy, jako je Spark, čímž snižuje dobu vytvoření na minuty, a řekl, že v této oblasti se chystá další vývoj. Protože se predikáty aplikují během samotného skenování bloku, filtrované dotazy se vyhnou nadměrnému načítání kandidátů a udržují vysokou míru zachycení, a jeden dotaz se paralelizuje napříč CPU jádry.

Vyhledávání textu BM25 a hybridní dotazy

Databricks uvedl, že standardní vyhledávání tsvector v Postgresu postrádá kontext relevance na úrovni celého korpusu. lakebase_text hodnotí termíny pomocí globální inverzní frekvence dokumentů, přičemž dává vyšší váhu vzácným, vysoce záměrným termínům a nižší váhu běžným výplňovým slovům. Také kontroluje horní meze skóre při procházení indexu a odstraňuje celé bloky příspěvků, které nemohou ovlivnit výsledek top‑K, což společnost uvedla jako rychlejší než tsvector s GIN indexy.

Kombinace obou rozšíření umožňuje nativní hybridní vyhledávání v rámci Postgresu: jeden dotaz může aplikovat běžné SQL filtrické predikáty, spojovat živé provozní tabulky a slučovat semantické vektorové hodnocení s relevance klíčových slov BM25. Databricks uvedl, že systém škáluje od jednoho řádku až po miliardu vektorů a od jednoho dotazu za sekundu až po tisíce bez ručního přeprovizování, přičemž popsal návrh jako určený pro AI agenty, jejichž pracovní postupy mohou během několika sekund spustit tisíce souběžných požadavků na vyhledávání.

Databricks představuje Lakebase Search pro uživatele, kteří chtějí provozní a vyhledávací data konsolidovaná v jediné databázi, zatímco Databricks AI Search zůstává jeho spravovaným enginem pro vyhledávání, který funguje ihned po nasazení. Lakebase Search je obecně dostupný na AWS a Azure; stávající uživatelé Lakebase mohou rozšíření aktivovat a noví uživatelé se mohou zaregistrovat do Lakebase.