Każdy z nas jest prawdopodobnie znakomicie obeznany w relacyjnych bazach danych. Kilka popularnych silników zdominowało rynek. W małych projektach bazy relacyjne wydają się niezastąpione. Główną zaletą jest łatwość projektowania baz oraz wysoka spójność danych. Jak sprawa wygląda w naprawdę w dużych, rozproszonych projektach? Gdy potrzebujemy “rozproszyć” dane między różne komputery, zaczynają się problemy. W jaki sposób zachować spójność i integralność danych pomiędzy różnymi komputerami? Co zrobić ze słownikami? Replikować na każdym z komputerów?Jeśli spojrzymy na graf zaprojektowanej relacyjnej bazy danych,  z pewnością ciężko będzie nam rozdzielić różne części danych pomiędzy komputery – okaże się, że z każdego węzła jesteśmy w stanie przejść na dowolny drugi (to trochę pesymistyczny przypadek ale w praktyce dużo tabel jest powiązanych ze sobą).

W tym przypadku polecane są bazy nierelacyjne. W Internecie szukając informacji o tym warto wpisać w wyszukiwarce NoSQL. W przypadku baz nierelacyjnych nie mamy żadnych powiązań między tabelami (nie ma czegoś takiego jak JOIN). Umożliwia to łatwe skalowanie horyzontalne. Praktycznym rozwiązaniem opartym na NoSQL jest np. Azure Tables. Warto wspomnieć, że RDBMS  zwykle nadają się do małych baz z częstymi operacjami Read\Write lub dużych z operacjami odczytu (zapis jest wolny – potrzeba przebudowania indeksów). Ważną cechą odróżniającą relacyjne silniki jest brak ustalonego schematu danych .