Bases de datos en producción

Mi serie de GitLab CI fue un curso largo que construye todo desde cero. Esta es lo contrario: posts cortos, una práctica específica en cada uno, sin relleno. Cada parte debería tomarte unos cinco minutos y dejarte una cosa que vas a hacer diferente.

El tema es bases de datos en servicios web de backend, la capa detrás de los incidentes de producción que más asustan. No porque las bases de datos sean frágiles, sino porque la mayoría de los bugs de base de datos comparten una propiedad traicionera: son invisibles en desarrollo local y solo aparecen bajo carga. Un request a la vez, todo funciona. Mil requests concurrentes, y el servicio está caído mientras la base de datos está ahí, tranquila.

Cada post de esta serie trata de un bug así:

• Una fuga de conexiones que se ve exactamente como una caída de la base de datos.
• Un N+1 que llega a producción porque los datos de dev eran 10 filas.
• Una migración que toma un lock y pone a todos los requests a hacer fila detrás de ella.
• Un task en background que corre contra datos que todavía no existen.

Los ejemplos usan el stack con el que trabajo a diario — Python, FastAPI, SQLAlchemy, GraphQL, PostgreSQL — pero casi todas las prácticas se traducen directo a cualquier lenguaje y ORM, porque las reglas de fondo son de la base de datos, no del framework.

Una cosa más sobre el origen de estos posts. Estoy haciendo práctica estructurada de backend: para cada una de estas trampas construyo un programa pequeño y roto, lo arreglo con un test que prueba el fix, y solo entonces escribo el post. Así que todo lo que leas aquí fue roto y reparado a propósito antes de ser explicado. Si algún post contradice tu experiencia, quiero saberlo.

La parte 2 sale la próxima semana: una fuga de conexiones que puede tumbar un servicio completo, y por qué la limpieza va en un finally.