Supabase czy Firebase: co wybrać do aplikacji w 2026?

Supabase czy Firebase: co wybrać?

To przede wszystkim wybór między bazą SQL a bazą dokumentów oraz między dwoma sposobami płacenia. Cała reszta z tego wynika. Najważniejsze różnice w jednym miejscu:

Wybierz Supabase, gdy dane są ze sobą powiązane: użytkownicy, zamówienia, płatności, raporty. Także wtedy, gdy masz prototyp z Lovable, bo jego backend to najpewniej już Supabase.

Wybierz Firebase, gdy budujesz przede wszystkim aplikację mobilną, dane są proste (profile, wiadomości, ustawienia), a liczą się gotowe usługi Google: powiadomienia push, raporty awarii i analityka.

Co to jest Supabase?

Supabase to platforma backendowa open source zbudowana na PostgreSQL. W jednym miejscu dostajesz bazę danych, logowanie użytkowników, przechowywanie plików, zmiany w czasie rzeczywistym i funkcje uruchamiane na serwerze (Edge Functions). Do tego panel, w którym tabele wyglądają prawie jak arkusz.

Dla właściciela produktu najważniejsze jest to, co pod spodem. To zwykły PostgreSQL, który zna każdy backendowiec. Dane wyeksportujesz standardowym narzędziem pg_dump i przeniesiesz na inny serwer. Na PostgreSQL stoją też backendy, które budujemy sami, na przykład w Museo i FishPRO.

Co to jest Firebase i czym jest dziś?

Firebase to platforma Google do budowania aplikacji mobilnych i webowych. Jej rdzeń to Firestore, baza dokumentów NoSQL, oraz Firebase Authentication do logowania. Dookoła jest cały zestaw usług: Cloud Storage na pliki, Cloud Functions, hosting, powiadomienia push (Cloud Messaging) i Crashlytics do raportów awarii.

Firebase nie trzeba brać w całości. W wielu aplikacjach, także naszych, Firebase wysyła powiadomienia push i zbiera raporty awarii, a dane leżą w osobnej bazie PostgreSQL. Tak działają Prenta i Museo.

Czy Firebase jest darmowy? Ile kosztuje Supabase?

Darmowy projekt Supabase zasypia po tygodniu bez ruchu, więc nie nadaje się do aplikacji, z której ktoś naprawdę korzysta.

Uważaj na pliki. Od 30 października 2024 nowy domyślny bucket Cloud Storage wymaga planu Blaze, a od 3 lutego 2026 bez Blaze tracisz dostęp także do plików, które już tam są. Nic nie znika, ale aplikacja przestaje je widzieć. Cloud Functions też działają tylko w Blaze. Odpowiedź na pytanie, czy Firebase jest płatny, brzmi więc: jest darmowy, dopóki aplikacja nie potrzebuje zdjęć, plików ani logiki na serwerze.

Różnica w praktyce: w Supabase rachunek rośnie skokowo, razem z wielkością instancji. W Firebase rośnie z każdym odczytem i zapisem dokumentu. Źle zaprojektowany ekran, który przy każdym otwarciu czyta setki dokumentów, widać więc od razu na fakturze.

Czy prototyp z Lovable ma już backend na Supabase?

Lovable ma wbudowany backend o nazwie Lovable Cloud i według dokumentacji jest on domyślnie włączony. Działa na otwartym fundamencie Supabase. Możesz też podłączyć własny projekt Supabase. W obu przypadkach pytanie "Supabase czy Firebase" rozstrzygnęło się, zanim je zadałeś.

Przy przejściu z prototypu do prawdziwej aplikacji sprawdź trzy rzeczy:

• Region. Region Lovable Cloud (Ameryki, Europa albo Azja i Pacyfik) wybierasz przy włączaniu backendu i później nie da się go zmienić. Jeśli twoi użytkownicy są w Polsce, a baza powstała w Ameryce, przeniesienie jej to osobna praca.
• Własność. Lovable nie przenosi projektu z wbudowanego backendu do twojego projektu Supabase jednym ruchem. Trzeba wyeksportować bazę, odtworzyć ją, przenieść pliki i od nowa ustawić logowanie i sekrety.
• Reguły dostępu. Prototyp ma działać, a nie być szczelny. Zanim wpuścisz prawdziwych użytkowników, ktoś musi przejrzeć reguły dostępu do danych (Row Level Security) i sprawdzić, czy klucze nie siedzą w kodzie aplikacji.

O drodze z prototypu do sklepów piszemy osobno: aplikacja z Lovable w App Store: opakować czy przebudować?.

Gdzie są dane twoich użytkowników i co z RODO?

RODO nie zabrania korzystania z amerykańskich dostawców. Musisz jednak wiedzieć, gdzie trafiają dane, i mieć umowę powierzenia przetwarzania. Supabase udostępnia taką umowę (DPA). Google w dokumentach prywatności Firebase określa się jako podmiot przetwarzający i jest certyfikowany w ramach EU-U.S. Data Privacy Framework. To nie porada prawna, tylko punkty, które warto sprawdzić z prawnikiem.

Supabase

Projekt postawisz w konkretnym regionie AWS w Unii: we Frankfurcie, w Irlandii, Paryżu albo Sztokholmie. Dokumentacja Supabase radzi wybrać konkretny region UE, a nie ogólną grupę "Europa", bo ta obejmuje też Londyn i Zurych, czyli miejsca poza Unią. Zaznacza też, że region to nie wszystko: znaczenie mają kopie zapasowe, logi, Edge Functions i podwykonawcy.

Firebase

