PgDog – Ein Tool zum Sharding von Postgres ohne separate Erweiterungen

• Ein in Rust entwickelter Transaktions-Pooler und Manager für logische Replikation für PostgreSQL, der horizontale Skalierung und die Automatisierung von Sharding bietet
• PostgreSQL-Datenbanken lassen sich einfach ohne Erweiterungen sharden, optimiert für die Verwaltung von Hunderten Datenbanken und Hunderttausenden Verbindungen
• Als DB-Load-Balancer auf Anwendungsebene (OSI 7) kann SELECT automatisch an Replikate und alles andere an den Primärknoten weiterleiten
• Unterstützt wie PgBouncer Transaktions-/Session-Pooling, parst aber zusätzlich Queries für automatisches Routing auf Shards und führt sogar das Zusammenführen der Ergebnisse durch
• Mit COPY und logischer Replikation kann es Daten automatisch auf Shards verteilen oder bestehende Datenbanken ohne Downtime sharden
• Die Konfiguration lässt sich einfach über TOML-Dateien definieren und zur Laufzeit neu konfigurieren
• Anders als Citus, das PostgreSQL-Erweiterungen nutzt, ist es ein externer Proxy der Datenbank und kann daher auch mit RDS, Cloud SQL usw. verwendet werden

---

Projektvorstellung und zentrale Vorteile

• PgDog ist eine Open-Source-Lösung für PostgreSQL-Datenbanken, die einfaches Sharding, logische Replikation, Transaktions-Pooling und L7-Load-Balancing für umfassende horizontale Skalierung unterstützt
• Es wurde in Rust entwickelt und bietet dadurch hohe Performance und Sicherheit
• Ohne Installation von Erweiterungen ermöglicht PgDog bereits mit der Bereitstellung eines einzelnen Proxys Sharding, Datenverteilung, Failover und flexibles Load-Balancing
• Im Unterschied zu Konkurrenzprodukten (z. B. PgBouncer, PgCat) unterstützt es zusätzlich automatisches Sharding und logische Replikation und punktet mit Konfigurationsänderungen im laufenden Betrieb und Echtzeit-Monitoring

Hauptfunktionen

Lastverteilung (Load Balancer)

• PgDog ist ein Proxy auf Anwendungsebene der OSI-Schicht 7, der Queries auf mehrere PostgreSQL-Replikate und Primärknoten verteilt und so Ausfälle sowie Überlastung verhindert
• Es werden verschiedene Verteilungsstrategien angeboten, darunter Round-Robin, zufällig und Least Connections
• Durch Erkennung des Query-Typs werden SELECTs an Replikate und andere Schreib-Queries automatisch an den Primärknoten weitergeleitet
• Führt Health Checks und automatisches Failover bei Störungen durch und stellt so Verfügbarkeit auch bei Netzwerkfehlern oder Hardwareausfällen sicher

Transaktions-Pooling

• Wie PgBouncer unterstützt PgDog Transaktions- und Session-Pooling zur effizienten Verwaltung von Verbindungsressourcen, sodass auch Hunderttausende Clients mit wenigen Backend-Verbindungen abgedeckt werden können

Sharding

• Parst Query-Syntax direkt, um Sharding-Keys zu extrahieren und optimale Routing-Algorithmen anzuwenden
• Unterstützt auch Cross-Shard-Queries über mehrere Shard-Datenbanken hinweg, fasst Ergebnisse im Speicher zusammen und liefert sie transparent an den Client zurück
• Bei Ausführung des COPY-Befehls wird Multi-Shard-Verteilung von Daten durch CSV-Parsing unterstützt, praktisch für große Ladevorgänge
• Auf Basis des PostgreSQL-Protokolls für logische Replikation sind unterbrechungsfreie Hintergrundsynchronisierung sowie das Hinzufügen und Skalieren von Shards im laufenden Betrieb möglich

Monitoring

• Unterstützt sowohl eine Admin-Datenbank im Stil von PgBouncer als auch einen OpenMetrics-Endpunkt
• Bietet Beispiele für externes Monitoring und Dashboards wie Datadog

Konfiguration und Laufzeit

• Typische Umgebungen: Kubernetes (mit Helm-Chart), Docker und lokale Umgebungen (Rust-Build) für einfache Bereitstellung und Tests
• In der Regel reichen 2 Konfigurationsdateien (pgdog.toml, users.toml) aus, um eine minimale Sharding- und benutzerbasierte Betriebsumgebung einzurichten
• Die meisten Konfigurationswerte können in Echtzeit geändert und ohne Neustart des Prozesses dynamisch übernommen werden

