PgBouncer vs Supavisor vs PgCat: który Postgres bilard?

PgBouncer minimalizuje, Supavisor pule w skali wielu dzierżawców, PgCat dodaje funkcje sieciowe do surowego puli. Żaden z trzech nie zastępuje bezpośrednio pozostałych dwóch, chociaż często porównuje się je termin po terminie na tych samych stronach.

Kolumny w kolejności: PgBouncer, Supavisor, PgCat. Charakterystyka architektury zgodna z oficjalnymi zgłoszeniami każdego projektu, którą należy potwierdzić w wdrażanej wersji, ekosystem szybko ewoluuje pod tym względem.

PgBouncer robi tylko jedno: łączy połączenia Postgres, bez żadnych dodatkowych funkcji. Ten celowo wąski zakres w dużej mierze wyjaśnia jego długowieczność i przyjęcie go jako podstawowego elementu składowego większości produkcyjnych stosów Postgres.

Dostępne są trzy tryby łączenia. Tryb sesji otwiera jedno połączenie serwera na każde połączenie klienta, najbardziej liberalne. Tryb transakcyjny ponownie wykorzystuje połączenie serwerowe pomiędzy kilkoma klientami, zwalniane na każdym końcu transakcji. Tryb instrukcji idzie jeszcze dalej i jest rzadko używany w produkcji. To właśnie tryb transakcyjny przynosi realny zysk z puli, ale narzuca rygorystyczne zasady. Dowolny stan sesji (zmienneSET, blokady doradcze, LISTEN/NOTIFY) nie przetrwa transakcji. Szczegółowo opisujemy te zasady i związane z nimi pułapki w naszym dedykowanym artykule na temat trybu łączenia transakcji w PgBouncer.

Historycznie jednoprocesowa instancja PgBouncer domyślnie używa jednego rdzenia procesora. Uruchamianie wielu instancji za tym samym portem (za pośrednictwem SO_REUSEPORT) jest nowszą ewolucją projektu, a nie początkową funkcją projektową. Po stronie uwierzytelniania PgBouncer obsługuje konfigurowalną auth_query, funkcję SQL wykonywaną przy każdym połączeniu w celu dynamicznego rozpoznawania hasła roli. Mechanizm ten pozwala uniknąć uzależnienia od statycznego pliku zawierającego listę każdego użytkownika z wyprzedzeniem. To właśnie ten mechanizm wykorzystuje Aurabase do swoich ról w projekcie (sekcja 05).

Supavisor rozwiązuje problem, do rozwiązania którego PgBouncer nigdy nie został zaprojektowany na taką skalę. Wiąże się to z obsługą bardzo dużej liczby odrębnych baz danych dzierżawców w ramach pojedynczej usługi, a nie jednej instancji puli na bazę danych. Napisany w Elixir i wykonany na wirtualnej maszynie Erlang (BEAM), projekt jest rozwijany i utrzymywany przez Supabase, w otwartym kodzie źródłowym, we własnym repozytorium GitHub.

Natywny model z wieloma najemcami stanowi prawdziwą różnicę strukturalną. Tam, gdzie klasyczna flota PgBouncera wymaga jednego procesu (lub zestawu dedykowanych połączeń) na bazę docelową, Supavisor działa inaczej. Dynamicznie rejestruje najemców za pośrednictwem interfejsu administracyjnego HTTP i kieruje każde połączenie przychodzące do właściwej bazy danych bez ponownego uruchamiania usługi. Właśnie z tego powodu Supabase przeprowadziła migrację własnych projektów chmurowych z PgBouncer do Supavisor. Klasyczny klaster puli, po jednym na bazę danych, nie jest skalowalny do chmury z wieloma dzierżawcami, w której znajdują się setki tysięcy projektów.

