En un momento en el que la conversación tecnológica parece girar siempre hacia lo mismo —bases de datos distribuidas, particionamiento agresivo y arquitecturas cada vez más exóticas— OpenAI ha publicado un relato que va a contracorriente: ChatGPT y su plataforma de APIs se apoyan en PostgreSQL como columna vertebral, con una arquitectura que, sobre el papel, suena casi minimalista. Según la compañía, su despliegue en Azure Database for PostgreSQL opera con un único nodo primario para escrituras y casi 50 réplicas de lectura repartidas por varias regiones, capaces de sostener “millones” de consultas por segundo para 800 millones de usuarios.
La tesis no es que PostgreSQL sea “mágicamente infinito”, sino que —en un entorno marcadamente orientado a lecturas— la combinación de disciplina operativa, optimización de consultas y mecanismos de contención de picos puede estirar mucho más el sistema de lo que suele asumirse en presentaciones y debates de pasillo. En el texto, firmado por Bohan Zhang (miembro del equipo técnico), OpenAI detalla un año de crecimiento de carga superior a 10×, con el objetivo de mantener latencias bajas y evitar incidentes que escalen en cascada.
Cuando el problema no es la base de datos, sino la estampida
El patrón que describe OpenAI es reconocible para cualquier equipo que opere servicios globales: un fallo “aguas arriba” (capa de caché, nueva funcionalidad, un endpoint que se viraliza) provoca un aumento repentino de carga. Con la latencia al alza, llegan los timeouts; después, los reintentos; y finalmente, una espiral que amenaza con degradar el servicio completo.
La compañía enumera tres detonantes típicos: tormentas de fallos de caché (cache misses masivos), consultas muy costosas —como joins múltiples— que saturan CPU, y picos de escrituras tras lanzamientos de producto. En otras palabras: el enemigo no es solo el volumen, sino la sincronización de un “pico perfecto” que llega de golpe y golpea justo donde más duele.
El talón de Aquiles: las escrituras y el coste oculto de MVCC
OpenAI reconoce que, incluso en un escenario predominantemente “read-heavy”, las escrituras son el punto delicado cuando se mantiene un único primario. El motivo no es anecdótico: PostgreSQL se basa en MVCC (multiversion concurrency control), que en cargas intensas de escritura puede generar amplificación de escritura (nuevas versiones de filas) y, con ello, más presión de mantenimiento y limpieza (autovacuum), además de amplificación de lectura al convivir múltiples versiones (“dead tuples”).
Para aliviar esa presión, la empresa afirma haber migrado cargas “shardables” y con muchas escrituras a sistemas particionados, citando explícitamente Azure Cosmos DB, y ha fijado una norma interna: no se permiten nuevas tablas en el despliegue actual de PostgreSQL; los nuevos desarrollos deben nacer ya en sistemas shardeados. El mensaje implícito es claro: PostgreSQL se mantiene como núcleo por su madurez y fiabilidad, pero se evita convertirlo en el contenedor universal de cualquier nueva necesidad.
Las palancas que han permitido estirar el sistema
OpenAI estructura su receta en varias líneas de defensa. No son trucos de laboratorio: son medidas operativas y de diseño que, juntas, convierten una arquitectura “simple” en una plataforma robusta.
1) Descargar lecturas al máximo (y asumir que el primario no debe leer)
El primario existe para escribir, y debe conservar margen para absorber picos de escritura. En la práctica, OpenAI intenta llevar las lecturas a réplicas “siempre que sea posible”, con la salvedad de aquellas lecturas que forman parte de transacciones de escritura.
2) Optimización de consultas y control del ORM
En su experiencia, pocas consultas mal diseñadas pueden tumbarlo todo. Citan un caso concreto: una consulta que llegaba a unir 12 tablas, cuya subida repentina de frecuencia estuvo ligada a incidentes graves. La recomendación es conservadora: evitar joins complejos y, si son inevitables, trocear la lógica y desplazar parte al nivel de aplicación.
3) Alta disponibilidad con “hot standby”
Para reducir el riesgo del “single point of failure” del primario, OpenAI opera el primario en modo de alta disponibilidad con un hot standby sincronizado, listo para asumir el rol si hay caída o mantenimiento. La idea es minimizar tiempo de indisponibilidad y, sobre todo, evitar que una incidencia de base de datos se convierta automáticamente en un apagón total.
4) Aislamiento de cargas para evitar el “vecino ruidoso”
Una de las decisiones más pragmáticas es separar tráfico por prioridades: rutas de baja prioridad a instancias dedicadas y rutas críticas a otras. Con ello, una funcionalidad nueva (y potencialmente ineficiente) tiene menos capacidad de degradar lo esencial.
5) PgBouncer como cinturón de seguridad contra tormentas de conexiones
OpenAI cuantifica un problema clásico: los límites de conexiones. En su caso citan un máximo de 5.000 conexiones por instancia en Azure PostgreSQL, y explican que han tenido incidentes por “connection storms”. La respuesta pasa por PgBouncer como capa proxy para “pooling” de conexiones, en modos statement o transaction, reutilizando conexiones y reduciendo el coste de establecimiento. En benchmarks internos, aseguran haber bajado el tiempo medio de conexión de 50 ms a 5 ms.
6) Caché con “locking/leasing” para frenar el pánico en avalancha
Cuando una clave de caché falla y miles de peticiones intentan recomponerla a la vez, la base de datos paga el precio. OpenAI dice haber implantado un mecanismo de cache locking (y leasing): si varias solicitudes fallan sobre la misma clave, solo una adquiere el bloqueo y consulta PostgreSQL; el resto espera a que la caché se repueble. El objetivo es cortar de raíz las lecturas redundantes que disparan CPU y latencias.
El siguiente techo: replicación y el coste de “servir WAL” a decenas de réplicas
La propia arquitectura impone un límite: cuantas más réplicas, más presión para el primario, que debe enviar WAL (Write Ahead Log) a todas. OpenAI sostiene que, aunque hoy el diseño aguanta con instancias grandes y mucho ancho de banda, no se puede crecer indefinidamente en número de réplicas sin afectar red y CPU del primario.
Por eso trabaja con el equipo de Azure en replicación en cascada, donde réplicas intermedias redistribuyen WAL hacia réplicas “hijas”, con la ambición de superar el umbral de cientos de réplicas sin ahogar al primario. La compañía lo califica como una función “aún en pruebas” por la complejidad adicional en escenarios de failover.
Resultados: latencia baja, “cinco nueves” y una advertencia
OpenAI afirma que el sistema mantiene latencias p99 en “decenas bajas” de milisegundos y disponibilidad de cinco nueves (99,999 %) en producción, con solo un incidente SEV-0 relacionado con PostgreSQL en los últimos 12 meses. Ese incidente, apunta, llegó con un lanzamiento viral de ChatGPT ImageGen, cuando el tráfico de escritura subió más de 10× y más de 100 millones de nuevos usuarios se registraron en una semana.
El caso, en todo caso, no vende una receta universal: más bien demuestra que la escala no siempre exige complejidad inmediata, pero sí una obsesión por la ingeniería preventiva: limitar escrituras, medir, aislar, amortiguar picos y diseñar para el fallo.
Preguntas frecuentes
¿Cómo puede una sola base de datos PostgreSQL soportar un servicio global como ChatGPT?
Porque el patrón de uso descrito es mayoritariamente de lectura y se apoya en una combinación de réplicas multi-región, caché agresiva y control estricto de picos, reduciendo la presión sobre el nodo primario y reservándolo para escrituras.
¿Qué papel juega PgBouncer en arquitecturas PostgreSQL de alta demanda?
Actúa como pool de conexiones: evita tormentas de conexiones, reutiliza sesiones y reduce la latencia de establecimiento. En entornos con miles de clientes concurrentes, es habitual que sea un componente decisivo para estabilidad.
¿Qué es “cache locking” y por qué evita caídas cuando falla la caché?
Es una técnica que asegura que, ante un fallo de caché en una clave concreta, solo una petición va a la base de datos a regenerarla; el resto espera. Así se previene el “thundering herd” que, de otro modo, saturaría CPU e I/O.
¿Qué limitaciones tiene escalar solo con réplicas de lectura?
Aumentar réplicas implica que el primario debe distribuir más WAL, elevando el coste de red y CPU y aumentando el riesgo de lag. Por eso se exploran enfoques como replicación en cascada o la migración de cargas de escritura a sistemas shardeados.
vía: Scaling PostgreSQL
