Postgres 16 vs 17 vs 18: zyski mają znaczenie

Te trzy wersje nie różnią się żadnym ogólnym wskaźnikiem wydajności. Każdy koryguje konkretny punkt architektury, za każdym razem z inną publicznością: duże tabele dla Postgres 17, pamięć masowa o dużych opóźnieniach dla Postgres 18. Poniższa tabela podsumowuje możliwe do sprawdzenia fakty, wszystkie datowane, przed przejściem do szczegółów każdego projektu.

Źródła: oficjalne informacje o wydaniu projektu PostgreSQL (postgresql.org), z odniesieniami do analiz publikowanych przez Microsoft Tech Community i Crunchy Data po każdym większym wydaniu. Dostęp: 24 sierpnia 2026 r.

Przed Postgres 17 VACUUM przechowywało listę martwych krotek do oczyszczenia w prostej tablicy o rozmiarze maintenance_work_mem. Problemem nie była szybkość obliczeń, ale sama struktura: wielkość tej tabeli utrzymywała się na poziomie około 1 GB, niezależnie od tego, ile skonfigurowano powyżej. Na stole zawierającym ponad 178 milionów martwych wierszy program VACUUM musiał wykonać pętlę w wielu przebiegach, z których każdy ponownie odczytywał całe indeksy.

Postgres 17 zastępuje tę tablicę strukturą zwaną TidStore, adaptacyjnym drzewem radix, które mocno kompresuje przestrzeń potrzebną do przechowywania identyfikatorów krotek. Oficjalne informacje o wydaniu projektu wskazują, że w niektórych przypadkach pamięć wykorzystywana przez VACUUM została zmniejszona nawet 20-krotnie, bez sztucznego sufitu związanego ze starą konstrukcją. Źródło: oficjalne informacje o wersji PostgreSQL 17, postgresql.org, 26 września 2024 r. Społeczność Microsoft Tech Community i Crunchy Data opublikowały analizę techniczną tej zmiany wkrótce po wydaniu. Obydwa potwierdzają konkretne zainteresowanie tabelami zawierającymi kilkaset milionów wierszy, z dużą częstotliwością usuwania lub aktualizacji.

Projekt ten przynosi korzyści głównie w konkretnym scenariuszu: dużej tabeli z dużą częstotliwością usuwania lub aktualizacji. VACUUM poprzednio działał w kilku przebiegach z powodu braku dostępnej pamięci. Na małym stole lub przy obciążeniu głównie do czytania wzmocnienie pozostaje marginalne lub nawet niewidoczne.

Drugi projekt Postgres 17 dotyka bardziej dyskretnego punktu: obliczania migawek transakcji. Każde zapytanie musi wiedzieć, jakie inne transakcje są w toku, aby wymusić reguły widoczności MVCC Postgres. Na maszynie z dużą liczbą rdzeni i aktywnych połączeń obliczenia te spowodowały rywalizację o wspólną strukturę wewnętrzną. Jest to wąskie gardło, które od dawna dokumentowali uczestnicy projektu.

Postgres 17 redukuje to twierdzenie. Efekt jest mierzony głównie w przypadku instancji o dużej współbieżności, z wieloma jednoczesnymi aktywnymi połączeniami na sprzęcie wielordzeniowym. Przy niskim obciążeniu współbieżności różnica w porównaniu z Postgres 16 pozostaje marginalna: jest to projekt skalowalny, a nie zmniejszenie opóźnień na pojedyncze żądanie.

Zysk ten nie zastępuje modułu puli połączeń, po prostu zmniejsza jego koszt wewnętrzny. Jeśli liczba aktywnych połączeń jest już Twoim wąskim gardłem, wersja główna schodzi na dalszy plan. Nasz przewodnik dostrajania max_connections i nasze porównanie trybów transakcji PgBouncer omawiają ten temat bardziej szczegółowo.