Performance und Lizenz

• PgDog ist ein hochperformanter asynchroner Netzwerk-Proxy auf Basis von Rust und Tokio, mit Fokus auf minimale Datenbewegung und geringe Performance-Einbußen
• Benchmark-Ergebnisse werden in der offiziellen Dokumentation bereitgestellt, sodass sich Performance-Benchmarks festlegen lassen
• Veröffentlicht unter der Open-Source-Lizenz AGPL v3, vollständig offen für interne Unternehmensnutzung und private Anpassungen
• Allerdings gilt für Anbieter öffentlicher Cloud-Dienste die Bedingung, Änderungen am Code offenzulegen, wenn sie den Code modifizieren

Projektstatus und Beiträge

• Das Projekt befindet sich derzeit in einer frühen Phase; Early Adopters wird die eigenständige Einführung empfohlen, während die Stabilisierung der Funktionen kontinuierlich voranschreitet
• Funktionsbezogene Tests und Benchmarks werden ebenfalls laufend durchgeführt
• Beiträge aus der Open-Source-Community sind willkommen; Details finden sich in den Contribution Guidelines

Fazit

• PgDog bietet eine hervorragende Lösung für Entwicklungsteams und Unternehmen, die in Produktionsumgebungen horizontale Skalierbarkeit, hohe Verfügbarkeit und automatisches Sharding für PostgreSQL benötigen
• Ein großer Vorteil ist, dass es sich schnell einführen und anpassen lässt, ohne separate Erweiterungen oder den Aufbau einer komplexen Infrastruktur

[GN⁺]

Hacker-News-Kommentare

• Begrüßt Lev und erklärt die aktuelle Situation, in der PgDog mit einer Eigenentwicklung für das Sharding einer 40-TB-Postgres-Datenbank verglichen wird; erwähnt, dass eine Lösung benötigt wird, die wie Vitess for PostgreSQL funktioniert, und betont, dass zusätzlich zur Scatter-Gather-Funktion auch konfigurationsbasiertes Management auf Basis von etwas wie etcd, Shard-Splitting sowie Best-Effort-Transaktionen zum Anwenden von Schemaänderungen auf alle Shards nötig sind; fragt nach Erfahrungen mit Query-Rewriting über pg_query.rs, teilt mit, dass das Rewriting wegen der Unveränderlichkeit der AST-Typen und fehlender Deep-Clones schwierig wirkte, nutzt inzwischen letztlich das sqlparser-Crate mit Unterstützung für das Visitor-Pattern und arbeitet nebenbei an Online-Schemaänderungen für PG auf Basis von Shadow Tables und logischer Replikation

  • Freut sich über das Kooperationsangebot und teilt Kontaktinformationen; erklärt, dass Konfigurationsmanagement bereits mit K8s oder verschiedenen CD-Tools gelöst werden kann und dass sich das Neuladen der PgDog-Konfiguration synchronisieren lässt; erwähnt, dass Best-Effort-Transaktionen für Schemaänderungen über alle Shards bereits funktionieren, idempotente Schemaänderungen aber am besten seien und bei Fehlschlägen auch Two-Phase Commit in Betracht komme; nennt als Beispiel, dass Shard-Splitting per logischer Replikation möglich sei, und verweist auf Erfahrungen mit 10 TB+ bei Instacart; teilt das Verfahren, nach dem nach dem Öffnen eines Replikationsslots per Recovery auf N Instanzen wiederhergestellt, Daten mit nicht übereinstimmender Shard-Nummer gelöscht und anschließend per logischer Replikation erneut synchronisiert werden; erwähnt die Idee, in Pg 17 logische Replikation auf einer Streaming Replica für paralleles Splitting zu nutzen, und denkt auch über eine Methode nach, Daten per COPY direkt über Foreign Tables zu übertragen; hebt hervor, dass pg_query.rs inzwischen wohl mutierbar arbeitet und daher in letzter Zeit aktiv für Query-Rewriting und -Generierung genutzt wird, wobei der große Vorteil die 100%ige Basis auf dem Postgres-Parser ist; die Funktion „deparse“ sei an vielen Stellen vorhanden und ermögliche daher komplexe Arbeiten

• Fragt, ob nicht Yugabyte diese Rolle übernehmen würde, falls es so etwas wie Vitess for Postgres gäbe

