U kódu je izolace běžná rutina. Vývojář otevře větev v Gitu, automatické testy běží nad vlastní kopií repozitáře, náhled aplikace se nasadí zvlášť a po sloučení změny zmizí. Tenhle model funguje dobře, dokud se změna týká hlavně souborů.

Podstatná část stavu reálné webové aplikace je ale mimo repozitář: v databázi, migracích, uživatelských účtech, oprávněních a datech podobných produkci. Jakmile vývojář nebo AI agent mění schéma, testuje přístupová práva nebo ladí chybu závislou na konkrétních datech, samotná větev v Gitu přestává stačit.

V mnoha týmech se to dlouho řešilo sdílenou testovací databází. Nebyla produkční, takže se do ní mohlo zapisovat. Zároveň produkci trochu připomínala. S AI agenty je tenhle kompromis vidět ostřeji: pracují rychle, zkoušejí varianty, vracejí se, spouštějí migrace a mohou paralelně testovat několik hypotéz. Pokud to všechno dělají nad jednou databází, samostatná větev kódu izoluje jen část práce.

Větvení databáze se snaží přidat podobný pracovní prostor i k datům. Pro vývoj, testy, náhledová prostředí a agentí pokusy dává jednoduché pravidlo: změny kódu i změny databázového stavu mají běžet odděleně.

Proč větev v Gitu nestačí

Ve větvi v Gitu zůstávají oddělené hlavně změny v souborech. U databáze se podobný postup zavádí hůř. Databáze má historii zápisů, indexy, živá data, přístupová práva a často i provozní omezení.

V malém týmu sdílená testovací databáze chvíli funguje. Pak jeden člověk spustí migraci, druhý testuje formulář, automatické testy smažou data a agent do toho začne vytvářet vlastní scénáře. Chyba se pak neprojeví jen v jeho pracovním prostoru, ale v databázi, do které sahají i ostatní.

Chybějící část je samostatný stav dat. K pull requestu, testu nebo agentímu běhu se dá přidat databázová větev se stavem z určitého okamžiku. Agent v ní může spustit migraci, vytvořit testovací účty, změnit data nebo ověřit destruktivní dotaz. Nepovedený pokus se zahodí spolu s větví.

Databázová větev jako pracovní kopie stavu

Neon popisuje databázovou větev jako copy-on-write klon dat: nová větev nemusí fyzicky zkopírovat celou databázi, ale vychází ze stavu rodičovské větve a vlastní zápisy ukládá jako rozdíl. Podobně Xata popisuje model, ve kterém agent pracuje s vlastním PostgreSQL branchem místo sdílené databáze.

Samotná možnost vytvořit větev nestačí. Důležité je, kdy se větev používá a kdo ji smí používat. Agent nemá sahat do produkce, rizikové změny má spouštět ve vlastní větvi, migrace má ověřovat tamtéž a po skončení práce musí větev zmizet.

Kde se databázová větev hodí

Nejjednodušší použití je náhled pull requestu. Kód běží ve vlastní větvi, aplikace má vlastní adresu a databáze dostane vlastní stav. Reviewer pak nekliká na oddělenou aplikaci, která ve skutečnosti zapisuje do jedné společné testovací databáze.

Podobně fungují migrace. Agent nebo automatické testy vytvoří větev, spustí migraci, ověří základní scénáře a teprve potom změnu pošlou dál. Když migrace smaže špatný sloupec, poškodí jen dočasnou větev.

Třetí častý případ je reprodukce chyb. Některé chyby vznikají jen nad konkrétní kombinací dat. Lokální testovací data je nenapodobí. Větev z produkčně podobného stavu umožní chybu ověřit bez zásahu do produkce.

Větev databáze má provozní náklady

Dodavatelé databází u větvení často zdůrazňují, že větev nevzniká jako plná kopie dat. U velké databáze je to zásadní rozdíl. Kdyby každá větev znamenala kompletní kopii, většina týmů by u několika paralelních prostředí rychle narazila na čas i cenu.

Princip copy-on-write pomáhá hlavně tím, že nová větev může sdílet nezměněná data s rodičem a ukládat až rozdíly. To řeší okamžik vytvoření větve. Pro aktivní větev jsou ale pořád potřeba výpočetní prostředky, připojení, přístupové údaje, dohled a úklid.

Pokud v ní agent přepíše hodně dat, vytvoří nové indexy nebo spustí větší backfill, změny se musí někam uložit. A pokud se dočasné větve nemažou, postupně přibude další provozní zátěž. U větvení databáze proto nestačí řešit jen to, jak rychle větev vznikne. Stejně důležité je, kdo ji vytvořil, jak dlouho bude existovat a kdo k ní má přístup.

BranchBench: když větví není pár, ale stovky

