OpenAI mejoró la escalabilidad de PostgreSQL para ChatGPT manteniendo un único primario en Azure, derivando las lecturas a ~50 réplicas y robusteciendo el stack con agrupación de conexiones, limitación de tasa en múltiples capas, simplificación de consultas y aislamiento de cargas de trabajo. El resultado: millones de QPS, p99 de latencia de dos dígitos bajos y disponibilidad de cinco 9 en escala global.

Por qué esto es importante ahora

ChatGPT opera a una escala sin precedentes—~800 millones de usuarios semanales—lo que obliga a realizar arduas decisiones de ingeniería. En lugar de saltar a una base de datos distribuida, OpenAI demostró hasta dónde se puede llevar Postgres con los patrones correctos, primitivas en la nube, y una eliminación implacable de la presión de escritura.

La arquitectura principal (sorprendentemente simple)

• Un solo primario (escritor) en Azure PostgreSQL Flexible Server.

• ~50 réplicas de lectura en varias regiones para mantener las lecturas rápidas y resilientes.

• Postgres sin particionar para lecturas; las cargas de trabajo intensivas en escritura, que pueden ser particionadas, se movieron a Cosmos DB.

• Resultados: millones de QPS, ms p99 de doble dígito bajo, ~99.999% de disponibilidad.

¿Por qué no particionar Postgres ahora?

Particionar rutas de aplicaciones heredadas es costoso y lento. Dado que ChatGPT es intensivo en lecturas, OpenAI mantuvo un único escritor y se centró en eliminar picos de escritura mientras escalaba las lecturas horizontalmente. Particionar sigue siendo una opción futura, no un requisito a corto plazo.

Siete patrones que puedes copiar

1) Reducir la carga en el primario (trata las escrituras como un recurso escaso)

• Derivar todas las lecturas posibles a las réplicas.

• Corregir errores en la aplicación que causan escrituras redundantes; introducir escrituras diferidas para suavizar los picos.

• Imponer estrictos límites de tasa en rellenos y actualizaciones en segundo plano.

• Mover dominios pesados en escritura que pueden ser particionados a un sistema particionado (por ejemplo, Cosmos DB).

2) Optimizar consultas (escapar de los errores típicos de ORM)

• Identificar consultas “destructivas” (por ejemplo, uniones de 12 tablas) que pueden hundir el clúster.

• Descomponer uniones complejas en lógica más sencilla a nivel de aplicación; revisar el SQL generado.

• Configurar idle_in_transaction_session_timeout para detener transacciones inactivas que bloquean autovacuum.

3) Aislar vecinos ruidosos

• Dividir el tráfico en niveles de alta y baja prioridad en instancias dedicadas.

• Aislar productos/servicios para evitar que un lanzamiento en un área degrade otra.

4) Agrupar conexiones como si tu tiempo de actividad dependiera de ello

• Azure Postgres limita las conexiones (por ejemplo, ~5,000). Utiliza un agrupador para evitar tormentas y acumulaciones inactivas.

• Ajustar el máximo de conexiones, límites de cola y tiempos de espera; bloquear clientes abusivos tempranamente.

5) Limitar la tasa en múltiples capas (y evitar tormentas de reintentos)

• Aplicar controles en las capas de aplicación, agrupador, proxy y consulta.

• Evitar intervalos agresivos de reintento; implementar bloqueos basados en resumen para consultas problemáticas.

6) Gestionar el esquema con una mentalidad de radio de explosión

• No realizar reescrituras completas de tablas en migraciones de producción; tiempos de espera de DDL de 5 segundos.

• Crear/eliminar índices solo de forma concurrente.

• ¿Nuevas tablas para nuevas funciones? Ponerlas en sistemas particionados, no en el primario.

7) Planificar el crecimiento de réplicas con replicación en cascada

• La transmisión primaria de WAL a docenas de réplicas no se escalará para siempre.

• Probar replicación en cascada para que intermediarios retransmitan WAL aguas abajo, permitiendo más de 100 réplicas sin sobrecargar al escritor (con mayor complejidad de conmutación por error).

Resultados a los que puedes aspirar

Con estas tácticas, OpenAI reporta millones de QPS, casi sin retraso en la replicación, lecturas geo-distribuidas de baja latencia y disponibilidad de cinco 9, a pesar de funcionar con un único escritor. Han tenido un incidente SEV-0 de Postgres en 12 meses, provocado por un auge viral del producto, y se recuperaron según lo diseñado.

Plan de implementación práctico (90 días)

1. Semana 1–2: Línea base
   Capturar QPS por endpoint, CPU, conexiones y resúmenes de consultas lentas; mapear dominios intensivos en escritura.

2. Semana 3–4: Agrupación + tiempos de espera
   Desplegar agrupación del estilo PgBouncer; establecer valores predeterminados sensatos para tiempos de espera de conexión/sentencia/inactividad; limitar conexiones máximas.

3. Semana 5–6: Limitación de tasa
   Añadir límites de tasa a nivel de aplicación y proxy; implementar retrocesos exponenciales y disyuntores; introducir bloqueos a nivel de resumen para los peores infractores.

4. Semana 7–8: Cirugía de consultas
   Eliminar uniones múltiples; trasladar lógica de uniones a la aplicación; añadir índices de cobertura dirigidos; imponer idle_in_transaction_session_timeout.

5. Semana 9–10: Aislamiento de cargas de trabajo
   Separar el tráfico de baja prioridad/en segundo plano de las rutas interactivas; escalar réplicas de lectura a nivel regional.

6. Semana 11–12: Rellenos + barandillas de esquemas
   Regular rellenos; imponer tiempos de espera de 5 segundos en DDL; solo cambios de índice concurrentes; no nuevas tablas en el primario.

7. Rama paralela: Evaluar replicación en cascada en preparación para crecimiento futuro.

Preguntas frecuentes

¿Qué base de datos utiliza ChatGPT?
OpenAI ejecuta un solo primario en PostgreSQL para cargas de trabajo principales con ~50 réplicas de lectura y complementa dominios intensivos en escritura con sistemas particionados como Cosmos DB.

¿Cuán grande es la base de usuarios de ChatGPT hoy?
Informes recientes sitúan a ChatGPT en ~800 millones de usuarios activos semanales para principios de 2026, con investigaciones propias de OpenAI que refieren a más de 700 millones en 2025.

¿Por qué no cambiar a una base de datos SQL distribuida?
Particionar rutas heredadas es costoso; las cargas de trabajo de ChatGPT son intensivas en lectura, por lo que OpenAI maximizó primero Postgres con réplicas, agrupación y límites de tasa, manteniendo abierta la opción de particionar más adelante.

¿Qué configuraciones importan más?
Comienza con límites en el agrupador, tiempos de espera de conexión/sentencia/inactividad, idle_in_transaction_session_timeout y controles disciplinados de DDL.

Próximos pasos

¿Quieres esta arquitectura para tu producto? Contacta a Generation Digital para una revisión de disponibilidad, plan de implementación y soporte práctico.