Dlaczego Wybrałem PostgreSQL Zamiast NoSQL dla Projektu SaaS

Sześć miesięcy temu zacząłem budować z klientem multi-tenant B2B SaaS. Spędziliśmy dwa tygodnie debatując Postgres kontra MongoDB, zrobiliśmy prototypy w obu i wylądowaliśmy na Postgresie. Ten artykuł opisuje założenia, które początkowo pchały nas w stronę Mongo, dlaczego zmieniliśmy zdanie i liczby, które uczyniły decyzję oczywistą z perspektywy czasu.

Zastrzeżenie: to konkretna decyzja dla konkretnej skali. Jeśli budujesz real-time social feed ze setkami milionów dokumentów, Mongo może nadal być właściwym wyborem. Dla 80% produktów B2B SaaS, które nigdy nie przekroczą 10 milionów wierszy na tenant, Postgres wygrywa.

Trzy założenia, które pchały nas w stronę Mongo

• —Schemat miał się zmieniać cały czas i chcieliśmy uniknąć migracji. Zakładaliśmy, że schemaless model Mongo pozwoli nam szybciej iterować.
• —Produkt miał kształt dokumentów — rekordy klientów z zagnieżdżonymi polami, audit traile i bloby configów. Naturalne wydawało się trzymanie ich jako dokumentów.
• —Spodziewaliśmy się, że rekrutacja będzie łatwiejsza dla Mongo niż dla Postgresa. Każdy junior zna MongoDB z tutoriali, prawda?

Dlaczego zmieniliśmy zdanie

Każde założenie rozsypało się, kiedy spojrzeliśmy na nie uczciwie. Schemaless nie oznacza wolnego od migracji — oznacza, że migracje stają się runtime checkami rozproszonymi po kodzie, a bugi stają się incydentami produkcyjnymi zamiast błędami w czasie deployu. Dane w kształcie dokumentów trzymają się świetnie w Postgresowym JSONB, z tą zaletą, że możesz na nich odpalać prawdziwy SQL. A rekrutacja? Każdy backend developer, z którym pracowałem w ostatnich pięciu latach, woli Postgresa. Historia o juniorze znającym Mongo jest dekadę spóźniona.

Postgres vs MongoDB w naszej skali

JSONB to odblokowanie

Funkcją, która uczyniła Postgresa oczywistym wyborem, był JSONB. Pozwala przechowywać dowolne dokumenty JSON w kolumnie, indeksować konkretne ścieżki i odpytywać je SQL-em. W praktyce oznacza to mongo-podobną elastyczność dla pól, które naprawdę tego potrzebują — metadane klientów, bloby configów, payloady audytu — przy zachowaniu ścisłych schematów tam, gdzie to się opłaca. Najlepsze z obu światów.

CREATE TABLE customers (
  id uuid PRIMARY KEY,
  tenant_id uuid NOT NULL,
  email text NOT NULL,
  metadata jsonb NOT NULL DEFAULT '{}'
);

CREATE INDEX customers_metadata_gin
  ON customers USING gin (metadata);

-- Zapytanie w JSON:
SELECT id, email
FROM customers
WHERE metadata->>'plan' = 'enterprise'
  AND tenant_id = $1;

Ten indeks GIN sprawia, że zapytania JSONB są wystarczająco szybkie dla realnych obciążeń. Na SaaS, który budowałem, tabela customers uderzyła w 2 miliony wierszy podczas load testingu, a zapytania po metadanych nadal zwracały w czasie poniżej 40ms. Bez shardingu, bez aggregation pipeline — po prostu SQL.

“Najlepsza baza danych to prawie zawsze ta nudna, którą Twój zespół już umie obsługiwać. Postgres w 2026 to najnudniejsza baza na świecie i to jest dokładnie powód, dla którego powinieneś jej używać.”

Kiedy wybrałbym coś innego

• —Kolekcje dokumentów liczone w setkach milionów, gdzie dominuje throughput zapisów — Mongo albo DynamoDB
• —Ciężkie obciążenia time-series z rotacyjną retencją — TimescaleDB albo ClickHouse
• —Full-text search jako główny wzorzec zapytań — Elasticsearch albo Meilisearch obok Postgresa, nie zamiast
• —Aplikacje edge-first z globalnymi wymaganiami latencji poniżej 50ms — PlanetScale, Neon albo Turso

Dla wszystkiego, co wygląda jak normalny B2B SaaS, Postgres z JSONB jest domyślnym wyborem, po który teraz sięgam. Jeśli jesteś w środku tej decyzji dla własnego produktu i chcesz omówić tradeoffy — napisz do mnie. Powiązane czytanie w moim wpisie o monolicie vs mikroserwisach, który pokrywa odpowiadający tradeoff po stronie serwisów.

Powiązane Artykuły

ArchitectureMicroservices

Mikroserwisy vs Monolit: Pragmatyczny Przewodnik na 2026

CMSArchitecture

Headless CMS vs Tradycyjny: Jak Wybrać Stack dla Strony Firmowej