SmartRMM – Dlaczego wybraliśmy SQLite zamiast PostgreSQL? Architektura i Wydajność do 1 500 stacji

W świecie systemów zarządzania IT (RMM) i oprogramowania B2B jednym z pierwszych pytań zadawanych przez architektów i potencjalnych nabywców jest:

„Na jakiej bazie danych działa SmartRMM? Czy to PostgreSQL? Czy SQLite nie będzie za wolny pod obciążeniem?”

To pytanie jest w pełni zrozumiałe. Wśród inżynierów przez lata utrwalił się stereotyp, że „SQLite nadaje się tylko do prototypów lub aplikacji mobilnych, a prawdziwy system serwerowy musi mieć PostgreSQL lub MySQL”.

Wybór silnika bazy danych w SmartRMM nie był przypadkiem ani drogą na skróty. Był świadomą, głęboko przemyślaną decyzją inżynierską podyktowaną realiami operacyjnymi firm MSP, dążeniem do wyeliminowania przestojów (Zero-Maintenance) oraz bezprecedensową szybkością odczytu danych w pamięci procesu.

Kto naprawdę korzysta z SQLite w systemach o krytycznym znaczeniu?

Zanim przejdziemy do liczb, warto rozprawić się z mitem „zabawkowego” charakteru SQLite:

Airbus A350: Oprogramowanie pokładowe awioniki pasażerskiej Airbusa korzysta z certyfikowanego silnika SQLite. Awaria bazy w locie nie wchodzi w grę.
Apple iOS & macOS: Każdy iPhone, iPad i Mac przechowuje zdjęcia, kontakty, wiadomości i historię systemową w tysiącach baz SQLite działających jednocześnie.
Przeglądarki Google Chrome, Edge, Safari i Firefox: Cała historia, ciasteczka, depozyty kluczy i indeksy przeglądarek obsługujących miliardy zapytań na sekundę są oparte na SQLite.
Expensify: Globalna platforma rozliczeń finansowych przetwarzająca miliardy dolarów transakcji rocznie oparła swój silnik Bedrock bezpośrednio na SQLite.
Rządy i wojsko: SQLite jest jedną z nielicznych baz danych dopuszczonych przez Bibliotekę Kongresu USA jako oficjalny standard długoterminowej archiwizacji cyfrowej.

Jak zauważył twórca SQLite, dr Richard Hipp: „SQLite nie powstał po to, aby zastąpić PostgreSQL w klastrach bankowych. Powstał po to, aby zastąpić zawodne pliki płaskie i zaoferować najszybszy możliwy dostęp do danych w architekturze in-process.”

Matematyka Obciążenia Platformy RMM

Aby ocenić, czy baza podoła wyzwaniu, należy przeanalizować charakterystykę ruchu sieciowego generowanego przez agentów stacji roboczych:

Każdy agent SmartRMM wysyła pakiet telemetryczny (heartbeat) co 60 sekund.
Pakiet zawiera stan procesora, pamięci RAM, zajętość dysków, status antywirusa i kopii zapasowej.

Liczba Monitorowanych Stacji	Częstotliwość Heartbeatu	Średnia Liczba Zapisów / s	Obciążenie Silnika SQLite WAL
100 stacji	co 60 s	1,6 zapisu / s	< 0,1% przepustowości
250 stacji	co 60 s	4,1 zapisu / s	~0,2% przepustowości
500 stacji	co 60 s	8,3 zapisu / s	~0,4% przepustowości
1 000 stacji	co 60 s	16,6 zapisu / s	~0,8% przepustowości
2 500 stacji	co 60 s	41,6 zapisu / s	~1,8% przepustowości

Wniosek inżynieryjny:

Współczesny dysk NVMe w trybie WAL (Write-Ahead Logging) przyjmuje bez trudu od 2 000 do 4 000 transakcji zapisu na sekundę. Ruch generowany przez 1 000 stacji roboczych (16,6 zapisu/s) stanowi zaledwie ułamek procenta fizycznych możliwości bazy!

Twarde Dane: Oficjalny Test Obciążeniowy SmartRMM (Benchmark)

Aby nie opierać się wyłącznie na teorii, przeprowadziliśmy syntetyczny test wydajnościowy symulujący środowisko produkcyjne dużej firmy MSP:

1 000 zarejestrowanych komputerów (Windows 10, 11, Windows Server),
500 000 rekordów historii zdarzeń telemetrycznych (event_logs),
Równoległe zapytania pulpitu nawigacyjnego, odpytywanie historii urządzeń oraz ciągłe serie heartbeatów.

Badana Operacja w Systemie	Objętość Danych	Zmierzony Czas Odpowiedzi	Interpretacja Biznesowa
Ładowanie Pulpitu Głównego (`SELECT 50`)	1 000 stacji w tabeli	0,192 ms (mniej niż 1/5 ms!)	Błyskawiczne odświeżanie interfejsu bez jakichkolwiek opóźnień.
Zapis Heartbeatu Stacji (`UPDATE`)	Ciągły strumień telemetrii	0,110 ms per stacja	Baza może przyjąć ponad 9 000 heartbeatów na sekundę.
Wyszukanie Historii Konkretnego Urządzenia	500 000 wierszy w tabeli	1,799 ms	Pobranie 100 ostatnich zdarzeń stacji z pół miliona wpisów trwa poniżej 2 ms.
Masowy Zapis Zdarzeń (`Bulk INSERT`)	500 000 zdarzeń	23 239 wierszy / sekundę	Całkowity czas importu pół miliona wpisów: zaledwie 21,5 sekundy.
Rozmiar Bazy na Dysku	1 000 maszyn + 500k zdarzeń	90,86 MB	Pół miliona zdarzeń mieści się w zaledwie 90 MB przestrzeni dyskowej.

