Relační databáze jsou skvělou volbou pro většinu aplikací. Mají jasné schéma, silné transakce a díky SQL se v nich snadno dotazuje. Jenže jakmile aplikace roste, začnou se objevovat situace, kdy přestávají stačit. Prvním signálem bývá rostoucí latence zápisů, kdy i jednoduchý insert trvá déle, než by měl, a databáze tráví čas zamykáním a čekáním na volné prostředky. Druhým je horizontální škálování. Relační databáze se sice dají škálovat vertikálně – přidáním CPU, RAM nebo rychlejších disků – ale tenhle přístup má strop. Jakmile ho dosáhnete, musíte řešit replikaci, sharding nebo obojí, což s sebou nese spoustu ruční práce a rizika nekonzistence.

Typickým úzkým hrdlem je také složitost dotazů. Čím více JOINů a agregací aplikace potřebuje, tím více zatěžuje databázi. U velkých tabulek se pak i dobře napsaný dotaz může stát pomalým, protože optimalizátor nemá dost prostoru. Podobně je to s transakcemi, které drží zámky příliš dlouho. Pokud vaše aplikace zapisuje hodně často a potřebuje nízkou latenci, relační model vás začne brzdit. V takovém okamžiku stojí za to zvážit alternativy, ať už jde o NoSQL databáze, key-value úložiště, dokumentové databáze nebo širokosloupcové systémy. Než se ale do nějaké pustíte, projděte si praktického průvodce NoSQL, který vám pomůže rozhodnout, jestli je to pro váš případ vůbec vhodné.

NoSQL databáze nejsou univerzálním řešením. Často obětují silnou konzistenci ve prospěch dostupnosti a partition tolerance, což se hodí u distribuovaných systémů, ale ne u aplikací, kde záleží na každé transakci. Dokumentové databáze jako MongoDB nebo Couchbase zvládají dobře flexibilní schéma a rychlé čtení, ale složitější vztahy v nich modelujete obtížněji. Key-value úložiště jako Redis nebo DynamoDB jsou extrémně rychlé pro jednoduché operace, ale neumí dotazy nad více atributy. Širokosloupcové databáze jako Cassandra nebo ScyllaDB zase vynikají v zápisu a škálování, ale vyžadují pečlivý návrh klíčů. Volba tedy závisí na tom, co je pro vás prioritou – zda konzistence, latence, propustnost, nebo jednoduchost vývoje.

Než se rozhodnete relační databázi opustit, zkuste nejdřív vytěžit maximum z toho, co máte. Často stačí přidat cache, optimalizovat indexy, rozdělit tabulky nebo použít read repliky. Teprve když ani to nepomůže, má smysl uvažovat o změně. Přechod na jiný typ databáze je totiž nákladný nejen finančně, ale i z hlediska času a rizika. Pokud ale narazíte na skutečné limity relačního modelu, alternativy vám mohou otevřít cestu k řešení, které bude škálovatelnější a levnější. Klíčem je porozumět svým datům a tomu, jak je aplikace používá.