Relační databáze jsou po desetiletí výchozím bodem pro většinu aplikací. Mají transakce, silné schéma, zralé nástroje a obrovskou základnu zkušených vývojářů. Jenže právě ta zralost svádí k tomu je použít i tam, kde jejich přednosti přestávají hrát roli. Jakmile narazíte na data, která se nevejdou do tabulek a cizích klíčů, začnete bojovat s nástrojem místo s problémem. Pokud hledáte alternativu a chcete vědět, co je NoSQL a kdy ho použít, je dobré nejdřív pochopit, kde relační model naráží.

Prvním signálem je extrémní objem zápisů bez potřeby složitých dotazů. Zvažte telemetrii ze senzorů, logy aplikací nebo kliknutí uživatelů. Data přicházejí v desítkách tisíc záznamů za sekundu a málokdy je zpětně spojujete do osmi tabulek. Relační databáze takový provoz zvládne, ale za cenu vertikálního škálování, dražšího hardwaru a neustálého ladění indexů. Když se zápis stane úzkým hrdlem a čtení je jednoduché, sloupcová nebo dokumentová úložiště bývají přirozenější volbou.

Druhým případem je silně proměnlivá struktura. Produktový katalog, kde každá kategorie má jiné atributy, konfigurace zařízení nebo obsah redakčního systému s desítkami typů článků. V relačním modelu to znamená buď tabulku s desítkami prázdných sloupců, nebo EAV schéma, které je pomalé a nečitelné. Dokumentová databáze uloží každý záznam jako samostatný objekt a vývojář přestane řešit migrace při každé změně pole. Není to univerzální výhra, ale pro tento typ dat odpadá spousta zbytečné práce.

Posledním varovným signálem je potřeba horizontálního škálování napříč regiony. Relační databáze se distribuuje obtížně, protože transakce a konzistence drží data pohromadě. Když aplikace musí běžet v Tokiu, Frankfurtu i Virginii a každý region má obsluhovat své uživatele, centralizovaná instance přestává stačit. Některé NoSQL systémy jsou navržené přesně pro tento scénář, jiné obětují konzistenci. Volba pak není o módě, ale o tom, které vlastnosti jste ochotni vyměnit za dostupnost a latenci.