Ten wybór architektoniczny ma udokumentowaną wadę. Stabilizacja funkcji z PgBouncerem w zaawansowanych przypadkach wymagała czasu po uruchomieniu projektu. Dwa przykłady: pewne zachowania LISTEN/NOTIFYi dokładne zarządzanie przygotowanymi wyciągami w trybie transakcyjnym. Sprawdź swoją wersję przed migracją, jeśli Twoja aplikacja zależy od tych konkretnych zachowań.

PgCat jest wyraźnie pozycjonowany jako alternatywa dla PgBouncera, napisanego w Rust. Dodaje funkcje sieciowe do klasycznego łączenia zasobów, których natywnie nie osadza ani PgBouncer, ani Supavisor. W szczególności trzy: dzielenie aplikacji według klucza partycji, równoważenie obciążenia między replikami odczytu i automatyczne przełączanie awaryjne w przypadku uszkodzonej repliki. Projekt narodził się w Instacart, a dziś został przejęty i utrzymywany przez PostgresML.

Konkretnie, PgCat może odgrywać rolę, jaką normalnie pełniłyby dwie odrębne warstwy: moduł puli połączeń i serwer proxy aplikacji do routingu pomiędzy kilkoma instancjami Postgres. Zespół, który już ręcznie shardował swoje dane, może uprościć swój kod za pomocą PgCat. To samo dotyczy logiki dystrybucji odczytów pomiędzy opracowanymi wewnętrznie replikami: dedykowana warstwa sieciowa bezpośrednio ją zastępuje.

Istnieje również odwrotny kompromis: PgCat jest młodszym projektem, ze znacznie mniejszym ekosystemem dokumentacji i informacji zwrotnych z produkcji niż PgBouncer. Przyjęcie funkcji fragmentowania i przełączania awaryjnego oznacza także zgodę na uzależnienie od dojrzałości tego konkretnego komponentu, a nie tylko od jego możliwości łączenia.

Repozytorium Aurabase wdraża PgBouncer na dwóch oddzielnych poziomach, oba w trybie transakcyjnym. W przypadku współdzielonej floty wykres Helm definiuje dedykowane wdrożenie PgBouncera przed współdzieloną płaszczyzną danych (deploy/helm/aurabase/templates/infra/pgbouncer.yaml, obraz edoburu/pgbouncer). Dla dzierżawy w dedykowanej instancji dostawca generuje zasób Pooler zarządzany natywnie przez CloudNativePG (deploy/cnpg/tenant-pooler.yaml, renderowany przez k8s_tenant.rs). Ani nie używa Supavisora, ani PgCata. Kod nie dokumentuje wyraźnego porównania poprzedzającego ten wybór. Z drugiej strony wykazuje głęboką i już operacyjną integrację z ekosystemem CloudNativePG, co jest spójne z faktem, że PgBouncer jest natywną cegiełką do Poolingu.

Jednak nie wszystko przechodzi przez Pooler i jest to celowy wybór udokumentowany w samym kodzie. PostgREST pozostaje połączony na żywo z Postgres, nigdy za pośrednictwem PgBouncer. Komentarz do wykresu Helma jasno określa przyczynę: gromadzenie transakcji przerwałoby przeładowanie schematu, które zależy od LISTEN na kanale pgrst. Ten mechanizm jest niezgodny z odzyskanymi połączeniami serwera między klientami. Pula administracyjnaaura-db (schemat, DDL, blokady doradcze sesji) również pozostaje w bezpośrednim połączeniu z tego samego podstawowego powodu. SET search_path i blokady sesji niemające zakresu transakcji nie przetrwają puli w trybie transakcji.

# Płaszczyzna danych aura-db: za pośrednictwem PgBouncer wszystko ma zasięg transakcji (SET LOCAL)
DATABASE_URL: postgresql://aura_authenticator:...@pgbouncer:5432/aura_db_master

