PgDog boucle une levée de fonds et arrive près de votre base de données

 (pgdog.dev)
1 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • PgDog est un proxy placé devant PostgreSQL, qui permet de faire évoluer Postgres horizontalement via le pooling de connexions, le load balancing et le sharding, sans réécrire l’application
  • L’existence de bases de données comme Mongo ou Dynamo est vue comme une conséquence du problème de passage à l’échelle de Postgres ; s’il pouvait gérer correctement des tables de plus de 100 To et 1 million de requêtes par seconde, il n’y aurait pas besoin d’autres bases de données
  • PgDog traite déjà plus de 2 millions de requêtes par seconde en production, a shardé plus de 20 To dans le périmètre vérifié, et son image Docker sur GitHub a dépassé 1,4 million de pulls
  • Cette équipe de trois personnes s’appuie sur son expérience des applications Postgres à grande échelle et sur l’hypercroissance par 5 d’Instacart en avril 2020, où elle a géré les problèmes de sharding Postgres sur RDS, Aurora et EC2
  • L’entreprise a levé 5,5 millions de dollars auprès de Basis Set, YC, Pioneer Fund et d’autres investisseurs, et construit PgDog comme un produit open source destiné à faire fonctionner Postgres à toutes les échelles

Levée de fonds et orientation produit

  • Le développement de Postgres est parti de l’idée que c’est la seule base de données nécessaire
  • L’existence de bases de données comme Mongo ou Dynamo est attribuée au problème de passage à l’échelle de Postgres
  • Si Postgres pouvait gérer correctement des tables de plus de 100 To et 1 million de requêtes par seconde, il n’y aurait pas de raison d’utiliser une autre base de données
  • PgDog place un proxy devant Postgres existant pour permettre une montée en charge horizontale
  • PgDog peut être déployé partout, sur site comme dans le compte cloud de l’utilisateur
  • Il suffit de récupérer l’image Docker et de modifier DATABASE_URL pour laisser PgDog prendre le relais

