gik|iewicz

PgDog, open source’owy connection pooler napisany w Rust, zdobył finansowanie od Y Combinator. Projekt ma ambicję stać się standardem w ekosystemie PostgreSQL, oferując alternatywę dla PgBouncer z lepszą obsługą prepared statements i shardingiem. Twórcy zapowiadają intensywny rozwój narzędzia.

TL;DR: PgDog to connection pooler dla PostgreSQL napisany w Rust, który zdobył finansowanie od Y Combinator. Projekt oferuje routing po kluczu partycji, obsługę prepared statements i sharding. Kod jest dostępny na GitHubie na licencji AGPL-3.0. Narzędzie celuje w zastąpienie PgBouncera w scenariuszach wymagających skalowania.

Czym jest PgDog i dlaczego otrzymał finansowanie?

PgDog to connection pooler oraz router dla PostgreSQL napisany w języku Rust. Projekt został wybrany do programu Y Combinator, co oznacza finansowanie oraz wsparcie mentorskie. Narzędzie obsługuje routing zapytań na podstawie klucza partycji, co pozwala na skalowanie bazy danych bez zmiany kodu aplikacji. Kod źródłowy jest dostępny na GitHubie na licencji AGPL-3.0. Finansowanie z Y Combinator daje projektowi szansę na szybszy rozwój i dotarcie do szerszej grupy użytkowników.

PgDog celuje w problem, z którym PgBouncer radzi sobie gorzej – obsługę prepared statements w trybie transaction pooling. Ponadto oferuje sharding wbudowany w pooler, co eliminuje potrzebę stosowania dodatkowych warstw pośrednich. Projekt jest stosunkowo młody, ale zyskuje uwagę dzięki podejściu opartym na wydajności Rust.

Jak PgDog rozwiązuje problem connection poolingu w PostgreSQL?

Connection pooling w PostgreSQL to mechanizm zmniejszający liczbę jednoczesnych połączeń do bazy danych. PgDog działa jako proxy między aplikacją a serwerem PostgreSQL, utrzymując pulę aktywnych połączeń i przydzielając je na żądanie. W przeciwieństwie do PgBouncera, PgDog obsługuje prepared statements w trybie transaction pooling, co jest częstym problemem w aplikacjach korzystających z ORM.

PgDog implementuje protokół PostgreSQL w wersji 3, co oznacza kompatybilność z większością sterowników baz danych. Pooler obsługuje tryby session pooling oraz transaction pooling. W trybie transaction pooling połączenie jest zwracane do puli natychmiast po zakończeniu transakcji, co pozwala obsługiwać więcej klientów przy ograniczonej liczbie połączeń do bazy.

Routing zapytań odbywa się na podstawie klucza partycji, na przykład identyfikatora użytkownika lub tenant ID. Pooler analizuje zapytanie SQL i kieruje je do odpowiedniego shardu. To podejście eliminuje potrzebę modyfikacji kodu aplikacji przy skalowaniu poziomym bazy danych.

Jakie funkcje oferuje PgDog w porównaniu do PgBouncera?

PgDog oferuje zestaw funkcji wykraczających poza standardowe możliwości PgBouncera. Główne różnice dotyczą obsługi prepared statements, shardingu oraz routingu zapytań. PgBouncer od lat dominuje jako connection pooler dla PostgreSQL, jednak ma ograniczenia w scenariuszach wymagających skalowania poziomego.

PgDog obsługuje również failover i load balancing między replikami. Konfiguracja odbywa się przez plik TOML, podobnie jak w PgBouncerze. Migracja z PgBouncera do PgDoga ma być prosta dzięki zbliżonej składni konfiguracji.

Dlaczego PgDog jest napisany w Rust?

Rust oferuje bezpieczeństwo pamięci bez garbage collectora, co jest istotne dla narzędzi infrastrukturalnych pracujących pod dużym obciążeniem. PgDog przetwarza tysiące zapytań na sekundę, dlatego język implementacji ma znaczenie dla wydajności i stabilności. Rust eliminuje całą klasę błędów związanych z zarządzaniem pamięcią, takich jak buffer overflow czy use-after-free.

PgBouncer jest napisany w C, co daje mu przewagę w postaci dojrzałości ekosystemu oraz stabilności udowodnionej latami produkcji. Jednakże C wymaga ręcznego zarządzania pamięcią, co zwiększa ryzyko błędów krytycznych. Rust oferuje porównywalną wydajność z dodatkowymi gwarancjami bezpieczeństwa na poziomie kompilatora.

