Aplikacja FirMAG korzysta z bazy danych typu SQL. Do komunikacji z bazą danych wykorzystuje technologię klient/serwer
polegającą na wysyłaniu i odbieraniu zapytań i danych pomiędzy aplikacją i serwerem.
Taki model korzystania z bazy danych i umieszczenie serwera SQL i bazy danych na dedykowanym serwerze, powoduje
całkowitą izolację powłoki klienta od powłoki serwera.
Serwer bazy danych ma zaimplementowaną obsługę transakcji, co oznacza to, że aplikacja rozpoczynając jakiekolwiek zmiany zaznacza na serwerze, że rozpoczyna transakcję, następnie próbuje wykonać ciąg zmian i wysyła do serwera rozkaz zakończenia transakcji. Jeżeli pomiędzy rozpoczęciem, a zakończeniem transakcji wystąpi jakikolwiek błąd (np. nagłe wyłączenie stacji roboczej klienta), serwer nie otrzymawszy rozkazu zatwierdzenia, końca transakcji, po prostu wycofuje wszystkie zmiany od momentu ich rozpoczęcia.
Jednocześnie aplikacja kliencka nie ma bezpośredniego dostępu do odczytywanych danych (np. lista klientów jest tylko kopią danych wysłaną do aplikacji na jej żądanie).
Ten sposób pracy zapewnia wysoki stopień odporności na uszodzenia danych, spowodowane przez nieprzewidywalne czynniki, występujące po stronie klienta.
Serwer bazy danych zapewnia również obsługę kontroli spójności danych na poziomie bazy danych, poprzez wykorzystanie kluczy referencyjnych, jak również na poziomie oprogramowania bazy danych, znajdującego się w bazie danych. Mechanizmy takie zostały oczywiście wykorzystane przez producenta aplikacji. Powodem wprowadzenia tak dużej kontoli integralności danych na poziomie bazy danych, było założenie projektu, mówiące o pracy aplikacji na wielu stanowiskach klienckich. Niemożliwe praktycznie byłoby sprawdzenie integralności danych innym sposobem niż kontrola ich w miejscu składowania, czyli w bazie danych i za pomocą innego narzędzia niż serwer bazodanowy. Przykładem takiego wykorzystania mechanizmów serwera jest np. kontrola stanów magazynowych, czy sprawdzanie on-line zależności pomiędzy różnymi typami danych rozrzuconymi w różnych miejscach bazy danych.
Ujemną stroną takiego rozwiązania jest nieznaczne spowolnienie aktualizacji danych, spowodowane właśnie przez kontrolę integralności wymuszaną przez serwer bazy.
Jednak patrząc na kierunki rozwoju oraz ceny sprzętu komputerowego, nic nie stoi na przeszkodzie, aby serwer bazy danych pracował na wieloprocesorowej maszynie, pozwalającej na współbieżne wykonywanie wielu operacji na kiku procesorach i wyposazonej w dużą ilość pamięci RAM, pozwalającej serwerowi bazodanowemu na utworzenie cache dla danych, co z kolei minimalizuje ilość odczytów dysku twardego, będącego najwolniejszym elementem całego systemu serwera.
Do użytkownika należy jedynie dbanie o systematyczne wykonywanie kopii bezpieczeństwa bazy danych, tak aby zapobiec utracie danych w skutek awarii sprzętowej serwera lub innych nieprzwidzianych okoliczności.

Należy pamiętać również o tym, iż serwer bazodanowy wykorzystuje katalog (folder) TEMP systemu.
Dla Linux jest to zawsze katalog /tmp .
Rozmiar takiego katalogu musi pozwolić serwerwi na przygotowanie pliku z odpowiedzią dla klienta oraz plików tymczasowych, wykorzystywanych podczas pracy serwera.

Uwagi dodatkowe dotyczące bazy danych pracującej pod kontrolą systemu Linux:
Serwer bazodanowy musi posiadać odpowiednie prawa dostępu do katalogu i plików baz danych.
Domyślnie serwer Firebird pracuje na koncie użytkonika firebird.
Jeżeli dane przechowujemy w /var/db, to prawa należy dodać następujące:
chown firebird.firebird /var/db
chmod 0644 firebird /var/db
WYnikiem nadania takich uprawnień będzie zezwolenie na zapis i odczyt dla grupy i użytkownika firebird. Każdy plik bazy danych znajdujący się w tym katalogu powinien mieć również prawo zapisu odczytu dla użytkownika firebird. Dodatkowo aplikacja używa biblioteki dynamicznej libdbutil.dll.so , którą należy zainstalować w :
/opt/firebird/UDF/libdbutil.dll.so .
Nadanie praw wyglada następująco:
chown root.root /opt/firebird/UDF/libdbutil.dll.so
chmod 0555 /opt/firebird/UDF/libdbutil.dll.so