Artículo técnico que examina las críticas habituales al diseño de control de concurrencia multiversión (MVCC) de PostgreSQL y rebate la idea de que cualquier otro motor ofrezca una solución claramente superior. Partiendo de casos conocidos —la migración de Uber de PostgreSQL a MySQL en 2016 por la amplificación de escritura, o el análisis del grupo de Andy Pavlo en Carnegie Mellon— el autor reproduce cada cargo sobre una instancia PostgreSQL 19 beta2 para mostrar que no son defectos accidentales sino consecuencias de cuatro decisiones de diseño: dónde residen las versiones antiguas, hacia dónde apuntan las cadenas de versiones, qué direccionan los índices y quién limpia.
El texto demuestra empíricamente la amplificación de escritura: actualizar una columna no indexada en una tabla con cinco índices genera 7,1 registros WAL por fila frente a los 3,0 de la misma tabla sin índices secundarios, porque cada índice apunta a la ubicación física (ctid) de la fila y debe reescribirse cuando la fila se mueve. La mitigación nativa, las actualizaciones HOT, solo aplica cuando la nueva versión cabe en la misma página; con tablas densas el porcentaje HOT ronda el 42 % en el primer lote y mejora al 66 % tras podas oportunistas.
También reproduce el llamado "bloat treadmill": una sola sentencia UPDATE sobre un millón de filas, revertida con ROLLBACK, duplica el tamaño de la tabla y deja un 47 % de tuplas muertas. El autor recuerda que ningún motor evita el MVCC si quiere lectores y escritores no bloqueantes; cada alternativa simplemente traslada el coste a otra capa (escritor, lector histórico, tempdb, caché o compactador) y todas fallan de forma diferente ante transacciones长时间 abiertas.