PostgreSQL Samodzielnie Hostowany na VPS: Uniknij Kosztów Zarządzanej Bazy Danych

Obliczenia. Pamięć. Retencja kopii zapasowej.

Eksport migawki, o którym zapomniałeś. Opłata za transfer z otoczenia testowego, które uruchomiło 'pg_dump’ w zeszły wtorek.

Nikt nie otwiera faktury za zarządzaną bazę danych spodziewając się niskich kosztów.

Ależ cholera.

Różnica między ofertą „Postgres za 25 dolarów miesięcznie” a tym, co pojawia się na karcie, stała się duża, a 4 GB VPS w cenie pojedynczego dodatku Supabase teraz obsługuje całą Twoją bazę danych, pozostawiając jeszcze miejsce na pamięć podręczną systemu operacyjnego dla często używanych stron.

Samodzielne hostowanie produkcyjnej bazy danych Postgres nie jest już operacyjnym koszmarem, jakim bywało kiedyś. Repozytorium PostgreSQL Global Development Group (PGDG) jest solidne; współczesne instalacje PostgreSQL (v14+) domyślnie używają szyfrowania haseł SCRAM-SHA-256, a starsze MD5 zostało oficjalnie wycofane od wersji v18. Powody, dla których ludzie pozostają przy RDS, Supabase lub Neon, są operacyjne, a nie techniczne.

Mówimy o rzeczywistych fakturach, rzeczywistych kosztach operacyjnych i jak naprawdę wygląda nowoczesny hosting Postgres.

Ile Naprawdę Kosztuje Samodzielne Hostowanie PostgreSQL na VPS?

Samodzielnie hostowany PostgreSQL na 4 GB VPS zazwyczaj kosztuje ułamek w porównaniu z równoważnymi cenami RDS, Supabase Pro lub Neon Scale, gdy w rachunek zarządzany wliczone są magazynowanie, kopie zapasowe i transfer danych.

PostgreSQL jest bazą danych, której używa 55,6% programistów, według ankiety Stack Overflow z 2025 roku dla programistów, najpopularniejszą przez ostatnie dwa lata. To również baza danych, którą możesz wygodnie obsługiwać samodzielnie.

Porównanie dla reprezentatywnego obciążenia małego zespołu (4 GB RAM, ~100 GB danych, niskie do umiarkowanego obciążenie zapisem, pojedynczy region), wycenione na maj 2026:

Opcja	Obliczenia	Pamięć	Transfer poza darmowym limitem	Najlepsze dla
Samodzielnie hostowany na VPS 4 GB	Stała cena planu	Zazwyczaj wliczone	Zazwyczaj nielimitowany lub wysoki limit	Stałe obciążenia, zespoły wrażliwe na koszty, komfortowe z Linuxem
AWS RDS db.t4g.medium	47,45 USD/miesiąc tylko za obliczenia	~0,115 USD/GB-miesiąc gp3	~0,09 USD/GB internet/poza regionem	Zespoły, które chcą zarządzanych kopii zapasowych, failoveru i operacji natywnych dla AWS
Supabase Pro	25 USD/miesiąc baza + zużycie	0,125 USD/GB dysku bazy danych poza 8 GB wliczonymi w cenę	0,09 USD/GB po 250 GB	Aplikacje potrzebujące Postgres, autoryzacji, pamięci i czasu rzeczywistego w jednym stosie
Neon Scale	0,222 USD za CU/godzinę	0,35 USD za GB/miesiąc	Rozliczanie zgodne z użyciem	Zmienne, obciążone przeglądami, ciężkie workflow rozwoju

Cena usługi RDS db.t4g.medium na żądanie wynosi około $0.065 na godzinę, czyli około $47.45 miesięcznie tylko za obliczenia.

Dodaj 100 GB pamięci gp3 za około 0,115 USD/GB-miesiąc oraz automatyczne kopie zapasowe, a pojedyncza instancja AZ osiągnie wartość około 60 USD/miesiąc. Włącz przełączanie awaryjne Multi-AZ, a linia obliczeniowa mniej więcej się podwoi, co spowoduje, że konfiguracja klasy produkcyjnej osiągnie 100 USD/miesiąc i więcej.

To nie jest mała luka.

Self-hosting jest tańszy, ponieważ ty wykonujesz pracę, za którą płacił zarządzany rachunek. Dyscyplina operacyjna, dyżur, o 2 nad ranem, gdy dysk się zapełnia. Alternatywa zarządzanej bazy danych, z którą się porównujesz, może mieć inną dolną granicę w przyszłym kwartale, więc przelicz koszty na własnym rachunku zanim się zobowiążesz.

Kiedy Ma Sens Samodzielne Hostowanie PostgreSQL?

Samodzielne hostowanie PostgreSQL na VPS ma sens, gdy w zespole jest osoba z podstawową znajomością Linuxa, stabilne obciążenie, przewidywalny rozmiar zestawu roboczego i rzeczywisty powód, aby uniknąć rachunku za usługę zarządzaną.

Nie działa, gdy nie masz możliwości operacyjnych, regulowanych wymagań HA, których nie możesz samodzielnie zbudować, lub gdy masz do czynienia ze wzorcem z korzyściami wynikającymi ze skali natychmiastowej.

Trzy rzeczy wpływają na tę decyzję. Koszt, prywatność i suwerenność danych oraz kontrola.

Gdzie hosting własny wygrywa zdecydowanie:

• Stały ruch w jednym regionie z przewidywalnym zestawem roboczym.
• Małe do średnich aplikacji SaaS z jedną bazą danych Postgres i zespołem zaznajomionym z Linuxem.
• Prace wrażliwe na prywatność, gdzie baza danych nie powinna znajdować się w dzierżawie kogoś innego.
• Zespoły dbające o koszty, których zarządzane rachunki przekroczyły próg operacyjnych kłopotów.

Gdzie zarządzanie wygrywa bezapelacyjnie:

• Zadania o nieregularnym obciążeniu, które korzystają z natychmiastowego zwiększania i zmniejszania skali.
• Konfiguracje wieloregionalne, gdzie produktem jest globalna replikacja.
• Środowiska regulowane wymagające gotowych rozwiązań HA, certyfikatów zgodności i ścieżek audytu.
• Zespoły bez dodatkowej zdolności operacyjnej i bez planów na jej rozbudowę.

Liczba oszczędności kosztów w wysokości 40% do 60% jest często cytowana. Datuj to ostrożnie.

W 2021 roku, autor AWS Rupesh Desai udokumentował, że PostgreSQL na EC2 działa o 40% do 60% taniej niż RDS przy równoważnych specyfikacjach, starszy niż większość obecnych rodzin instancji RDS.

Obecna wersja to analiza kosztów byteiota, opublikowana pod koniec 2025 roku, która wskazuje, że RDS jest o 75% do 88% droższe niż odpowiedni dedykowany sprzęt.

Szacowny próg rentowności to godziny operacyjne, a nie koszt serwera.

Jak Wybrać Odpowiedni Rozmiar VPS dla PostgreSQL?

Większość baz danych aplikacji produkcyjnych działa sprawnie na 4 GB RAM z pamięcią NVMe. Większe zbiory danych, intensywne równoczesne połączenia lub obciążenia analityczne zwiększają wymagania do 8 GB lub 16 GB i więcej.

RAM decyduje o tym, ile ze zbioru roboczego Postgres może przechowywać w pamięci; gdy gorące strony są zapisywane na dysku, zapytania spowalniają. NVMe ma znaczenie, ponieważ Postgres jest wrażliwy na opóźnienia przy losowym odczycie gorących stron oraz na przepustowość opróżniania dla dziennika zapisu z wyprzedzeniem.

Typowe wskazówki dostrajania PostgreSQL zaczynają się od:

• shared_buffers około 25% RAM systemowego.
• effective_cache_size około 50%-75% RAM systemowego.
• work_mem rozmiar z konserwatywnym podejściem — oparty na złożoności równoczesnych zapytań, a nie tylko na całkowitym RAM.

Na 4 GB VPS oznacza to zwykle przydzielenie około 1 GB na shared_buffers, pozostawiając wystarczająco dużo pamięci na bufor strony systemu Linux, aby przechowywać często używane dane. Ta równowaga jest częścią powodu, dla którego skromne 4 GB pudełko może komfortowo obsługiwać wiele małych do średnich obciążeń produkcyjnych.

Mapa planu do obciążenia, którą musisz znać:

Poziom RAM	Typowe Obciążenie	Zalecany Plan Stosu
2 GB	Środowiska developerskie, projekty poboczne o niskim ruchu	Poniżej podstawowego
4 GB	Większość baz danych aplikacji produkcyjnych	Stos 4
8 GB	Większe zbiory danych, więcej jednoczesnych połączeń	Stos 8
16 GB+	Postgres wraz z innymi ciężkimi usługami, analiza	Stos 16

VPS Hosting DreamHost oferuje dostęp Root, pamięć NVMe i niemierzony transfer danych w ramach przewidywalnego miesięcznego rachunku.

To cztery rzeczy, od których zależy samodzielnie hostowana praca w Postgres.

Jak Zainstalować PostgreSQL na VPS?

Instalujesz PostgreSQL na VPS w pięciu skondensowanych krokach.

1. Konfiguracja VPS: Wybierz plan z wystarczającą ilością RAM dla twojego zestawu roboczego (bazowa konfiguracja to Stack 4/4 GB). Zalecanym systemem operacyjnym jest Ubuntu 24.04 LTS. Użyj uwierzytelniania na bazie kluczy, a nie hasła, aby się połączyć przez SSH.
2. Instalacja z oficjalnego repozytorium PGDG: Domyślna dystrybucja ‘apt install postgresql’ opóźnia główne wersje. Dodaj repozytorium apt PGDG, a następnie ‘sudo apt install postgresql-18.’ Potwierdź przy użyciu ‘sudo systemctl status postgresql’
3. Ustaw hasło postgres i stwórz rolę dla swojej aplikacji: Uruchom sudo -i -u postgres, następnie psql, a potem password postgres. Stwórz dedykowaną rolę o minimalnych uprawnieniach: ‘CREATE ROLE myapp WITH LOGIN PASSWORD '...';’ oraz ‘CREATE DATABASE myapp_prod OWNER myapp;’
4. Poprawnie przypisz nasłuchiwanie: Otwórz /etc/postgresql/18/main/postgresql.conf. Ustaw listen_addresses = 'localhost’, jeśli aplikacja i baza danych znajdują się na tym samym serwerze, lub przypisz do prywatnego IP, jeśli aplikacja działa na oddzielnym VPS. Unikaj przypisywania PostgreSQL do 0.0.0.0 na publicznie dostępnym interfejsie. Publicznie dostępne instancje PostgreSQL są intensywnie skanowane i atakowane przez zautomatyzowane boty.
5. Zabezpiecz ‘pg_hba.conf’ i UFW: Edytuj pg_hba.conf, aby zezwolić tylko na IP aplikacji, które faktycznie potrzebujesz, z ‘scram-sha-256’ jako metodą uwierzytelniania. Skonfiguruj UFW, aby zezwalać na port 5432 tylko z tych samych IP. Używaj tunelu SSH dla narzędzi administracyjnych (i proszę, nie otwieraj portu 5432 do publicznego internetu).

Spróbuj z innego komputera: psql -h <vps-ip> -U postgres.

Przekroczenie czasu lub odmowa połączenia z nieautoryzowanego IP zazwyczaj oznacza, że nasłuchiwanie i zasady firewalla działają prawidłowo. Monit o hasło z publicznego internetu oznacza, że coś jest źle skonfigurowane. Gdy Postgres działa, konfiguracja stanowi tylko połowę pracy.

Jak Zabezpieczyć PostgreSQL na VPS?

PostgreSQL na VPS jest zabezpieczany na trzech poziomach, plus higiena ról i częstotliwość aktualizacji.

1. Uwierzytelnianie: Użyj scram-sha-256 dla nowych instalacji i usuń przestarzałe reguły md5 z pg_hba.conf. Dokumentacja PostgreSQL teraz ostrzega, że wsparcie dla haseł zaszyfrowanych MD5 jest przestarzałe i zostanie usunięte w przyszłej wersji.
2. Sieć: Powiąż PostgreSQL z ‘localhost’, prywatnym IP lub interfejsem dostępnym tylko dla twoich serwerów aplikacji. Unikaj powiązań z interfejsem dostępnym publicznie. Dodaj na wierzch UFW i zezwalaj na port 5432 tylko z zaufanych IP aplikacji.
3. Szyfrowanie w transmisji: Włącz TLS dla każdego połączenia przekraczającego granicę sieci. Ustaw ssl = on w postgresql.conf, a następnie użyj reguł hostssl … scram-sha-256 w pg_hba.conf, aby klienci nie mogli niezauważalnie przejść na połączenia bez TLS. Samopodpisane certyfikaty są akceptowalne dla ruchu wewnętrznego, jeśli klienci je prawidłowo zweryfikują.
4. Role: Połączenia aplikacji powinny używać roli o minimalnych uprawnieniach, z tylko prawami potrzebnymi dla schematów tej aplikacji. Superużytkownik jest do migracji i sytuacji awaryjnych.
5. Aktualizacje: Użyj repozytorium PGDG apt dla aktualnych pakietów PostgreSQL. Włącz automatyczne aktualizacje bezpieczeństwa dla systemu operacyjnego, ale planuj aktualizacje PostgreSQL świadomie, aby niespodziewany restart nie stał się twoim incydentem tygodnia. 

Twoja lista kontrolna bezpieczeństwa:

• Używaj tylko scram-sha-256; wyłącz md5.
• Przypisz 'listen_addresses’ do localhost lub prywatnego IP.
• Zasady UFW zezwalają na 5432 tylko z zaufanych IP.
• SSL/TLS włączony dla każdego połączenia przekraczającego sieć.
• Aplikacja łączy się jako rola o najmniejszych uprawnieniach, nigdy jako 'postgres’.
• Włączone nieobsługiwane aktualizacje bezpieczeństwa.
• Nigdzie w 'pg_hba.conf’ nie ma linii 'host all all 0.0.0.0/0 md5′.

Ostatni punkt to przestroga.

Public-facing port 5432 z słabymi danymi uwierzytelniającymi jest znanym celem koparek kryptowalut i ataków brute-force. Narażone instancje PostgreSQL są ciągle skanowane przez zautomatyzowane boty szukające domyślnych kont, wycieków haseł lub zbyt liberalnych zasad w pliku pg_hba.conf.

Publicznie dostępne instancje Postgres z słabym uwierzytelnieniem często są kompromitowane w szokująco krótkim czasie. Baza danych bezpośrednio wystawiona na internet bez odpowiednich kontroli sieciowych, TLS i izolacji ról to błąd, który przeradza się w raport z incydentu. Prawidłowo skonfigurowana baza danych jest ciągle jedną awarią dysku od utraty danych.

Jak Wykonać Kopię Zapasową I Replikować PostgreSQL Na VPS?

Kopie zapasowe PostgreSQL na VPS korzystają z jednego z trzech mechanizmów, wybranego w zależności od awarii, przed którą się chronisz. Logiczne kopie zapasowe za pomocą pg_dump dla przenośności, fizyczne kopie zapasowe za pomocą pg_basebackup plus archiwizacja WAL dla odzyskiwania danych do określonego momentu oraz replikacja strumieniowa dla wysokiej dostępności.

Logiczne kopie zapasowe obsługują migracje, częściowe przywracanie i odświeżanie dla programistów. Uruchom pg_dump –format=custom –file=mydb.dump mydb_prod z codziennego Cron Job. Format niestandardowy dobrze się kompresuje i wraz z formatem katalogów obsługuje opcje równoległego i selektywnego przywracania przez pg_restore. Prześlij zrzut do zewnętrznego magazynu obiektów poza VPS (DreamObjects, kompatybilne z S3).

Fizyczne kopie zapasowe umożliwiają przywracanie całego systemu i odzyskiwanie do określonego punktu w czasie. pg_basebackup w połączeniu z ciągłym archiwizowaniem dziennika Write-Ahead Log (WAL) pozwala na odzyskanie danych do dowolnego momentu pomiędzy ostatnim pełnym backupem a najnowszym segmentem WAL, co jest opcją klasy produkcyjnej, gdy tolerancja na utratę danych wynosi sekundy, a nie godziny.

Replikacja strumieniowa to trzecia opcja. Replika do odczytu na drugim VPS jest gorącym zapasem dla obciążeń intensywnie korzystających z odczytu lub szybkim celem dla przełączenia awaryjnego. Konfiguracja replikacji bazy danych wymaga drugiego VPS, ale ogranicza twój najgorszy przypadek awarii do minut.

Mechanizm	Co Otrzymujesz	Koszt
pg_dump + cron + przechowywanie poza VPS	Dzienna logiczna kopia zapasowa, przenośna	Opóźnienie przywracania, brak przywracania do określonego momentu
pg_basebackup + archiwizacja WAL	Fizyczna kopia zapasowa z możliwością przywracania do określonego momentu	Złożoność operacyjna i magazynowa
Replikacja strumieniowa	Gotowość operacyjna, minimalny czas do przywrócenia (RPO), skalowanie odczytu	Drugi VPS plus zarządzanie replikacją

Przywracanie-test co miesiąc. Zarządzane usługi włączają to wszystko, i to jest część tego, co oszczędności na samodzielnym hostingu zyskują z powrotem. Jeśli już korzystasz z usług zarządzanych, droga wyjścia jest prostsza, niż się wydaje.

Jak Przenieść Dane z RDS, Supabase lub Neon na VPS?

Migrujesz z zarządzanego dostawcy Postgres na VPS w czterech krokach.

1. Przygotuj docelowy VPS: Dokładnie dopasuj wersję główną Postgres z źródłem. Zainstaluj PostgreSQL na nowym VPS, postępując zgodnie z powyższymi krokami, a następnie wstępnie utwórz rolę aplikacji i bazę danych.
2. Kopia z źródła: Uruchom pg_dump –format=custom –no-owner –no-privileges –file=src.dump <source-connection-string>. Flagi –no-owner i –no-privileges usuwają przywileje specyficzne dla dostawcy, które rzadko są poprawnie odtwarzane na nowym hoście.
3. Przywróć do docelowego: Uruchom pg_restore –dbname=myapp_prod –jobs=4 –no-owner –no-privileges src.dump. Zwróć uwagę na ostrzeżenia dotyczące rozszerzeń. RDS, Supabase i Neon często włączają rozszerzenia, które mogą nie istnieć w standardowym Postgresie. Zainstaluj kompatybilne rozszerzenia z pakietów PGDG lub postgresql-contrib przed przywróceniem.
4. Zamiana i weryfikacja ciągu połączeniowego: Najpierw skieruj środowisko stagingowe na nowy VPS, uruchom swój zestaw testów, następnie zweryfikuj reprezentatywne zapytania produkcyjne i przepływy aplikacji przed zmianą produkcyjnego ciągu połączeniowego. Dla aplikacji z niskim poziomem zapisu, krótkie okno konserwacji podczas finalnego przecięcia jest często prostsze niż konfiguracja replikacji. Zachowaj bazę danych źródłową online i tylko do odczytu przez kilka dni jako cel przywracania.

Co zmienia dostawca?

1. Od RDS: Specyficzne role RDS (’rds_superuser’, 'rdsadmin’) nie istnieją w czystym Postgresie; opcje –no-owner i –no-privileges radzą sobie z większością z nich. Niektóre rozszerzenia zarządzane przez RDS wymagają ręcznej instalacji, a przesyłanie danych poza AWS podczas zrzutu jest płatne.
2. Od Supabase: Postgres w Supabase to prawdziwy Postgres, ale warstwy uwierzytelniania, przechowywania danych i krawędzi w Supabase nie migrują. Twój schemat aplikacji tak. Zastąp te warstwy odpowiednikami hostowanymi samodzielnie przed przełączeniem.
3. Od Neon: Branche znikają po migracji; planuj kopie zapasowe zamiast tego. Procedura zrzutu i przywracania jest prosta, ale operacyjne nawyki takie jak natychmiastowe tworzenie branchy wymagają zastąpienia innym przepływem pracy.

Sama migracja zwykle zajmuje mniej czasu niż wybór planu VPS. Realistyczny czas przestoju to minuty dla małych baz danych, dłużej przy odtwarzaniu WAL dla dużych. Większość instalacji kończy się na tym etapie, ale jest jeden scenariusz, który popycha cię dalej…

Kiedy Dodać PgBouncer lub Pozostać przy Vanilla Postgres?

Większość aplikacji na 4 GB VPS nie potrzebuje początkowo puli połączeń. Dodaj PgBouncer, gdy liczba jednoczesnych połączeń przekroczy około 100, lub gdy stos aplikacyjny otwiera nowe połączenie na żądanie.

Połączenia PostgreSQL są obciążające, ponieważ każde z nich to pełny proces systemu operacyjnego. Posiadając 4 GB RAM, nie chcesz setek bezczynnych połączeń, które zużywają pamięć. Pooler przechowuje kosztowne połączenia Postgres po swojej stronie i udostępnia twojej aplikacji tanie, krótkotrwałe połączenia po drugiej stronie.

Dwa tryby grupowania mają znaczenie:

• Pooling sesji: Każdy klient otrzymuje jedno połączenie serwerowe na sesję. Bezpieczne dla każdej aplikacji, bez zmiany semantyki, mniejszy wzrost przepustowości.
• Pooling transakcji: Każdy klient otrzymuje połączenie serwerowe na jedną transakcję. Duży wzrost przepustowości. Tracisz funkcje zależne od stanu sesji (przygotowane instrukcje, blokady doradcze, 'LISTEN’/’NOTIFY’), chyba że aplikacja jest napisana z myślą o tym.

Większość małych aplikacji SaaS z ORM wykorzystującym pulę połączeń działa dobrze bez PgBouncer, dopóki nie przestaje. Sygnałem, że przekroczyłeś granicę, są błędy ‘FATAL: too many connections’ lub problemy z pamięcią spowodowane przez bezczynne połączenia.

Zainstaluj to za pomocą sudo apt install pgbouncer, skonfiguruj /etc/pgbouncer/pgbouncer.ini z listą swojej bazy danych i trybem puli, a następnie skieruj aplikację na PgBouncer na porcie 6432.

Tak, będziesz wiedzieć, kiedy to będzie potrzebne.

Podejmowanie Ostatecznej Decyzji

Różnica w kosztach jest na tyle rzeczywista, by uzasadnić przeliczenie matematyczne własnego rachunku. Ale konfiguracja to nie jest trudna część.

Trudna część to prace operacyjne, które były pokrywane przez zarządzaną fakturę. Kopie zapasowe, ćwiczenia przywracania, łatanie i monitorowanie.

Niezależnie od wszystkiego, weź głęboki oddech zanim otworzysz następną fakturę.

Najczęściej Zadawane Pytania dotyczące PostgreSQL na VPS

Ile RAM potrzebuje PostgreSQL na VPS?

PostgreSQL działa na 1 do 2 GB dla małych obciążeń i komfortowo na 4 GB dla większości produkcyjnych baz danych aplikacji. Większe zbiory danych, więcej równoczesnych połączeń lub obciążenia analityczne zwiększają wymagania do 8 GB lub więcej.

Czy mogę uruchomić PostgreSQL na VPS-ie z 2 GB?

Tak, możesz uruchomić PostgreSQL na 2 GB VPS dla małych aplikacji, środowisk developerskich i projektów pobocznych o niskim ruchu. Serwer z 2 GB pamięci oferuje mało miejsca na pamięć podręczną, więc wydajność zapytań spada, gdy dane przekroczą dostępną pamięć. Dla środowisk produkcyjnych bezpieczne minimum to 4 GB.

Czy samodzielne hostowanie PostgreSQL na VPS jest tańsze niż RDS lub Supabase?

Tak, samoobsługowe hostowanie PostgreSQL na VPS jest tańsze niż RDS czy Supabase dla większości stałych obciążeń. VPS o pojemności 4 GB zazwyczaj kosztuje ułamek ceny odpowiednika w RDS, Supabase Pro czy Neon Scale, kiedy doliczy się pamięć, kopie zapasowe i przesył danych. Kompromisem jest to, że musisz samodzielnie zarządzać bazą danych.

Jak bezpiecznie udostępnić PostgreSQL na VPS?

Nie udostępniaj portu 5432 publicznemu internetowi. Powiąż PostgreSQL z lokalnym hostem lub prywatnym adresem IP, wymagaj uwierzytelniania scram-sha-256 oraz korzystaj z tunelu SSH dla narzędzi administracyjnych zamiast otwierać port 5432 dla swojego laptopa. Publiczny port 5432 z słabym uwierzytelnianiem jest znanym celem dla kryptokoparek.

Czy muszę używać Dockera dla PostgreSQL na VPS?

Nie, Docker nie jest wymagany. Oficjalne repozytorium apt PGDG instaluje PostgreSQL jako rodzimą usługę systemową, co jest najprostszym rozwiązaniem produkcyjnym. Docker jest rozsądnym wyborem, jeśli już uruchamiasz inne kontenery.

Jak wykonać kopię zapasową PostgreSQL na VPS?

Uruchom pg_dump –format=custom codziennie według harmonogramu Cron Job i przechowuj wynik poza VPS w zgodnym z S3 magazynie obiektów. Użyj pg_basebackup wraz z archiwizacją WAL do przywracania w określonym punkcie czasu, gdy liczą się sekundy utraty danych. Przeprowadzaj testy przywracania co miesiąc.

Jaki plan powinienem wybrać do samodzielnego hostingu PostgreSQL na DreamHost?

Plan VPS Stack 4 DreamHost (4 GB RAM) jest zalecaną bazą dla większości baz danych aplikacji produkcyjnych. Wybierz Stack 8 (8 GB) dla większych zbiorów danych lub wysokiej współbieżności, a Stack 16 dla Postgres wraz z innymi usługami o dużym zapotrzebowaniu na zasoby.

Czy powinienem używać PgBouncer z PostgreSQL na małym VPS?

Większość aplikacji na 4 GB VPS nie potrzebuje PgBouncer na początku. Dodaj pulę połączeń, gdy liczba jednoczesnych połączeń zbliży się do 100 lub gdy twoja aplikacja otwiera nowe połączenie na żądanie.