Postgres 18, wydany pod koniec września 2025 r., rozwiązuje problem o bardziej strukturalnym charakterze. Do tego czasu każdy odczyt dysku Postgres blokował proces, który tego zażądał. Nowy asynchroniczny podsystem wejścia-wyjścia (AIO) umożliwia procesowi równoległe inicjowanie wielu odczytów i kontynuowanie pracy po ich zakończeniu, zamiast czekać na każdy z nich sekwencyjnie.

Parametr io_method kontroluje to zachowanie: worker (procesy dedykowane we/wy, domyślnie) lub io_uring w systemie Linux, gdy Postgres został skompilowany z tą obsługą. Skanowania sekwencyjne, skanowanie stosów map bitowych i VACUUM przynoszą pierwsze korzyści, szczególnie w przypadku pamięci masowej o dużych opóźnieniach: dysków sieciowych, woluminów w chmurze, a nie lokalnych NVMe.

PlanetScale, która oferuje zarządzaną ofertę Postgres, opublikowała własne porównania Postgres 17 i 18 skupiające się na tej zmianie we/wy. Są to pomiary dokonane na ich własnej infrastrukturze, a nie dane, które tutaj niezależnie odtworzyliśmy. Potraktuj to jako sygnał, że temat warto przetestować na rzeczywistym obciążeniu, a nie jako uniwersalny procent.

Uogólnione AIO Postgres 18 stanowi kontynuację projektu rozpoczętego w Postgres 17, a nie odosobnioną zmianę. Wersja 17 wprowadziła już interfejs strumieniowego wejścia/wyjścia, ale ograniczyła się do ANALIZY i skanowania sekwencyjnego. Postgres 18 rozszerza tę samą logikę na szerszy zakres operacji, w tym skanowanie sterty VACUUM i bitmap. Dlatego te dwie wersje należy czytać jako postęp, a nie jako dwa osobne zakłady na wejścia/wyjścia.

Warto monitorować trzy inne zmiany w Postgres 18, nawet jeśli nie dotyczą one bezpośrednio surowej wydajności.

Skanowanie pominięcia na wielokolumnowym indeksie B-drzewa pozwala Postgresowi na użycie indeksu złożonego, nawet jeśli zapytanie nie filtruje według kolumny głównej. Przed Postgres 18 ten scenariusz często wymagał pełnego skanowania tabeli lub utworzenia dodatkowego dedykowanego indeksu.

Wygenerowane przez kolumny wirtualne (GENERATED ALWAYS AS (...) VIRTUAL) stają się zachowaniem domyślnym, jeśli nie określono STORED. Kolumna wirtualna jest obliczana podczas odczytu, a nie zapisywania na dysku, co zmniejsza ilość zapisaną za każdym razem, gdy wiersz źródłowy jest wstawiany lub aktualizowany.

Postgres 18 wreszcie dodaje obsługę OAuth 2.0 po stronie uwierzytelniania (RFC 8628, przepływ urządzeń), obok istniejących mechanizmów, takich jak SCRAM, certyfikaty czy LDAP. Istotny punkt dla każdej organizacji, która już centralizuje swoją tożsamość za pośrednictwem zewnętrznego dostawcy OAuth/OIDC.

W Aurabase baza danych dzierżaw działa obecnie w Postgres 16.15, a nie 17. Można to zweryfikować bezpośrednio w repozytorium: referencyjny obraz CNPG (docker/Postgres.CNPG.Dockerfile) zaczyna się od ghcr.io/cloudnative-pg/postgresql:16-standard-bookworm, przypiętego przez skrót, tej samej wersji głównej co warstwa współdzielona (docker/Postgres.Dockerfile). Zweryfikowano 24 sierpnia 2026 r.

Kod dokumentuje również dlaczego. Komentarz korygujący w k8s_tenant.rs wyjaśnia, że ​​wcześniejsze odwołanie błędnie wskazywało na postgresql:17.2. Podany wówczas powód, że standardowy obraz nie zawierał pgvector, po weryfikacji okazał się fałszywy. Obydwa obrazy mają pgvector: 0.8.0 na 17.2, 0.8.5 na 16-standardowym molu książkowym mierzonym w klastrze floty.