# Administrator puli (DDL, introspekcja): BEZPOŚREDNIO na Postgres, nigdy PgBouncer
# USTAW ścieżkę_wyszukiwania inną niż LOKALNA + blokady sesji przerywają łączenie transakcji
ADMIN_DATABASE_URL: postgresql://aura:...@postgres:5432/aura_db_master

Uwierzytelnianie odbywa się według wzorca auth_query opisanego w sekcji 02: AUTH_QUERY: SELECT * FROM pgbouncer.user_lookup($1), bez statycznego pliku userlist.txt. To właśnie umożliwia rolom tworzonym dynamicznie dla każdego projektu (project_<uuid>_authenticator) uwierzytelnianie za pośrednictwem PgBouncer bez ponownego wdrażania modułu puli dla każdego nowego projektu.

Ostatni szczegół, drobny, ale odkrywczy: wykres Helma domyślnie przypina edoburu/pgbouncer:v1.24.1-p1, podczas gdy lokalna ława k3d używa v1.25.2-p0. Nie jest to wybór architektoniczny, po prostu niewielki brak synchronizacji wersji między dwoma środowiskami, rodzaj szczegółów, które recenzja kodu wyłapuje szybciej niż post na blogu. Dokumentujemy go takim, jaki jest, zamiast go upiększać. Aby uzyskać szczegółowe informacje na temat partycjonowania schematu obsługiwanego przez tę pulę, zobacz nasz artykuł na tematizolacji RLS dla wielu dzierżawców.

Wybierz PgBouncer, jeśli…

• Klaster Postgres zarządzany ogólnie przez CloudNativePG lub Kubernetes
• Chcesz najbardziej sprawdzonego i dobrze udokumentowanego gracza bilardowego
• Docelowa baza na instancję Poolera Ci odpowiada

Wybierz Supavisor, jeśli…

• Setki lub tysiące baz za tą samą usługą
• Należy dynamicznie rejestrować najemców za pośrednictwem interfejsu API, bez konieczności ponownego wdrażania
• Już w ekosystemie Supabase lub chcąc na nim polegać

Wybierz PgCat, jeśli…

• Udostępnianie aplikacji już istnieje lub jest planowane na poziomie Poolera
• Równoważenie obciążenia i replika awaryjna bez oddzielnej warstwy aplikacji
• Wygodny z młodszym projektem, mniej udokumentowanym niż PgBouncer

Niezależnie od tego, jaki basen zostanie wybrany, nie zastępuje on rozmiaru samego Postgres. Rozmiar puli i serwer max_connections należy rozpatrywać łącznie, a nie jeden po drugim. Obfita pula przed zbyt niskim max_connections po prostu przesuwa nasycenie z jednego poziomu na drugi. Nasz przewodnik na temat tuningu max_connections szczegółowo opisuje wzór doboru, który należy zastosować przed ustawieniem rozmiaru basenu.

PgBouncer, Supavisor i PgCat rozwiązują trzy odmiany tego samego problemu, a nie trzy wersje tego samego narzędzia. PgBouncer pozostaje najbezpieczniejszym wyborem, gdy Twoja platforma opiera się już na Kubernetes i CloudNativePG lub gdy po prostu potrzebujesz najbardziej udokumentowanego Poolera. Supavisor staje się istotny poza określoną liczbą baz obsługujących tę samą usługę. PgCat jest warty obejścia, jeśli brakuje Ci fragmentowania i przełączania awaryjnego replik na poziomie sieci, pod warunkiem, że zaakceptujesz dojrzałość młodszego projektu.

Kod Aurabase pokazuje spójny, a nie neutralny wybór: PgBouncer w trybie transakcyjnym, na dwóch poziomach, współdzielona flota i CNPG Pooler na dedykowanego najemcę. Pozostają dwa udokumentowane wyjątki dla PostgREST i administrowania schematem. Jeśli chcesz zobaczyć, jak ten projekt wygląda w praktyce, a nie na papierze, nasza strona Performance dokumentuje powiązaną metodologię pomiaru.