• Auch wenn es beim Blick auf die Kernfunktionen klein wirkt, sei es ein enormer Vorteil von PgDog, dass sich damit Code vermeiden lässt und Reads auf Read Replicas sowie Writes auf die Primary getrennt werden können; viele Apps unterstützten R/W-Trennung nicht direkt, daher habe die Behandlung auf Proxy-Ebene in der Vergangenheit große Geschwindigkeitsverbesserungen gebracht; lobt das Projekt

  • Hinweis, dass diese Funktion bereits in pgcat verfügbar ist, zusammen mit dem pgcat-Link

  • Teilt die Erfahrung, bei Instacart mit Makara R/W-Trennung umgesetzt zu haben, und dass es ziemlich lästig war, dieselbe Logik in verschiedenen Sprachumgebungen wie Python oder Go immer wieder neu zu implementieren

• Bewertet das Projekt als beeindruckend, hat aber etwas Distanz zu vollständig automatisiertem Sharding; erklärt, dass Sharding normalerweise an Mandantengrenzen erfolgt und man möchte, dass das Überschreiten dieser Grenzen mit Reibung verbunden ist; meint, dass Cross-Shard-Joins sich hinsichtlich Performance, Speicher und CPU von In-Shard-Joins unterscheiden und dies klarer sichtbar gemacht werden sollte; hat aber keine Zweifel am Projekt selbst und erwartet sehr viele Einsatzfälle

  • Fragt, warum man absichtlich Reibung wolle, und ergänzt, dass Performance-Probleme bei Cross-Shard-Joins meist gut verstanden und per Echtzeitmetriken verfolgbar seien; letztlich brauche man beide Ansätze, und die Alternative, Joins im App-Code auszuführen, sei nicht besonders wünschenswert

• Beobachtet PgDog bereits aufmerksam und bewertet es als sehr beeindruckend; gratuliert zum Launch und hofft auf eine weitere gute Entwicklung

  • Erklärt, dass eine 15-jährige Reise jetzt erst beginne

• Meint, der zentrale Reiz liege darin, verteilte Queries zu verarbeiten und dabei Transparenz und Kompatibilität auf der Netzwerkschicht zu wahren; die aktuellen Einschränkungen in der Dokumentation seien natürlich und es werde wohl Trade-offs brauchen; ist neugierig, wie das gelöst wird, und würde sich an weiteren Diskussionen gern beteiligen

  • Lädt zur Teilnahme an der Discord-Community ein und teilt den Einladungslink

• Erwähnt, dass die größte Schwierigkeit bei Lösungen wie PgDog darin liege, die letzten 1 % komplexer Sharding-Queries sauber zu verarbeiten (oder anormale Queries zu erkennen) oder Isolation und Konsistenz vollständig zu garantieren

• Hat beim Blick in die Dokumentation als Erstes geprüft, ob Unique Indexes unterstützt werden, bedauert aber, dass dies noch nicht der Fall ist, weil dafür Query-Rewriting und eine separate Ausführungs-Engine nötig seien; sieht dennoch Potenzial und ist gespannt

  • Erwidert, dass als kleiner Trost die Erzeugung shardübergreifend eindeutiger Primärschlüssel bereits unterstützt wird, und teilt den Link zur zugehörigen Dokumentation; die Implementierung shardübergreifender Unique Indexes sei teuer, weil bei allen Queries geprüft werden müsse, und man sei für Ideen offen

• Betont, dass dies das interessanteste Postgres-Projekt seit Jahren sei; die bereitgestellten Benchmarks schienen nur grundlegendes Connection Pooling zu behandeln, daher sei man neugierig auf die Ergebnisse, wenn Query Parsing oder Cross-Shard-Joins aktiv sind

  • Erklärt, dass der Query-Parser gecacht wird und bei Prepared Queries oder bei der Nutzung von Platzhaltern praktisch nur Locks und Hash-Lookups zusätzlich anfallen, also fast keine Kosten entstehen; bei Cross-Shard-Joins könne der Query-Verarbeitungsaufwand höher werden, wenn Filter nicht optimal sind, und bei großen Ergebnismengen könne Paging auf Disk nötig werden; der Fokus liege zunächst auf OLTP und darauf, Joins so weit wie möglich per Pushdown auszuführen, aber es sei zu erwarten, dass der Bedarf an Cross-Shard-Joins bald ebenfalls zunehme

• Bewertet es als dringend nötige Innovation für die Skalierbarkeit von Postgres und gratuliert zum Launch

• Das Projekt wirkt ausgesprochen hervorragend, Glückwunsch zum Launch

  • Betont, dass darin die Arbeit vieler Jahre steckt