Dla SaaS gotowego na skalowanie właściwym domyślnym wyborem jest PostgreSQL. Pokrywa około 90% tego, czego potrzebuje produkt webowy lub mobilny: dane transakcyjne, relacje między encjami, wyszukiwanie, JSON, lekkie kolejki, a nawet część obciążenia wektorowego dla AI. Prawdziwe pytanie prawie nigdy nie brzmi "relacyjna czy NoSQL", lecz "czy mam konkretny powód, żeby NIE wybrać Postgresa". W większości przypadków — nie.
PostgreSQL domyślnie: dlaczego działa w 9 na 10 przypadków
SaaS obsługuje dane ustrukturyzowane i powiązane ze sobą: użytkownicy należący do organizacji, subskrypcje powiązane z fakturami, projekty powiązane z zadaniami. To dokładnie to, do czego stworzono bazy relacyjne. Postgres dokłada do tej podstawy supermoce, które pozwalają nie piętrzyć kolejnych narzędzi: kolumny JSONB dla danych półustrukturyzowanych, wbudowane wyszukiwanie pełnotekstowe, rozszerzenie pgvector dla embeddingów AI oraz ograniczenia gwarantujące integralność twoich danych.
- Transakcje ACID: twoje płatności i dane krytyczne pozostają spójne, nawet po awarii.
- Jeden system do obsługi, backupu i monitoringu zamiast trzech: niższe koszty, mniej awarii.
- Dojrzały ekosystem: Prisma, migracje, replikacja, hosting zarządzany wszędzie (Cloud Run, Neon, Supabase, RDS).
- JSONB, gdy potrzebujesz elastyczności, bez rezygnowania z relacyjności w pozostałych obszarach.
Relacyjna vs NoSQL: kiedy opuścić Postgresa
NoSQL (MongoDB, DynamoDB, Firestore) nie jest "nowocześniejszy", odpowiada na inne ograniczenia. Opłaca się tylko wtedy, gdy twój przypadek użycia naprawdę pasuje: ogromny wolumen z bardzo intensywnym zapisem, naprawdę nieprzewidywalny schemat albo potrzeba ekstremalnej dystrybucji geograficznej. Dla typowego SaaS B2B na etapie startu i wzrostu te ograniczenia jeszcze nie istnieją, a wdrożenie NoSQL zbyt wcześnie każe ci płacić złożonością za coś, czego nigdy nie użyjesz.
Wybór NoSQL, bo "się skaluje", gdy masz 200 użytkowników, to optymalizacja problemu, którego nie masz, kosztem tych, które już masz.
Indeksy, migracje, skalowanie: trzy odruchy już od V1
Dobrze wybrana baza to nie wszystko: o tym, czy twój SaaS wytrzyma przy 10 000 użytkowników, decydują trzy nawyki. Po pierwsze indeksy: zapytanie skanujące całą tabelę jest szybkie przy 100 wierszach i katastrofalne przy 1 milionie. Indeksuj kolumny, po których często filtrujesz i łączysz, i mierz za pomocą EXPLAIN. Następnie migracje: każda zmiana schematu musi być wersjonowana i odtwarzalna (Prisma Migrate), nigdy nakładana ręcznie na produkcji. Wreszcie skalowanie: najpierw pionowo (więcej CPU/RAM), potem repliki do odczytu, a o shardingu myśli się dopiero bardzo późno: większość SaaS nigdy do tego nie dochodzi.
- Indeksy: celuj w kolumny z klauzul WHERE, JOIN i ORDER BY; zły indeks kosztuje przy zapisie, brakujący zabija odczyt.
- Migracje: wersjonowane, testowane, odwracalne: baza ewoluuje wraz z produktem bez downtime.
- Skalowanie: najpierw pionowo, potem repliki do odczytu; Postgres obsługuje miliony wierszy na długo przed tym, zanim pojawi się sharding.
Właściwa decyzja dla V1
Wybór PostgreSQL od pierwszego dnia, czyste modelowanie, założenie właściwych indeksów i wersjonowanie migracji: to właśnie oszczędza ci przepisywania w 12. miesiącu. To dokładnie ten fundament, który budujemy w naszych V1 dostarczanych w 7 dni za 15 000 € — Next.js, NestJS, Prisma i Postgres — baza, która prowadzi cię od pierwszego klienta aż po skalowanie, bez ukrytego długu technicznego.