Escalando PostgreSQL para dar soporte a 800 millones de usuarios de ChatGPT

• OpenAI amplió a gran escala su infraestructura de PostgreSQL para responder al rápido aumento del tráfico de ChatGPT y de la API, procesando millones de QPS con un único servidor flexible de Azure PostgreSQL y alrededor de 50 réplicas de lectura
• Mantuvieron una arquitectura optimizada para cargas centradas en lectura y migraron parte de las cargas a Azure Cosmos DB para aliviar la presión de escritura
• Mejoraron la estabilidad y la latencia con varias optimizaciones, como pooling de conexiones con PgBouncer, bloqueo de caché, rate limiting y aislamiento de cargas de trabajo
• Para superar las limitaciones de una arquitectura con un solo primario, avanzaron en paralelo con configuraciones de alta disponibilidad (HA), hot standby y pruebas de replicación en cascada (cascading replication)
• Con este enfoque lograron 99.999% de disponibilidad y latencia p99 en decenas de milisegundos, dejando abierta la posibilidad de escalar en el futuro hacia PostgreSQL con sharding o sistemas distribuidos alternativos

---

Resumen del escalado de PostgreSQL

• PostgreSQL es el sistema de datos central de ChatGPT y de la API de OpenAI, y en el último año la carga creció más de 10 veces
  • Un único primario y unas 50 réplicas de lectura distribuidas globalmente procesan las solicitudes de 800 millones de usuarios
• Mantuvieron una arquitectura centrada en lectura y trasladaron parte de las cargas a Azure Cosmos DB para aliviar la carga de escritura
• Se prohibió agregar nuevas tablas, y las nuevas cargas de trabajo se colocan por defecto en un sistema con sharding

Desafíos de una arquitectura con un solo primario y cómo los abordaron

• Una arquitectura con un solo escritor tiene límites de escalabilidad en escritura y un problema de punto único de falla (SPOF)
  • El tráfico de lectura se distribuye en las réplicas, y el tráfico de escritura de cargas que pueden fragmentarse se trasladó a Cosmos DB
  • Una configuración de alta disponibilidad con hot standby permite una promoción rápida ante fallos (failover)
• Cuando la carga de lectura se dispara, los fallos de caché pueden saturar la CPU
  • Introdujeron un mecanismo de bloqueo de caché para evitar consultas duplicadas sobre la misma clave

Optimización de consultas y recursos

• Consultas complejas con múltiples joins consumían demasiada CPU y provocaban latencia en el servicio
  • Revisaron el SQL ineficiente generado por el ORM y movieron la lógica de joins complejos a la capa de aplicación
  • Configuraron idle_in_transaction_session_timeout para evitar consultas inactivas de larga duración
• Para resolver el problema de “noisy neighbor”, separaron el tráfico en instancias por prioridad
  • Así, las solicitudes de baja prioridad no afectan a los servicios de alta prioridad

Gestión de conexiones y control de carga

• Para resolver el límite de 5,000 conexiones de Azure PostgreSQL, introdujeron PgBouncer como capa de proxy
  • Reutilizar conexiones redujo el tiempo promedio de conexión de 50 ms a 5 ms
  • Para reducir la latencia de red entre regiones, ubicaron el proxy, el cliente y la réplica en la misma región
• Aplicaron rate limiting a nivel de aplicación, proxy y consulta para evitar picos bruscos de tráfico
  • También mejoraron la capa ORM para poder bloquear determinados digest de consultas

Replicación y gestión de cambios de esquema

• Como el primario debe hacer streaming de logs WAL a todas las réplicas, aumentar la cantidad de réplicas eleva la carga de red
  • Están probando replicación en cascada (cascading replication) en colaboración con el equipo de Azure
  • Una réplica intermedia retransmite el WAL a las réplicas inferiores, lo que abre la posibilidad de escalar a más de 100 réplicas
• Se prohíben los cambios de esquema que provoquen una reescritura completa de la tabla (full table rewrite)
  • Solo se permiten cambios ligeros dentro de un timeout de 5 segundos, y la creación o eliminación de índices puede hacerse de forma concurrente
  • Incluso durante el backfill se aplican límites de velocidad estrictos

Resultados y próximos pasos

• PostgreSQL procesa millones de QPS y logró latencia p99 de decenas de milisegundos y 99.999% de disponibilidad
  • En los últimos 12 meses solo hubo un incidente SEV-0, ocurrido durante el lanzamiento de ChatGPT ImageGen
• Las cargas restantes centradas en escritura también se están migrando gradualmente a Cosmos DB
• Una vez completada la replicación en cascada, planean reforzar la escalabilidad y la estabilidad de las réplicas
• A futuro evalúan la posibilidad de adoptar PostgreSQL con sharding o sistemas distribuidos alternativos

[GN⁺]

Comentarios en Hacker News

