Neon czy Supabase? Skalowanie do zera przy cichym ruchu

Neon może być tańszym wyborem dla aplikacji, której baza przez długie okresy nie obsługuje żadnych połączeń: wtedy moc obliczeniowa może się wyłączyć. Jeśli ruch utrzymuje bazę w ciągłej gotowości, ta przewaga kosztowa znika. O wyborze między Neonem a Supabase decydują wówczas rozmiar pracującej instancji, sposób skalowania i usługi, których potrzebuje aplikacja.

Dla prototypu z krótkimi sesjami pracy mocnym argumentem za Neonem są uśpienie bazy i szybkie tworzenie odizolowanych branchy z danymi. Dla stabilnego SaaS Supabase może być wygodniejsze, jeśli zespół chce korzystać z jego Auth, Storage i API jako jednego zestawu. Przy ruchu skokowym trzeba rozdzielić dwie sytuacje: okresy pełnej ciszy pozwalają oszczędzać na uśpieniu, a wzrost obciążenia podczas aktywności wymaga odpowiedniej mocy i połączeń.

Kiedy uśpienie naprawdę obniża koszt

Dokumentacja obliczeń Neona podaje, że instancja domyślnie przechodzi w stan bezczynności po pięciu minutach bez aktywności. Częste próby połączenia, integracje i zadania w tle mogą za każdym razem uruchamiać licznik od nowa. Mała liczba użytkowników nie wystarcza więc do oszacowania oszczędności: znaczenie mają rzeczywiste odstępy między połączeniami z PostgreSQL.

Pierwsze zapytanie po uśpieniu musi wybudzić instancję, co dodaje opóźnienie. W aplikacji, w której pierwsza odpowiedź po przerwie musi być szybka i przewidywalna, można utrzymywać bazę aktywną, ale wtedy rośnie czas naliczania mocy obliczeniowej. Dla serwisu używanego sporadycznie ten kompromis może być rozsądny; dla systemu obsługującego zapytania przez całą dobę funkcja uśpienia nie tworzy oszczędności.

Uśpienie, automatyczne skalowanie działającej instancji i ręczna zmiana jej konfiguracji oznaczają różne operacje. Neon dostosowuje moc w ustawionym zakresie autoskalowania bez restartu, lecz zmiana rozmiaru instancji o stałej mocy oraz zmiana granic autoskalowania mogą przerwać istniejące połączenia. Zespół potrzebujący ciągłej obsługi żądań powinien uwzględnić tę różnicę w sposobie wdrażania zmian, nawet jeśli sama baza zwykle szybko odpowiada na zapytania.

Ile kosztuje baza, która pracuje

Cennik Neona przewiduje w planie Free 100 CU-godzin miesięcznie i 1 GB danych na projekt, a w planie Launch stawki 0,106 USD za CU-godzinę oraz 0,35 USD za GB danych miesięcznie. CU-godzina łączy rozmiar instancji z czasem jej pracy: większa instancja działająca przez ten sam okres zużywa więcej jednostek. Płatny rachunek zależy więc od faktycznej aktywności i mocy, a nie tylko od liczby utworzonych baz.

Przechowywanie danych jest osobną pozycją także wtedy, gdy instancja śpi. Znaczenie mają ponadto historia zmian i branche, które zaczynają gromadzić własne dane. Branch współdzielący dane z rodzicem może na początku zajmować niewiele dodatkowego miejsca, ale jego koszt rośnie wraz ze zmianami albo po wyjściu poza okno współdzielenia historii. Dla krótkotrwałych środowisk testowych daje to inny rachunek niż dla wielu branchy utrzymywanych miesiącami.

Cennik Supabase podaje cenę Pro od 25 USD miesięcznie i 10 USD miesięcznego kredytu na moc obliczeniową, który pokrywa jedną instancję Micro; większy rozmiar i dodatkowe projekty zwiększają rachunek. Plan obejmuje również limity dotyczące danych, transferu, plików i aktywnych użytkowników. Kwota wejścia jest zatem użytecznym punktem odniesienia, lecz nie jest ceną maksymalną dla rosnącej aplikacji.

Porównanie samych stawek za PostgreSQL pomija pracę potrzebną do złożenia pozostałych części backendu. Jeśli zespół używa już własnego uwierzytelniania, API i przechowywania plików, większą wagę może mieć cena oraz zachowanie bazy. Jeśli dopiero buduje te elementy, wspólna konfiguracja usług może być warta więcej niż różnica między rachunkami za samą instancję.

