- OpenAIはPostgreSQLをシャーディングなしで利用しながら、数億人規模のユーザートラフィックを効果的に処理する方法をPGConf.dev 2025で共有
- 書き込みボトルネックを解消するため、書き込み分散、クエリ最適化、スキーマ管理など多様なアプローチを導入
- 主な課題として、MVCC設計によるテーブル/インデックス肥大化、WALによるレプリケーション遅延など、PostgreSQLの構造的な限界と運用上の難しさに言及
- 読み取り負荷分散と長時間トランザクションの制限、ORMの最小化などのクエリ最適化戦略が中核
- OpenAIは地理的に分散した40台超のレプリカを通じて100万QPSを達成し、障害発生時にも高い可用性を確保
OpenAIのPostgreSQL大規模拡張事例
背景
- OpenAIの中核サービスの多くがPostgreSQLに依存
- データベース障害が発生するとサービス全体に直接的な影響が及ぶ
- 過去にChatGPTをはじめとする主要サービスで、PostgreSQLの問題により停止が発生した経験がある
- OpenAIはAzureマネージドデータベース上で**Primary-Replicaアーキテクチャ（単一Primary + 40台超のReplicas）**を運用
- 月間5億人のアクティブユーザーを抱える環境では、スケーラビリティが事業成功の中核要素として機能
主な課題
- 読み取りトラフィックは多数のReplicaへ分散できる一方、書き込みリクエストは単一Primaryに集中し、ボトルネックが発生
- 主な改善ポイント
- 可能な限りすべての書き込みリクエストをオフロードして分散
- 新規サービスによるPrimary DBへの追加接続を最小化
- **MVCC（多版同時実行制御）**の構造上、テーブル/インデックスの肥大化、複雑なガベージコレクションのチューニング、インデックス可視性チェックなどの欠点がある
- Replica数が増えると**WAL（Write-Ahead Logging）**トラフィックも急増し、ネットワーク帯域が別のボトルネック要因として浮上
対応策
Primaryデータベースの負荷分散
- 書き込み負荷の予測と緩和:
- 可能な限りすべての書き込みをオフロード
- 不要なアプリケーションレベルの書き込みを防止
- Lazy Writeを適用し、データのバックフィル周期を調整
- 読み取り負荷は可能な限りReplicaへ分散し、やむを得ずPrimaryで処理する場合には高い効率性を求める
クエリ最適化
- 長時間トランザクションはシステム資源を長く占有し、ガベージコレクションの遅延を招く
- セッション/クエリ/クライアントごとにTimeoutを適用し、Idle in transactionセッションを制限
- ORM使用時には非効率性が高まる可能性があることを明示し、慎重な利用を推奨
- 複雑なmulti-joinクエリ（例: 12テーブル結合）の最適化を実施
単一障害点（SPOF）への対応
- Primaryは障害時に書き込み不能となるが、Replicasは一部に障害があっても読み取り継続性を保証
- 重要リクエスト（高優先度）は専用Replicaで処理し、低優先度リクエストの干渉を最小化
スキーマ管理
- 新規テーブル作成や新規ワークロード導入はクラスタ上で制限
- カラム追加/削除は5秒以内に収まる軽量作業のみ許可し、全テーブル再書き換えを必要とする作業は不可
- インデックス作成/削除はCONCURRENTLYオプションでのみ許可
- 1秒以上かかる長時間クエリがスキーマ変更を継続的にブロックする問題が発生しており、アプリケーション側でそのようなクエリの最適化/オフロードが必要
運用結果
- クラスタ全体で100万QPS（読み取り+書き込み）を処理し、OpenAIの主要サービスを支援
- 40台余りのReplicaを追加してもレプリケーション遅延は増加せず
- 複数RegionにRead-only Replicaを配置し、低レイテンシを維持
- 直近9か月でPostgreSQL関連のSEV0障害は1件のみ発生
- 今後の成長余力を満たすための容量を確保
障害事例
- キャッシュ障害によるcascading effect
- CPU使用率が高い際、WALSenderプロセスがWAL転送を停止してループ状態に陥るバグ → レプリケーション遅延が発生
PostgreSQLに提案された機能改善要望
- インデックス管理: 不要なインデックスを安全に無効化するためのDisable機能を提案（削除前のリスク最小化が目的）
- 可観測性: p95、p99などのレイテンシヒストグラム/パーセンタイルベース指標の提供を要望
- スキーマ変更履歴: DDLなどのスキーマ変更内容を保存する機能を要望
- 監視ビューの意味の明確化: 特定セッションがClientRead状態で長時間維持される現象の原因と対応について照会
- デフォルトパラメータ最適化: PostgreSQLのデフォルト値が過度に保守的であり、より良い初期値またはヒューリスティクス導入を要望
Lao Fengのコメント
- このような極限環境でのOpenAIの拡張戦略は、PostgreSQLコア開発者にとって実運用の活用事例として有意義
- 中国のTantanなど大規模サービスでも類似の経験（Replica 33台、40万QPS、アプリケーション側シャーディング導入）がある
- 今日の高性能HW環境では、OpenAIのように単一PostgreSQLクラスタでも積極的な拡張が現実的であり、分散DBが必須とは限らないことを示唆
- OpenAIはAzureマネージドPostgreSQL、40台超のReplica、cross-region配置、Kubernetes + PgBouncerを活用
- Azure PostgreSQLチームの重点的な支援を受けているが、それでもなお運用面でのアプリケーション/DBAの力量と可観測性が不可欠
- Datadogによる監視と、性能およびコスト負担にも言及
- 運用ノウハウ、失敗経験、DBA資産がサービス品質の中核
Lao Feng Q&A
インデックス無効化機能
- PostgreSQLでは内部的にindisvalidフィールドでindexを無効化可能（ただし、superuser権限が必要で、RDS環境では制限あり）
- 実質的な代替策は、監視を通じてindexの利用有無を確認した上で安全に削除する方法
可観測性の拡張: P95/P99 latency
- pg_stat_statementsでのパーセンタイル指標サポートはメモリオーバーヘッドのため困難であり、pg_stat_monitor/eBPF/アプリケーション層でのlatency監視などの迂回手段がある
- AzureマネージドPostgreSQL環境では一部オプション（サーバーアクセス、eBPFなど）が未対応
スキーマ変更履歴
- ログファイル、pgaudit、CREATE EVENT TRIGGER、pg_ddl_historizationなどの活用が可能（ただし、superuser権限が必要で、Azure RDSではサポート制限あり）
- 求められているのは、クエリ可能なシステムビュー/テーブル形式で履歴を保存すること
監視ビューの意味
- State=Active + WaitEvent=ClientReadの組み合わせは、Statement実行中にクライアント入力待機状態であることを意味し、必ずしもバグではなく多様な原因があり得る
- 接続維持時間の制限（HAProxyなどネットワーク層での接続期限設定、クライアント側connection poolの寿命管理など）により副作用を最小化可能で、Azureでは当該機能のサポート有無は不明
デフォルトパラメータ
- PostgreSQLのデフォルト値は過度に保守的だが、サービスごとの細かなヒューリスティクスや自動パラメータチューニング（RDS、Pigstyなど）で補完可能
- 将来的にPostgreSQLツール内でHW仕様を自動検出して適用する機能が導入されれば、現場負担の軽減が期待される
自己運用（セルフホスティング）オプション
- 実運用上の問題はPostgreSQL自体というよりAzureマネージドの制約から派生している
- IaaS環境などで独自にNVMe SSDベースのPostgreSQLクラスタを構築（Pigstyなど）すれば、機能面・運用面の柔軟性が高まる
- Pigstyのようなソリューションを活用すればOpenAIの要求の大半を先回りして解決できるため、規模や要件に応じて導入を検討する余地がある
2件のコメント
Hacker Newsのコメント
先週のPGConfに参加したが、この発表が最も人の集まっていたセッションの一つだったのが印象的だった。特に、多くのセッションがPostgres自体の開発に焦点を当てていた内向きなカンファレンスだっただけに、この事例発表は新鮮に感じられた。製品がうまく成長したとき、スタックの特定部分をどうスケールさせるかを深く理解していないチームは多い、ということを常に覚えておく必要がある。この発表は、小さなチームがどう問題を乗り越えながら学んでいくかを示す素晴らしい話だった。「こうすればいいのでは？」のような単純化された反応ではなく、実際のユーザーの話を通じて成長の過程と製品の高い人気を生き生きと見せていた点で、社内開発者寄りのイベントにぴったりのセッションだったと思う。この発表の核心メッセージは、書き込みが多くなければ、読み取り専用ノード（read replicas）と単一マスター構成だけでもPostgresを途方もない読み取りスループットまでスケールできる、ということだ。このメッセージこそ大半のアプリに当てはまるという主張。Q&Aでは主にPostgresコア開発者たちがユースケースを学ぼうとする質問が中心で、批判しようという意図はほとんどなく、Postgresコミュニティは本当に親切でオープンな雰囲気だという感想
「書き込みが多くないなら、単一マスターと読み取り専用レプリカでPostgresの読み取りスループットを大きく伸ばせる」というメッセージについて、システムデザイン面接をしていて感じるのは、あまりに多くの候補者が毎秒5回読む程度の単純なシステムに対しても、巨大な分散構造や、結局整合性が崩れるシステムから導入しようとすることだという話。1000万人のユーザーも実際にはそれほど大規模ではないという主張。業界全体が水平分散にばかり集中している一方で、実際のハードウェアは想像以上に速く大きくなっていることを、もっと多くの人が認識してほしいという願い。Amazonで32TB RAMサーバーを借りられる時代だという説明。規模が大きくなった状況でも、ACID保証は依然として非常に貴重だという強調
発表が本当に伝えたかった核心メッセージだったとして感謝（Bohan）
この発表のスライドや録画を見られる場所はあるかという質問
このスレッドはそのチームに対してやや辛口評価だという印象を受けたという意見。この分野に経験の多いHNユーザーたちは、ChatGPTのような大規模サービスをアーキテクチャ的にどうスケールさせたのか、ほぼ無制限の資源を持つ会社がどう採用しているのかに興味を持っているという説明。「ORMを使うと非効率なクエリが起きやすいので注意すべきだ」という発表メッセージ自体が、そのチームがこのような大規模インフラ運用にまだそれほど経験が多くないことの傍証だという解釈
柔軟性の面ではself-hosting postgresは魅力的だが（スーパーユーザー権限や高度な機能の活用など）、実際に自分で運用するのは気がかりだという感じ。クラウドプロバイダーも、インデックスを本当にdropする前に、クエリプランナーでインデックスを無効化する機能を標準でサポートしてくれるとよいのに、という希望。大企業ならスタックのカスタマイズのためにself-hostingを選ぶのは十分合理的だと思う
Postgresでは特定のインデックスを使わせたり無効化したりするさまざまな方法がすでにあり、クラウドのマネージドPostgresインスタンスでも使えるという説明。代表的にはクエリプランナーの設定をクエリごとに調整する方法（例: enable_indexscan=off）、where句に簡単な四則演算を入れて意図的にインデックスを使わせない方法、そしてpg_hintplan拡張（コメント文でどのインデックスを使うかヒントを与えられる、参考: https://pg-hint-plan.readthedocs.io/en/latest/hint_table.html#hints-for-scan-methods）
（Azure Postgresチーム所属であることを明かしたうえで）OpenAIはself-hostではなく、AzureのマネージドPostgreSQL（Flexible Server）を使っている
OpenAIの登壇者（Bohan）本人が明かしていたが、self-host環境ではなくAzure Database for PostgreSQLを使用している。発表で「Azure Postgres」と何度か言及してはいたが、Microsoftが管理するサービスだという点をもっと明確にすべきだったとして謝罪
MySQLやMariaDBには、インデックスをINVISIBLEまたはIGNOREDにしてクエリプランナーから無視させるDDLがあるのに、Postgresに似た機能がないのは驚きだという意見
「Self-hosting postgres の利点は柔軟性…」という原文の引用のみ
スキーマ変更イベント（カラム追加・削除など）の履歴記録機能が必要だという要望に対し、すでにEVENT TRIGGERを活用してリアルタイムに実装可能で、例としてAquameta（https://github.com/aquametalabs/aquameta）の実装事例を参考にできるという案内
こちらでも自前のPostgres環境にDDL変更の履歴管理機能を実装中だという説明。Postgres自体が強力なのでさまざまな方法で実装できるが、履歴管理や大規模・重要DBの運用記録（log）も非常によくある要求だという点。大半は自分で痛い目を見るまでその重要性に気づかないという主張。DDL変更だけでなく、主要な運用ポリシー（例: 価格モデル変更、SKU/価格カスタムなど）が反映されるときも、必ず「監査可能性」を確保しなければならないという説明。完全にリレーショナルモデルを設計していくと、実際のアプリでは頻繁に変わるテーブルは一部だけで、大半はほとんど変更のない「静的（static）」テーブルだという点、このようなテーブルが変わるときはその履歴を細かく残しておくことで過去データの解釈やロールバックに有利だという主張
私たち（Xata）はpgroll（https://github.com/xataio/pgroll）とpgstream（https://github.com/xataio/pgstream）の両方でEVENT TRIGGERを使ってDDL変更を検知し、スキーママイグレーション履歴を残したり、スキーマ変更イベントを論理レプリケーションストリームに含めたりする機能を使っている。ただし、多くのPostgres系DBaaSではEVENT TRIGGERはスーパーユーザー権限のため一部制限されており、RDS/AuroraとXataはサポート、Supabaseも対応準備中という情報
Aquametaを覚えていてくれてありがとう、もうすぐ素敵な新機能が出るというティーザー
この内容（大規模でのインデックス同時作成、テーブルリライト回避、トラフィック分散、トランザクションタイムアウト、読み取りレプリカなど）は、実はOpenAIよりはるかに小さい規模の運用でもほぼ必須の基本事項だという主張。Postgresに求める要件も実際には以前から皆が求めてきた内容で、「Next Level」と題してはいるが、実際にはシングルマスターを必死に維持しながらスケールしている姿［新規ワークロードに制限がある状況］に近いという見方。大規模な読み取り負荷を無難にさばけることが核心ポイントだが、これはそれ自体、すでに読み取りレプリカと水平分散の王道だという説明。インデックスをdisableする方法（内部フィールド
indisvalidの操作）も公式には提供されていないトリックで、このようなシステムカタログの調整は危険だという警告。モニタリングビューでインデックス使用有無を確認してdropすべきだという主張も完全な解決策ではなく、どのインデックスが必要・不要かをより明確にするにはクエリプランまで確認してこそ信頼性が出るという説明TFA（元記事）はOpenAIがAzureで毎秒100万クエリを処理しているとしているが、このレベルは実際のクラウド環境、特にネットワークベースのストレージを使う環境ではかなり印象的だという解釈。ただし全体で約40個の読み取りレプリカに分散された値なので、単一インスタンスあたり2.5万QPS程度であり、それほど驚くほどではないという意見。インデックス利用の是非をめぐる議論については、最新の統計とDBの特性さえきちんと把握していれば、どのインデックスを使うのが適切か、クエリの条件／projectionがインデックスのleft-most prefixによく従っているかだけ確認すれば十分だという説明
OpenAIがPostgresをシャーディングしない理由について何の説明もないのは、正直もどかしいという指摘。ユーザー単位のシャーディングだけでももっと簡単に問題を解けそうなのに、なぜシングルマスターにこだわるのか疑問
物理レプリケーションを使っているようだが、私は今、コスト削減（リージョン間の送信トラフィック削減）のために論理レプリケーションへの移行を検討中という悩み。Postgres 17以降でネイティブ論理レプリケーション機能がかなり進化したようだが、本番で試す価値があるか意見が聞きたい
さまざまなクエリに対応するためには、別のストレージエンジン（キー・バリュー、検索、ベクトル検索、キャッシュなど）も併用しているはずなのに、発表内容がPostgresだけに集中しているのは不思議だという指摘。実際には内部でさまざまな形でトラフィック分散・負荷分散する複数の戦略を取っているのでは、という推測
書き込みインスタンスだけローカル高速SSDを載せた専用サーバーで直接運用し、読み取りはマネージドサービスだけで処理したら、もっと良い性能が出るのではないかという考え
「DBをシャーディングしろ」という強い主張。ユーザー／組織単位でシャーディングするだけでも、いま抱えている主な問題は簡単に解決できるはずだという見解。複雑な回避策を何度も試すほうがむしろ遠回りだという不満
発表では、あえてシャーディングしなくても単一マスター構成だけでとてつもない処理量までスケール可能だという点が核心メッセージであり、もちろんシャーディングも検討したがトレードオフが見合わず、現行構成でもスケールできているという経験が示されていた
OpenAIの発表者（Bohan）からの直接回答: ワークロードのシャーディングは簡単な状況ではなく、すでに書き込み負荷の高いワークロードはPostgreSQLから切り離してシャードで処理しており、残っているものはほぼ読み取り専用なので、シャーディング導入には莫大な労力がかかるという説明。現時点ではAzure Database for PostgreSQLだけでも十分なスケーラビリティ確保と将来の受け皿まであるという判断。ただし長期的にシャーディングを完全に排除するつもりはなく、短期の優先順位ではないというメッセージ
シャーディングは考えるほど単純ではないという主張。強力なDBを使う理由は複雑なデータ分析・クエリが可能だからであり、単なる保存・分散だけが目的なら、いっそ複数のNFSマウントを使うほうが簡単だという説明
毎秒100万クエリのような途方もないDBに、単純にシャーディングを適用しろと言うのは簡単ではないという現実的なフィードバック。組織単位がシャードキーとして自然に見えるとはいえ、この規模になると単純なものは何一つないという意見
上の論旨に強く同意する反応
ORMを慎重に使えという発表での言及について、すべてのORM（特にマルチDB互換型ORM）が問題だと考えるという自分の立場。ORMを使うとデータパターンをアプリケーションコードのレベルでしか考えなくなり、結局DBごとの強力な機能をほとんど使えなくなるという主張。自分はORMをまったく使わず、Postgres専用のクエリや機能を積極的に活用しており、言語や利便性よりDBの力に集中するほうがずっと得だという説明。結局、良いSQLを自分で書くことがシステム全体に幸福をもたらすという結論
以前DB2からpsqlへ移行したとき、ダウンタイム最小化のためにORMが大いに役立った経験。ORMのおかげでDB切り替えが透過的にでき、ほとんどのロジックをほぼ触らずに済んだし、すべての開発者が直接クエリを書くことに慣れているわけではなく、コードにクエリが混ざるとリファクタリングや理解が非常に難しくなるという主張。結局SQLもライブラリとして抽象化されていくという説明
Django ORMを長く使ってきて本当に優れたソフトウェアだという印象を持っていたが、最近sqlcを使ってみて、クエリをGoコードにそのまま変換してくれる形が、むしろORMとraw SQLの間の理想的な折衷案だと思うようになった
本当に優れたORM（例: Entity Framework Core）をまだ体験していないだけだという立場
タイトルは「Scaling PostgreSQL to the Next Level at OpenAI」が実際の発表タイトルとしてふさわしい気がする、という軽いフィードバック
Oracle RACやDB2 pureScaleのようなマルチライト可能な商用製品は、そもそも検討対象ではないようですね。