> ## Content Index > Fetch the complete content index at: https://lsdev.pl/llms.txt > Use this file to discover other available public pages before exploring further. # Managed vs self-hosted PostgreSQL: kiedy się opłaca - URL: https://lsdev.pl/posts/managed-vs-self-hosted-postgresql-kiedy-sie-oplaca/ - Published: 2026-09-06T19:02:39.000Z - Updated: 2026-09-06T19:03:32.000Z - Description: RDS Multi-AZ kosztuje ponad dwukrotnie więcej niż Single-AZ. Patroni wymaga osobnego DCS i wrażliwości na awarię okna bez redundancji. Decyzja nie spada na liczbę rdzeni — pada na pytanie, czy utrzymanie HA jest już czyjąś pracą, czy zawsze projektem specjalnym. - Author: Łukasz Sakowicz - Tags: PostgreSQL, RDS, Kubernetes, Patroni, infrastruktura, HA, #lsdev-ai Telefon dzwoni o drugiej w nocy, bo primary Postgresa właśnie padł. W modelu managed to problem AWS albo Microsoftu — w modelu self-hosted to problem osoby, która akurat ma dyżur, niezależnie od tego, czy umie odróżnić awarię sieci od awarii dysku. Pytanie „managed czy self-hosted” rzadko rozstrzyga się na liczbie rdzeni albo cenie za GB storage. Rozstrzyga się na tym, ile godzin specjalistycznej uwagi jesteś gotów zamienić na rachunek, który i tak przyjdzie — tylko w innej walucie. ## Za co realnie płacisz w modelu managed RDS dla PostgreSQL w konfiguracji Multi-AZ utrzymuje synchroniczny standby w innej zonie dostępności i automatycznie przełącza ruch przy awarii instancji — to jest cały sens tej opcji. Cena tej gwarancji nie jest liniowa. Blog go-cloud.io szacuje, że samo włączenie Multi-AZ dokładnie podwaja opłaty za compute i storage względem wariantu Single-AZ, a dokumentacja AWS dodaje, że przy każdej aktualizacji bazy zużycie I/O rośnie dwukrotnie, bo dane są synchronicznie replikowane do standby. Storage potrafi zaskoczyć osobno: w przykładzie z dokumentacji AWS dedykowany wolumin logów io1 o pojemności 1024 GiB i 3000 IOPS w regionie US East (N. Virginia) kosztuje około 428 USD miesięcznie dla samej instancji Single-AZ — a to tylko wolumin logów, bez kosztu obliczeń. Podobnie w Azure Database for PostgreSQL: materiały Azure dotyczące rozliczeń wskazują, że serwer zone-redundant HA o konfiguracji 8 vCore i 1024 GiB storage jest rozliczany za compute i storage obu replik naraz — primary i secondary. Dokumentacja Microsoft Learn podaje, że w zamian failover trwa 60–120 sekund bez utraty danych; jeśli jednak cała zona padnie bez włączonej redundancji zonalnej, jedyną drogą powrotu jest odtworzenie point-in-time z backupu, nie automatyczny switchover. Managed nie kończy się na dniu wdrożenia. Dokumentacja AWS pokazuje, że Extended Support pozwala trzymać główną wersję PostgreSQL nawet trzy lata po tym, jak community przestaje ją wspierać — ale opłaty Multi-AZ nadal dotyczą obu instancji w tej konfiguracji, nie tylko primary. To jest koszt, który rośnie z czasem, nie opada. ## Czego wymaga własny klaster HA, zanim Patroni czy CloudNativePG zaczną działać CloudNativePG opiera wysoką dostępność na fizycznej replikacji WAL wbudowanej w PostgreSQL, nie na replikacji na poziomie storage — dokumentacja projektu wprost odradza tę drugą strategię, choć technicznie ją dopuszcza. To dobra decyzja inżynierska, ale nie zwalnia z infrastruktury pod spodem. Ta sama dokumentacja zaleca wdrażanie węzłów Postgresa w wielokrotnościach trzech — jeden na zonę dostępności — tak, żeby klaster z primary i dwoma standby faktycznie był rozproszony na różne węzły. Problem: dokumentacja zaznacza, że rekomendowane minimum to trzy zony dostępności dla samego klastra Kubernetes, a typowe samodzielnie zarządzane klastry on-premise mają dostępne tylko jedno centrum danych. Jeśli Kubernetes stoi w jednej lokalizacji, cała architektura „trzech węzłów w trzech zonach” jest fikcją na papierze — i to zanim policzysz koszt samego Postgresa. CloudNativePG ma też twardą granicę: nie wykonuje automatycznego failover między klastrami Kubernetes, bo nie ma władzy poza jednym klastrem. Disaster recovery między regionami to ręczny proces, nie funkcja operatora. Patroni jest starszym i bardziej elastycznym podejściem — ale wymaga własnej warstwy konsensusu. Dokumentacja Patroni jest tu jednoznaczna: DCS (etcd, ZooKeeper albo Consul) musi działać w konfiguracji trzech albo pięciu węzłów, żeby konsensus i odporność na awarie miały sens. To nie jest dodatek — to trzeci komponent, który sam wymaga monitoringu, aktualizacji i planu na własną awarię, zanim jeszcze dotknie się Postgresa. ## Awaria o 2 w nocy: co naprawdę różni managed od self-hosted Tu leży różnica, której nie widać w cenniku. Replikacja strumieniowa w PostgreSQL jest domyślnie asynchroniczna — dokumentacja projektu ostrzega, że jeśli primary padnie, część zatwierdzonych transakcji może nie zdążyć się zreplikować do standby, co oznacza realną utratę danych. To dotyczy zarówno RDS, jak i klastra Patroni, jeśli nie ustawi się `synchronous_commit` inaczej niż domyślnie. Przy replikacji synchronicznej każde zatwierdzenie transakcji czeka na potwierdzenie zapisu WAL na dysku na primary i na standby — dokumentacja PostgreSQL podaje, że utrata danych jest możliwa tylko wtedy, gdy primary i standby ulegną awarii jednocześnie. To jest właściwe ustawienie dla danych, których nie można stracić, ale kosztuje opóźnienie każdego commitu. W klastrze Patroni z dwoma węzłami failover jest automatyczny, ale dokumentacja projektu zaznacza, że przez chwilę po przełączeniu nie ma żadnej redundancji, dopóki uszkodzony węzeł nie wróci do klastra. W tym oknie druga awaria oznacza brak standby, na który można się przełączyć — i to jest moment, w którym różnica między managed i self-hosted przestaje być teoretyczna, a staje się pytaniem, kto o 2 w nocy wie, że trzeba ręcznie dołączyć węzeł z powrotem do klastra. ## Gdzie przebiega próg opłacalności Dokumentacja Patroni mówi to bez ogródek: testowanie rozwiązania HA jest procesem czasochłonnym z wieloma zmiennymi i wymaga wyszkolonego administratora systemów albo konsultanta. Nie ma tu podanej liczby godzin tygodniowo — i to nie przypadek: ta liczba zależy od tego, jak często coś się psuje, a nie od kalendarza, więc żadna dokumentacja jej nie poda. Decyzję trzeba więc oprzeć na innym pytaniu: czy w zespole jest ktoś, dla kogo utrzymanie DCS i operatora jest już częścią etatu, czy to zawsze będzie projekt specjalny, na który ktoś musi rzucić inne rzeczy. Nieoficjalne wyliczenie z bloga selfhost.dev (to nie jest materiał producenta, tylko szacunek jednego autora, więc traktuj poniższe liczby jako rząd wielkości, nie cennik) daje punkt odniesienia: w pełni zarządzany RDS z Multi-AZ, repliką i backupami wychodzi tam na około 744 USD miesięcznie, self-hosted na EC2 na około 332 USD samej infrastruktury — ale ponad 832 USD, gdy dolicza się czas pracy inżynierów — a model BYOC (zarządzane operacje na własnej infrastrukturze) na 300–400 USD miesięcznie. | Sytuacja zespołu | Orientacyjny koszt/mies. (wg selfhost.dev, szacunek jednego autora) | Decyzja | | ---------------------------------------------------------------- | ------------------------------------------------------------------- | ----------------------------------------- | | Nikt nie zna Patroni/etcd/CloudNativePG na poziomie produkcyjnym | RDS Multi-AZ \~744 USD | Managed (RDS / Cloud SQL / Azure) | | Jest senior ops, ale zajęty innymi projektami | Self-hosted \~332 USD infra, \~832 USD z czasem pracy | Managed, dopóki nie zwolni się etat | | Utrzymanie DCS/operatora jest już częścią czyjegoś etatu | BYOC \~300–400 USD zarządzane | CloudNativePG na Kubernetesie z trzema AZ | Odpowiedź na pytanie „kiedy się to opłaca” nie jest liczbą serwerów ani liczbą godzin — to moment, w którym utrzymanie DCS i operatora przestaje być projektem specjalnym i staje się czyjąś codzienną pracą. Poniżej tego punktu bierz managed i przestań o tym myśleć — ręczne HA kosztuje więcej w przerwanych nocach, niż zaoszczędzisz na rachunku. Powyżej — CloudNativePG na własnym Kubernetesie z trzema zonami dostępności jest rozsądniejszym wyborem niż goły Patroni z ręcznie stawianym etcd, bo operator przejmuje część roboty, którą inaczej robiłoby się ręcznie. Nie wybieraj Patroniego tylko dlatego, że jest starszy i lepiej znany — jeśli masz Kubernetesa i trzy zony, CloudNativePG daje tę samą fizyczną replikację WAL z mniejszą liczbą osobnych komponentów do utrzymania.