Darmowy klaster MongoDB Atlas kończy się na pół gigabajta danych i stu operacjach na sekundę, czyli mniej więcej w tym samym momencie, w którym projekt przestaje być zabawką, a wtedy zestawienie MongoDB vs PostgreSQL przestaje być kwestią wygody i zaczyna kosztować pieniądze. Obie bazy zapiszą dokument JSON. Obie wytrzymają obciążenie typowej aplikacji. Różnią się tym, co robią z danymi, których kształt zmienia się w trakcie życia projektu.
Pytanie o kształt danych, od którego zależy cała reszta
Zanim porównasz wydajność, odpowiedz sobie na jedno pytanie: czy twoje dane mają stały kształt.
Jeśli każdy rekord ma te same pola, a relacje między nimi są przewidywalne, model relacyjny opisuje to dokładniej. Zamówienie ma klienta, klient ma adres, produkt ma cenę. Baza pilnuje tych związków sama, bez kodu po twojej stronie.
Jeśli kształt rekordu zmienia się między klientami, między wersjami produktu albo między źródłami, model dokumentowy zdejmuje z ciebie sporo pracy. Katalog sprzętu, w którym laptop ma inne pola niż lodówka. Zdarzenia z czujników, gdzie każdy producent wysyła co innego. Odpowiedzi z zewnętrznych interfejsów, których nie kontrolujesz.
Ten wybór wygląda w pierwszym tygodniu na techniczny szczegół. Po roku jest fundamentem, którego nie wymienisz bez przepisania warstwy dostępu do danych.
Kiedy MongoDB jest właściwym wyborem
Najmocniejszy argument za MongoDB brzmi prosto: dokument, który zapisujesz, wygląda tak samo jak obiekt w kodzie. Znika warstwa tłumacząca jedno na drugie, a wraz z nią klasa błędów.
Drugi argument to tempo na starcie. MongoDB nie wymaga z góry sztywnego schematu tabel, więc model danych rozwijasz stopniowo i część zmian wprowadzasz bez klasycznych migracji. Strukturę dokumentów i tak trzeba zaprojektować pod sposób ich odczytu, ale przy pierwszej wersji produktu ta swoboda realnie skraca pracę.
Trzeci: dane zagnieżdżone czytane w całości. Jeśli aplikacja zawsze pobiera cały dokument razem z jego podelementami, MongoDB robi to jednym odczytem, bez złączeń.
Czwarty: rozpraszanie danych na wiele serwerów jest w MongoDB wbudowane od dawna i dobrze opisane. Przy zbiorach, które nie mieszczą się na jednej maszynie, to skraca drogę.
Według release notes MongoDB aktualna linia stabilna serwera to 8.3, a wcześniejsze wydania stabilne to 8.0 i 7.0. Darmowy klaster w Atlasie stoi na wersji 8.0 i nie da się jej samodzielnie podnieść.
Kiedy PostgreSQL wygrywa, mimo że dane wyglądają na dokumentowe
PostgreSQL wygrywa wtedy, gdy większość danych ma stałą strukturę, a nieregularne pola są dodatkiem do niej.
Silnik od lat ma typ JSONB, czyli binarny zapis dokumentu JSON z indeksowaniem i zapytaniami po polach w środku. W praktyce nieregularne dane trzymasz w jednej kolumnie. Obok nich, w tej samej tabeli, stoją zwykłe kolumny z twardymi więzami.
Ten układ obsługuje przypadek, który ludzie opisują jako “moje dane są dokumentowe”: rdzeń danych ma stały kształt, a nieregularne pola są dodatkiem i workiem na wyjątki. Mieszany model obsługuje jedno i drugie w jednym silniku.
Drugi powód: raporty. Prędzej czy później ktoś poprosi o zestawienie sprzedaży w podziale na miesiąc i kanał. W bazie relacyjnej to zapytanie na kilka linijek. W bazie dokumentowej to potok agregacji, który trzeba napisać, przetestować i utrzymać.
Trzeci: jedna baza zamiast dwóch. PostgreSQL obsłuży dokumenty, wektory przez rozszerzenie pgvector i dane przestrzenne przez PostGIS. Znika drugi silnik, drugi zestaw kopii zapasowych i druga wiedza do utrzymania w zespole. Jeśli rozważasz jeszcze inne silniki relacyjne, zestawiliśmy osobno PostgreSQL z MySQL, a przy małych projektach lokalnych warto sprawdzić SQLite kontra PostgreSQL.
Transakcje i spójność, czyli miejsce, gdzie łatwo się pomylić
Powtarzane od lat zdanie “MongoDB nie ma transakcji” jest nieprawdziwe. Wielodokumentowe transakcje ACID, czyli operacje wykonywane w całości albo wycofywane, działają na zestawach replik od wersji 4.0, a na klastrach rozproszonych od 4.2.
Ciekawsze jest to, co pisze o nich dokumentacja producenta. Transakcja rozproszona kosztuje w większości przypadków więcej niż zapis pojedynczego dokumentu. Jej dostępność nie powinna zastępować dobrze zaprojektowanego schematu. Producent sam kieruje użytkownika z powrotem w stronę modelu, w którym powiązane dane siedzą w jednym dokumencie.
Wniosek praktyczny jest taki. Jeśli twoja domena z natury wymaga operacji obejmujących wiele niezależnych bytów naraz, czyli przelewy, stany magazynowe czy rezerwacje, baza relacyjna daje ci to zachowanie jako stan domyślny. W MongoDB dostaniesz to samo, ale jako świadomą decyzję z kosztem, który trzeba rozumieć.
Co w każdej z tych baz trzeba potem utrzymywać
W PostgreSQL trzeba pilnować głównie sprzątania starych wierszy i liczby połączeń, a w MongoDB klucza odłamka oraz pamięci. Porównania kończą się zwykle na funkcjach, a praca zaczyna się po wdrożeniu.
W PostgreSQL pierwszym z nich jest sprzątanie starych wersji wierszy. Silnik zostawia je w tabeli, a usuwa proces autovacuum. Przy dużej liczbie aktualizacji trzeba go obserwować, bo zaniedbany potrafi rozdąć tabelę i spowolnić zapytania. Drugie miejsce to połączenia. Każde z nich jest osobnym procesem, więc przy aplikacji otwierającej setki połączeń dokłada się pośrednika, na przykład PgBouncera.
W MongoDB kluczową decyzją jest klucz odłamka, czyli pole, według którego dane rozjeżdżają się na serwery. Dobry klucz rozkłada ruch równo. Zły skupia zapisy na jednym serwerze i cała obietnica skalowania przestaje działać. Zmiana tej decyzji to operacja na całej kolekcji, więc warto ją przemyśleć przed wdrożeniem, a nie po. Drugie miejsce to pamięć. Silnik działa najlepiej, gdy zbiór aktywnie używanych danych mieści się w pamięci operacyjnej serwera, więc rachunek za maszynę rośnie razem z danymi.
Żadna z tych rzeczy nie przesądza wyboru. Obie warto znać wcześniej, bo to one zajmują czas zespołu w drugim roku projektu.
Licencja SSPL, czyli różnica, o której warto wiedzieć wcześniej
Serwer MongoDB Community jest od 16 października 2018 wydawany na Server Side Public License, w skrócie SSPL.
Sedno tej licencji siedzi w sekcji trzynastej. Jeżeli udostępniasz funkcjonalność programu osobom trzecim jako usługę, masz obowiązek opublikować kod źródłowy całej tej usługi, łącznie z narzędziami do zarządzania, monitorowania, kopii zapasowych i hostingu.
Dla firmy, która używa MongoDB wyłącznie jako zaplecza własnej aplikacji, ten zapis zwykle nie ma zastosowania. Aplikacja webowa z bazą w środku nie jest oferowaniem MongoDB jako usługi. Sekcja celuje w dostawców chmury, którzy sprzedawali zarządzanego MongoDB, nie oddając nic w zamian.
Warto jednak wiedzieć o dwóch konsekwencjach. SSPL nie uzyskała zatwierdzenia Open Source Initiative, a MongoDB wycofało ją z procesu oceny w 2019 roku. Zmiana licencji sprawiła też, że Fedora usunęła pakiety serwera MongoDB, a Debian zrezygnował z dystrybucji nowszych wydań i ostatecznie usunął pakiet, więc instalacja idzie z repozytorium producenta. PostgreSQL nie ma żadnego odpowiednika tego problemu, bo jego licencja jest zatwierdzona przez OSI i projekt deklaruje, że jej nie zmieni.
Pierwsza Misja AI · Kodożercy
Używasz AI codziennie, ale czy robisz to dobrze?
Kurs Pierwsza Misja AI pokaże Ci techniki promptowania, które naprawdę działają. Praktyczne ćwiczenia na żywym modelu, gamifikacja i certyfikat.
Sprawdź program kursu →
Co ten wybór kosztuje po roku
Rachunek za decyzję z pierwszego tygodnia przychodzi później i ma trzy pozycje.
Koszt usługi zarządzanej
Darmowy klaster Atlas ma udokumentowane limity: pół gigabajta danych, pięćset połączeń, sto operacji na sekundę, jeden darmowy klaster na projekt oraz dziesięć gigabajtów transferu w każdą stronę w oknie siedmiu dni. Klaster bez żadnego połączenia przez trzydzieści dni zostaje uśpiony. Przekroczenie limitu operacji albo transferu ogranicza przepustowość, a nie przenosi cię automatycznie na płatny plan. Miejsce na dane jest twarde, więc darmowy plan traktuj jak środowisko do nauki, a nie jak start produkcyjny. PostgreSQL ma darmowe warianty u części dostawców chmury i na własnym serwerze bez limitu, za to z kosztem utrzymania po twojej stronie.
Koszt wiedzy w zespole
SQL jest szerzej rozpowszechniony wśród programistów i analityków. Potok agregacji MongoDB zna znacznie węższa grupa. Przy rekrutacji i przy zastępstwie w trakcie urlopu ta różnica bywa odczuwalna.
Koszt zmiany zdania
Przejście z MongoDB na PostgreSQL to osobny projekt: trzeba zaprojektować schemat, przenieść dane i przepisać zapytania. Droga w drugą stronę jest podobnie kosztowna. Decyzja o silniku ma ten sam ciężar co wybór platformy dla repozytorium kodu: podejmujesz ją w godzinę, a żyjesz z nią latami.
{ aplikacje webowe }Masz pomysł na aplikację? Najpierw go zobacz
Zanim zainwestujesz w pełny system, przygotujemy klikalny prototyp, który pokażesz zespołowi albo klientom. Potem budujemy aplikację webową, która rośnie razem z firmą.
Najczęstsze pytania
Czy MongoDB jest szybszy od PostgreSQL?
Przy odczycie całego dokumentu po identyfikatorze MongoDB jest bardzo szybki, bo nie musi składać danych z kilku tabel. Przy zapytaniach łączących dane z wielu zbiorów i przy agregacjach przewagę zwykle ma PostgreSQL. Porównania z internetu mierzą cudzy schemat na cudzym sprzęcie, więc jedyny wiarygodny test to twoje własne zapytania na twoich danych.
Czy PostgreSQL obsłuży dane w formacie JSON?
Tak, przez typ JSONB, który przechowuje dokument w postaci binarnej i pozwala indeksować oraz odpytywać pola w jego wnętrzu. W jednej tabeli możesz mieć kolumny o sztywnym kształcie obok kolumny z dokumentem. Dla wielu projektów to wystarcza, żeby w ogóle nie dokładać drugiej bazy.
Czy licencja SSPL dotyczy mojej firmy?
Jeśli budujesz aplikację i udostępniasz klientom jej funkcje, a MongoDB jest tylko jej wewnętrzną częścią, sekcja trzynasta ciebie nie dotyczy. Obowiązek publikacji kodu uruchamia się wtedy, gdy udostępniasz osobom trzecim funkcjonalność samej bazy jako usługę. Przy wątpliwościach to pytanie do prawnika, a nie do dokumentacji technicznej.
Czy da się używać obu baz naraz?
Da się i część zespołów tak robi, na przykład trzymając rozliczenia w PostgreSQL, a zdarzenia z aplikacji w MongoDB. Cena tego rozwiązania to dwa zestawy kopii zapasowych, dwa monitoringi i dwie ścieżki aktualizacji. Dla małego zespołu zwykle taniej wychodzi wybrać jeden silnik i mocniej go poznać. Osobną decyzją jest to, jak aplikacja ma te dane pobierać — rozkładamy ją w tekście o REST kontra GraphQL.
Podsumowanie
Sensowna kolejność decyzji wygląda tak. Najpierw sprawdź kształt danych. Jeśli rekordy mają stałe pola i twarde relacje, PostgreSQL opisze to dokładniej. Jeśli każdy rekord wygląda inaczej i czytasz go w całości, MongoDB zdejmie z ciebie pracę. Potem sprawdź, czy nieregularna część danych to naprawdę większość, bo jeśli nie, kolumna JSONB w PostgreSQL załatwia sprawę bez drugiego silnika. Na koniec policz koszty, których nie widać na starcie: limity darmowego klastra Atlas, dostępność wiedzy w zespole i cenę ewentualnej zmiany zdania. Numery wersji i limity z tego tekstu sprawdź u źródła przed decyzją, bo obie bazy zmieniają je częściej niż raz do roku.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