• En PostgreSQL, las consultas idle de larga duración suelen causar problemas
  En el código de nuestra empresa había mucho el patrón de “connect → iniciar transacción → hacer trabajo → commit si todo sale bien”
  Ese enfoque seguía ocupando slots de conexión incluso cuando en realidad no se estaba usando la base de datos, así que al final hubo que aumentar la cantidad de conexiones de Postgres a miles
  Por eso agregaron una verificación en tiempo de compilación en el código Rust, para que si se llama a .await mientras se mantiene una conexión dentro de una función async, el compilador avise de inmediato
  Se corrigieron más de 100 lugares, pero gracias a eso ahora las pruebas de carga no se ralentizan ni siquiera usando un pool de 32 en vez de 10,000 conexiones
  Reducir simplemente el idle timeout también era una opción, pero la verificación estática resultó ser una solución mucho más segura

  • También propusieron que sería mejor cambiar el orden a “hacer primero el trabajo → tomar una conexión del pool e iniciar la transacción solo al final → devolverla después del commit”
  • Hubo quien preguntó si esa verificación estática era una regla de lint o una implementación basada en el sistema de tipos

• El artículo era demasiado superficial y solo repetía palabras clave como “¡hicimos sharding!”
  Casi no había detalles y daba la impresión de ser texto para SEO

  • Incluso parecía publicidad de un socio de infraestructura
  • Sobre caché, connection pooling y optimización de joins, también se quedaba en explicaciones demasiado genéricas

• La idea principal del texto se resumía más o menos en “un solo writer no escala, así que redujimos las escrituras y separamos las lecturas”
  Casi no había nada nuevo, y solo mencionaba enfoques comunes como optimización de consultas, sharding y réplicas de lectura

• Lo que me gusta de Postgres es que puede aguantar bastante escala con solo aumentar CPU y disco
  Para cuando llegas al punto de necesitar sharding, ya también puedes permitirte contratar a un especialista

  • De hecho, PostgreSQL ya soporta sharding básico con FDW y particionamiento
    Por eso suena raro decir que “para hacer sharding hay que dejar Postgres”
  • Pero hubo dudas sobre eso de “ya podrás permitirte contratar especialistas”
    Por ejemplo, hay noticias de que OpenAI sigue teniendo pérdidas enormes y ni siquiera está claro si podrá aguantar hasta 2027

• Sobre los cambios de esquema y los timeouts, se comentó que no basta con configurar timeouts
  Ejecutar en paralelo scripts que terminen automáticamente las transacciones en conflicto durante el rollout del esquema sería mucho más eficiente
  Estaría bien que Postgres ofreciera eso de forma nativa, porque es mejor cancelar algunas transacciones que quedarse esperando con locks pesados

  • Aunque también hubo quien respondió que Postgres ya soporta cambios de esquema transaccionales, así que no necesariamente hace falta matar procesos

• Como primera publicación del blog de OpenAI Engineering, resultó interesante
  Me gustaría ver más casos en el futuro

  • También hubo una reacción en tono de broma diciendo que probablemente llegaron hasta aquí a punta de caídas frecuentes y arreglos de emergencia a las 2 a. m.

• Había curiosidad por la configuración de replicación
  Decían que incluso con 50 réplicas de lectura casi no había retraso de replicación,
  pero en la práctica es muy probable que algunas réplicas se atrasen por picos de CPU o memoria
  En ese caso, el primario también podría volverse más lento por tener que esperar el envío de WAL

  • Aunque también hubo quien opinó que el primario no se ralentiza por esperar TCP ACK, sino que solo aumenta la cantidad de segmentos WAL retenidos

• Había una parte que decía que “si una función nueva necesita tablas adicionales, se pone en Azure CosmosDB en vez de PostgreSQL”
  Es decir, parecía que mantenían el sistema existente y movían solo las funciones nuevas a otra base de datos

  • Aun así, CosmosDB es muy caro, así que fuera de una empresa con mucho dinero como OpenAI, es difícil de usar

• Decían que “aumentaron el tamaño de las instancias”, pero quedaba la duda de hasta qué nivel
  Había interés en saber qué CPU y RAM usan, si son instancias comunes como las de cualquier usuario o si se trata de hardware personalizado

  • Los principales proveedores cloud ofrecen SKU que asignan un servidor completo de dos sockets a una sola VM
    Ejemplo: Azure Standard_E192ibds_v6 (96 núcleos, 1.8 TB de RAM, 10 TB SSD, 3M IOPS)
    Y hay modelos aún mayores para SAP HANA, como Standard_M896ixds_24_v3, que ofrece 896 núcleos, 32 TB de memoria y red de 185 Gbps
    Estas instancias rondan los 175 mil dólares al mes, aunque OpenAI seguramente habrá obtenido descuentos muy grandes
    Personalmente, prefiero usar las VM HX176rs para servidores de base de datos
    Gracias a la caché HBM, el ancho de banda de memoria es mucho mayor y el rendimiento fue muy superior al de VM generales de precio similar

• Usar Azure PostgreSQL y CosmosDB juntos debe ser carísimo
  Aun así, este artículo parecía uno de los ejemplos más realistas de “cómo escalar PostgreSQL” en la práctica
  Fue fácil identificarse con un enfoque operado en un entorno cloud estándar, sin modificar el kernel ni hackear el código fuente