Perplexity si postavila vlastní databázi. Vyhledávání je teď rychlejší

Perplexity narazila na limity běžné cloudové databáze

Na první pohled to může vypadat jako další výměna jedné databáze za jinou. Ve skutečnosti jde o poměrně přesný příklad toho, jak se mění nároky na infrastrukturu kolem AI vyhledávačů.

Tradiční webový vyhledávač často pracuje s krátkým výsledkem, titulkem, adresou stránky nebo několika řádky textu. Perplexity ale při generování odpovědi potřebuje získat mnohem více dat najednou. Pro jednotlivé dotazy načítá pasáže webových stránek a také vektorové reprezentace dokumentů, které pomáhají určit, zda spolu obsahově souvisejí.

Jedna položka má podle zveřejněných údajů průměrně kolem 50 KB a běžný dávkový dotaz načítá 10 až 15 klíčů. Při provozu v řádu stovek tisíc požadavků za sekundu se z drobného zpoždění stává významný provozní problém. Databáze pak není jen místo, kam se ukládají záznamy. Je to něco jako výdejní pult, u kterého stojí celý AI systém a čeká na ingredience pro další odpověď.

Perplexity proto podle zjištění InfoQ nahradila DynamoDB vlastním distribuovaným úložištěm CobbleDB. Firma současně zveřejnila technické podrobnosti architektury a výsledky měření z produkčního provozu.

Co je CobbleDB a proč vznikla

CobbleDB je specializovaná key-value databáze. To znamená, že pracuje s dvojicemi klíč–hodnota: podle identifikátoru dokumentu nebo stránky rychle vyhledá uložený obsah. Nejde o databázi určenou pro libovolné podnikové aplikace, složité transakce nebo univerzální analytiku.

Její účel je užší a díky tomu může být i jednodušší. CobbleDB se zaměřuje na dávkové čtení většího množství položek. Místo série jednotlivých požadavků dokáže pracovat s více klíči najednou, takže omezuje počet síťových cest mezi službami.

Databáze je napsaná v jazyce Rust a používá RocksDB jako vestavěný úložný engine. Data se ukládají na lokální NVMe SSD, zatímco paměťově mapované cache pomáhají udržovat často používané části dat blízko výpočetních uzlů.

Pro každou část dat existují tři repliky na samostatných výpočetních uzlech. Router následně posílá požadavky na repliku ve stejné dostupnostní zóně. Pokud některý uzel odpovídá pomalu, může požadavek paralelně odeslat také na alternativní repliku. Tento postup zvyšuje šanci, že jednotlivé pomalé uzly neprotáhnou odpověď celému systému.

Tři vrstvy místo jedné univerzální databáze

Jedním z nejzajímavějších prvků není jen samotná databáze, ale rozdělení celého úložiště na tři části.

Pillar uchovává trvalý stav

Komponenta Pillar se stará o dlouhodobé uložení metadat webových stránek, pasáží a vektorových reprezentací. Její úloha připomíná archiv. Nemusí být nejrychlejší při každém jednotlivém čtení, ale musí udržovat konzistentní stav a verze dat.

Lorry připravuje aktualizace

Lorry funguje jako mezivrstva pro zpracování změn. Seskupuje aktualizovaná data do dávek a ukládá je do Amazon S3. Tím odděluje náročné zápisy způsobené procházením webu nebo novými embeddingy od provozu, který obsluhuje živé dotazy uživatelů.

CobbleDB obsluhuje rychlé dotazy

Samotná CobbleDB je takzvaná hot vrstva. Nemusí řešit celý životní cyklus dokumentu. Dostává připravené dávky a soustředí se na co nejrychlejší načítání během generování odpovědí.

Tohle rozdělení je důležité. Když se například změní způsob dělení textu nebo se použije nový model pro tvorbu embeddingů, může vzniknout velké množství nových zápisů. Pokud by tyto zápisy mířily přímo do stejné databáze, která zároveň obsluhuje dotazy uživatelů, mohly by si navzájem překážet.

Latence klesla pětkrát, nejvíce je to vidět na pomalých odpovědích

Nejvýraznější výsledek se týká dávkového čtení. Mediánová latence, tedy hodnota uprostřed měřených požadavků, klesla z 31,44 ms u DynamoDB na 5,60 ms u CobbleDB. Perplexity to uvádí jako zrychlení o 82 procent, respektive přibližně 5,6násobně nižší latenci.

Ještě důležitější je 99. percentil. Ten ukazuje, jak dlouho trvá odpověď u pomalejší části požadavků. Hodnota klesla ze 123 ms na 24,2 ms. Rozdíl mezi typickou a pomalejší odpovědí je u AI vyhledávače podstatný, protože výsledná odpověď se skládá z více navazujících kroků.

