PgDogが資金調達を完了し、あなたのすぐそばのデータベースへ
(pgdog.dev)- PgDog は PostgreSQL の前段に置くプロキシで、アプリケーションを書き換えることなく、接続プーリング・ロードバランシング・シャーディングを通じて Postgres を水平スケールさせます
- Mongo や Dynamo のようなデータベースが存在する理由を Postgres のスケーリング問題 にあると捉え、100TB を超えるテーブルと毎秒 100 万クエリを処理できるなら、他のデータベースは不要だと考えています
- PgDog は本番環境で毎秒 200 万件以上のクエリを処理しており、確認済みの範囲で 20TB 超を シャーディング していて、GitHub の Docker pull は 140 万回を超えています
- 3 人規模のチームが、Postgres ベースの大規模アプリケーションと Instacart の 2020 年 4 月における 5 倍スケールの経験をもとに、RDS、Aurora、EC2 で Postgres のシャーディング問題に取り組んできました
- Basis Set、YC、Pioneer Fund などから 550 万ドル を調達し、あらゆる規模で Postgres を動かせるオープンソース製品として PgDog を構築中です
資金調達と製品の方向性
- Postgres こそが必要な唯一のデータベースだという視点から PgDog の開発は始まりました
- Mongo や Dynamo のようなデータベースが存在する理由を Postgres の スケーリング問題 にあると見ています
- Postgres が 100TB を超えるテーブルと毎秒 100 万クエリをきちんと処理できるなら、他のデータベースは使わないだろうと考えています
- PgDog は既存の Postgres の前にプロキシを置くことで 水平スケール を可能にします
- PgDog はオンプレミスやユーザーのクラウドアカウントなど、どこにでもデプロイできます
- Docker イメージを取得して
DATABASE_URLを変更すれば、PgDog が処理を引き受ける仕組みです
現状と実行の背景
-
現在の状況
- PgDog は本番の数十のデプロイ環境で毎秒 200 万件以上のクエリを処理中です
- 確認済みの範囲で、PgDog は 20TB 超を シャーディング しています
- PgDog はオープンソースで、誰でもデプロイできます
- GitHub での Docker pull は 140 万回を超えています
- 新バージョンは毎週木曜日に公開されています
- Discord コミュニティは成長中で、毎日質問への回答とサポートが行われています
-
チームと信頼の根拠
- PgDog は 3 人規模の小さなスタートアップです
- チームはインフラエンジニア、アプリケーションエンジニア、ジェネラリストで構成されています
- チームは Postgres が広く注目される前から、Postgres ベースのアプリケーションを作り、大規模に動かしてきました
- Instacart で 2020 年 4 月に会社が 5 倍にスケールする間、Postgres 運用の経験を積みました
- 当時最大の課題は、Postgres が毎分数十万件の食料品配送注文を処理できるようにすることでした
- RDS、Aurora、EC2 で Postgres をシャーディングし、基本原理と多くのコードによって実際の問題を解決してきました
- その同じ技術が、現在はオープンソース製品として提供されています
-
デプロイ方式と資金
- PgDog の開発はピボットではなく、Postgres のスケーリングが引き続き唯一の目標です
- PgDog はユーザーのクラウド、コロケーションラック、オンプレミス、ノート PC 上で動作するように作られています
- PgDog は依存関係や隠れたサーバーレス費用なしに、必要な場所で動作します
- CPU を提供できれば、PgDog のマルチスレッドコードがすべての CPU を使います
- Postgres の採用は今後も増え続けると見ています
- Basis Set、YC、Pioneer Fund とそのほかの投資家から 550 万ドルを調達し、数年分のランウェイを確保しました
- 目標は、すべての人にとって、あらゆる規模で Postgres がきちんと動作するようにすることです
-
Enterprise edition
- PgDog の Enterprise edition は、AWS 上でより簡単に実行できるよう開発中です
- Enterprise edition は、チームによる SLA ベースのサポートを提供します
1件のコメント
Hacker Newsのコメント
MongoやDynamoのようなデータベースが存在する理由はPostgresのスケーリング問題だと言われるが、いろいろな場所でPostgresを使ってきた経験では、常に最優先の問題は高可用性であって、スケーリングではなかった。
単一のPostgresクラスタで毎分10万トランザクションは簡単に処理できたが、プライマリノードが落ちると呼び出しを受けてスタンバイノードへ手動フェイルオーバーし、その後スタンバイノードも手動で入れ替える必要があった。
手動ツールは非常に扱いづらかったが、それでも一応は動作し、自動化された解決策はそこまで到達していなかった。
良いHAストーリーが不足しているため、セルフホストのPostgresはできるだけ避けるようになった。
ヘルスチェックとフェイルオーバーを備えたロードバランサがデフォルトで動作し、今では十分に本番での実績もあるので、一度見てみる価値はある。
https://github.com/patroni/patroni
自分の用途では本当にうまく動いた。
「Why Us」に「InstacartでPostgresを運用しており、2020年4月に会社が5倍に成長したとき、Postgresに毎分数十万件の食料品配達注文を処理させることが最大の課題だった」と書かれているなら、これ以上に良いなぜ我々なのかはない気がする。
Postgresインスタンス1台でも十分処理できそうに見える。
現代的な高品質エンタープライズSSDなら、実際の
fsyncを毎秒3.5万回前後処理できる。もちろん、それがPostgresのせいなのか、別の設計上の欠陥によるものなのかは分からない。
基本的なところを理解したいのだが、今は大きなサーバー1台に4TBのDBがある。
PGDogのようなプロキシツールを使うと、それぞれ約500GBを担当する小さなサーバー8台と、プロキシ用の中規模サーバー1台を立てる構成になるのか気になっている。
今のプロジェクトは複数のサービスからの書き込みトラフィックが非常に多く、Webアプリがそこから読み取っている。
そろそろ、インデックス作成、クエリ最適化、キャッシュ、サーバーアップグレードをどれだけやっても効果がなくなる地点に近づいている。
静的データの大半をClickHouseへ移してDBサイズを減らす案も見ているが、PgDogや他のシャーディングがこの用途に有用かどうか聞いてみたい。
連絡してほしい(lev@pgdog.dev)。
手助けするか、少なくとも今何が動いていて何が動いていないのかを伝えて、選択肢を把握できるようにできる。
pgdogのドキュメントを読むと、リクエストをどのシャードサーバーへルーティングするかを教える必要があることが分かり、魔法のようにただ動くわけではない。
それでも、特に高コストなPostgres接続を再利用してくれるので価値はある。
魔法ではないので、内部で何が起きているかを理解しておく必要があり、たとえばシャード間トランザクションはない。
シャーディングは、データ整合性を気にするなら難しいので、まずはアプリケーションが読み取りレプリカで恩恵を受けられるかを見るだろう。
レプリカはそれぞれ全データのコピーを持ち、書き込みはマスターにのみ行い、ほぼリアルタイムより少し遅れる可能性のあるレプリカで実行してよいトランザクションかどうかを自分で判断する必要がある。
たとえばWebページを作るための読み取りはレプリカでもたいてい安全だが、読み取り-変更-書き込みはそうではない。
Postgresで最大のダウンタイム要因であるメジャーバージョンアップグレードに、これがどう役立つのか気になる
プーラーはフェイルオーバーや負荷分散には優れているが、アップグレードのために年に1〜2回、毎回10〜20分ほどのダウンタイムが必要になる
旧バージョンから新バージョンへの論理レプリケーションは役に立つかもしれないが、部分的な書き込みやおかしな状態なしにすべてを新しいクラスタへ移す作業は依然として必要そう
こうした経験がある人がいるか気になる
DBサイズは約1〜1.5TBだが、変更量や毎秒クエリ数はそれほど多くない
実質的にはここで説明されている方法: https://www.pgedge.com/blog/always-online-or-bust-zero-downt...
Infrastructure as Codeの構成があるなら、メジャーバージョンだけ異なり設定は同じ新しいクラスタを作成し、スキーマを取り込んだあと、旧バージョンの読み取りレプリカからデータコピーを始め、旧バージョンへの書き込み受け付けを止めてから（ダウンタイム開始）、シーケンス番号を同期し、サービスを新しいクラスタへ向ける（ダウンタイム終了）
CloudNativePGのようなものを使えば、CLIツールと宣言的構文でこの過程の一部を自動化してくれる
そうでなければ自分で時間をかけて把握する必要がある
複雑に聞こえるかもしれないが、ステージングDBで練習してうまくいけば、本番でも同じ手順を踏めばよい
さらにPostgres 19には、シーケンスのワンショット論理レプリケーション用のパッチがあるようだ: https://www.depesz.com/2025/11/11/waiting-for-postgresql-19-...
クラスタを順次回せば、ダウンタイムは非常に小さく、だいたい60秒程度にできる
この先、自分がそれを見る日が来るのか疑問だ
なぜこれが絶対的な最優先事項と見なされていないのか、いまだに不思議だ
資金調達おめでとう、Lev
ここではPgDogを満足して使っている
プロキシ機能の中でも、接続ごとに異なる接続設定、たとえば
statement_timeoutを扱える点がかなり気に入っている以前RDS Proxyを調べたときは対応しておらず、pgbouncerも同様だった気がして、アプリケーション側の変更がかなり必要だった
PgDogでは透過的にそのまま動く
先ほど発表されたSupabaseのmultigresと比較できるものなのか気になる
Enterprise Editionがあるようだが、どの機能がオープンソースではないのか明確に教えてもらえるとありがたい
新たに追加される機能が、VC投資家に報いるためにEEライセンスになると予想しているのかも気になる
1つ目は、マルチノード展開を管理するコントロールプレーンで、PgDogを簡単にデプロイして使える「すぐに動く」体験を提供する
2つ目はサービス品質(QoS)で、悪いクエリがデータベースを落とせないよう自動で遮断する
最後に、P0までSLA保証付きのサポートを受けられる
新機能は2つのカテゴリに分かれる
シャーディングと大規模Postgres運用は常にオープンソースで、インフラ管理やPgDogを大規模で簡単に運用できるようにする機能はエンタープライズになる
PgDog、Neki、multigresが出てくるのは良いことだ
まさにこれがPostgresの中核的な問題で、さらにインデックスヒントがないのも問題なので、Postgres 19に期待している
設定は難しいが、最近はAIの助けで構成しやすくなった
pg_hint_plan拡張はコアには入っていないが、プランナーを上書きする必要があるときにはかなり有能だ「私たちが把握しているだけで20TB超をシャーディングした」はおそらく誤記だろう
20TBはそこまで大きくない
実際にはもっと多くをシャーディングしているはずだと思う
データベースごとにホットデータとコールドデータの比率が違うので、これ以上の情報がなければ比較は不可能だ
より良い指標はIOPSかもしれない
RDSは、プロビジョンドIOPSにかなり多くの費用をかけるかAuroraを使わない限り、最大IOPSがかなり低い
比較として言うと、ほぼ10年前にSegmentで約50TBのデータを持つ単一のAurora PostgreSQLインスタンスを運用していたが、これはS3に保存されたはるかに大きいファイルコーパス内の潜在的識別子データをインデックスするために使われていた
PgDogは良い
正直必要ではないのだが、森をハイキングしているときに聴くものがなくて、たまたまPostgres FMポッドキャストを聴いて興味を持ち、自分のオンプレミスKubernetesで使っている
https://open.spotify.com/episode/6qgpfiW68KcvRASs6649Fb