Appwrite czy Supabase: porównanie i nasz test wydajności

Budujesz aplikację i nie chcesz pisać backendu od zera. Na liście zostały dwa otwarte projekty: Appwrite i Supabase. Oba dają bazę danych, logowanie, pliki i funkcje na serwerze. Oba działają w chmurze albo na twoim własnym serwerze. Różnią się tym, ile zasobów zużywają, ile kosztują przy większym ruchu i jak łatwo je samemu utrzymać.

Krótka odpowiedź: jeśli chcesz postawić backend na własnym serwerze za kilka euro miesięcznie, wybierz Appwrite. W naszym teście obsłużył na tym samym sprzęcie wyraźnie więcej jednoczesnych użytkowników niż Supabase i zużywał dużo mniej procesora bez ruchu. Jeśli wolisz chmurę i zależy ci na PostgreSQL z pełnym SQL i dużą liczbą gotowych integracji, wybierz Supabase. W tym tekście zebraliśmy treść trzech naszych angielskich artykułów: porównanie funkcji, test wydajności i odpowiedź na pytanie, kiedy self-hosting się opłaca.

Appwrite czy Supabase: co wybrać?

Appwrite, gdy liczy się lekki serwer i stały rachunek, Supabase, gdy liczy się zarządzana baza PostgreSQL w chmurze. Obie platformy to backend jako usługa (BaaS, Backend as a Service), czyli gotowy zestaw usług serwerowych. Aplikacja korzysta z nich przez gotowe SDK, więc nie musisz pisać serwera od zera. Najważniejsze różnice w tabeli:

Jeśli w twoim zestawieniu jest jeszcze Firebase, porównanie z nim, w tym RODO i region danych, opisaliśmy w tekście "Supabase czy Firebase: co wybrać do aplikacji w 2026?".

Czym różnią się Appwrite i Supabase?

Supabase zaczyna od bazy danych i dokłada do niej usługi, Appwrite zaczyna od usług i od niedawna daje do nich prawdziwy PostgreSQL. Dla ciebie to różnica w tym, kto w zespole będzie się czuł u siebie: backendowiec znający SQL czy programista aplikacji, który woli gotowe API.

Supabase to platforma open source zbudowana wokół PostgreSQL. Tabele, relacje, zapytania SQL, reguły dostępu na poziomie wierszy (Row Level Security) i rozszerzenia, takie jak pgvector do wyszukiwania podobieństw w AI, są w centrum. Dane wyeksportujesz standardowym pg_dump. Na Supabase domyślnie działa też backend prototypów z Lovable, więc jeśli masz taki prototyp, wybór często zapadł już wcześniej. Co z nim zrobić dalej, opisujemy w tekście o tym, jak przenieść aplikację z Lovable do App Store.

Appwrite to otwarty serwer backendowy, który instalujesz jednym poleceniem w Dockerze (narzędziu do uruchamiania gotowych paczek z programami). Przez lata jego baza miała API w stylu dokumentów, a pod spodem działała MariaDB. Appwrite 2.0, ogłoszony 31 sierpnia 2026, dodał natywny PostgreSQL 18 z rozszerzeniami takimi jak pgvector oraz trzy rodzaje baz: TablesDB (tabele z relacjami), DocumentsDB (dokumenty bez stałego schematu) i VectorsDB (wektory do wyszukiwania w AI). W wersji do samodzielnej instalacji, wydanej na początku września 2026, PostgreSQL jest domyślną bazą nowych instalacji, a MariaDB i MongoDB nadal są obsługiwane.

Co z tego wynika: samo "potrzebuję SQL" nie jest już powodem, żeby odrzucić Appwrite. O wyborze decydują teraz koszt utrzymania, wydajność na twoim sprzęcie i to, czy chcesz trzymać backend samodzielnie.

Ile kosztują Appwrite i Supabase w chmurze?

Oba zaczynają się za darmo, a płatny plan kosztuje od 25 USD miesięcznie. Różnica pojawia się dopiero przy większym ruchu, bo wtedy płacisz za zużycie ponad limity planu.

Darmowe plany wystarczą na prototyp albo test pomysłu. Do aplikacji, z której ktoś naprawdę korzysta, nie nadaje się projekt, który zasypia po tygodniu ciszy, ani taki, który przy przekroczeniu limitu przestaje przyjmować zapisy.

Który jest wydajniejszy? Wyniki naszego testu

