Snapshot Isolation (SI) es un nivel de aislamiento de transacciones que garantiza que todas las lecturas dentro de una transacción vean un estado consistente de la base de datos, como si se hubieran realizado en un único punto en el tiempo (una "instantánea"). A diferencia de los niveles de aislamiento más estrictos como Serializable, SI permite que las transacciones de lectura no bloqueen las transacciones de escritura, y viceversa. Logra esto manteniendo múltiples versiones de los datos (Multi-Version Concurrency Control o MVCC), de modo que cada transacción opera sobre su propia versión consistente sin interferir con otras. Sin embargo, SI no previene el fenómeno de "write skew", donde dos transacciones que leen un mismo conjunto de datos y luego escriben en base a esas lecturas pueden llevar a un estado inconsistente si sus escrituras no se superponen directamente.
Snapshot Isolation es ampliamente adoptado en sistemas de bases de datos modernos debido a su buen equilibrio entre rendimiento y consistencia. Ejemplos notables incluyen PostgreSQL (donde es el comportamiento predeterminado para el nivel de aislamiento 'Repeatable Read'), Oracle Database (conocido como 'Serializable' pero implementando SI), y Microsoft SQL Server (cuando se habilita 'SNAPSHOT' o 'READ_COMMITTED_SNAPSHOT'). También es fundamental en muchas bases de datos distribuidas y NewSQL, como CockroachDB y YugabyteDB, donde MVCC es clave para la resiliencia y escalabilidad, permitiendo que las transacciones operen sobre versiones locales de los datos sin necesidad de bloqueos globales excesivos.
Para un arquitecto, Snapshot Isolation es crucial porque ofrece un rendimiento significativamente mejor que Serializable en muchas cargas de trabajo, especialmente aquellas con muchas lecturas concurrentes, al eliminar la necesidad de bloqueos de lectura. Sin embargo, es vital comprender sus limitaciones, particularmente el "write skew". Los arquitectos deben evaluar si la aplicación puede tolerar este tipo de anomalía o si requiere mitigaciones adicionales (como bloqueos explícitos o la promoción a un nivel de aislamiento más estricto para transacciones críticas). La elección de SI implica un trade-off entre rendimiento, complejidad de desarrollo (al tener que considerar y manejar "write skew" si es relevante) y la robustez de la consistencia. Es una elección común para sistemas que necesitan alta disponibilidad y escalabilidad, pero requiere un diseño cuidadoso de las transacciones para evitar inconsistencias lógicas.