Warto sprawdzić repozytorium PgDog na GitHubie, aby zobaczyć architekturę projektu i przykłady konfiguracji. Kod jest dobrze udokumentowany, a struktura projektu ułatwia zrozumienie, jak pooler przetwarza zapytania SQL.

Kto stoi za projektem PgDog?

PgDog jest rozwijany przez zespół, który przeszedł proces selekcji Y Combinator. Informacje o twórcach są dostępne na stronie projektu oraz w repozytorium na GitHubie. Y Combinator wybiera projekty na podstawie potencjału rynkowego oraz zespołu, co oznacza, że PgDog został oceniony pod kątem komercyjnej wykonalności.

Twórcy PgDoga mają doświadczenie w pracy z PostgreSQL na dużą skalę. Projekt powstał z potrzeby rozwiązania konkretnych problemów napotykanych w produkcji, takich jak ograniczenia PgBouncera w trybie transaction pooling oraz brak wbudowanego shardingu. Finansowanie z Y Combinator pozwala zespołowi pracować nad projektem pełny etat.

Rekomenduję przeanalizowanie commit history w repozytorium, aby ocenić tempo rozwoju projektu. Aktywność twórców jest dobrym wskaźnikiem zaangażowania w rozwój narzędzia. Podobnie jak przy SpacetimeDB 2.0, warto sprawdzić, czy projekt ma jasną mapę drogową.

Jak wygląda konfiguracja PgDog w praktyce?

Konfiguracja PgDoga odbywa się przez plik TOML, zbliżony składnią do konfiguracji PgBouncera. Poniżej przykładowy plik konfiguracyjny z dwoma shardami:

[pools.main]
shards = 2

database = "myapp"

[pools.main.shards.0]
host = "pg-shard-0.internal"
port = 5432

[pools.main.shards.1]
host = "pg-shard-1.internal"
port = 5432

[settings]
pool_mode = "transaction"

Konfiguracja definiuje pulę połączeń z dwoma shardami. Pooler kieruje zapytania do odpowiedniego shardu na podstawie klucza partycji. Tryb transaction oznacza, że połączenia są zwracane do puli po każdej transakcji. PgDog obsługuje również konfigurację wielu baz danych oraz load balancing między replikami.

Najważniejsze jest zrozumienie, jak PgDog mapuje klucze partycji na shardy. Domyślnie pooler używa modulo na wartości klucza, ale obsługuje również niestandardowe funkcje mapowania. Konfiguracja admin database pozwala monitorować stan puli połączeń, podobnie jak w PgBouncerze.

Jakie są ograniczenia PgDoga?

PgDog jest projektem stosunkowo młodym, co oznacza, że może mieć ograniczenia w porównaniu do dojrzałych rozwiązań. PgBouncer jest używany w produkcji od kilkunastu lat i przeszedł wiele cykli testowania oraz optymalizacji. PgDog dopiero buduje swoją bazę użytkowników i zbiera feedback z produkcji.

Licencja AGPL-3.0 może być barierą dla niektórych firm komercyjnych. AGPL wymaga udostępnienia kodu źródłowego modyfikacji nawet przy użyciu narzędzia jako usługi sieciowej. Dla porównania PgBouncer jest na licencji BSD, która pozwala na swobodniejsze wykorzystanie w projektach komercyjnych. Podobne dylematy licencyjne pojawiają się przy Atlassian włącza domyślne zbieranie danych do trenowania AI.

Lista znanych ograniczeń PgDoga:

• Brak wsparcia dla wszystkich typów zapytań PostgreSQL
• Ograniczona dokumentacja w porównaniu do PgBouncera
• Mniejsza społeczność i mniej przetestowanych scenariuszy
• Licencja AGPL-3.0 wymagająca uwagi prawnej
• Brak gotowych paczek dla popularnych dystrybucji Linuxa
• Ograniczone wsparcie dla protokołów uwierzytelniania
• Mniej narzędzi monitorowania i debugowania
• Brak długoterminowego wsparcia dla starszych wersji PostgreSQL

Warto sprawdzić sekcję issues na GitHubie przed wdrożeniem PgDoga w produkcji. Na przykład problemy z konkretnymi sterownikami baz danych mogą wymagać obejść lub modyfikacji konfiguracji.

Jak wygląda roadmapa PgDoga po finansowaniu Y Combinator?

