ハクソク

世界を動かす技術を、日本語で。

PgDogが資金調達を行い、あなたの近くのデータベースに登場します

2026年6月10日原文(pgdog.dev)

概要

  • Postgres のスケーリング課題を解決するための PgDog の紹介
  • PgDogは Postgresの水平スケール を実現するプロキシ
  • オープンソース で、どこでも簡単にデプロイ可能
  • 実績として 2M QPS超・20TB以上シャーディング を達成
  • 小規模ながら 経験豊富なチーム による開発とサポート

Postgresは唯一のデータベースで十分

  • Postgres は高機能なリレーショナルデータベース
  • MongoやDynamoなど他DBの存在理由は Postgresのスケーリング問題
  • もし 100TB+テーブル・100万QPS が実現できれば他DBは不要という考え方
  • PgDog はこの課題を解決するためのプロダクト

PgDogの特徴と導入方法

  • PgDog はPostgresの前段に置くプロキシ
  • 水平スケーリング を実現
  • オンプレミス・クラウド問わず どこでもデプロイ可能
    • Dockerイメージをpull
    • DATABASE_URLを変更
    • PgDogがスケーリング処理を担当
  • オープンソース で誰でも利用・デプロイ可能
  • 1.4M以上のDockerプル 実績
  • 毎週木曜に新バージョンリリース
  • Discordコミュニティ で日々サポート

PgDogの実績と運用事例

  • 本番環境で2M QPS超 を処理
  • 数十デプロイメント で稼働
  • 20TB以上のシャーディング 実績
  • ノーサーバレスコスト・依存関係なし
  • マルチスレッド対応 でCPUを最大活用
  • どこでも動く 柔軟性（クラウド・オンプレ・ローカル）

チームの信頼性と背景

  • 3人の小規模スタートアップ による開発
  • インフラ・アプリ両面の エンジニア経験豊富
  • InstacartでPostgresを大規模運用 した実績
    • 2020年4月に会社を5倍スケール
    • 数十万件/分の注文処理をPostgresで実現
    • RDS・Aurora・EC2でシャーディング 経験
  • 本質的な課題解決 を第一原理から実践
  • 5.5Mドルの資金調達 済み（Basis Set, YC, Pioneer Fund他）

PgDog Enterpriseエディションと今後

  • AWS向けEnterprise版 を開発中
    • SLA付きサポートを提供予定
  • 興味がある場合は連絡推奨
  • ドキュメント・GitHubリポジトリ・Discord で情報提供中

PgDogの始め方・コミュニティ参加方法

  • ドキュメント を参照してPgDogを導入
  • GitHubリポジトリ でスター＆ウォッチ
  • Discordコミュニティ に参加して開発者と交流

Hackerたちの意見

基本的な理解を得ようとしてるんだけど、今は4TBのデータベースが一つの大きなサーバーにあるんだ。PGDogみたいなプロキシツールを使えば、8つの小さいサーバーを立ち上げて、それぞれ500GBくらいを処理できるってことかな？今、複数のサービスからの書き込みトラフィックがすごくて、これを読み込むウェブアプリもあるんだけど、インデックスやクエリの最適化、キャッシング、サーバーのアップグレードをしても全然効果がないんだ。静的データの大部分をClickHouseに移してDBサイズを減らそうかとも考えてるけど、PgDogや他のシャーディングがこのケースに役立つかどうか、ぜひ聞きたいな。

└

8つの小さいボックスがそれぞれ約500GBを処理して、あと1つ中くらいのボックスがプロキシ用？その通りだよ。連絡してね（lev@pgdog.dev）、手伝えるし、少なくとも今の状況がどうなってるか（何がうまくいってるか、何がダメか）教えるから、選択肢がわかると思うよ。

PostgreSQLの最大のダウンタイムの原因はメジャーバージョンのアップグレードなんだけど、これにどう役立つか気になる。プーラーはフェイルオーバーや負荷分散にはすごく役立つけど、年に1、2回、アップグレードのために10〜20分のダウンタイムが必要なんだ。古いバージョンから新しいバージョンへの論理レプリケーションが役立つかもしれないけど、部分的な書き込みなしで新しいクラスターに切り替える必要があるよね。これについて経験がある人いる？

└

同意。MySQLから来たから、これはPostgresが80年代のものに見える大きな後退だと思う。なんでこれが最優先事項として見られないのか、まだ不思議だよ。

└

論理レプリケーションを使って、pgbouncerで約5秒間の書き込みを一時停止・スワップしてる。これは約1〜1.5TBのDB用だけど、大きな変動やQPSはないんだ。ここで説明されてることに近い感じだね。https://www.pgedge.com/blog/always-online-or-bust-zero-downt...

└

論理レプリケーションが一般的なやり方だね。インフラをコードとして設定してるなら、メジャーバージョン以外は同じ設定の新しいクラスターを作って、スキーマをインポートして、古いバージョンのリードレプリカからデータをコピーし始めて、古いバージョンからの書き込みを停止（ダウンタイム開始）して、シーケンス番号を同期して、新しいクラスターにサービスを向ける（ダウンタイム終了）って流れ。CloudNativePGみたいなツールを使えば、CLIツールや宣言的な構文でプロセスの一部を自動化してくれるよ。そうじゃなければ手作業で時間をかけてやることになる。複雑に聞こえるかもしれないけど、ステージングDBで練習して、うまくいけば本番でも同じ手順を踏むだけ。追記：どうやらPostgres 19にはシーケンスの一回限りの論理レプリケーションのパッチがあるらしい！https://www.depesz.com/2025/11/11/waiting-for-postgresql-19-...

└

論理レプリケーションがこれを解決してくれるよ。クラスターをロールする時、ダウンタイムは最小限。たぶん60秒くらいかな。

└

PostgreSQLがまだ適切なオープンソースの一般的なマルチマスター実装を持ってないのは変だね。これからも見ることができるのか疑問に思ってる。

知ってる限りで20TBをシャーディングしたことがあるけど、これって多分タイプミスだよね？20TBってそんなに大きくないと思う。もっとシャーディングしてるんじゃないかな。

└

大多数のユースケースにおいて、20TBは本当に巨大だよ。

└

その通りだね。比較のために言うと、約10年前にSegmentで50TBのデータを持つ単一のAurora PostgreSQLインスタンスを使ってたんだけど、それはS3に保存されたもっと大きなファイル群の中から潜在的なアイデンティティデータをインデックスするために使われてた。

└

作業セットが20TBなら、かなり大きいね。それぞれのデータベースにはホットデータとコールドデータのミックスがあるから、もっと情報がないと比較は難しいよ。IOPSを測る方がいいかも。RDSは、プロビジョンドIOPSにもっとお金をかけるか、Auroraを使わない限り、最大IOPSがかなり低いんだ。

Hacker Newsで議論の続きを見る