W naszym teście Appwrite na każdym serwerze obsłużył więcej jednoczesnych użytkowników niż Supabase, a na serwerze z 8 vCPU różnica wyniosła 250 do 45. Test zrobiliśmy we wrześniu 2024 na ówczesnych wersjach obu platform, na domyślnych ustawieniach, bez żadnego strojenia.

Jak testowaliśmy. Postawiliśmy Appwrite i Supabase po kolei na czterech serwerach Hetzner z procesorami ARM (od 2 do 16 vCPU) i porównaliśmy je z darmowymi planami ich chmur w tych samych lokalizacjach. W bazie było 5000 użytkowników i 20 000 produktów. Narzędzie k6 symulowało klientów sklepu internetowego: każdy wirtualny użytkownik pobiera swoje dane, potem listę produktów, czeka sekundę i robi to samo od nowa. To celowo agresywny scenariusz, bo prawdziwy użytkownik patrzy na ekran dłużej niż sekundę. Zapytania szły przez sieć komórkową 4G/5G z odległości około 1500 km od serwerów w Niemczech, tak jak w prawdziwej aplikacji mobilnej.

Mierzyliśmy dwie rzeczy. Strefa komfortu to największa 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. Punkt załamania to moment, w którym przy rosnącym ruchu pojawiają się pierwsze przekroczenia czasu i błędy. Serwer wtedy jeszcze działa, ale odpowiedzi trwają już kilka sekund.

* Na CAX21 Supabase zachowywał się prawie tak samo jak na CAX11 (różnice do około 10%), więc nie powtarzaliśmy pełnego testu. Ceny serwerów w 2024 roku były niższe: Hetzner podniósł je w 2026, więc najmniejszy serwer z testu nie kosztuje już około 5 euro.

Trzy rzeczy, które nas zaskoczyły. Po pierwsze, bez żadnego ruchu na najmniejszym serwerze Appwrite zajmował około 30% procesora, a Supabase około 200%, czyli oba rdzenie bez przerwy. Trudno było w to uwierzyć, więc powtórzyliśmy pomiar w chmurze i wynik był podobny. Po drugie, na CAX31 Appwrite załamał się dopiero przy 6800 użytkownikach i obsłużył w tym czasie 100 000 zapytań ze średnim czasem odpowiedzi 3 sekundy, a Supabase przy 3000 użytkownikach i 59 000 zapytań ze średnią 6 sekund. Po trzecie, własny serwer CAX31 poradził sobie lepiej niż obie darmowe chmury, zarówno pod względem liczby użytkowników, jak i czasu odpowiedzi.

Kod testów, skrypty k6 i pełne raporty z wykresami są publiczne na GitHubie, więc możesz powtórzyć te same scenariusze na swoich danych. Wszystkie wykresy z testu znajdziesz w oryginalnym artykule: Appwrite vs Supabase: cloud vs self-hosted performance comparison (EN).

Ilu użytkowników obsłuży serwer za kilka euro miesięcznie?

Aplikacja z 50 000 użytkowników miesięcznie zmieści się na najmniejszym serwerze z Appwrite, z zapasem. Liczba użytkowników miesięcznie brzmi groźnie, ale serwer interesuje tylko to, ilu z nich jest aktywnych w tej samej chwili.

Policzmy to jak w sklepie, gdzie liczy się kolejka przy kasie, a nie liczba klientów w miesiącu:

1. 50 000 użytkowników aktywnych przez około 25 dni w miesiącu to 2000 użytkowników dziennie.
2. Jeśli większość ruchu przypada na 8 godzin dziennie, to 250 użytkowników na godzinę.
3. 250 na godzinę to około 4 na minutę. Z zapasem na szczyty ruchu przyjmijmy 20 na minutę.
4. W naszym teście Appwrite na najmniejszym serwerze utrzymał 60 jednoczesnych użytkowników w strefie komfortu, przy scenariuszu dużo cięższym niż normalne używanie aplikacji.

Dla porównania: rozbudowane konfiguracje w AWS potrafią kosztować ponad 100 euro miesięcznie, zanim aplikacja zdobędzie pierwszych użytkowników. Własny serwer ma też jedną cechę, której chmura nie daje: rachunek się nie zmienia, bo płacisz za maszynę, a nie za każde zapytanie, transfer czy konto użytkownika.

Kiedy self-hosting wygrywa z chmurą?

Gdy ruch jest przewidywalny, chcesz stały rachunek i masz kogoś, kto zadba o serwer. Self-hosting (utrzymywanie backendu na własnym serwerze) przypomina kupno samochodu zamiast taksówki: płacisz z góry i sam dbasz o przeglądy, ale przy codziennej jeździe wychodzi to korzystniej i jedziesz, dokąd chcesz.