Bazę Firestore założysz w regionie europe-central2, czyli w Warszawie. Lokalizacji nie zmienisz po utworzeniu bazy, więc to decyzja na start. Za to Firebase Authentication według Google działa wyłącznie z centrów danych w USA. Jeśli logujesz użytkowników przez Firebase, ich dane logowania są przetwarzane w Stanach.

W praktyce: dla większości aplikacji konsumenckich oba rozwiązania da się poprawnie opisać w polityce prywatności. Gdy klient wymaga, żeby dane leżały na jego własnych serwerach, zostaje self-hosting. Tak działa zbudowane przez nas Skillcredible: każdy klient dostaje własny backend i własne dane.

Jak łatwo potem zmienić dostawcę?

Uzależnienie od dostawcy (vendor lock-in) to koszt, którego nie widać na fakturze, dopóki nie musisz się przenieść.

Appwrite: open source, tak jak Supabase, z wersją do postawienia na własnym serwerze.

Kiedy self-hosting wychodzi lepiej niż chmura? Nasz test

We wrześniu 2024 zrobiliśmy własny test obciążeniowy. Postawiliśmy Supabase i Appwrite na serwerach Hetzner z procesorami ARM i porównaliśmy je z darmowymi planami ich chmur w tych samych lokalizacjach. Scenariusz udawał sklep internetowy: użytkownik pobiera swoje dane i listę produktów, czeka sekundę i powtarza. Kod i pełne wyniki są publiczne na GitHubie.

"Strefa komfortu" to u nas liczba jednoczesnych użytkowników, przy której 90% odpowiedzi przychodzi w 200 ms, 95% w 500 ms, 99% w sekundę, a 99% zapytań kończy się sukcesem. Wyniki:

• Na serwerze z 8 vCPU i 16 GB RAM Appwrite utrzymał strefę komfortu przy 250 jednoczesnych użytkownikach, Supabase przy 45.
• Na tym samym serwerze Appwrite zaczął się sypać przy 6 800 użytkownikach, Supabase przy 3 000.
• Na najmniejszym serwerze (2 vCPU, 4 GB RAM) w spoczynku Appwrite zajmował około 30% procesora, a Supabase około 200%, czyli oba rdzenie.
• Własny serwer z 8 vCPU poradził sobie lepiej niż obie darmowe chmury, zarówno pod względem liczby użytkowników, jak i czasu odpowiedzi.

Uczciwie: to test sprzed dwóch lat, na domyślnych ustawieniach, przez sieć komórkową. Obie platformy od tego czasu się zmieniły, a Hetzner w 2026 roku podniósł ceny serwerów. Traktuj te liczby jako kierunek, nie wyrocznię.

Self-hosting ma sens, gdy

• ruch jest przewidywalny i wolisz stały rachunek niż płacenie za każde zapytanie,
• dane muszą zostać na twoich serwerach albo w wybranym kraju,
• ktoś w zespole zadba o aktualizacje, kopie zapasowe i bezpieczeństwo.

Zostań w chmurze, gdy

• dopiero sprawdzasz pomysł i liczy się czas, a nie koszt serwera,
• ruch jest nieprzewidywalny i potrzebujesz automatycznego skalowania,
• nie masz nikogo, kto zajmie się serwerem.

Pamiętaj, że Supabase na własnym serwerze to wersja okrojona. Według dokumentacji nie ma w niej między innymi branchingu, zarządzanych kopii zapasowych z PITR ani API do zarządzania platformą, a wsparcia udziela społeczność, nie Supabase.

Co to jest Appwrite i kiedy go wybrać?

Appwrite to backend open source z bazą danych, logowaniem, plikami i funkcjami, dostępny w chmurze albo na własnym serwerze. W Polsce prawie nikt go nie szuka: Google nie podpowiada nawet frazy "appwrite co to". A w naszym teście był najlżejszy i najprostszy do postawienia u siebie.

Chmura Appwrite ma region we Frankfurcie. Od 1 września 2025 darmowy plan pozwala na dwa projekty w organizacji.

Wybierz Appwrite, gdy od początku planujesz własny serwer i chcesz wycisnąć z niego jak najwięcej. Jeśli masz już działający prototyp na Supabase, uporządkowanie go zwykle kosztuje mniej niż przeprowadzka.

Jak wybieramy backend w projektach Codigee?

Nie zaczynamy od narzędzia. Zaczynamy od danych i od tego, kto będzie utrzymywał aplikację za dwa lata.

• DaneJakie dane trzyma aplikacja i jak są ze sobą powiązane.
• MiejsceGdzie muszą leżeć: w UE, w konkretnym kraju czy na serwerze klienta.
• KosztIlu użytkowników będzie za rok i jak rośnie rachunek w każdej opcji.
• WyjścieCo się stanie, gdy trzeba będzie zmienić dostawcę.

Wynik bywa mieszany. Prenta przyszła do nas z pomysłem i prototypem z AI, a dziś ma backend na PostgreSQL i powiadomienia push z Firebase. W CrossChem przenieśliśmy powiadomienia z Pushera do Firebase, gdy limity Pushera zaczęły przeszkadzać.

Masz już aplikację i nie wiesz, na czym stoi? Audyt aplikacji sprawdza kod i architekturę, awarie, wydajność i stan w sklepach. Kosztuje 17 500-28 000 zł netto i kończy się konkretnym planem na piśmie. Wszystkie ceny są w cenniku.

Masz prototyp z Lovable, Bolt albo Replit i chcesz go wydać w sklepach? Zobacz, jak pracujemy z takimi projektami: prototyp z AI w App Store i Google Play.