ai_explainer_worthy26 de septiembre de 2026Edición #126

Por qué tu base de datos está copiando todo en cada escritura

MVCC — Multi-Version Concurrency Control — es el motor detrás de la mayoría de las bases de datos modernas. PostgreSQL, MySQL 8.0+, Oracle, SQL Server, CockroachDB. Permite que múltiples lecturas y escrituras ocurran al mismo tiempo sin bloquearse entre sí.

El truco es simple: cada fila en la tabla lleva columnas extra. Un número de versión. Un ID de transacción. Una bandera de visibilidad. Cuando se inserta una nueva fila, la base de datos no toca la antigua. Escribe una copia nueva. Cuando una transacción vieja aún necesita la versión previa, lee la copia vieja.

Por eso tus lecturas nunca bloquean tus escrituras.

¿El costo? Las versiones viejas se quedan. Se acumulan. Las tablas crecen. Lo ves en el uso de disco. Tu factura de almacenamiento sube. Tus backups se hacen más grandes. Tus consultas se vuelven más lentas porque el motor tiene que verificar la visibilidad de la versión en cada fila que toca.

PostgreSQL le llama bloat. Se acumula hasta que ejecutas VACUUM. VACUUM marca las versiones viejas como muertas. No libera el espacio de vuelta al sistema operativo. Solo lo hace disponible para reutilizar. Por eso a menudo ejecutas VACUUM FULL — reescribe toda la tabla, elimina las copias muertas y devuelve el espacio.

InnoDB de MySQL lo maneja diferente. Usa un undo log. Las versiones viejas viven ahí. Un hilo de purga en segundo plano las limpia. Pero si tus transacciones son largas, o tus escrituras son pesadas, ese undo log crece. Lo ves en consultas lentas. Lo ves en esperas de bloqueo.

Lo difícil no es entender el concepto. Es leer tu propio esquema y darte cuenta de que cada tabla está guardando en silencio su propia historia. Cada INSERT. Cada UPDATE. Las filas viejas no desaparecen. Esperan. Esperan hasta que llega VACUUM o purge o autovacuum.

Así que cuando planeas una migración, cuando dimensionas tu base de datos, cuando presupuestas almacenamiento — no solo estás presupuestando los datos de hoy. Estás presupuestando cada versión que aún está viva.

Por qué nos importa: nuestras apps y nuestras bases de datos son baratas de construir pero caras de mantener si no respetamos el costo oculto de cada escritura — y ese costo se refleja en nuestras facturas, en nuestros lentitudes y en nuestras alertas de medianoche.

“Cada INSERT está guardando en silencio su propia historia.”

hubs.la

Lee el originalAbrir en pestaña nueva
#databases#performance#infrastructure#engineering

Boletín diario · sin spam

Recibe el diario en tu puerta

Un correo corto al día — IA, tecnología y lo que significa para nuestras comunidades. Lenguaje claro, mirada cultural, sin jerga de Silicon Valley.