Neon to PostgreSQL w modelu serverless: baza usypia, gdy nikt z niej nie korzysta, rośnie przy większym ruchu i pozwala w sekundę zrobić kopię do testów. Na pięciu typowych projektach pokazujemy, kiedy to się opłaca, a kiedy nie.
CEO
04 paź 2026
Większość baz danych w małych i średnich projektach przez większość czasu nic nie robi. Panel dla klientów B2B pracuje w godzinach biurowych, MVP odwiedza kilkadziesiąt osób dziennie, środowisko testowe budzi się, gdy ktoś coś wdraża. A serwer bazy danych działa i kosztuje przez całą dobę. Neon to PostgreSQL w modelu serverless, który odwraca ten układ. Baza zasypia, gdy nikt z niej nie korzysta, budzi się przy pierwszym zapytaniu i sama dokłada mocy, kiedy ruch rośnie. Do tego potrafi w sekundę zrobić pełną kopię bazy do testów, podobnie jak programiści tworzą gałęzie w kodzie.
PostgreSQL to jedna z najpopularniejszych relacyjnych baz danych, czyli takich, w których dane są przechowywane w powiązanych ze sobą tabelach. W tradycyjnym modelu stawia się ją na serwerze albo wykupuje jako usługę w chmurze z określoną mocą, która działa bez przerwy. Serverless to model, w którym nie płaci się za serwer, tylko za faktyczne użycie. Aplikacja uruchamia się na żądanie i znika, gdy nie ma ruchu. Dobrze opisuje to koncepcja FaaS, czyli funkcji uruchamianych w chmurze na żądanie. Bazy danych długo do tego modelu nie pasowały, bo były z natury „zawsze włączone”.
Neon rozdzielił bazę na dwie części. Dane leżą w osobnej warstwie przechowywania, a moc obliczeniowa, czyli to, co wykonuje zapytania, uruchamia się wtedy, gdy jest potrzebna. Dla aplikacji to nadal zwykły PostgreSQL z tymi samymi zapytaniami, rozszerzeniami i narzędziami. Zmienia się sposób działania i rozliczania.
W maju 2025 r. Neon został przejęty przez Databricks, firmę od platform analitycznych. W ogłoszeniu podano, że ponad 80% baz tworzonych w Neonie zakładały automatycznie agenty AI, a nie ludzie.
Startup sprawdza pomysł. Aplikacja ma kilkudziesięciu testowych użytkowników, którzy logują się kilka razy w tygodniu. Budżet jest ograniczony, a nikt nie wie, czy za trzy miesiące projekt będzie żył.
Tu Neon pasuje niemal idealnie. Według cennika Neona z października 2026 r. darmowy plan obejmuje 100 godzin mocy obliczeniowej miesięcznie na projekt i 1 GB danych. Baza usypia po pięciu minutach bezczynności, więc przy małym ruchu darmowy limit często wystarcza na cały miesiąc. Jeśli pomysł się nie sprawdzi, nie zostaje żaden serwer do wyłączenia.
Ceną jest tak zwany zimny start. Po uśpieniu pierwsze zapytanie musi poczekać, aż baza się obudzi, co według dokumentacji Neona trwa kilkaset milisekund. Dla użytkownika MVP, czyli pierwszej wersji produktu do sprawdzenia pomysłu, to zwykle niezauważalne. Przy usłudze, gdzie liczy się każda odpowiedź, trzeba to wziąć pod uwagę.
Firma udostępnia klientom panel do zamówień. Ruch jest przewidywalny: od 8 do 18 w dni robocze, w nocy i w weekendy prawie nic.
Policzmy to na przykładzie. Przy płatnym planie Launch godzina pracy jednostki obliczeniowej (CU, czyli porcji mocy procesora i pamięci) kosztuje 0,106 USD, a gigabajt danych 0,35 USD miesięcznie. Baza korzystająca z pół jednostki przez 10 godzin dziennie przez 22 dni robocze zużyje 110 CU-godzin, czyli około 11,7 USD. Z 5 GB danych rachunek wyniesie około 13,4 USD miesięcznie. Ta sama baza działająca bez przerwy kosztowałaby około 40 USD. To przykładowe wyliczenie, bez transferu danych i dodatkowych funkcji, ale dobrze pokazuje mechanizm. Im bardziej nierówny ruch, tym większa różnica na korzyść modelu serverless. Przy panelu B2B różnica jest wyraźna, choć w złotówkach to wciąż niew ielkie kwoty. Prawdziwe oszczędności pojawiają się przy wielu bazach naraz, o czym za chwilę.
Sklep internetowy na co dzień ma umiarkowany ruch, ale przy kampanii albo wyprzedaży liczba odwiedzin rośnie kilkukrotnie w ciągu kwadransa. Tradycyjną bazę trzeba wtedy albo z góry przeskalować i płacić za zapas, albo liczyć się ze spowolnieniem. Neon dokłada mocy automatycznie, w granicach ustawionych przez zespół, i odejmuje ją, gdy ruch spada. Nie trzeba przewidywać szczytu ani ręcznie zmieniać rozmiaru serwera przed kampanią.
Drugi problem przy takich skokach to liczba połączeń. Aplikacje serverless, na przykład działające na Vercelu albo w AWS Lambda, uruchamiają wiele krótkich instancji naraz, a każda chce własnego połączenia z bazą. Zwykły PostgreSQL ma limit połączeń i przy ruchu z kampanii potrafi go szybko wyczerpać. Neon ma wbudowany pośrednik połączeń PgBouncer, który według dokumentacji przyjmuje do 10 000 połączeń klientów i rozdziela je na mniejszą pulę połączeń do bazy. Ma też sterownik działający przez HTTP, który dobrze sprawdza się w funkcjach brzegowych, czyli kodzie uruchamianym blisko użytkownika.
Autoskalowanie ma jednak górny limit, a jego podniesienie oznacza wyższy rachunek. Przed dużą kampanią i tak warto przeprowadzić testy wydajnościowe i sprawdzić, czy wąskim gardłem nie okażą się nieoptymalne zapytania.
Tu Neon różni się od większości baz najbardziej. Branch, czyli gałąź bazy danych, to pełna kopia danych i struktury, którą tworzy się w sekundę, niezależnie od wielkości bazy. Nie kopiuje się przy tym fizycznie wszystkich danych. Nowa gałąź zapisuje tylko zmiany względem oryginału. W praktyce wygląda to tak. Programista zmienia strukturę tabeli zamówień. System CI/CD, czyli automatycznego budowania i wdrażania zmian, tworzy dla tej zmiany osobne środowisko podglądu z własną gałęzią bazy, zawierającą kopię prawdziwych danych. Tester sprawdza zmianę na realnych zamówieniach, a nie na trzech rekordach testowych. Po zatwierdzeniu gałąź znika.
Dla zespołu oznacza to mniej niespodzianek po wdrożeniu. Migracja, która na pustej bazie testowej trwała sekundę, na kopii produkcji może trwać kwadrans i to lepiej wiedzieć przed wdrożeniem. Narzędzia do zarządzania strukturą bazy, takie jak Prisma czy Drizzle ORM, działają z gałęziami Neona bez zmian.
Na tym samym mechanizmie opiera się szybkie przywracanie danych. Jeśli ktoś przez pomyłkę usunie dane, bazę można cofnąć do stanu sprzed kilku minut albo godzin, w zakresie zależnym od planu. Dane osobowe w kopiach produkcji trzeba jednak traktować tak samo jak w produkcji albo je anonimizować.
Agent AI to program oparty na modelu językowym, który sam wykonuje zadania, na przykład pisze kod albo przygotowuje środowisko. Narzędzia takie jak Cursor czy Claude Code potrafią przez MCP, czyli standard łączenia AI z innymi aplikacjami, samodzielnie założyć bazę w Neonie, utworzyć gałąź i przetestować na niej zmianę. Stąd wzięły się dane z ogłoszenia Databricks o 80% baz tworzonych przez agentów. Platformy, które pozwalają budować aplikacje z poziomu czatu, zakładają osobną bazę dla każdego projektu użytkownika. Większość z nich szybko przestaje być używana. Tu usypianie i rozliczanie za użycie przestają być ciekawostką, a stają się warunkiem opłacalności.
Neon obsługuje też rozszerzenia PostgreSQL do wyszukiwania wektorowego, czyli szukania podobnych znaczeniowo treści. Pozwala to trzymać dane aplikacji i bazę wiedzy dla RAG, czyli odpowiadania przez AI na podstawie firmowych dokumentów, w jednej bazie, bez osobnego systemu.
Model serverless wygrywa przy nierównym ruchu. Przy ruchu stałym przewaga znika, a czasem się odwraca. Kilka sytuacji, w których lepiej rozważyć coś innego:
Ostatni przypadek to często pole dla Supabase, czyli backendu open source zbudowanego wokół PostgreSQL. Neon rozwija własne usługi dodatkowe, ale w centrum nadal stoi baza. Inną filozofię ma też PlanetScale, który wyrosł z ekosystemu MySQL.
Jedna rzecz przemawia za Neonem nawet przy wątpliwościach. To zwykły PostgreSQL. Jeśli projekt utonie i stała instancja okaże się tańsza, dane przenosi się standardowymi narzędziami, bez przepisywania aplikacji.
Przeniesienie istniejącej bazy PostgreSQL to zwykle eksport danych, import do Neona i zmiana adresu połączenia w aplikacji. Przy większych bazach stosuje się replikację logiczną, która synchronizuje dane na bieżąco i pozwala przełączyć aplikację z minimalną przerwą. Więcej pracy wymaga dostosowanie aplikacji do modelu serverless. Trzeba korzystać z puli połączeń, ustawić rozsądne limity autoskalowania i sprawdzić, które części systemu nie znoszą zimnego startu. Od razu dobrze jest też podpiąć gałęzie bazy do procesu wdrażania, bo to one dają zespołowi najwięcej na co dzień. Neon dobrze pasuje do aplikacji w Next.js i Node.js, które budujemy na co dzień, szczególnie gdy działają w modelu serverless.
Wybór bazy to jednak decyzja architektoniczna, którą lepiej podjąć na podstawie profilu ruchu i wymagań co do danych niż mody. Pomagamy w tym w ramach usług DevOps i architektury, a przenosiny istniejących systemów prowadzimy jako migracje aplikacji.
Jeśli zastanawiasz się, czy Neon pasuje do Twojego projektu, napisz do nas przez formularz kontaktowy Boring Owl.
FAQ
Blog
Czy jesteś gotowy na rewolucję w obszarze baz danych w chmurze? PlanetScale, przez wielu uznawany za game-changer, otwiera nową erę w świecie DBaaS. Oparte na udoskonalonym MySQL, gwarantuje skalowalność, wydajność i niezawodność na nieosiągalnym dotąd poziomie.
ERD, czyli Diagram Zależności Encji, to nieodłączny element procesu projektowania bazy danych. Tworzony na etapie analizy systemu, umożliwia wizualizację struktury informacji w organizacji, stając się fundamentem dla efektywnego tworzenia modelu bazy danych. Pozwala bowiem dostrzec wszystkie powiązania i zależności pomiędzy różnymi elementami systemu informacyjnego, zapobiegając potencjalnym błędom na późniejszych etapach realizacji projektu.
Transakcje ACID odgrywają kluczową rolę w zapewnianiu integralności i niezawodności baz danych. Aczkolwiek, jak to działa w praktyce? W tym artykule pochylimy się nad koncepcją ACID - zrozumiemy jej fundamentalne zasady i pokażemy, jak przyczynia się ona do efektywnego i bezpiecznego zarządzania danymi w różnych scenariuszach.
Zarządzanie wydajnością bazy danych to niezmiennie gorący temat. Jednym z technik, które znacznie przyspieszają jej działanie, jest Batch Fetching. Jest to metoda grupowania zapytań, która pozwala na znaczące optymalizacje. Zapraszam do lektury, w której podejmiemy próbę zrozumienia jak to działa i jak możemy z tego skorzystać.
Poznaj Drizzle-ORM, potężne narzędzie do zarządzania bazami danych, które usprawni Twoją pracę w obszarze programowania. Dowiedz się, jak wykorzystać jego funkcje do efektywnej manipulacji danymi, optymalizacji zapytań i zintegrowania z różnymi platformami. Nasz przewodnik po Drizzle-ORM poprowadzi Cię przez proces od podstaw do zaawansowanych technik.
Sztuczna inteligencja rozwija się w błyskawicznym tempie, a jednym z jej najnowszych i najbardziej obiecujących osiągnięć jest technologia RAG (Retrieval-Augmented Generation). To innowacyjne podejście łączy możliwości generowania tekstu przez AI z dynamicznym wyszukiwaniem informacji w zewnętrznych źródłach. Dzięki temu odpowiedzi są nie tylko poprawne językowo, ale także aktualne i oparte na zweryfikowanych danych.
