PgDog schließt Finanzierung ab und kommt in eine Datenbank in Ihrer Nähe

 (pgdog.dev)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • PgDog ist ein Proxy vor PostgreSQL, der Postgres ohne Neuschreiben der Anwendung durch Connection Pooling, Load Balancing und Sharding horizontal skalierbar macht
  • Den Grund für die Existenz von Datenbanken wie Mongo oder Dynamo sieht das Team im Skalierungsproblem von Postgres und ist der Ansicht, dass keine anderen Datenbanken nötig wären, wenn sich Tabellen mit mehr als 100 TB und 1 Million Abfragen pro Sekunde verarbeiten ließen
  • PgDog verarbeitet in der Produktion mehr als 2 Millionen Abfragen pro Sekunde, hat nachweislich mehr als 20 TB geshardet, und die Docker-Pulls auf GitHub liegen bei über 1,4 Millionen
  • Das dreiköpfige Team hat auf Basis von Erfahrungen mit großen Postgres-Anwendungen und der 5-fachen Skalierung bei Instacart am 5. April 2020 Probleme rund um Postgres-Sharding auf RDS, Aurora und EC2 gelöst
  • Von Basis Set, YC, Pioneer Fund und anderen wurden 5,5 Millionen US-Dollar eingesammelt; gebaut wird PgDog als Open-Source-Produkt, das Postgres in jeder Größenordnung funktionsfähig machen soll

Finanzierung und Produktausrichtung

  • Die Entwicklung von PgDog begann aus der Sicht heraus, dass Postgres die einzige Datenbank ist, die man braucht
  • Den Grund für die Existenz von Datenbanken wie Mongo oder Dynamo sieht das Team im Skalierungsproblem von Postgres
  • Wenn Postgres Tabellen mit mehr als 100 TB und 1 Million Abfragen pro Sekunde zuverlässig verarbeiten könnte, würde man keine andere Datenbank verwenden
  • PgDog ermöglicht horizontale Skalierung, indem ein Proxy vor bestehendes Postgres gesetzt wird
  • PgDog kann überall bereitgestellt werden, etwa On-Premises oder im Cloud-Konto des Nutzers
  • Man zieht das Docker-Image und ändert DATABASE_URL, den Rest übernimmt PgDog