Żaden użytkownik, technik ani administrator nie jest w stanie dostrzec różnicy między czasem odpowiedzi rzędu 0,19 ms a 1,8 ms — z perspektywy człowieka interfejs działa natychmiastowo.

Dlaczego do 1 500 stacji SQLite jest SZYBSZY od PostgreSQL?

Dla inżynierów niezaznajomionych ze specyfiką SQLite ten fakt bywa zaskoczeniem: w architekturze pojedynczego serwera SQLite jest zauważalnie szybszy od PostgreSQL. Wynika to z praw fizyki sieciowej:

Brak narzutu sieciowego (Zero Socket Overhead):
PostgreSQL to osobny proces systemowy. Każde zapytanie musi zostać zserializowane, wysłane przez gniazdo TCP (nawet na localhost), odebrane przez serwer bazy, sparsowane i odesłane. Sam ten proces dokłada 1 do 3 ms czystego opóźnienia.
SQLite to biblioteka skompilowana wprost do procesu serwera FastAPI. Dostęp do bazy następuje przez bezpośredni wskaźnik w pamięci RAM (0,05 ms).
Magia Trybu WAL (Write-Ahead Logging):
W tradycyjnym trybie bazy plikowe blokowały całą bazę na czas zapisu. W SmartRMM baza działa w trybie WAL:
- Odczytujący nigdy nie blokują piszących.
- Piszący nigdy nie blokują odczytujących.
- 50 techników może jednocześnie generować raporty i przeglądać urządzenia, podczas gdy setki agentów w tle zapisują telemetrię.

Korzyści Biznesowe dla Operatora MSP (Zero-Maintenance)

Dla firmy IT lub działu helpdesk utrzymanie zewnętrznej bazy danych wiąże się z ukrytymi kosztami:

Wdrożenie w 60 sekund (Single-Container Appliance): SmartRMM uruchamia się pojedynczym poleceniem docker run. Użytkownik nie musi instalować kontenera PostgreSQL, tworzyć ról, zarządzać uprawnieniami pg_hba.conf ani martwić się wersjami bibliotek.
Kopia zapasowa bez przestojów: Cała baza to jeden, spójny plik na dysku. Kopia bezpieczeństwa sprowadza się do skopiowania pliku lub wykonania polecenia VACUUM INTO. Przywrócenie serwera po awarii sprzętowej polega na wklejeniu tego jednego pliku do nowego kontenera.
Znikome zużycie zasobów (RAM & CPU): PostgreSQL potrzebuje dedykowanych buforów pamięci (shared_buffers, work_mem) rzędu 1–2 GB RAM, aby działać płynnie. SmartRMM z SQLite zużywa w stanie spoczynku zaledwie kilkadziesiąt megabajtów pamięci, co pozwala uruchomić go nawet na najtańszym VPS-ie za 20 zł miesięcznie lub na lokalnym serwerze NAS (QNAP / Synology).

Kiedy pojawia się potrzeba migracji na PostgreSQL? (Ścieżka Enterprise)

Jako odpowiedzialni inżynierowie nie twierdzimy, że SQLite rozwiąże każdy problem na świecie. Istnieją konkretne scenariusze, w których migracja do PostgreSQL jest uzasadniona i zaplanowana w naszej architekturze:

Flota powyżej 3 000 – 5 000 stacji roboczych wysyłających telemetrię o wysokiej częstotliwości (ponad 80 zapisów na sekundę).
Wymóg klastra High-Availability Active-Active: gdy organizacja wymaga uruchomienia 3 niezależnych serwerów FastAPI za wspólnym Load Balancerem (Nginx / HAProxy). Wtedy centralna baza PostgreSQL jest naturalnym punktem styku.

Dlaczego przejście na PostgreSQL w SmartRMM jest bezproblemowe?

Backend SmartRMM został napisany w oparciu o czysty, standardowy dialekt ANSI SQL. Tabele, relacje, indeksy oraz zapytania w warstwie bazy danych nie korzystają z egzotycznych mechanizmów specyficznych wyłącznie dla SQLite. W razie potrzeby wdrożenia korporacyjnego podpięcie sterownika PostgreSQL (np. asyncpg) to kwestia zaledwie kilku dni roboczych.

Podsumowanie dla Inwestora, CTO i Szefa IT

Wybór SQLite w SmartRMM to świadoma inżynieria zorientowana na cel:

Dla 99% instalacji (od 10 do 1 500 stacji): SQLite zapewnia bezkonkurencyjną szybkość (odczyt w 0,19 ms), zerowe koszty administracji, brak awarii sieciowych i banalnie prosty backup.
Wydajność potwierdzona testem: Pół miliona wpisów w historii zajmuje 90 MB i przeszukuje się w 1,8 milisekundy.
Bezpieczeństwo na przyszłość: Architektura kodu gwarantuje prostą ścieżkę migracji do PostgreSQL, gdy tylko skala działalności organizacji przekroczy próg instalacji klastrowej.

SmartRMM dostarcza system, który działa od razu po wyjęciu z pudełka, nie wymaga etatu administratora baz danych (DBA) i działa błyskawicznie każdego dnia.