Situation actuelle et contexte d’exécution

  • État actuel

    • PgDog traite actuellement plus de 2 millions de requêtes par seconde dans des dizaines de déploiements en production
    • Dans le périmètre vérifié, PgDog a shardé plus de 20 To
    • PgDog est open source et peut être déployé par n’importe qui
    • Les pulls Docker sur GitHub ont dépassé 1,4 million
    • Une nouvelle version sort chaque jeudi
    • La communauté Discord continue de grandir, avec des réponses aux questions et du support chaque jour

  • L’équipe et les éléments de confiance

    • PgDog est une petite startup de trois personnes
    • L’équipe est composée d’un ingénieur infra, d’un ingénieur applicatif et d’un généraliste
    • Elle construit et exploite à grande échelle des applications basées sur Postgres depuis avant que Postgres ne devienne largement populaire
    • Elle a acquis de l’expérience opérationnelle sur Postgres chez Instacart lorsque l’entreprise a connu une croissance par 5 en avril 2020
    • Le plus gros défi à l’époque était de faire en sorte que Postgres puisse traiter des centaines de milliers de commandes de livraison de courses par minute
    • L’équipe a shardé Postgres sur RDS, Aurora et EC2, et a résolu des problèmes concrets avec des principes de base solides et beaucoup de code
    • Cette même technologie est désormais proposée comme produit open source

  • Mode de déploiement et financement

    • Le développement de PgDog n’est pas un pivot ; l’extension de Postgres reste l’unique objectif
    • PgDog est conçu pour fonctionner dans le cloud de l’utilisateur, dans un rack de colocation, on-premise ou sur un laptop
    • PgDog fonctionne là où on en a besoin, sans dépendances ni coûts serverless cachés
    • Si vous pouvez fournir du CPU, le code multithreadé de PgDog utilisera tous les CPU disponibles
    • L’adoption de Postgres devrait continuer à croître
    • L’entreprise a levé 5,5 millions de dollars auprès de Basis Set, YC, Pioneer Fund et d’autres investisseurs, ce qui lui assure plusieurs années de runway
    • L’objectif est de faire en sorte que Postgres fonctionne correctement pour tout le monde et à toutes les échelles

  • Enterprise edition

    • La Enterprise edition de PgDog est en cours de développement pour simplifier son exécution sur AWS
    • L’Enterprise edition fournit un support basé sur le SLA de l’équipe

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Avis Hacker News

  • On dit que des bases de données comme Mongo ou Dynamo existent à cause des problèmes de scalabilité de Postgres, mais d’après mon expérience avec Postgres dans plusieurs contextes, le problème numéro un a toujours été la haute disponibilité, pas la scalabilité
    Avec un seul cluster Postgres, on gérait facilement 100 000 transactions par minute, mais si le nœud principal tombait, il fallait être d’astreinte, basculer manuellement sur le nœud de secours, puis remplacer aussi manuellement ce nœud de secours
    Les outils manuels étaient très délicats à utiliser, mais au moins ils fonctionnaient, alors que les solutions automatisées n’étaient même pas au niveau
    Faute d’une bonne histoire côté HA, on a fini par éviter autant que possible les déploiements Postgres auto-hébergés

    • Nous prenons aussi en charge la HA : https://docs.pgdog.dev/features/load-balancer/
      Un load balancer avec vérification d’état et basculement fonctionne par défaut, et c’est maintenant suffisamment éprouvé en production pour mériter qu’on y jette un œil
    • Patroni 1.0 est sorti en 2016, donc il y a presque 10 ans
      https://github.com/patroni/patroni
    • Je me demande si tu as essayé cnpg
      Pour mon usage, ça a vraiment très bien fonctionné
    • Aujourd’hui, Patroni résout plutôt bien ce problème
    • Je me demande si tu as aussi regardé des solutions comme CloudNativePG : https://cloudnative-pg.io/

  • Si, dans la section « Why Us », on lit : « Nous avons exploité Postgres chez Instacart, et quand l’entreprise a été multipliée par 5 en avril 2020, notre plus gros problème a été de faire en sorte que Postgres traite plusieurs centaines de milliers de commandes de courses livrées par minute », difficile d’imaginer un meilleur pourquoi nous que ça

    • 100 000 commandes par minute, est-ce vraiment beaucoup ?
      On dirait qu’une seule instance Postgres pourrait largement l’absorber
    • Je me demande pourquoi l’unité de mesure a été changée en par minute
      Un SSD enterprise moderne et de bonne qualité peut traiter autour de 35 000 vrais fsync par seconde
    • J’ai toujours trouvé Instacart extrêmement lent, avec beaucoup de latence
      Après, je ne sais pas si c’était dû à Postgres ou à d’autres défauts d’architecture

  • J’essaie surtout de comprendre le principe : actuellement, j’ai une DB de 4 To sur un gros serveur
    Si j’utilise un outil proxy comme PGDog, est-ce que ça revient à lancer 8 petits serveurs qui gèrent chacun environ 500 Go, plus un serveur intermédiaire de taille moyenne pour le proxy ?
    Le projet actuel a énormément de trafic en écriture depuis plusieurs services, et l’application web lit depuis cette base
    On approche maintenant du point où l’indexation, l’optimisation des requêtes, le cache et même les upgrades serveur n’aident presque plus
    On envisage aussi de déplacer une grande partie des données statiques vers ClickHouse pour réduire la taille de la DB, mais j’aimerais savoir si PgDog ou un autre mécanisme de sharding pourrait être utile dans ce cas

    • « 8 petits serveurs qui gèrent chacun environ 500 Go, plus un serveur intermédiaire de taille moyenne pour le proxy », c’est exactement l’idée
      N’hésite pas à nous contacter (lev@pgdog.dev)
      On pourra soit t’aider, soit au minimum te dire ce qui fonctionne actuellement et ce qui ne fonctionne pas, afin que tu comprennes mieux tes options
    • C’est justement le principe du sharding
      Si tu lis la documentation de pgdog, tu verras qu’il faut lui indiquer vers quel shard router les requêtes, donc ça ne fonctionne pas magiquement tout seul
      Cela dit, ça garde de la valeur, notamment parce qu’il réutilise les connexions, particulièrement coûteuses avec Postgres
      Comme ce n’est pas magique, il faut comprendre ce qui se passe en interne, et par exemple il n’y a pas de transactions inter-shards
      Le sharding est difficile si tu tiens à la cohérence des données, donc je regarderais d’abord si l’application peut déjà tirer parti de réplicas en lecture
      Chaque réplique possède une copie complète des données, les écritures ne se font que sur le master, et il faut toi-même déterminer quelles transactions peuvent s’exécuter sur une réplique légèrement en retard plutôt qu’en quasi temps réel
      Par exemple, les lectures servant à générer une page web sont généralement sûres sur une réplique, mais pas les opérations de type lecture-modification-écriture

  • Je me demande comment cela aiderait avec les mises à niveau de version majeure, qui sont la principale cause de downtime sur Postgres
    Un pooler est excellent pour le failover et la répartition de charge, mais les upgrades exigent quand même régulièrement 10 à 20 minutes de downtime, une ou deux fois par an
    La réplication logique entre l’ancienne et la nouvelle version peut aider, mais il faut toujours tout basculer vers le nouveau cluster sans écritures partielles ni état bizarre
    Je me demande si certains ont déjà vécu ça

    • Nous utilisons la réplication logique et une pause/bascule via pgbouncer, ce qui gèle les écritures pendant environ 5 secondes sans qu’elles échouent
      La base fait environ 1 à 1,5 To, mais le volume de changements et le nombre de requêtes par seconde ne sont pas énormes
      C’est en gros l’approche décrite ici : https://www.pgedge.com/blog/always-online-or-bust-zero-downt...
    • En général, on gère ça avec la réplication logique
      Si vous avez une configuration d’infrastructure as code, vous créez un nouveau cluster avec les mêmes réglages mais une version majeure différente, vous importez le schéma, vous lancez la copie des données depuis un réplica en lecture de l’ancienne version, puis vous arrêtez d’accepter les écritures sur l’ancienne version (début du downtime), vous synchronisez les numéros de séquence, et vous redirigez le service vers le nouveau cluster (fin du downtime)
      Avec quelque chose comme CloudNativePG, une partie du processus est automatisée via des outils CLI et une syntaxe déclarative
      Sinon, il faut y consacrer du temps soi-même
      Ça peut sembler compliqué, mais il suffit de s’entraîner sur une base de staging, puis d’appliquer la même procédure en production une fois que ça marche
      En plus, il semble que Postgres 19 inclue un patch pour une réplication logique ponctuelle des séquences : https://www.depesz.com/2025/11/11/waiting-for-postgresql-19-...
    • La réplication logique résout ça
      Si vous faites tourner les clusters de manière séquentielle, le downtime est très faible, de l’ordre de 60 secondes
    • C’est étrange que PostgreSQL n’ait toujours pas de véritable implémentation open source générique de multi-master
      À ce stade, je me demande si je verrai ça un jour
    • Quand on vient de MySQL, c’est une grosse régression, et ça donne à Postgres un côté technologie des années 80
      Je me demande toujours pourquoi ce n’est pas considéré comme une priorité absolue

  • Félicitations pour le financement, Lev
    Nous utilisons PgDog ici avec satisfaction
    J’apprécie particulièrement, côté proxy, la gestion de paramètres de connexion différents selon la connexion, par exemple statement_timeout
    Quand j’avais étudié RDS Proxy auparavant, il ne le prenait pas en charge, et je crois que c’était pareil pour pgbouncer, ce qui nécessitait beaucoup de changements côté application
    Avec PgDog, ça fonctionne simplement de façon transparente

  • Je me demande si c’est comparable au multigres de Supabase qui vient d’être annoncé

  • Je vois une Enterprise Edition ; pourriez-vous préciser clairement quelles fonctionnalités ne sont pas open source ?
    Je me demande aussi si vous prévoyez que les nouvelles fonctionnalités ajoutées passeront sous licence EE afin de rendre des comptes aux investisseurs VC

    • Il y a deux grosses fonctionnalités
      La première est un control plane qui gère les déploiements multi-nœuds et offre une expérience “prête à l’emploi” pour déployer et utiliser PgDog facilement
      La seconde, c’est la qualité de service (QoS), qui bloque automatiquement les mauvaises requêtes pour éviter qu’elles ne fassent tomber la base de données
      Enfin, vous pouvez aussi obtenir du support avec un SLA garanti jusqu’au niveau P0
      Les nouvelles fonctionnalités se répartissent en deux catégories
      Le sharding et l’exploitation de Postgres à grande échelle resteront toujours open source, tandis que la gestion de l’infrastructure et les fonctions qui facilitent l’exploitation de PgDog à grande échelle relèvent de l’édition enterprise

  • C’est bien de voir arriver PgDog, Neki et multigres
    C’est bien là l’un des problèmes centraux de Postgres, et l’absence de hints d’index en est un autre, donc j’attends Postgres 19 avec impatience

    • Il ne faut pas oublier le pionnier, PgBouncer
      Sa configuration est difficile, mais avec l’aide de l’IA, c’est devenu plus simple à mettre en place ces jours-ci
    • L’extension pg_hint_plan n’est pas intégrée au cœur, mais elle est tout à fait capable quand il faut forcer le planner

  • La phrase “nous avons shardé plus de 20 To, à notre connaissance” est probablement une faute de frappe
    20 To, ce n’est pas si énorme
    J’imagine qu’ils ont shardé bien davantage

    • Si vous considérez que 20 To n’est “pas si énorme”, j’aimerais savoir quel ordre de grandeur de base de données vous manipulez
    • Si l’ensemble de travail fait 20 To, c’est déjà assez gros
      Le ratio entre données chaudes et données froides varie d’une base à l’autre, donc sans plus d’informations, la comparaison est impossible
      Un meilleur indicateur serait peut-être les IOPS
      Sur RDS, le plafond d’IOPS est assez bas à moins de dépenser beaucoup plus pour des IOPS provisionnées ou d’utiliser Aurora
    • Oui
      À titre de comparaison, il y a presque 10 ans, chez Segment, nous faisions tourner une seule instance Aurora PostgreSQL avec environ 50 To de données, utilisée pour indexer des données potentiellement identifiantes dans un corpus de fichiers bien plus volumineux stocké sur S3
    • Pour la majorité des cas d’usage, 20 To est clairement énorme

  • PgDog est bien
    Honnêtement, je n’en ai pas besoin, mais en randonnée en forêt je n’avais rien à écouter, je suis tombé par hasard sur le podcast Postgres FM, ça m’a intéressé, et maintenant je l’utilise sur mon Kubernetes on-premise
    https://open.spotify.com/episode/6qgpfiW68KcvRASs6649Fb