Pro pull request, test migrace nebo reprodukci chyby většinou stačí jedna krátkodobá databázová větev. U AI agentů ale může vzniknout jiný typ práce: agent postupně zkouší více řešení, pro každé vytvoří vlastní stav databáze, výsledek vyhodnotí a nepoužité větve zahodí. V takové chvíli už nejde jen o pohodlí pro vývojáře, ale o výkon a náklady při opakovaném větvení.

Právě tohle zkoumá BranchBench, benchmark zveřejněný na arXivu 19. dubna 2026. Není to žebříček „nejlepší databáze pro agenty“. Autoři sledují smyčku branch-mutate-evaluate: vytvořit větev, změnit data nebo schéma, vyhodnotit výsledek a rozhodnout, jestli pokračovat, nebo větev zahodit.

Výsledek není jednoduchý vítěz. Některé systémy umí větve vytvářet rychle, ale při hlubších nebo složitějších větvích se jim zpomalují čtecí dotazy. Jiné drží dobrý výkon uvnitř větve, ale vytvoření nebo přepnutí větve trvá déle. Autoři v abstraktu uvádějí dvě různé metriky: u některých systémů až 5-4000× pomalejší čtení v hlubších větvích, u jiných 25-1500× vyšší latenci při vytváření nebo přepínání větví.

Pro běžný tým je důležitý hlavně rozdíl v měřítku. Databázová větev pro jeden pull request může být praktickým řešením už dnes. Agent, který vytváří stovky spekulativních stavů, zatím naráží na limity současných systémů i nákladů na jejich správu. DAPLab ve svém shrnutí k BranchBench proto píše, že dnešní databáze s podporou větví nejsou na takovou práci agentů připravené plošně.

Citlivá data se musí řešit předem

Výkon a cena nejsou jediné limity. Se samostatnou větví je menší riziko, že agent poškodí produkci, ale soukromí tím vyřešené není.

Pokud do větve zkopírujete produkční osobní údaje, pořád pracujete s produkčními osobními údaji. Jen v jiném prostředí. Izolace zápisů nenahrazuje anonymizaci ani omezený přístup.

Agent má dostat jen data, která opravdu potřebuje. Někdy stačí větev se schématem bez řádků. Jindy anonymizovaná kopie. Pokud se pracuje s daty podobnými produkci, měla by mít větev krátkou životnost, omezené přístupové údaje a dohled nad tím, kdo s ní pracoval.

Databáze není celý stav aplikace

Oddělená databáze nestačí, pokud agent mění i jiné části aplikace. Moderní web má stav také ve frontách, cache, souborech, úložišti objektů, relacích, indexech a externích službách. Když agent změní databázi, ale zároveň odešle e-mail, zapíše do fronty nebo upraví soubor v úložišti, samotná databázová větev nestačí.

Proto se objevují širší nápady typu StateFork, které chtějí agentům větvit celé pracovní prostředí. Pro běžné vývojářské použití je to zatím spíš připomínka než hotové doporučení. Databáze ale bývá první místo, kde se sdílený stav začne řešit v praxi.

Kde začít

Větvení databází nemá smysl zavádět jako velkou proměnu celého vývoje. Lepší je začít jedním konkrétním scénářem, kde sdílená databáze už dnes překáží.

Nejčistší kandidát je náhled pull requestu. Otevře se změna, vytvoří se databázová větev, spustí se migrace, náhledové nasazení dostane vlastní připojení a po začlenění nebo zavření změny se větev smaže.

Druhý dobrý kandidát jsou rizikové migrace. Agent nebo automatické testy si vytvoří větev, zkusí změnu, ověří základní scénáře a výsledek se použije jen jako kontrola před skutečným nasazením.

U agentů je opatrnost ještě důležitější. Nejdřív pravidla, potom oprávnění. Agent nemá dostat volnou ruku nad produkcí jen proto, že umí psát SQL. Má mít vlastní větev, omezená práva, krátkou životnost větve a jasné pravidlo, kdy musí člověk potvrdit destruktivní akci.

Větvení databází nevyřeší všechno. Přesto dává smysl se na něj dívat jako na chybějící díl izolace. V praxi už se běžně odděluje kód, buildy, testy i náhledová prostředí. Databázový stav ale často zůstává společný, a právě tam se při práci s agenty nejrychleji ukáže, že izolace není úplná.

Vlastní větev databáze proto není další módní doplněk k AI nástrojům. Je to způsob, jak agentovi vymezit pracovní prostor i tam, kde aplikace pracuje se stavem. Jakmile do něj patří reálnější data, migrace a oprávnění, nestačí řešit jen samotné vytvoření větve. Stejně důležité jsou přístupy, životnost větve, náklady a úklid po skončení práce.