Y Combinator finansuje projekty na 3-miesięcznym programie, co daje zespołowi PgDog czas na intensywny rozwój. Roadmapa projektu skupia się na rozszerzeniu obsługi protokołu PostgreSQL oraz dodaniu zaawansowanych mechanizmów shardingu. Twórcy planują również budowę komercyjnego wsparcia, co jest standardowym modelem biznesowym po przejściu akceleratora.

PgDog celuje w zastąpienie PgBouncera w scenariuszach wymagających skalowania poziomego. Dlatego roadmapa obejmuje obsługę większej liczby typów zapytań SQL oraz lepszą kompatybilność z popularnymi ORM. Program YC wymaga od startupów szybkiej walidacji modelu biznesowego, co oznacza, że PgDog będzie rozwijany z naciskiem na potrzeby produkcyjne użytkowników.

Kluczowe elementy roadmapy PgDog po finansowaniu:

• Pełna obsługa protokołu PostgreSQL w wersji 3
• Rozszerzenie kompatybilności z popularnymi sterownikami
• Zaawansowane funkcje shardingu i partycjonowania
• Narzędzia monitorowania i debugowania
• Dokumentacja i przykłady migracji z PgBouncera
• Gotowe paczki dla popularnych dystrybucji Linuxa
• Komercyjne wsparcie i plany SLA
• Integracja z narzędziami CI/CD

Jak PgDog radzi sobie z shardingiem na poziomie poolera?

Sharding wbudowany w connection pooler to rzadkie podejście w ekosystemie PostgreSQL. To podejście eliminuje potrzebę stosowania dodatkowych warstw pośrednich, takich jak Citus czy PgShard. PgDog obsługuje routing po kluczu partycji zdefiniowanym w konfiguracji TOML.

Pooler używa operacji modulo na wartości klucza do określenia docelowego shardu. Na przykład, przy dwóch shardach i kluczu partycji równym identyfikatorowi użytkownika, PgDog kieruje zapytania z parzystymi ID do shardu 0, a z nieparzystymi do shardu 1. Co więcej, konfiguracja obsługuje niestandardowe funkcje mapowania dla bardziej złożonych scenariuszy partycjonowania.

Sharding na poziomie poolera ma jednak ograniczenia. PgDog musi parsować każde zapytanie SQL, co dodaje narzut wydajnościowy. Z kolei zapytania obejmujące wiele shardów wymagają dodatkowej logiki agregacji. Mimo to, podejście to upraszcza architekturę aplikacji, ponieważ kod nie musi wiedzieć o istnieniu wielu baz danych.

Jakie scenariusze użycia ma PgDog w środowiskach produkcyjnych?

PgDog jest projektowany dla aplikacji wymagających skalowania poziomego PostgreSQL. Typowe scenariusze obejmują architektury multi-tenant, gdzie każdy tenant ma swoje dane na osobnym shardzie. Pooler kieruje zapytania na podstawie tenant ID, co pozwala na izolację danych bez konieczności utrzymywania osobnych połączeń dla każdego tenanta.

Kolejny scenariusz to aplikacje z dużą liczbą jednoczesnych połączeń, które wymagają connection poolingu w trybie transaction. PgDog rozwiązuje problem prepared statements w tym trybie, z którym PgBouncer nie radzi sobie. Ponadto pooler obsługuje load balancing między replikami, co pozwala na dystrybucję obciążenia odczytów.

• Aplikacje SaaS z architekturą multi-tenant
• Systemy wymagające tysięcy jednoczesnych połączeń
• Bazy danych z replikami do odczytu
• Migracje z PgBouncera przy potrzebie shardingu
• Środowiska korzystające z ORM z prepared statements
• Aplikacje wymagające failover między replikami

Jak licencja AGPL-3.0 wpływa na adopcję PgDoga?

Licencja AGPL-3.0 wymaga udostępnienia kodu źródłowego modyfikacji nawet przy użyciu narzędzia jako usługi sieciowej. Dla firm komercyjnych to istotne ograniczenie, ponieważ PgDog działający jako proxy w infrastrukturze może wymagać udostępnienia modyfikacji.

Jednakże model AGPL jest coraz częściej wybierany przez projekty open source finansowane przez VC. Licencja chroni przed wykorzystaniem kodu przez duże korporacje bez wkładu w społeczność. Twórcy PgDoga mogą oferować licencje komercyjne dla firm, które nie chcą publikować swoich modyfikacji. To standardowy model biznesowy stosowany przez projekty takie jak MongoDB czy Elastic.

