Rozhodnutí mezi relační databází a alternativami není otázkou módnosti, ale konkrétních požadavků na data a přístupové vzory. Relační model s SQL nabízí něco, co se v produkci jen těžko nahrazuje: silné transakce, deklarativní dotazy a jasně definované schéma. Pokud aplikace stojí na penězích, inventáři nebo oprávněních, jsou to právě tyto vlastnosti, které drží data v konzistentním stavu i při souběžných zápisech. Dokumentové, klíč-hodnota nebo grafové databáze řeší jiné problémy – flexibilitu schématu, horizontální škálování nebo vztahy s mnoha stupni. Nejde tedy o souboj, ale o to, který nástroj sedí na daný typ zátěže.

Kompromis začíná u dotazů. SQL umí agregace, spojení a analytické funkce bez předchozí přípravy, kdežto NoSQL často vyžaduje předem navržené přístupové cesty a denormalizaci. Jakmile se ptáte na data jinak, než jste předpokládali, může být přepis dotazu drahý. Na druhou stranu relační databáze špatně snáší extrémní zápisovou zátěž nebo schéma, které se mění každý týden. Pomůže přehled, co je NoSQL a kdy ho použít, protože ukazuje, že volba není černobílá. V praxi se často vyplatí zůstat u SQL pro transakční jádro a doplnit ho specializovaným úložištěm pro vyhledávání, cache nebo časové řady.

Provozní náklady bývají podceňovaným faktorem. Relační databáze mají zralé zálohování, replikaci, monitoring a nástroje, které zná každý nový vývojář. Alternativy sice slibují jednodušší škálování, ale přinášejí vlastní režii: správa clusteru, řešení konfliktů při zápisu, složitější migrace. Pokud tým nemá s danou technologií zkušenosti, může být přechod dražší než vertikální škálování stávajícího SQL serveru. Rozhodnutí by mělo vycházet z měření, ne z předpokladů. Zůstat u relační databáze je rozumné, dokud konkrétní úzké místo neospravedlní změnu.