Pokud jeden pomalý dotaz čeká na data z několika míst, zpoždění se může promítnout do celkové doby generování. Uživatel samozřejmě nevidí databázi ani percentily. Vidí jen to, že odpověď dorazí rychleji, nebo že se stránka několik sekund tváří, jako by přemýšlela nad smyslem existence.

Systém byl podle zveřejněných údajů provozován při zátěži kolem 200 000 dotazů za sekundu. To není běžný parametr, který by měl řešit vývojář interního firemního chatbotu. Ukazuje ale, proč Perplexity přestala řešit pouze cenu jednotlivých cloudových operací a začala si optimalizovat celý datový tok.

Úspora nejméně 20 procent není zadarmo

Perplexity odhaduje, že CobbleDB snižuje náklady na cloudové úložiště nejméně o 20 procent ve srovnání s DynamoDB. Jde o interní model firmy, nikoli o univerzální ceník nebo výsledek dostupný každému zákazníkovi. Úspora proto závisí na konkrétním objemu dat, počtu dotazů a způsobu provozu.

Výměnou za nižší provozní náklady ale Perplexity přebírá více práce. U spravované cloudové databáze část starostí řeší poskytovatel služby. U vlastního systému musí firma sama hlídat životní cyklus uzlů, zálohování, obnovu po chybách, rozdělení dat mezi partitiony i replikaci.

CobbleDB navíc nepoužívá klasické synchronní potvrzování všech změn. Repliky aktualizace aplikují asynchronně, takže mezi nimi může krátkodobě existovat rozdíl. Pro vyhledávací systém je takový kompromis přijatelnější než například pro bankovní převod. Pokud jedna replika obdrží nový obsah o něco později, nejde obvykle o stejný typ problému jako u nesprávného zůstatku na účtu.

Databázi vytvořili dva inženýři s pomocí AI agentů

Další pozornost vzbudil způsob vývoje. Podle zveřejněných informací vzniklo přibližně 40 000 řádků Rustu za zhruba dva měsíce. Na projektu pracovali dva systémoví inženýři a pomáhaly jim stovky AI kódovacích agentů.

Je důležité správně číst, co takové tvrzení znamená. Nejde o důkaz, že AI agenti samostatně navrhli, ověřili a provozují celou produkční databázi bez lidského dohledu. Z dostupného popisu vyplývá, že agenti pomáhali s integračním testováním, sledováním sestavení a přípravou provozních postupů. Odpovědnost za architekturu a nasazení zůstává na lidech.

Přesto jde o zajímavý signál pro vývoj infrastruktury. Specializované interní systémy už nemusí vznikat pouze jako několikaleté projekty velkých týmů. AI nástroje mohou zrychlit psaní podpůrného kódu, testování a opakované provozní úkoly. Neodstraňují ale potřebu rozhodnout, co má databáze garantovat, kde smí být nekonzistentní a jak se obnoví po selhání.

Co to znamená pro české uživatele a firmy

CobbleDB není nová veřejná služba, kterou by si mohl předplatit český uživatel nebo nasadit běžná firma jedním kliknutím. Jde o interní infrastrukturu Perplexity. Pro český trh se tím nemění cena, lokalizace ani dostupnost samotného vyhledávače; zdrojové oznámení žádnou takovou změnu nepopisuje.

Pro vývojáře je ale případ Perplexity užitečný jako příklad, kdy dává smysl opustit univerzální službu. DynamoDB je vhodná pro mnoho aplikací, protože nabízí spravované prostředí a nemusí se starat o vlastní databázové servery. Vlastní řešení začíná dávat ekonomický a výkonový smysl až ve chvíli, kdy je zátěž velmi předvídatelná, datový model úzký a tým dokáže převzít provozní odpovědnost.

Jinými slovy: pokud stavíte menší český SaaS, CobbleDB pravděpodobně není první věc, kterou potřebujete. Pokud obsluhujete stovky tisíc dotazů za sekundu a každý z nich tahá desítky kilobajtů dat pro generativní model, začíná být vlastní úložiště mnohem méně extravagantní nápad.

Perplexity oznámila záměr uvolnit zdrojový kód CobbleDB jako open source. K 26. září 2026 ale nebyl v dostupných podkladech uveden konkrétní termín vydání ani veřejný ceník. Prozatím je proto nejzajímavější především architektura: trvalý stav oddělený od aktualizací a rychlé čtecí úložiště navržené přesně pro potřeby AI vyhledávání.

FAQ

Technické podrobnosti zveřejnila také společnost Perplexity.