Dwa lata temu zgłosił się do nas klient z projektem opartym na Firebase. Aplikacja obsługiwała 10 000 użytkowników i generowała rachunek 3 000 dolarów miesięcznie. Po migracji do Supabase: 60 dolarów miesięcznie. To prawdziwy przykład — dane zanonimizowane, ale liczby realne.
Nie piszemy tego, żeby straszyć. Piszemy, żeby pokazać, że wybór platformy backendowej na etapie MVP ma realne konsekwencje finansowe w momencie wzrostu. Decyzja podjęta w weekend potrafi kosztować tysiące dolarów miesięcznie rok później.
Firebase: dojrzały ekosystem Google
Firebase to platforma BaaS od Google z ponad dziesięcioletnią historią. Oferuje kompletny zestaw narzędzi: Realtime Database i Firestore do przechowywania danych, Firebase Auth do autoryzacji, Cloud Storage na pliki, Cloud Functions do logiki serwerowej. Do tego świetne SDK mobilne — dla iOS i Androida — oraz głęboka integracja z całym ekosystemem Google Cloud.
Jeśli budujesz aplikację mobilną z potrzebą real-time sync, Firebase dowozi to out of the box. Firestore z listenerami pozwala synchronizować dane między urządzeniami w czasie milisekund bez żadnej dodatkowej infrastruktury. Dla aplikacji społecznościowych, gier wieloosobowych czy czatu — to naprawdę dobry wybór.
Są jednak trzy problemy, które w projektach SaaS stają się poważne.
Po pierwsze: Firestore to baza dokumentowa NoSQL. Dla danych relacyjnych — użytkownicy, organizacje, subskrypcje, uprawnienia — model dokumentowy generuje denormalizację i duplikację danych. Zapytania między kolekcjami są nieintuicyjne i ograniczone. JOIN-y nie istnieją.
Po drugie: cennik skaluje się nieliniowo. Firebase rozlicza za operacje odczytu i zapisu, nie za zasoby. Przy rosnącej bazie użytkowników i intensywnym używaniu Firestore rachunek może rosnąć szybciej niż przychody — co widać na przykładzie naszego klienta.
Po trzecie: vendor lock-in do Google. Migracja z Firebase to projekt sam w sobie — dane w Firestore nie eksportują się do SQL bez konwersji, Cloud Functions są specyficzne dla ekosystemu GCP, autoryzacja Firebase ma własny format tokenów.
Supabase: open-source, PostgreSQL-first
Supabase to platforma BaaS zbudowana na PostgreSQL — prawdziwej, relacyjnej bazie danych, nie NoSQL. Oferuje Supabase Auth (kompatybilny z JWT), Realtime przez WebSocket, Storage na pliki i Edge Functions oparte na Deno. Cały projekt jest open-source: możesz go uruchomić samodzielnie na własnej infrastrukturze.
Kluczowa różnica: masz pełne PostgreSQL. Oznacza to JOIN-y, transakcje, constrainty, triggery, widoki i cały ekosystem rozszerzeń. W tym pgvector — rozszerzenie umożliwiające przechowywanie i wyszukiwanie embeddingów AI bezpośrednio w bazie danych, bez osobnego wektorowego serwisu.
Row Level Security (RLS) to mechanizm PostgreSQL, który Supabase eksponuje w prosty sposób. Zamiast pisać logikę autoryzacji w każdym endpoincie API, definiujesz polityki bezpośrednio na poziomie tabel. Użytkownik widzi tylko swoje dane — na poziomie bazy, nie aplikacji. To upraszcza kod i eliminuje całą klasę błędów bezpieczeństwa.
Cennik Supabase jest oparty na zasobach: przechowywana ilość danych, pasmo, liczba aktywnych użytkowników. Nie płacisz za każdy odczyt i zapis. Dla aplikacji z intensywnym ruchem odczytu — typowych dashboardów SaaS — różnica w rachunkach jest dramatyczna.
SDK Supabase jest TypeScript-first, z automatycznym generowaniem typów ze schematu bazy danych. Piszesz zapytania, kompilator sprawdza typy — bez oddzielnego ORM-a.
Gdzie Firebase wygrywa
Firebase pozostaje dobrym wyborem w konkretnych scenariuszach.
Aplikacje mobilne z real-time sync — gry wieloosobowe, czat, współdzielone listy zakupów — to domyślny use case Firebase i działa bardzo dobrze. SDK iOS i Android są dojrzałe i dobrze udokumentowane.
Jeśli Twój zespół jest głęboko zakorzeniony w ekosystemie Google Cloud — BigQuery, Google Analytics, Firebase Performance Monitoring — integracja jest bezproblemowa. Firebase jest integralną częścią GCP.
Dla bardzo prostych aplikacji, gdzie model relacyjny jest overkill — prostych CRUD-ów bez złożonych zależności między danymi — Firebase jest szybki w starcie i nie wymaga znajomości SQL.
Jeśli masz gotowy zespół z doświadczeniem Firebase i sprawdzone procesy — koszt zmiany technologii zawsze wchodzi do rachunku.
Gdzie Supabase wygrywa
Supabase wygrywa w scenariuszach typowych dla produktów SaaS.
Dane relacyjne — użytkownicy, organizacje, subskrypcje, role, uprawnienia — naturalnie pasują do modelu tabelarycznego. SQL jest bardziej ekspresywny i wydajny dla tego typu zapytań niż kolekcje Firestore z manualną denormalizacją.
SQL znają prawie wszyscy developerzy. Onboarding nowego członka zespołu do projektu Supabase jest szybszy niż do projektu z Firestore. Nie ma nowej składni zapytań do nauki.
Predictable pricing to kluczowy argument dla bootstrapped SaaS. Zasoby rosną proporcjonalnie do użytkowników, nie wykładniczo z intensywnością użycia.
Ekosystem PostgreSQL to ogromna wartość. pgvector pozwala dodać wyszukiwanie semantyczne i funkcje AI bez osobnej bazy wektorowej — embeddingi trafiają prosto do tabeli obok reszty danych. Inne rozszerzenia — PostGIS dla geolokalizacji, pg_cron dla harmonogramowania — są dostępne z pudełka.
TypeScript i Next.js lub Astro to stack, w którym Supabase działa najlepiej. Generowane typy, klient działający zarówno po stronie serwera jak i przeglądarki, integracja z Server Actions — ekosystem jest przemyślany dla nowoczesnego frontendu.
Open-source oznacza brak lock-inu. Jeśli Supabase Cloud kiedykolwiek przestanie odpowiadać Twoim potrzebom, możesz przenieść się na self-hosted bez zmiany kodu — bo to nadal PostgreSQL.
Co wybieramy w MKM Labs
Dla wszystkich nowych projektów SaaS wybieramy Supabase. Powody są konkretne.
Model relacyjny pasuje do SaaS naturalnie. Organizacje, użytkownicy, role, subskrypcje, eventy — to dane z relacjami, a SQL jest właściwym narzędziem do ich modelowania i odpytywania.
pgvector daje nam AI out of the box. Każdy projekt, który potrzebuje wyszukiwania semantycznego, rekomendacji czy klasyfikacji embeddingami, może to zrobić bez osobnej infrastruktury. Embeddingi trafiają do tabeli, zapytanie wektorowe działa przez standardowy klient.
Open-source eliminuje ryzyko. Jeśli klient chce zmienić dostawcę infrastruktury, przenieść dane do własnego serwera albo wyjść spod kontroli konkretnej platformy — PostgreSQL idzie wszędzie.
Row Level Security upraszcza kod autoryzacji. Zamiast sprawdzać uprawnienia w każdym endpoincie, polityki RLS działają na poziomie bazy. Mniej kodu, mniej miejsca na błędy bezpieczeństwa.
Firebase polecamy jedynie dla projektów mobile-first z silnym wymaganiem real-time i zespołem, który dobrze zna ten ekosystem.
Budujesz SaaS? Pomagamy wybrać właściwy stack i dostarczamy MVP w kilka tygodni. Pierwsza rozmowa gratis.
Potrzebujesz podobnego rozwiązania?
Porozmawiajmy o Twoim projekcie
Pierwsza rozmowa jest bezpłatna. Opisz nam swój pomysł — odpowiemy w ciągu jednego dnia roboczego.
Umów bezpłatną rozmowę