Firmy rozważające PgDoga powinny skonsultować się z działem prawnym. Choć AGPL nie zabrania komercyjnego użycia, nakłada obowiązki dotyczące udostępniania kodu. Wobec tego dla wewnętrznych narzędzi licencja nie stanowi problemu, ale dla usług sieciowych może wymagać osobnej umowy licencyjnej.

Jakie są plany komercyjne PgDoga po akceleracji?

Y Combinator wymaga od startupów zdefiniowania modelu biznesowego. PgDog prawdopodobnie przyjmie model open core, gdzie podstawowa wersja jest darmowa na licencji AGPL, a funkcje enterprise wymagają płatnej subskrypcji. Typowe funkcje płatne to zaawansowane monitorowanie, wsparcie SLA oraz narzędzia zarządzania shardami. Model ten sprawdził się przy projektach takich jak SpacetimeDB 2.0.

Finansowanie z Y Combinator daje PgDogowi około 500 tysięcy dolarów (ok. 2 mln zł) seed investment. To pozwala na zatrudnienie zespołu i szybki rozwój przez 12-18 miesięcy. Startup musi jednak udowodnić traction, czyli rosnącą liczbę użytkowników i przychodów, aby zdobyć kolejną rundę finansowania. Dlatego twórcy będą intensywnie promować projekt i zbierać feedback z produkcji.

PgDog konkuruje nie tylko z PgBouncerem, ale również z rozwiązaniami chmurowymi. Amazon RDS Proxy, Azure Postgres Flexible Server czy Google Cloud SQL oferują wbudowany connection pooling. Otóż PgDog musi zaoferować wartość dodaną, której te usługi nie zapewniają – na przykład sharding wbudowany w pooler.

Często zadawane pytania

Czy PgDog może zastąpić PgBouncera w istniejącej infrastrukturze?

PgDog obsługuje zbliżoną składnię konfiguracji TOML i implementuje protokół PostgreSQL v3, co ułatwia migrację. Konfiguracja pool_mode, admin database i parametrów połączeń jest zbliżona do PgBouncera. Należy jednak przetestować kompatybilność z konkretnymi sterownikami przed migracją produkcyjną.

Jak PgDog obsługuje prepared statements w trybie transaction pooling?

PgDog przechowuje prepared statements po stronie poolera i mapuje je na połączenia serwerowe. W PgBouncerze prepared statements nie działają w trybie transaction pooling, ponieważ połączenie może być używane przez różnych klientów. PgDog rozwiązuje ten problem poprzez wewnętrzne zarządzanie statement handle.

Czy PgDog nadaje się do małych projektów?

PgDog jest projektowany dla scenariuszy wymagających skalowania poziomego i shardingu. Dla małych projektów z jednym serwerem PostgreSQL PgBouncer jest prostszym wyborem z dojrzalszą dokumentacją. PgDog dodaje wartość przy architekturach multi-tenant i aplikacjach wymagających routingu po kluczu partycji.

Jakie języki programowania i sterowniki są wspierane przez PgDog?

Dokumentacja projektu na GitHubie zawiera listę przetestowanych sterowników, w tym psycopg2, pgx dla Go oraz node-postgres. Kompatybilność jest rozbudowywana w miarę rozwoju projektu.

Podsumowanie

PgDog to projekt z jasnym celem – zaoferować connection pooler z wbudowanym shardingiem dla PostgreSQL. Finansowanie od Y Combinator daje zespołowi zasoby do intensywnego rozwoju. Kluczowe wnioski:

• PgDog rozwiązuje realny problem z prepared statements w trybie transaction pooling
• Sharding wbudowany w pooler upraszcza architekturę aplikacji multi-tenant
• Licencja AGPL-3.0 wymaga uwagi prawnej przy komercyjnym wykorzystaniu
• Projekt jest młody, ale zyskuje uwagę dzięki finansowaniu YC
• Migracja z PgBouncera jest ułatwiona dzięki zbliżonej konfiguracji

Jeśli pracujesz z PostgreSQL na dużą skalę, sprawdź repozytorium PgDog na GitHubie i przetestuj narzędzie w środowisku deweloperskim. Warto również śledzić LiteLLM Supply Chain Attack: 97 milionów pobrań narażonych na kradzież danych, aby pamiętać o bezpieczeństwie zależności w infrastrukturze.