Prawdziwe ryzyko, udokumentowane w samym komentarzu, leży gdzie indziej: CloudNativePG zabrania jakiejkolwiek zmiany wersji głównej po utworzeniu klastra. Flota udostępniona przez pomyłkę w Postgres 17 byłaby nieodwracalna, podczas gdy wszystko, co zostało kompleksowo sprawdzone w Aurabase, znajdowało się w Postgres 16.

// Wersja główna zostaje zachowana, jeśli nie zdefiniowano TENANT_POSTGRES_IMAGE
let repli = "ghcr.io/cloudnative-pg/postgresql:16-standard-bookworm";

tracing::warn!(
    image = repli,
    "TENANT_POSTGRES_IMAGE non défini : repli sur la version validée."
);

Nie jest to ocena Postgres 17 jako takiej. Jest to polityka ostrożności operacyjnej: nie przełączaj floty produkcyjnej na wersję główną, dopóki nie nastąpi kompleksowa walidacja. To samo rozumowanie dotyczy każdego zespołu zarządzającego Postgres za pośrednictwem CloudNativePG lub równoważnego operatora Kubernetes. Pytaniem nie jest tylko oczekiwany wzrost wydajności, ale także droga powrotna, jeśli coś pójdzie nie tak.

Czy powinieneś teraz przeprowadzić migrację do Postgres 17 lub 18?

Trzy kryteria umożliwiają podjęcie decyzji bez czekania na uniwersalną liczbę. Po pierwsze, rozmiar i częstotliwość mutacji największych tabel: jeśli VACUUM działa już w kilku przebiegach, witryna robocza pamięci Postgres 17 ma zastosowanie bezpośrednio w Twoim przypadku. Następnie Twoja pamięć masowa: na lokalnym dysku SSD o niskim opóźnieniu asynchroniczne operacje we/wy Postgres 18 zapewniają mniej niż w wolumenie sieciowym. Wreszcie droga powrotna: w przypadku operatora, który zabrania większych zmian na starszą wersję, testowanie najpierw w środowisku jednorazowym nie jest opcjonalnym środkiem ostrożności.

Konkretnie ta sama zasada dotyczy każdej floty zarządzanej przez operatora Kubernetes. Najpierw udostępnij klaster testowy w wersji docelowej, a następnie odtwórz na nim obciążenie reprezentatywne dla Twojej produkcji. Dotykaj rzeczywistego klastra dopiero po całkowitym sprawdzeniu tego testu, a nie tylko czytając informacje o wersji. Jeśli Twoja decyzja dotyczy również wyboru pomiędzy bazą dedykowaną a bazą współdzieloną w celu wchłonięcia tego typu zmian, w naszym artykule baza dedykowana a baza współdzielona bada ten kąt.

Wybór między Postgres 16, 17 i 18 nie polega tylko na tym, która wersja jest „najszybsza”. Postgres 17 rozwiązuje prawdziwy problem strukturalny VACUUM na dużych tabelach i zmniejsza rywalizację przy dużej współbieżności. Postgres 18 idzie dalej, oferując asynchroniczne operacje we/wy – zmianę w architekturze, która wymaga przetestowania rzeczywistego obciążenia i pamięci przed uogólnieniem.

Najczęściej zapominanym kryterium nie jest wydajność, ale odwracalność. W przypadku operatora takiego jak CloudNativePG aktualizacja głównej wersji nie jest cofana po fakcie. Przed zmianą floty produkcyjnej prawdziwym pytaniem jest nie tylko oczekiwany zysk, ale także droga powrotna w przypadku niepowodzenia testu. Jeśli przygotowujesz się do aktualizacji tej wersji, nasza lista kontrolna dostrajania Postgres w wersji produkcyjnej zawiera szczegółowe informacje na temat ustawień, które należy ponownie sprawdzić po istotnej zmianie wersji.