Własny serwer ma sens, gdy

• ruch rośnie przewidywalnie i wolisz stałą kwotę niż płacenie za zużycie,
• dane muszą zostać na twoich serwerach albo w wybranym kraju, na przykład z powodu wymagań klienta,
• potrzebujesz konfiguracji lub integracji, których chmura nie pozwala ustawić,
• ktoś w zespole zrobi aktualizacje, kopie zapasowe i monitoring.

Zostań w chmurze, gdy

• dopiero sprawdzasz pomysł i liczy się czas, a nie koszt serwera,
• ruch jest nieprzewidywalny i potrzebujesz automatycznego skalowania,
• nikt w zespole nie chce odpowiadać za serwer, poprawki bezpieczeństwa i kopie zapasowe.

Własny serwer to też zwykle jedyna droga, gdy każdy klient ma mieć dane osobno. Tak działa zbudowane przez nas Skillcredible: każdy klient dostaje własny backend i własne dane. Przy samodzielnym utrzymaniu możesz też łączyć serwery różnej wielkości: mniejszy do lekkich zadań w tle, mocniejszy do bazy danych.

Uwaga na Supabase na własnym serwerze. W naszym teście był trudniejszy w konfiguracji niż Appwrite, a część opcji panelu w wersji do samodzielnej instalacji była wyłączona albo ograniczona. Jeśli wiesz, że kiedyś wyprowadzisz się z chmury na własny serwer, łatwiej będzie zrobić to z Appwrite.

Co zmienił Appwrite 2.0 i czy wyniki są jeszcze aktualne?

Kierunek wyników wciąż ma sens, ale liczby traktuj jako punkt odniesienia, nie jako wyrok. Test robiliśmy we wrześniu 2024 i od tamtej pory obie platformy się zmieniły.

• Nowy silnik Appwrite. Appwrite 2.0 dostał nowy silnik obsługi zapytań i według producenta wyraźnie wyższą przepustowość przy pracy zależnej od bazy i dysku. Domyślna instalacja z PostgreSQL uruchamia 16 kontenerów zamiast 33. Tego jeszcze sami nie mierzyliśmy.
• Baza Appwrite. Test robiliśmy na MariaDB, a dziś nowe instalacje stoją domyślnie na PostgreSQL. Wybór bazy przy instalacji jest na stałe.
• Braki w wersji do samodzielnej instalacji. Firewall i dziennik zdarzeń projektu są na razie dostępne tylko w chmurze. API plików zgodne z S3 trafiło do wersji self-hosted w Appwrite 2.1 (wrzesień 2026). Sprawdź, czy potrzebujesz tych funkcji.
• Ceny serwerów. Hetzner podniósł ceny w 2026 roku, więc własny serwer kosztuje więcej niż w 2024. Rachunek dalej jest stały i przewidywalny, a to główny powód, żeby utrzymywać backend samemu.

Jeśli zaczynasz nowy projekt, zrób to, co my: uruchom nasze scenariusze z GitHuba na Appwrite 2.0 i na aktualnym Supabase z własnymi danymi, zanim podejmiesz decyzję na lata.

Jak wybrać backend do swojej aplikacji?

Odpowiedz na cztery pytania, w tej kolejności. Dwa pierwsze zwykle rozstrzygają sprawę.

• Pytanie 1Kto utrzyma serwer? Jeśli nikt, zostań w chmurze, a wybór między Appwrite i Supabase zależy od tego, czy twój zespół woli SQL, czy gotowe API.
• Pytanie 2Gdzie muszą leżeć dane? Jeśli u ciebie albo u klienta, wybierz własny serwer, a na nim raczej Appwrite.
• Pytanie 3Jak przewidywalny jest ruch? Przewidywalny sprzyja stałemu rachunkowi za serwer, nieprzewidywalny sprzyja chmurze.
• Pytanie 4Czy masz już prototyp? Prototyp z Lovable zwykle stoi na Supabase i często rozsądniej jest przy nim zostać.

W naszych projektach nie zawsze wygrywa gotowy backend. W Museo zbudowaliśmy własny backend na PostgreSQL, bo produkt potrzebował rozpoznawania dzieł sztuki i potoku AI. Do każdego backendu, gotowego czy własnego, możemy też dodać panel admina, którym zarządzasz z czatu AI. Opisaliśmy to w tekście o serwerze MCP do panelu admina. Ile kosztuje cały projekt, aplikacja razem z backendem, sprawdzisz w cenniku Codigee.