Co pokazują branche, repliki i zmiana mocy

W teście operacyjnym DevOps Daily, przeprowadzonym na projektach w tym samym regionie AWS i mierzonym z pobliskiej maszyny, branch Neona z danymi rodzica był gotowy po medianie 1,7 s, a branch Supabase zawierający schemat bez danych po 6,2–6,7 s. W tej samej publikacji mediana czasu do pierwszego zapytania z nowej repliki wyniosła 8 s dla Neona i 181 s dla Supabase. Podczas badanej zmiany mocy sondy SQL nie wykazały nieudanych prób w Neonie, natomiast w Supabase zmierzono około 39 s niedostępności.

Wynik branchingu trzeba czytać razem z zawartością nowego środowiska. W teście branch Neona udostępniał dane rodzica, podczas gdy świeży branch Supabase zawierał schemat i konfigurację. Ścieżka tworzenia brancha Supabase z danymi wymagała w badanych nowych projektach wcześniejszych fizycznych kopii zapasowych. Jeżeli test migracji wymaga danych z bazy źródłowej, sam czas utworzenia pustego schematu nie opisuje całego zadania.

Podobnie czas utworzenia repliki mówi o przygotowaniu dodatkowej mocy do odczytu, a nie o szybkości późniejszych zapytań. Neon dołącza instancję odczytową do współdzielonej pamięci danych; w badanej konfiguracji Supabase przygotowywało fizyczną kopię. Różnica jest istotna, gdy replikę trzeba dodać w reakcji na wzrost ruchu, lecz wynik jednego środowiska nie jest obietnicą identycznego czasu przy każdej wielkości bazy.

Pomiar zmiany mocy też ma wąskie znaczenie: test Neona dotyczył zmiany granic autoskalowania i sond sprawdzających nowe zapytania SQL. Brak nieudanych sond nie oznacza, że długo utrzymywane połączenia nigdy nie zostaną rozłączone; dokumentacja Neona przewiduje taką możliwość przy zmianie konfiguracji. Dla aplikacji liczą się zarówno dostępność nowych zapytań, jak i sposób ponawiania połączeń już otwartych.

Wartość usług poza PostgreSQL

Architektura Supabase łączy PostgreSQL z Auth, Storage, API, Realtime i funkcjami w ramach projektu. Dla aplikacji udostępniającej konta użytkowników, pliki i dane przez API zmniejsza to liczbę osobnych usług, które zespół musi zestawić. Wartość tego pakietu zależy jednak od tego, z których części produkt będzie rzeczywiście korzystał.

Neon oferuje obecnie także Managed Better Auth, Object Storage i Functions. Nie wystarcza więc już prosty podział na „samą bazę” oraz „cały backend”. Przy wyborze znaczenie ma konkretne dopasowanie usług: sposób obsługi użytkowników, plików i funkcji oraz to, czy środowiska testowe mają obejmować te zasoby razem z bazą. Zespół mający gotowe rozwiązania w tych obszarach może przypisać im mniejszą wartość niż zespół zaczynający od zera.

Wybór według wzorca ruchu

Prototyp i krótkie testy: Neon ma przewagę, gdy baza naprawdę zasypia między sesjami pracy, a branche z danymi przyspieszają testowanie zmian. Supabase jest sensownym wyborem, jeśli prototyp od początku potrzebuje jego zintegrowanych usług.
Stabilny SaaS: przy stale aktywnej bazie porównaj miesięczny koszt potrzebnej mocy i danych z pełnym rachunkiem Supabase. Skalowanie do zera daje tu niewiele, więc większe znaczenie mają rozmiar instancji, usługi backendowe i zachowanie połączeń podczas zmian.
Ruch skokowy: długie przerwy między falami zapytań sprzyjają Neonowi, o ile opóźnienie wybudzenia jest akceptowalne. Jeżeli zapytania napływają także między szczytami, ważniejsze od uśpienia stają się autoskalowanie aktywnej bazy, pula połączeń oraz czas przygotowania dodatkowych zasobów.

Do oszacowania kosztu potrzebny jest czas, przez który instancja pozostaje aktywna, jej przeciętny i szczytowy rozmiar, ilość danych oraz liczba środowisk testowych. Osobno trzeba wycenić usługi backendowe używane przez produkt. Dopiero taki rachunek pozwala stwierdzić, czy rzeczywiste okresy ciszy dają Neonowi przewagę nad pakietem Supabase.

Przeczytaj także: