PostgreSQL natywnie wspiera kilka wariantów replikacji, czyli replikowania danych z jednej instancji na innej, lub nawet innych. Wszystkie oparte są o wpisy do plików WAL lub same pliki WAL.

1. replikacja fizyczna strumieniowa - inaczej hot standby, która polega na przesyłaniu wszystkich wpisów WAL z instancji źródłowej do repliki i natychmiastowym ich odtwarzaniu. Występuje w dwóch formach, synchronicznej oraz asynchronicznej . W obu dane odtwarzane są na replice tak szybko jak to możliwe. Nawet w replikacji asynchronicznej “lag”, czyli opóźnienie w odtwarzaniu danych na replice, jest tak niskie, że można przyjąć, iż dane dostępne są w tej samej chwili bez żadnego opóźnienia. Replkacja synchroniczna od replikacji asynchronicznej różni się tylko sposobem commitowania transakcji na instancji primary(master). W synchronicznej transakcja na serwerze primary czeka na odtworzenie transakcji na replice przed zwróceniem informacji o poprawnym wykonaniu transakcji, przez co czas potrzebny na wykonanie każdej pojedynczej transakcji wzrasta o minimalnie “roundtrip time”, czyli czas, który pakiet potrzebuje, aby przebyć drogę z serwera primary na replikę i z powrotem. A w replikacji asynchronicznej transakcja jest commitowana w momencie zapisu wpisu do pliku WAL, dzięki czemu możemy osiągnąć wyższą liczbę transakcji na sekundę, kosztem potencjalnej różnicy danych pomiędzy serwerem primary a standby, w przypadku wystąpienia laga replikacji.
   Wadą tego rozwiązania jest to , że w pewnych przypadkach może negatywnie wpływać na wydajność instancji primary, a pozytywną stroną, że dane są w większości przypadków w tej samej postaci.
   
2. replikacja fizyczna “log-shipping” - inaczej ciągłe odzyskiwanie, warm standby. Serwer replikowany działający jako “log-shipping” replika wszystkie dane do odtwarzania wczytuje z plików WAL, które pobiera z archiwum WAL. Replikacja taka zawsze jest trochę opóźniona, o przynajmniej jeden plik WAL, ponieważ WALe są archiwizowane dopiero po zamknięciu loga, czyli po całkowitym wypełnieniu go wpisami WAL lub rotacji loga wywołanej w inny sposób czy to ręcznie, czy parametrem archive_timeout. Plusem takiego rozwiązania jest całkowity brak wpływu takiej repliki na instancję główną postgresa, a wadą jest ciągłe opóźnienie w odtwarzaniu danych, zawsze brakuje nam tych najświeższych.
   
3. replikacja logiczna - replikacja polegająca na przesyłaniu wpisów WAL z instancji primary na standby, podobnie jak w replikacji fizycznej strumieniowej. Różnica pomiędzy logiczną a fizyczną replikacją polega na sposobie odtwarzania tych wpisów. Fizyczna odtwarza je w dokładnie takiej formie, w jakiej je otrzymała, a logiczna dokonuje operacji rozszyfrowania tego wpisu oraz wyciągnięcia wszystkich operacji DML (INSERT, UPDATE, DELETE, TRUNCATE) z plików WAL w celu ich odtworzenia. Jej konfiguracja wymaga stworzenia dodatkowych struktur w Postgresie, takich jak publikacja (CREATE PUBLICATION) na serwerze primary, określająca, które obiekty powinny być replikowane, oraz subskrypcja (CREATE SUBSCRIPTION) na serwerze repliki, gdzie odtwarzane będą wszystkie zmiany. Największą wadą tego rozwiązania jest brak wsparcia dla replikacji zmian w strukturach obiektów (DDL - czyli wszystkie instrukcje CREATE i ALTER). Chcąc dodać nową kolumnę do tabeli, która jest replikowana, powinniśmy tę kolumnę najpierw utworzyć na serwerze docelowym, replice, a dopiero później na serwerze źródłowym, dzięki czemu unikniemy przerwania replikacji logicznej. Zaletami tego rozwiązania jest możliwość replikacji pomiędzy różnymi wersjami postgresa, przykładowo z wersji 13 do 15, dzięki czemu możemy z niej skorzystać jako alternatywnej metody aktualizacji postgresa do wyższej wersji. Replika może być otwarta również do zapisu, a od wersji 16 możliwa jest konfiguracja środowiska replikowanego “multi-master”, gdzie mamy kilka instancji obsługujących zapis do tych samych tabel i replikujących wszystkie zmiany na pozostałe serwery.