Nie jest to jednak koncepcja uniwersalna. Supabase i Aurabase, które udostępniają dedykowane instancje Postgres, nie eksponują tego samego mechanizmu w ten sam sposób. W tym artykule szczegółowo opisano, co faktycznie dokumentuje Neon podczas własnego zimnego startu, jak porównują się Vercel Postgres i Supabase oraz gdzie pasuje model Aurabase, co zostało zweryfikowane bezpośrednio w kodzie dostawcy usług, a nie wywnioskowane ze strony marketingowej.
Najważniejsze
- Bezserwerowy zimny start odnosi się do opóźnienia dodanego, gdy zawieszona baza danych musi obudzić swoje obliczenia przed odpowiedzią na pierwsze żądanie.
- Neon oddziela przechowywanie i obliczenia: komputer przechodzi w tryb uśpienia po udokumentowanym okresie bezczynności (domyślnie 5 minut w planie darmowym, konfigurowalne w planach płatnych).
- Neon dokumentuje ponowne uruchomienie w ciągu kilkuset milisekund do kilku sekund, a wartość tę publikuje wydawca i można ją zmierzyć na żywo za pomocą narzędzia społecznościowego neon-latency-benchmarks.vercel.app.
- Vercel Postgres opiera się na infrastrukturze Neon: zachowanie pobudzeniowe opiera się na tej samej mechanice, ale pod inną marką.
- Supabase zapewnia dedykowaną bazę danych dla każdego projektu, bez zimnego startu na połączenie. Tylko plan bezpłatny wstrzymuje nieaktywne projekty z możliwością ręcznego przywrócenia.
- Aurabase zapewnia dedykowaną bazę danych Postgres dla każdego projektu, dedykowany klaster CNPG lub dedykowaną bazę na współdzielonym klastrze: nie jest to model bezserwerowy Neon, zweryfikowany w kodzie dostawcy usług.
Co to jest zimny start bezserwerowej bazy danych Postgres?
Zimny start ma miejsce, gdy obliczenia uruchamiające bazę danych zostały uśpione z powodu braku aktywności, a nowe zapytanie musi najpierw zostać zrestartowane przed uruchomieniem. Nie jest to zwykłe opóźnienie sieciowe typowego połączenia TCP/TLS: jest to czas na uruchomienie nowego procesu Postgres i przywrócenie jego stanu, jeszcze przed rozpoczęciem wykonywania pierwszego żądania.
Termin ten pochodzi z szerokiego pojęcia przetwarzania bezserwerowego, w którym zerowe środowisko wykonawcze musi zostać ponownie uruchomione przed przetworzeniem żądania, niezależnie od tego, czy jest to funkcja serwera, czy środowisko wykonawcze WebAssembly na brzegu. Szczegółowo opisujemy ten mechanizm po stronie funkcji brzegowych w naszym artykule na temat zestawu WebAssembly zimnego startu skierowanego do kontenerów. W przypadku bazy danych mechanika jest inna: uruchamia się nie skompilowany plik binarny, ale kompletny serwer Postgres, który musi ponownie otworzyć swoje pliki, sprawdzić ich stan, a następnie zaakceptować nowe połączenia.
1. Logowanie Klienta
Otrzymano żądanie dotyczące projektu, którego obliczenia zostały zawieszone.
2. Wykrywanie snu
Platforma zauważa, że obliczenia nie są już aktywne.
3. Ponowne uruchamianie obliczeń
Proces Postgres uruchamia się ponownie, przywracany jest niezbędny stan.
4. Żądanie przetworzone
Połączenie powiodło się, żądanie jest wykonywane normalnie.
Ilustracja mechanizmu zimnego startu, uproszczona kolejność, bez mierzonej wartości czasu.
Dlaczego Neon uśpił swoje obliczenia i z jaką szybkością
Neon dzieli swoją architekturę bazy danych na dwie odrębne warstwy: pamięć trwałą, w której przechowywane są dane, oraz obliczenia, czyli sam proces Postgres, który można niezależnie zatrzymać i uruchomić ponownie. To oddzielenie pozwala Neonowi zawiesić obliczenia nieaktywnego projektu bez dotykania danych, a następnie ponownie uruchomić go na żądanie, zgodnie z oficjalną dokumentacją.
W planie bezpłatnym Neon dokumentuje domyślny limit czasu bezczynności wynoszący 5 minut przed uśpieniem komputera. Plany płatne pozwalają skonfigurować ten próg, a nawet znacznie go zwiększyć do użytku przy stałym ruchu. Ten typ ustawień domyślnych zmienia się wraz z aktualizacjami produktu: w momencie czytania należy sprawdzić dokumentację Neona, a nie tę odosobnioną ilustrację.
Ten projekt służy konkretnemu celowi, efemerycznym środowiskom. Baza danych na gałąź Git, środowisko podglądu za pomocą żądania ściągnięcia, testowa baza danych, która jest używana tylko przez kilka minut dziennie: ciągłe wykonywanie obliczeń dla tych zastosowań jest kosztowne i nie przynosi żadnych realnych korzyści. Zawieszenie obliczeń między dwoma zastosowaniami zmniejsza rachunek bez usuwania danych – jest to główny argument bezserwerowego modelu Neon.
Jak długo działa budzik Neon i jak to sprawdzić samodzielnie
Neon wskazuje w swojej dokumentacji ponowne uruchomienie obliczeń trwające zazwyczaj od kilkuset milisekund do kilku sekund, w zależności od rozmiaru projektu i ilości dzienników transakcji, które należy odtworzyć, zanim obliczenia będą gotowe. To liczba opublikowana przez samego wydawcę, a nie niezależny audyt: traktuj ją jako udokumentowany rząd wielkości, a nie gwarancję umowną.
Do pomiaru w świecie rzeczywistym narzędzie społeczności publicznej neon-latency-benchmarks.vercel.app ankiety zawieszały projekty Neon w regularnych odstępach czasu i wyświetlały zaobserwowane opóźnienie wybudzenia. Jest to rodzaj metodologii, który ma większe znaczenie niż same dane zawarte w dokumentacji: warunki testowe pozostają widoczne, a nie ukryte za średnią marketingową. Stosujemy tę samą zasadę w naszej własnej metodologii testów porównawczych backendu: publikuj protokół przed opublikowaniem rysunku.
| Rozmiar projektu | Więcej relacji i wolumin WAL do sprawdzenia sprawiają, że ponowne uruchomienie jest dłuższe. |
|---|---|
| Region i odległość sieciowa | Zwiększa opóźnienie połączenia, niezależnie od samego zimnego startu. |
| Plan cenowy | Plany płatne umożliwiają skonfigurowanie lub wydłużenie progu braku aktywności. |
| Częstotliwość połączeń | Obliczenia, które są regularnie żądane, nigdy nie doświadczają tego opóźnienia. |
Vercel Postgres i Neon: ten sam silnik pod inną marką?
Firma Vercel zbudowała swoją ofertę baz danych Postgres w oparciu o infrastrukturę Neon, a partnerstwo zostało upublicznione w 2024 r. W chwili pisania tego tekstu integracja z Postgres jest oferowana na platformie Vercel Marketplace jako opcja przechowywania wraz z innymi dostawcami. Sprawdź zaktualizowaną stronę produktu Vercel: ten rodzaj partnerstwa szybko ewoluuje na rynku, który zmienia się co kwartał.
Konkretnie, zachowanie bazy danych Postgres w trybie uśpienia i wybudzenia udostępnionej za pośrednictwem Vercela przebiega według tej samej mechaniki, co ta opisana powyżej bezpośrednio dla Neona. Nie jest to oddzielny silnik z własnym modelem zimnego rozruchu, to ta sama infrastruktura ukryta za integracją Vercel.
Czy Supabase ma porównywalny zimny start?
Nie, nie w ten sam sposób. Supabase zapewnia dedykowaną instancję Postgres na projekt, a nie bezserwerowe obliczenia zawieszane na połączenie. Dlatego też, w przeciwieństwie do modelu Neon, do każdej nowej sesji nie jest dodawane opóźnienie budzenia po kilku minutach bezczynności.
Jednak w planie darmowym istnieje inny mechanizm: Supabase dokumentuje automatyczne wstrzymywanie nieaktywnych projektów po dłuższym okresie, rzędu tygodnia, zgodnie z dokumentacją, z ręcznym przywróceniem z poziomu pulpitu nawigacyjnego, a nie automatycznym wznowieniem na pierwsze żądanie. Jest to próg mierzony w dniach, a nie minutach i wyraźne działanie, a nie przejrzyste odzyskiwanie: dwie różnice strukturalne w przypadku zimnego rozruchu Neona, a nie prosta odmiana tego samego mechanizmu. Aby uzyskać pełne porównanie architektury, nasze szczegółowe porównanie Aurabase vs Supabase dokumentuje inne rozbieżności.
I model Aurabase: dlaczego porównanie nie ma zastosowania w obecnej postaci
Aurabase nie oferuje modelu bezserwerowego, takiego jak Neon. Zweryfikowany w kodzie Provisioner (aura-provisioner, open source na github.com/daylami555/aurabase): każdy projekt otrzymuje albo dedykowany klaster Postgres zarządzany przez CloudNativePG, operatora Kubernetes CNPG, albo dedykowaną bazę na klastrze CNPG współdzielonym przez kilka projektów tej samej organizacji, w zależności od wybranego planu. W obu przypadkach nie jest to pojedyncze obliczenie, które zawiesza się i wznawia przy każdym połączeniu: jest to kompletny klaster Postgres z replikami podstawowymi i możliwymi.
Mechanizm hibernacji istnieje po stronie Aurabase, ale służy innemu celowi. W przypadku długotrwałej bezczynności, domyślnie 7 dni i konfigurowalnej za pomocą zmiennej środowiskowej, progu weryfikowanego w kodzie, dostawca usług uśpi nieaktywne instancje, aby zwolnić zasoby, a nie w celu optymalizacji opóźnienia sporadycznego użycia. Budzenie uśpionego klastra CNPG powoduje odtworzenie jego podów z woluminów trwałych, co jest strukturalnie cięższym mechanizmem niż proste ponowne uruchomienie procesu bezserwerowego.
Aurabase nie opublikował jak dotąd żadnych danych dotyczących opóźnienia wybudzenia, ani nie twierdził, że jest to szybki czas wybudzania, ani nie porównywał go z Neonem. To nie jest ten sam produkt i nieuczciwością byłoby przedstawianie go jako takiego bez opublikowanych pomiarów.
Ta dedykowana architektura ma bezpośredni odpowiednik pod względem izolacji i przewidywalności wydajności: projekt nie współdzieli swoich obliczeń z innym projektem, w przeciwieństwie do współdzielonego klastra o małej wielkości. Szczegółowo opisujemy ten arbitraż w dedykowanym artykule: dedykowana vs baza współdzielona, rzeczywisty wpływ na wydajność i izolację.
Wybierz zgodnie ze swoim przypadkiem użycia
Model bezserwerowy Neon jest przeznaczony dla konkretnego przypadku użycia: wielu środowisk efemerycznych lub środowisk o bardzo sporadycznym ruchu, gdzie płacenie za nieprzerwane obliczenia nie ma ekonomicznego sensu. Baza danych na oddział Git, środowisko podglądu za pomocą żądania ściągnięcia, prototyp testowany kilka razy w tygodniu: okazjonalny zimny start staje się akceptowalnym kompromisem w stosunku do faktury proporcjonalnej do rzeczywistego wykorzystania.
Z drugiej strony, dedykowana, zawsze włączona architektura Postgres staje się preferowana zawsze, gdy opóźnienie pierwszego połączenia musi pozostać przewidywalne: produkcyjne API z regularnym ruchem, backend, który nie może sobie pozwolić na sporadyczne skoki opóźnień na żądanie użytkownika, lub system, w którym p99 ma większe znaczenie niż koszt izolowanej gałęzi testowej.
| Dostawca | Model obliczeniowy | Wyzwalacz snu | Typowy budzik |
|---|---|---|---|
| Neon | Przetwarzanie bezserwerowe oddzielone od pamięci masowej | Brak aktywności, od 5 minut (abonament bezpłatny) | Automatyczny, sekunda do sekundy (twierdzony redaktor) |
| Vercela Postgresa | Infrastruktura Neonowa (partnerstwo) | Podobnie jak Neony | Podobnie jak Neony |
| Supabaza | Dedykowany organ dla każdego projektu | Dłuższy brak aktywności, tylko plan bezpłatny | Ręcznie, przywróć z pulpitu nawigacyjnego |
| Aurabaza | Dedykowany lub współdzielony klaster CNPG | Dłuższy brak aktywności, domyślnie 7 dni | Nie jest przeznaczony jako subsekundowy, nie jest publikowany |
Neonowy budzik: rząd wielkości udokumentowany przez wydawcę, niepotwierdzony niezależnym audytem. Próg hibernacji Aurabase: zaznaczono aura-provisioner, zmienna HIBERNATE_INACTIVITY_DAYS, domyślnie 7 dni.
Często zadawane pytania
O czym pamiętać
Bezserwerowy zimny start Postgres nie jest koncepcją uniwersalną: jest bezpośrednią konsekwencją architektury Neon, która oddziela przechowywanie i obliczenia, aby zawiesić to drugie między dwoma zastosowaniami. Vercel Postgres dziedziczy ją bezpośrednio poprzez partnerstwo z Neonem. Supabase i Aurabase, które udostępniają dedykowane instancje Postgres, udostępniają inny mechanizm mierzony w dniach, a nie minutach, który nie jest przeznaczony do tego samego celu.
Zanim wybierzesz dostawcę wyłącznie na podstawie tego kryterium, sprawdź trzy rzeczy: faktyczny próg bezczynności udokumentowany przez dostawcę, czy można go skonfigurować w ramach Twojego planu oraz czy ruch w Twojej aplikacji uzasadnia zawieszenie przetwarzania. W przypadku rzeczywistego, sporadycznego ruchu, gałęzi testowych lub podglądów model bezserwerowy zapewnia wyraźne korzyści ekonomiczne. W przypadku produkcji o regularnym ruchu dedykowana architektura po prostu eliminuje ten problem.