Cada vez que sale un artículo sobre la infraestructura de una empresa grande, la mitad de los comentarios en Hacker News son variaciones de «pues claro, usan Kubernetes con 47 microservicios y una base de datos distribuida con consensus protocol propio». Y cuando resulta que no, que usan PostgreSQL pelado con un solo primary y disciplina, se hace un silencio incómodo.
Eso acaba de pasar con OpenAI.
Los números que nadie se esperaba
Bohan Zhang, ingeniero de infraestructura de OpenAI, ha publicado los detalles de cómo escalan PostgreSQL para ChatGPT. Los números:
- 800 millones de usuarios
- Un solo PostgreSQL primary (writer) en Azure
- ~50 read replicas
- Millones de queries por segundo
- p99 de 10-19ms
- 99,999% de disponibilidad
- Un solo SEV-0 en un año (y fue por el lanzamiento viral de ImageGen, que metió 100 millones de usuarios nuevos en una semana)
Lee eso otra vez. Un. Solo. Writer. Para 800 millones de usuarios.
«Pero es que deberían shardear»
No. Y la razón es brutalmente pragmática.
Shardear PostgreSQL habría requerido modificar cientos de endpoints en la aplicación. Cada query que asume que todos los datos están en la misma base de datos — que son prácticamente todas — tendría que reescribirse para saber en qué shard vive cada dato.
¿El coste de esa migración? Meses de trabajo de ingeniería, bugs nuevos en cada esquina, y un periodo de transición donde tienes que mantener ambos sistemas.
¿Lo que hicieron en su lugar? Identificaron los writes más pesados y los movieron a Cosmos DB. No porque Cosmos sea mejor que PostgreSQL, sino porque esos workloads específicos encajaban mejor en un modelo de documento. El resto — la inmensa mayoría de la lógica de negocio — se quedó en PostgreSQL.
Dicho en cristiano: en vez de complicar todo el sistema, aislaron el problema y lo resolvieron donde dolía. Cirugía con bisturí, no con motosierra.
PgBouncer: de 50ms a 5ms por conexión
Uno de los primeros cuellos de botella que encontraron fue la latencia de establecer conexiones. PostgreSQL crea un proceso por cada conexión nueva. Con miles de conexiones simultáneas desde cientos de pods de aplicación, el overhead de conexión se comía 50ms antes de ejecutar ni una sola query.
La solución: PgBouncer como connection pooler. Mantiene un pool de conexiones ya establecidas y las reutiliza. Resultado: la latencia de conexión bajó a 5ms. Un 90% menos, cambiando una pieza de fontanería.
No es una tecnología nueva. PgBouncer lleva más de 15 años en producción en empresas de todo tamaño. Pero ahí está: una herramienta baqueteada y aburrida resolviendo un problema en una de las aplicaciones más usadas del planeta.
El ORM que hacía joins de 12 tablas
Este es mi favorito. Porque lo he visto en proyectos de mis alumnos, en startups, en bancos. En todas partes.
El ORM generaba queries con joins de 12 tablas. No porque alguien lo hubiese diseñado así, sino porque los modelos estaban relacionados entre sí y el ORM, obedientemente, seguía las relaciones hasta el final.
La solución no fue cambiar de ORM, ni pasarse a queries manuales para todo. Fue mover lógica a la aplicación. En vez de pedirle a PostgreSQL que hiciera un join monstruoso, hacían varias queries más simples y juntaban los datos en el código.
¿Es eso menos elegante? Sí. ¿Es más rápido? Enormemente. Porque PostgreSQL puede optimizar queries simples mucho mejor que un join de 12 tablas con condiciones cruzadas. Y porque puedes cachear los resultados parciales y reutilizarlos.
-- ANTES: el ORM genera esto
SELECT u.*, p.*, s.*, t.*, ...
FROM users u
JOIN profiles p ON ...
JOIN settings s ON ...
JOIN teams t ON ...
JOIN ... -- 12 tablas
WHERE u.id = $1;
-- DESPUÉS: queries separadas, lógica en aplicación
SELECT * FROM users WHERE id = $1;
SELECT * FROM profiles WHERE user_id = $1;
-- cacheable, paralelizable, debuggeable
Cada query individual es trivial. El query planner las ejecuta en microsegundos. Y si una falla o va lenta, sabes exactamente cuál es.
Las defensas que nadie ve
Lo que de verdad me parece brillante del artículo de Bohan Zhang no son los números grandes, sino las pequeñas defensas que evitan que todo se venga abajo:
idle_in_transaction_session_timeout
Si una transacción se queda abierta sin hacer nada, PostgreSQL la mata después de un tiempo configurable. ¿Por qué importa? Porque una transacción abierta bloquea el autovacuum. Y sin autovacuum, las tablas se hinchan, los índices se degradan, y eventualmente tu base de datos empieza a ir más lenta cada día.
Es como dejar la puerta del frigorífico abierta. No pasa nada los primeros 5 minutos. Pero si te olvidas toda la noche, al día siguiente todo está a temperatura ambiente.
Schema changes con timeout de 5 segundos
Cuando haces un ALTER TABLE en PostgreSQL, necesitas un lock sobre la tabla. Si hay transacciones largas en curso, ese lock espera. Y mientras espera, bloquea todas las queries nuevas. Una migración de schema que tarda 200ms puede tumbar tu base de datos si hay una transacción vieja que no termina.
La solución de OpenAI: SET lock_timeout = '5s'. Si la migración no consigue el lock en 5 segundos, aborta. Mejor fallar rápido y reintentar que bloquear todo el sistema esperando.
Rate limiting en 4 capas
No una. No dos. Cuatro capas de rate limiting:
- Edge/CDN — bloqueo de tráfico abusivo antes de que llegue a la aplicación
- API gateway — límites por usuario/API key
- Aplicación — límites por tipo de operación
- Base de datos — connection limits y statement timeouts
Cada capa atrapa lo que la anterior deja pasar. Defensa en profundidad. La misma filosofía de la cebolla que aplico para las defensas contra alucinaciones, pero para infraestructura.
Aislamiento de workloads por prioridad
No todas las queries son iguales. Una query de «mostrar el chat del usuario» es crítica — si falla, el usuario ve un error. Una query de «generar un informe de analítica» es importante, pero puede esperar 30 segundos.
OpenAI rutea las queries según prioridad a diferentes read replicas. Las réplicas de alta prioridad tienen menos carga y responden más rápido. Las de baja prioridad pueden ir más cargadas sin afectar la experiencia del usuario.
Es sentido común, pero requiere disciplina. Tienes que clasificar cada query, configurar el ruteo, y resistir la tentación de mandar todo a la réplica rápida «porque total, es solo una query más».
Los backfills que tardan semanas
Cuando necesitas rellenar una columna nueva para 800 millones de usuarios, no puedes hacer un UPDATE users SET new_column = computed_value. Eso bloquearía la tabla, saturaría el disco, y probablemente tumbaría el primary.
En OpenAI, los backfills se ejecutan con rate limiting estricto. Semanas. Un backfill que tarda semanas.
¿Suena horrible? Es lo contrario. Es la decisión de un equipo que entiende que la velocidad del backfill es irrelevante comparada con la estabilidad del sistema. Mejor tardar 3 semanas y que nadie se entere, que tardar 3 horas y tener un SEV-0 a las 2 de la madrugada.
La cascading replication que viene
Actualmente tienen ~50 réplicas conectadas directamente al primary. Cada réplica consume una conexión de replicación y ancho de banda del primary. Con 50 es manejable. Con 100+ sería un problema.
La solución que están desarrollando: cascading replication. Réplicas que replican de otras réplicas, no del primary. Un árbol en vez de una estrella. El primary envía datos a 5-10 réplicas de primer nivel, y esas réplicas alimentan al resto.
Es la misma idea que BitTorrent. En vez de que todo el mundo descargue del mismo servidor, los nodos comparten entre sí. Funciona para pelis pirata, funciona para WAL segments.
La lección que nadie quiere oír
La industria tiene una adicción al over-engineering. Cada semana sale una base de datos nueva que promete resolver problemas que la mayoría de empresas no tienen. Y cada semana, equipos de ingeniería adoptan esas tecnologías porque «escalan mejor» o «son más modernas», sin preguntarse si PostgreSQL con un poco de disciplina haría el trabajo.
OpenAI — la empresa que está definiendo el futuro de la IA, con uno de los productos de mayor crecimiento de la historia — usa PostgreSQL. Con un solo primary. Sin sharding. Sin una base de datos distribuida exótica.
Usan PgBouncer (2007). Read replicas (concepto de los 90). Connection pooling (tan viejo como las bases de datos relacionales). Rate limiting (inventado antes de que la mayoría de nosotros naciera).
La magia no está en la tecnología. Está en la disciplina:
- Queries simples en vez de joins monstruosos
- Timeouts agresivos en vez de esperas infinitas
- Aislamiento de workloads en vez de «todo al mismo servidor»
- Migrar solo lo que necesita migrar, no reescribir todo
Para tu próximo standup
La próxima vez que alguien en tu equipo proponga migrar a una base de datos distribuida, o shardear PostgreSQL, o meter un servicio de colas entre la API y la base de datos «porque no va a escalar», enséñale estos números.
800 millones de usuarios. Un primary. p99 de 10-19ms. 99,999% uptime.
Y pregúntale: «¿Nuestro problema es realmente que PostgreSQL no escala? ¿O es que nuestras queries son una chapuza?»
Porque casi siempre es lo segundo.
Fuente: Inside the Postgres Setup Powering 800M ChatGPT Users — Bohan Zhang, OpenAI. Si solo lees un artículo de infraestructura este año, que sea este.
Read this article in English.
