PostgreSQL 14 traci wsparcie 12 listopada 2026

12 listopada 2026 społeczność PostgreSQL wyda ostatnią poprawkę wersji 14. Na RDS i Aurorze standardowe wsparcie potrwa do 28 lutego 2027. Od 1 marca baza z włączonym Extended Support przejdzie na płatne wsparcie. To ustawienie jest domyślnie włączone, gdy tworzysz bazę przez API, CLI albo Terraform, a w konsoli trzeba je zaznaczyć. Bazę bez niego AWS sam zaktualizuje do nowszej wersji 1 marca albo wkrótce potem, w terminie, którego nie wybierasz.

Sprawdź, na jakiej wersji są Twoje bazy. Każdą na 14 przenieś na PostgreSQL 18. Na własnym serwerze zrób to przed 12 listopada, na AWS przed końcem lutego.

Terminy i koszt Extended Support

Po 12 listopada baza na 14 będzie działać dalej, ale kolejnej luki w zabezpieczeniach społeczność już nie załata.

AWS nie podał jeszcze stawek Extended Support dla wersji 14 na zwykłych instancjach RDS i Aurory. Dla wersji 13 cennik AWS na dzień 29 września 2026 podaje we Frankfurcie około 178 USD miesięcznie na małej instancji db.t4g.medium z 2 vCPU. Sama instancja on-demand kosztuje tam około 54 USD miesięcznie, więc za wsparcie płacisz ponad trzy razy więcej niż za serwer.

Jak sprawdzić wersję

Na AWS wersje baz PostgreSQL wypisze to polecenie:

aws rds describe-db-instances \
  --query "DBInstances[?contains(Engine, 'postgres')].[
    DBInstanceIdentifier,
    Engine, EngineVersion,
    EngineLifecycleSupport]" \
  --output table

Ostatnia kolumna mówi, czy baza ma włączony Extended Support. W Aurorze to ustawienie pokaże aws rds describe-db-clusters. Pozostałe regiony sprawdzisz, dodając --region.

Na własnym serwerze i w Dockerze:

# własny serwer
sudo -u postgres psql -c 'SELECT version()'

# Docker
docker exec <kontener> postgres --version

Wersja 18 czy 17

Z 14 przejdziesz na 18 bez wersji pośrednich. Polecam 18, bo ma wsparcie do listopada 2030, o rok dłużej niż 17. Jest już dostępna w RDS i Aurorze. Wersja 19 jest dopiero w fazie testów: beta 4 wyszła 24 września 2026.

Wersję 17 wybierz tylko wtedy, gdy aplikacja, ORM albo któreś rozszerzenie nie działa jeszcze z 18.

Jak zaktualizować bazę

Na własnym serwerze zainstaluj binarki 18 obok 14 i na kopii bazy uruchom pg_upgrade --check. To próba na sucho: pg_upgrade sprawdza starą i nową instalację i wypisuje, co trzeba poprawić. Zanim zaczniesz właściwą aktualizację, zrób backup i sprawdź, czy da się go odtworzyć.

W Dockerze sama zmiana tagu obrazu z 14 na 18 bazy nie zaktualizuje. Zatrzymaj aplikację i przenieś dane przez pg_dumpall do kontenera z wersją 18 na osobnym wolumenie. Stary wolumen zostaw do końca testów.

Na RDS i Aurorze zrób snapshot, odtwórz z niego kopię, zaktualizuj ją i przetestuj na niej aplikację. Z produkcją poczekaj do okna serwisowego, bo podczas aktualizacji wersji głównej baza jest niedostępna. Próba na kopii pokaże, ile mniej więcej to potrwa.

Po aktualizacji uruchom ANALYZE w każdej bazie. RDS i Aurora w ogóle nie przenoszą statystyk planera, a pg_upgrade na własnym serwerze nie przenosi wszystkich.

Kiedy się tym zająć

Jeśli baza na 14 stoi na własnym serwerze albo w Dockerze, zaplanuj aktualizację na październik albo początek listopada. Mogę ją zrobić w ramach utrzymania i administracji.

Na RDS i Aurorze zaplanuj aktualizację na styczeń, żeby w lutym został zapas na poprawki.

Z wersją 15 lub nowszą w tym roku nie musisz nic robić, bo społeczność wspiera 15 do listopada 2027.

Z wersją 13 albo starszą jesteś już po terminie. Społeczność jej nie wspiera, a na RDS standardowe wsparcie 13 skończyło się 28 lutego 2026. Jeśli baza ma włączony Extended Support, domyślny przy tworzeniu przez API, CLI i Terraform, już za niego płacisz.