Berkeley DB obsługuje wielu użytkowników pracujących jednocześnie. Pozwala na nakładanie blokad na niemal dowolnym poziomie. Zastosowanie innego niż w SQL stylu API sprawia, że system nawet przy dużym obciążeniu może działać efektywnie.

Motor Berkeley DB obsługuje transakcje. Programista może określać najbardziej efektywny sposób przechowywania danych, np. w b-drzewie lub w tablicy hashującej. Berkeley DB może być osadzony w aplikacji, ale może też być "osobnym" serwerem - obsługuje równoważenie obciążeń, replikację itp. Zawiera mechanizmy obsługujące dzieloną pamięć podręczną.

Warto podkreślić, że mechanizm Berkeley DB jest wykorzystywany, m.in. do zapisywania tabel w MySQL. Motor ten jest także stosowany w wielu implementacjach protokołu LDAP.

Ciekawym pomysłem jest baza danych SQLLite. Jest to motor RDBMS, który można połączyć z własną aplikacją. Motor realizuje duży podzbiór poleceń SQL, ale - co najważniejsze - jego kod źródłowy składa się z kilku modułów: zależnego od systemu operacyjnego modułu I/O, podstawowego modułu obsługującego maszynę wirtualną, indeksy i pamięć podręczną.

Główna część SQLite to plik dla parsera LEMON LALR(1), który definiuje zbiór poleceń SQL rozumianych przez określony motor. Programista, modyfikując ten plik, może łatwo rozszerzać czy ograniczać możliwości motoru, manipulując równocześnie jego wielkością.

W wielu przypadkach wygodnym formatem zapisu danych okazuje się XML. Parser XML można także wykorzystać jako narzędzie do wyszukiwania informacji, zwłaszcza gdy np. trzeba przetworzyć dane w warstwie środkowej aplikacji czy tymczasowo zapisać zbiór rekordów do przeglądania po stronie klienta.

Dzięki tego typu rozwiązaniom programista zapisuje dane w sposób właściwy dla swojego stylu programowania, bez sztucznej konwersji na inny model danych. Z zastosowaniem tej metody można obsługiwać jedynie stosunkowo niewielkie zbiory danych.

Motor bazodanowy może działać na innym komputerze niż aplikacja kliencka czy wręcz można go przenieść na bardziej wydajny komputer, który obsłuży większą liczbę danych. Jednocześnie model relacyjny wymusza trochę inny sposób patrzenia na informacje i częściowo zabezpiecza przed chęcią przeglądania po stronie klienta (czy warstwy środkowej) tabel z milionami transakcji.

Mówiąc o danych relacyjnych, warto pamiętać, że mimo, iż teoretycznie język zapytań i interfejsy dostępu do bazy danych są w dużym stopniu uniwersalne, wybór bazy narzuca określone rozwiązania w aplikacji. Bazy danych typu PostgreSQL, MySQL czy nierelacyj- na Berkeley DB sprawiają, że migracja na "duży" serwer jest dosyć skomplikowana. Gdy programista ma za zadanie przygotowanie "małej" aplikacji, która później ma być przeniesiona na duży serwer, warto przyjrzeć się ofercie uproszczonych baz danych Microsoftu, Oracle'a czy Sybase. Zwykle są to roz-wiązania bardzo tanie lub bezpłatne, a ponadto niemal w 100% zgodne z pełnymi wersjami systemów.