Aktueller Stand und Hintergrund der Umsetzung

  • Aktueller Stand

    • PgDog verarbeitet in Dutzenden Produktionsumgebungen mehr als 2 Millionen Abfragen pro Sekunde
    • Nachweislich hat PgDog mehr als 20 TB geshardet
    • PgDog ist Open Source und kann von jedem bereitgestellt werden
    • Die Docker-Pulls auf GitHub liegen bei über 1,4 Millionen
    • Neue Versionen erscheinen jeden Donnerstag
    • Die Discord-Community wächst; täglich werden Fragen beantwortet und Support geleistet

  • Team und Vertrauensbasis

    • PgDog ist ein kleines Startup mit drei Personen
    • Das Team besteht aus Infrastructure Engineers, Application Engineers und Generalists
    • Das Team hat schon bevor Postgres breite Aufmerksamkeit bekam Postgres-basierte Anwendungen gebaut und im großen Maßstab betrieben
    • Bei Instacart sammelte es Betriebserfahrung mit Postgres, als das Unternehmen im April 2020 auf das Fünffache skalierte
    • Das größte Problem damals war, Postgres so zu betreiben, dass Hunderttausende Lebensmittel-Lieferbestellungen pro Minute verarbeitet werden konnten
    • Postgres wurde auf RDS, Aurora und EC2 geshardet; mit grundlegenden Prinzipien und viel Code wurden echte Probleme gelöst
    • Dieselbe Technik wird heute als Open-Source-Produkt angeboten

  • Bereitstellungsmodell und Finanzierung

    • Die Entwicklung von PgDog ist kein Pivot; die Skalierung von Postgres bleibt das einzige Ziel
    • PgDog ist dafür gemacht, in der Cloud des Nutzers, in Colocation-Racks, On-Premises und auf Laptops zu laufen
    • PgDog funktioniert dort, wo es gebraucht wird, ohne Abhängigkeiten oder versteckte Serverless-Kosten
    • Wenn CPU bereitgestellt werden kann, nutzt der multithreaded Code von PgDog alle CPUs
    • Das Team geht davon aus, dass die Nutzung von Postgres weiter zunehmen wird
    • Von Basis Set, YC, Pioneer Fund und weiteren Investoren wurden 5,5 Millionen US-Dollar eingesammelt, was mehrere Jahre Runway sichert
    • Das Ziel ist, Postgres für alle und in jeder Größenordnung zuverlässig funktionsfähig zu machen

  • Enterprise edition

    • Die Enterprise edition von PgDog wird entwickelt, um den Betrieb auf AWS zu vereinfachen
    • Die Enterprise edition bietet SLA-basierten Support durch das Team

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Hacker-News-Kommentare

  • Man sagt zwar, dass Datenbanken wie Mongo oder Dynamo wegen der Skalierungsprobleme von Postgres existieren, aber nach meiner Erfahrung mit Postgres an mehreren Orten war das Problem erster Priorität immer Hochverfügbarkeit und nicht Skalierung.
    Mit einem einzigen Postgres-Cluster haben wir problemlos 100.000 Transaktionen pro Minute verarbeitet, aber wenn der Primary ausgefallen ist, wurde man angerufen, musste manuell auf den Standby failovern und danach auch den Standby wieder manuell ersetzen.
    Die manuellen Tools waren sehr heikel, haben aber wenigstens funktioniert, und automatisierte Lösungen kamen nicht einmal annähernd heran.
    Wegen der fehlenden guten HA-Story vermeide ich selbst betriebenes Postgres nach Möglichkeit.

    • Wir unterstützen auch HA: https://docs.pgdog.dev/features/load-balancer/
      Ein Load Balancer mit Health Checks und Failover läuft standardmäßig, und inzwischen ist das auch ausreichend im Praxiseinsatz erprobt, sodass es einen Blick wert sein dürfte.
    • Patroni 1.0 erschien 2016, also vor fast 10 Jahren.
      https://github.com/patroni/patroni
    • Ich frage mich, ob du cnpg ausprobiert hast.
      Für meinen Anwendungsfall hat es wirklich gut funktioniert.
    • Inzwischen löst Patroni diesen Bereich ziemlich gut.
    • Ich frage mich, ob du dir auch etwas wie CloudNativePG angesehen hast: https://cloudnative-pg.io/

  • Wenn auf der „Why Us“-Seite steht: „Wir haben Postgres bei Instacart betrieben, und als das Unternehmen im April 2020 auf das Fünffache anwuchs, war das größte Problem, dafür zu sorgen, dass Postgres Hunderttausende Bestellungen für Lebensmittellieferungen pro Minute verarbeiten konnte“, dann gibt es kaum ein besseres Warum wir als das.

    • Sind 100.000 Bestellungen pro Minute viel?
      Das sieht so aus, als könnte auch eine einzelne Postgres-Instanz das gut bewältigen.
    • Ich frage mich, warum man den Maßstab auf pro Minute geändert hat.
      Moderne hochwertige Enterprise-SSDs können real etwa 35.000 fsync-Operationen pro Sekunde verarbeiten.
    • Ich hatte immer das Gefühl, dass Instacart extrem langsam war und hohe Latenzen hatte.
      Ob das an Postgres lag oder an anderen Architekturfehlern, weiß ich natürlich nicht.

  • Ich möchte das grundsätzlich verstehen: Im Moment haben wir eine 4-TB-DB auf einem großen Server.
    Wenn man ein Proxy-Tool wie PGDog verwendet, bedeutet das dann, dass man 8 kleine Server startet, die jeweils etwa 500 GB übernehmen, plus einen mittelgroßen Server als Proxy?
    Das aktuelle Projekt hat sehr viel Schreibtraffic aus mehreren Services, und die Web-App liest daraus.
    Wir nähern uns jetzt einem Punkt, an dem Indexierung, Query-Optimierung, Caching und Server-Upgrades kaum noch helfen.
    Wir prüfen auch, den Großteil der statischen Daten nach ClickHouse zu verschieben, um die DB-Größe zu reduzieren, aber ich würde gern hören, ob PgDog oder anderes Sharding für diesen Zweck nützlich sein könnte.

    • „8 kleine Server, die jeweils etwa 500 GB übernehmen, plus ein mittelgroßer Server als Proxy“ ist genau diese Architektur.
      Melde dich gern (lev@pgdog.dev).
      Wir können helfen oder dir zumindest sagen, was derzeit funktioniert und was nicht, damit du deine Optionen besser einschätzen kannst.
    • Das ist das Konzept von Sharding.
      Wenn du die pgdog-Dokumentation liest, wirst du sehen, dass du angeben musst, an welchen Shard-Server Anfragen geroutet werden sollen; es funktioniert nicht einfach magisch von selbst.
      Trotzdem hat es Wert, weil besonders teure Verbindungen in Postgres wiederverwendet werden.
      Es ist keine Magie, daher muss man verstehen, was intern passiert; zum Beispiel gibt es keine shardübergreifenden Transaktionen.
      Sharding ist schwierig, wenn dir Datenkonsistenz wichtig ist, daher würde ich zuerst prüfen, ob die Anwendung von Read Replicas profitieren kann.
      Replikas haben jeweils eine vollständige Kopie der Daten und schreiben nur auf den Master; außerdem musst du selbst beurteilen, welche Transaktionen auch auf einem Replikat laufen dürfen, das fast in Echtzeit ist, aber leicht hinterherhängen kann.
      Zum Beispiel sind Lesevorgänge zum Rendern einer Webseite auf einem Replikat meist unproblematisch, Read-Modify-Write dagegen nicht.

  • Ich frage mich, wie das bei Major-Version-Upgrades, der größten Ursache für Downtime bei Postgres, helfen soll
    Pooler sind großartig für Failover und Load Balancing, aber wegen Upgrades braucht man ein- bis zweimal im Jahr trotzdem zuverlässig etwa 10–20 Minuten Downtime
    Logische Replikation von der alten auf die neue Version kann helfen, aber man muss wohl weiterhin alles auf den neuen Cluster umziehen, ohne partielle Writes oder seltsame Zustände zu erzeugen
    Mich würde interessieren, ob jemand damit Erfahrung hat

    • Wir nutzen logische Replikation und ein Pause/Umschalten mit pgbouncer, sodass Writes nicht fehlschlagen, sondern nur etwa 5 Sekunden pausieren
      Die DB ist etwa 1–1,5 TB groß, aber die Änderungsrate oder die Zahl der Queries pro Sekunde ist nicht extrem hoch
      Im Grunde genau die hier beschriebene Methode: https://www.pgedge.com/blog/always-online-or-bust-zero-downt...
    • Üblicherweise macht man das mit logischer Replikation
      Wenn man Infrastruktur als Code eingerichtet hat, erstellt man einen neuen Cluster mit identischer Konfiguration, nur mit anderer Major-Version, importiert das Schema, startet das Kopieren der Daten von einem Read-Replica der alten Version, stoppt dann das Akzeptieren von Writes auf der alten Version (Beginn der Downtime), synchronisiert die Sequenznummern und lenkt den Service auf den neuen Cluster um (Ende der Downtime)
      Mit etwas wie CloudNativePG wird ein Teil dieses Prozesses durch CLI-Tools und deklarative Syntax automatisiert
      Sonst muss man sich eben selbst die Zeit nehmen, das auszuarbeiten
      Es klingt vielleicht kompliziert, aber wenn man es erst auf einer Staging-DB geübt hat und es dort funktioniert, führt man in Produktion denselben Ablauf aus
      Außerdem scheint es für Postgres 19 einen Patch für eine einmalige logische Replikation von Sequenzen zu geben: https://www.depesz.com/2025/11/11/waiting-for-postgresql-19-...
    • Logische Replikation löst das
      Wenn man die Cluster nacheinander betreibt, ist die Downtime sehr klein, vielleicht etwa 60 Sekunden
    • Es ist seltsam, dass PostgreSQL noch immer keine brauchbare Open-Source-Allzweck-Implementierung für Multi-Master hat
      Inzwischen frage ich mich, ob ich das überhaupt noch erleben werde
    • Wenn man von MySQL kommt, ist das ein großer Rückschritt und lässt Postgres wie Technik aus den 80ern wirken
      Ich frage mich immer noch, warum das nicht absolut oberste Priorität hat

  • Glückwunsch zur Finanzierung, Lev
    Wir nutzen PgDog hier zufrieden
    Mir gefällt besonders bei den Proxy-Funktionen, dass unterschiedliche Connection-Einstellungen pro Verbindung verarbeitet werden, zum Beispiel statement_timeout
    Als ich mir früher RDS Proxy angesehen habe, wurde das nicht unterstützt, und bei pgbouncer war es wohl genauso, sodass viele Änderungen an der Anwendung nötig gewesen wären
    Bei PgDog funktioniert es transparent einfach so

  • Ich frage mich, ob das mit dem gerade angekündigten multigres von Supabase vergleichbar ist

  • Ich sehe eine Enterprise Edition und würde gern klarer verstehen, welche Funktionen nicht Open Source sind
    Mich würde auch interessieren, ob zu erwarten ist, dass neu hinzukommende Funktionen unter einer EE-Lizenz stehen werden, um den VC-Investoren etwas zurückzugeben

    • Es gibt zwei große Funktionen
      Erstens eine Control Plane zur Verwaltung von Multi-Node-Deployments, die eine „funktioniert sofort“-Erfahrung bietet, damit man PgDog leicht deployen und nutzen kann
      Zweitens Quality of Service (QoS), das schlechte Queries automatisch blockiert, damit sie die Datenbank nicht herunterziehen
      Außerdem kann man Support mit SLA-Garantie bis hin zu P0 erhalten
      Neue Funktionen fallen in zwei Kategorien
      Sharding und der Betrieb von Postgres in großem Maßstab bleiben immer Open Source, während Infrastrukturverwaltung und Funktionen, die den großflächigen Betrieb von PgDog vereinfachen, Enterprise sind

  • Es ist schön zu sehen, dass PgDog, Neki und multigres erscheinen
    Zu Recht ist das ein Kernproblem von Postgres, und dazu kommt noch das Fehlen von Index-Hints, weshalb ich mich auf Postgres 19 freue

    • Man darf auch den Urvater PgBouncer nicht vergessen
      Die Konfiguration ist schwierig, aber mit KI-Unterstützung ist das Einrichten heute leichter geworden
    • Die Erweiterung pg_hint_plan ist zwar nicht im Core enthalten, aber ziemlich leistungsfähig, wenn man den Planner übersteuern muss

  • „Wir wissen von über 20 TB, die geshardet wurden“ ist wahrscheinlich ein Tippfehler
    20 TB sind nicht so groß
    Ich denke, es wurde deutlich mehr geshardet

    • Wenn du meinst, 20 TB seien „nicht so groß“, würde mich interessieren, mit welchen DB-Größen du arbeitest
    • Wenn der Working Set 20 TB beträgt, ist das ziemlich groß
      Das Verhältnis zwischen heißen und kalten Daten ist je nach Datenbank unterschiedlich, daher kann man ohne mehr Informationen nichts sinnvoll vergleichen
      Ein besserer Maßstab könnte IOPS sein
      Bei RDS sind die maximalen IOPS ziemlich niedrig, wenn man nicht deutlich mehr für provisionierte IOPS bezahlt oder Aurora nutzt
    • Stimmt
      Zum Vergleich: Vor fast 10 Jahren haben wir bei Segment eine einzelne Aurora-PostgreSQL-Instanz mit etwa 50 TB Daten betrieben, die zum Indexieren potenziell identifizierender Daten in einem deutlich größeren, in S3 gespeicherten Dateikorpus genutzt wurde
    • Für die meisten Anwendungsfälle sind 20 TB definitiv riesig

  • PgDog ist gut
    Ehrlich gesagt brauche ich es nicht, aber ich hatte beim Wandern im Wald nichts zum Anhören, bin zufällig auf den Podcast Postgres FM gestoßen, fand es interessant und nutze es jetzt auf meinem On-Premises-Kubernetes
    https://open.spotify.com/episode/6qgpfiW68KcvRASs6649Fb