OpenAI a optimisé PostgreSQL pour ChatGPT en maintenant un seul serveur principal sur Azure, en déchargeant les lectures sur environ 50 répliques, et en renforçant la pile avec une mise en commun des connexions, une limitation des taux multi-niveaux, une simplification des requêtes et une isolation des charges de travail. Le résultat : des millions de QPS, une latence p99 à deux chiffres faible et une disponibilité de cinq neuf à l'échelle mondiale.

Pourquoi c'est important maintenant

ChatGPT fonctionne à une échelle sans précédent—environ 800 millions d'utilisateurs hebdomadaires—ce qui impose des compromis techniques pointus. Au lieu de se précipiter vers une base de données distribuée, OpenAI a démontré jusqu'où vous pouvez pousser Postgres avec les bons modèles, les primitives du cloud et l'élimination sans concession de la pression d'écriture.

L'architecture de base (étonnamment simple)

• Un seul principal (écrivain) sur Azure PostgreSQL Flexible Server.

• Environ 50 répliques en lecture à travers les régions pour garder les lectures rapides et résilientes.

• Postgres non fragmenté pour les lectures; les charges de travail lourdes en écriture shardables ont été déplacées vers Cosmos DB.

• Résultats: des millions de QPS, une latence à deux chiffres ms p99, environ 99.999 % de disponibilité.

Pourquoi ne pas fragmenter Postgres maintenant?

La fragmentation des chemins d'applications héritées est coûteuse et lente. Parce que ChatGPT est consommateur de lectures, OpenAI a conservé un seul écrivain et s'est concentré sur la suppression des pics d'écriture tout en augmentant l'évolutivité des lectures horizontalement. La fragmentation reste une option future, pas une exigence à court terme.

Sept modèles que vous pouvez copier

1) Réduire la charge sur le principal (traitez les écritures comme une ressource rare)

• Décharger chaque lecture possible vers des répliques.

• Corriger les bugs d'application causant des écritures redondantes; introduire des écritures procrastinées pour lisser les pics.

• Imposer des limites strictes de taux sur les remplissages et les mises à jour en arrière-plan.

• Déplacer les domaines shardables lourds en écriture vers un système fragmenté (par ex., Cosmos DB).

2) Optimiser les requêtes (évadez les pièges de l'ORM)

• Identifier les requêtes « destructrices » (par ex., les jointures de 12 tables) qui peuvent faire couler le cluster.

• Décomposer les jointures complexes en logique d'application plus simple; passer en revue le SQL généré.

• Configurer idle_in_transaction_session_timeout pour arrêter les transactions inactives bloquant l'autovacuum.

3) Isoler les voisins bruyants

• Diviser le trafic en niveaux de haute et basse priorité sur des instances dédiées.

• Isoler les produits/services pour éviter qu'un lancement dans un domaine dégrade un autre.

4) Mettre en pool les connexions comme si votre disponibilité en dépendait

• Azure Postgres limite les connexions (par ex., environ 5 000). Utiliser un pool pour éviter les tempêtes et les accumulations inactives.

• Ajuster les connexions maximales, les limites de file d'attente et les délais d'attente; bloquer tôt les clients abusifs.

5) Appliquer des limites de taux à plusieurs niveaux (et éviter les tempêtes de reprises)

• Appliquer des contrôles aux niveaux application, pooler, proxy, et requête.

• Éviter des intervalles de reprise agressifs; mettre en œuvre des blocs basés sur les résumés pour les mauvaises requêtes.

6) Gérer le schéma avec un état d'esprit de rayon d'impact

• Pas de réécritures complètes de tables lors des migrations en production; délais d'attente pour DDL de 5 secondes.

• Créer/supprimer les index de façon concurrente uniquement.

• De nouvelles tables pour de nouvelles fonctionnalités? Les placer dans des systèmes shardés, pas sur le principal.

7) Planifier la croissance des répliques avec réplication en cascade

• Le streaming WAL principal vers des dizaines de répliques ne conviendra pas éternellement.

• Tester la réplication en cascade pour que les intermédiaires transmettent le WAL en aval, permettant plus de 100 répliques sans surcharger l'écrivain (avec complexité de basculement ajoutée).

Résultats que vous pouvez viser

Avec ces tactiques, OpenAI rapporte des millions de QPS, un lag de réplication quasi nul, des lectures à faible latence géo-distribuées et une disponibilité à cinq neuf—malgré l'utilisation d'un seul écrivain. Ils ont eu un incident SEV-0 Postgres en 12 mois, déclenché par une vague de produits viral, et récupéré par conception.

Plan de déploiement pratique (90 jours)

1. Semaine 1–2: Établissement de la ligne de base
   Capturez les QPS par point d'extrémité, le CPU, les connexions et les résumés de requêtes lentes; cartographier les domaines lourds en écriture.

2. Semaine 3–4: Mise en commun + délais d'attente
   Déployer une mise en commun de style PgBouncer; définir des valeurs par défaut raisonnables pour les délais de connexion/affirmation/inaction; plafonner les connexions maximales.

3. Semaine 5–6: Limitation des taux
   Ajouter des limites de taux au niveau de l'application et du proxy; mettre en œuvre des reculs exponentiels et des disjoncteurs; introduire des blocs au niveau des résumés pour les pires contrevenants.

4. Semaine 7–8: Chirurgie des requêtes
   Éliminer les jointures multi-chemins; pousser la logique de jointure dans l'application; ajouter des index de couverture ciblés; imposer idle_in_transaction_session_timeout.

5. Semaine 9–10: Isolation des charges de travail
   Séparer le trafic de basse priorité/arrière-plan des chemins interactifs; échelonner les répliques en lecture régionalement.

6. Semaine 11–12: Remplissages + garde-fous sur les schémas
   Ralentir les remplissages; imposer des délais d'attente DDL de 5 secondes; seuls les changements d'index simultanés; pas de nouvelles tables sur le principal.

7. Piste parallèle: Évaluer la réplication en cascade en mise en scène pour une croissance future.

FAQs

Quelle base de données utilise ChatGPT?
OpenAI utilise une PostgreSQL à principal unique pour les charges de travail principales avec environ 50 répliques en lecture et complète les domaines lourds en écriture avec des systèmes shardés comme Cosmos DB.

Quelle est la taille de la base d'utilisateurs de ChatGPT aujourd'hui?
Des rapports récents situent ChatGPT à environ 800 millions d'utilisateurs actifs hebdomadaires d'ici début 2026, avec la propre recherche d'OpenAI se référant à plus de 700M en 2025.

Pourquoi ne pas passer à une base de données SQL distribuée?
Fragmenter les chemins hérités est coûteux; les charges de travail de ChatGPT sont principalement des lectures, donc OpenAI a d'abord maximisé Postgres avec des répliques, une mise en commun, et des limites de taux—en gardant la porte ouverte pour une fragmentation plus tard.

Quels réglages sont les plus importants?
Commencez par les limites du pooler, les délais d'attente de connexion/affirmation/inaction, idle_in_transaction_session_timeout, et un contrôle discipliné des DDL.

Prochaines étapes

Voulez-vous cette architecture pour votre produit? Contactez Generation Digital pour une évaluation de l'état de préparation, un plan de déploiement et une mise en œuvre pratique.