Explica los niveles de aislamiento de transacciones y cuál usa tu base de datos por defecto.

Los cuatro niveles son read uncommitted, read committed, repeatable read y serializable, y cambian concurrencia por las anomalías que permiten: lecturas sucias, lecturas no repetibles, lecturas fantasma y write skew. PostgreSQL usa read committed por defecto, donde cada sentencia ve una instantánea nueva; MySQL con InnoDB usa repeatable read, donde toda la transacción ve una sola instantánea. Serializable es el único nivel que garantiza que el resultado equivale a algún orden serial.

Van desde read uncommitted hasta serializable, y cada escalón elimina una anomalía a cambio de algo de concurrencia. Read committed corta las lecturas sucias, pero cada sentencia recibe su propia instantánea, así que la misma consulta dos veces dentro de una transacción puede devolver filas distintas. Repeatable read fija una instantánea para toda la transacción. Serializable además garantiza que el resultado equivale a ejecutar las transacciones una detrás de otra, lo que en Postgres se logra con seguimiento de predicados, así que en vez de bloquear puede abortar una transacción y tienes que estar listo para reintentar. Los valores por defecto importan: Postgres es read committed e InnoDB es repeatable read, lo que sorprende a quien salta de uno a otro. El bug que sufrí de verdad fue write skew en una tabla de reservas, donde dos peticiones comprobaron que no existía una reserva solapada, ambas vieron una instantánea limpia y ambas insertaron. Repeatable read no ayudó porque escribían filas distintas. Lo arreglamos con serializable más reintento, y luego con una restricción de exclusión, que sale más barata.