Imagina un sistema bancario donde un usuario transfiere 500 euros de su cuenta a la de otra persona. La operación requiere dos pasos: debitar 500 euros de la cuenta origen y acreditar 500 euros en la cuenta destino.
Si el sistema falla entre los dos pasos, o si dos transferencias ocurren al mismo tiempo sobre la misma cuenta, el dinero puede perderse, duplicarse o quedar en un estado inconsistente.
Las propiedades ACID son el conjunto de garantías que evitan exactamente ese escenario. Son los fundamentos sobre los que se construye la confiabilidad de cualquier base de datos transaccional y uno de los conceptos que todo desarrollador backend, Data Engineer o Data Scientist necesita entender para trabajar con datos de forma profesional.
Qué es ACID
ACID es un acrónimo que representa las cuatro propiedades que debe cumplir una transacción en una base de datos para garantizar la integridad y fiabilidad de los datos:
- Atomicidad (Atomicity)
- Consistencia (Consistency)
- Isolamiento (Isolation)
- Durabilidad (Durability)
El término fue formalizado por Jim Gray y Andreas Reuter en 1992 en su libro Transaction Processing: Concepts and Techniques, aunque los conceptos ya se usaban en sistemas de bases de datos relacionales desde los años setenta.
Una transacción es una unidad de trabajo que agrupa una o más operaciones sobre la base de datos. La idea central de ACID es que la transacción debe tratarse como una operación indivisible desde el punto de vista del sistema: o se completa totalmente, o no deja ninguna huella.
Las cuatro propiedades ACID explicadas
A – Atomicidad
La atomicidad garantiza que una transacción se ejecuta completamente o no se ejecuta en absoluto. Si falla cualquier operación dentro de la transacción, se revierten todos los cambios realizados hasta ese punto, dejando la base de datos exactamente como estaba antes de que empezara la transacción.
🔴 ¿Quieres Aprender a Programar con Python? 🔴
Descubre el Full Stack Jr. Bootcamp - Aprende a Programar desde Cero de KeepCoding. La formación más completa del mercado y con empleabilidad garantizada
👉 Prueba gratis el Bootcamp Aprende a Programar desde Cero por una semanaEl mecanismo que implementa esto son las operaciones COMMIT (confirmar todos los cambios) y ROLLBACK (revertir todos los cambios).
-- Ejemplo: transferencia bancaria atómica en PostgreSQL
BEGIN;
UPDATE cuentas SET saldo = saldo - 500 WHERE id = 1; -- Débito cuenta origen
UPDATE cuentas SET saldo = saldo + 500 WHERE id = 2; -- Crédito cuenta destino
-- Si ambas operaciones son correctas, confirmar
COMMIT;
-- Si algo falla (p.ej. saldo insuficiente, error de red),
-- el sistema ejecuta automáticamente:
-- ROLLBACK; → ambas operaciones se deshacenSin atomicidad, un fallo de sistema entre el débito y el crédito dejaría 500 euros debitados de una cuenta sin que aparecieran en la otra. La atomicidad garantiza que ese escenario es imposible.
C – Consistencia
La consistencia garantiza que una transacción lleva la base de datos de un estado válido a otro estado válido, respetando todas las restricciones de integridad definidas: claves primarias, claves foráneas, restricciones NOT NULL, CHECK, UNIQUE y cualquier regla de negocio implementada a nivel de base de datos.
Si una transacción viola cualquier restricción de integridad, se rechaza y se revierte automáticamente.
-- Restricción de consistencia: saldo no puede ser negativo
ALTER TABLE cuentas ADD CONSTRAINT saldo_positivo CHECK (saldo >= 0);
BEGIN;
UPDATE cuentas SET saldo = saldo - 1000 WHERE id = 1; -- Saldo actual: 500
-- La restricción CHECK detecta saldo negativo (-500)
-- La transacción se rechaza automáticamente con ROLLBACK
COMMIT;Es importante distinguir entre la consistencia que garantiza el motor de base de datos (restricciones de integridad) y la consistencia lógica de negocio, que es responsabilidad del desarrollador.
La base de datos no puede saber si una transferencia tiene sentido desde el punto de vista de negocio: solo puede verificar que los datos resultantes cumplen las reglas definidas.
I – Aislamiento
El aislamiento garantiza que las transacciones concurrentes se ejecutan de forma independiente, como si fueran las únicas en ejecución sobre la base de datos. Los cambios parciales de una transacción no son visibles a otras transacciones hasta que se confirman con COMMIT.
Sin aislamiento, varios tipos de anomalías pueden ocurrir en acceso concurrente:
| Anomalía | Qué ocurre |
|---|---|
| Dirty Read | Una transacción lee datos que otra transacción ha modificado pero no confirmado todavía. Si la segunda hace ROLLBACK, la primera leyó datos que nunca existieron. |
| Non-Repeatable Read | Una transacción lee el mismo registro dos veces y obtiene valores distintos porque otra transacción lo modificó entre las dos lecturas. |
| Phantom Read | Una transacción ejecuta la misma consulta dos veces y obtiene un conjunto de filas diferente porque otra transacción insertó o eliminó filas entre ambas consultas. |
El estándar SQL define cuatro niveles de aislamiento que controlan qué anomalías se permiten a cambio de mayor rendimiento concurrente:
| Nivel | Dirty Read | Non-Repeatable Read | Phantom Read |
|---|---|---|---|
| READ UNCOMMITTED | ✅ Posible | ✅ Posible | ✅ Posible |
| READ COMMITTED | ❌ Prevenido | ✅ Posible | ✅ Posible |
| REPEATABLE READ | ❌ Prevenido | ❌ Prevenido | ✅ Posible |
| SERIALIZABLE | ❌ Prevenido | ❌ Prevenido | ❌ Prevenido |
-- Configurar nivel de aislamiento en PostgreSQL
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN;
SELECT saldo FROM cuentas WHERE id = 1; -- Lee el saldo
-- Otras transacciones no pueden modificar este registro hasta el COMMIT
UPDATE cuentas SET saldo = saldo - 100 WHERE id = 1;
COMMIT;El nivel por defecto en PostgreSQL es READ COMMITTED. En MySQL/InnoDB es REPEATABLE READ. SERIALIZABLE ofrece las máximas garantías pero a costa de mayor contención y posibles deadlocks en entornos de alta concurrencia.
D — Durabilidad
La durabilidad garantiza que una vez que una transacción se confirma con COMMIT, sus cambios son permanentes aunque ocurra un fallo inmediatamente después: corte de energía, crash del servidor, fallo de hardware.
El mecanismo técnico principal que implementa la durabilidad es el Write-Ahead Logging (WAL): antes de aplicar cualquier cambio a los datos, el motor de base de datos escribe una entrada en un registro de transacciones (log) en almacenamiento persistente.
Si el sistema falla, el log permite recuperar y reaplica las transacciones confirmadas que no llegaron a escribirse en los archivos de datos.
-- En PostgreSQL, la durabilidad está garantizada por defecto
-- El parámetro synchronous_commit controla el nivel de durabilidad
-- synchronous_commit = on (por defecto): máxima durabilidad
-- synchronous_commit = off: mejor rendimiento, menor durabilidad
SHOW synchronous_commit; -- on
-- Una vez ejecutado COMMIT, los datos están garantizados
-- incluso si el servidor falla en el siguiente milisegundo
BEGIN;
INSERT INTO pedidos (cliente_id, total) VALUES (42, 150.00);
COMMIT; -- A partir de aquí, el pedido existe para siempreACID en una transacción completa: el ejemplo bancario
El ejemplo canónico para entender ACID en conjunto es una transferencia bancaria. Veamos cómo las cuatro propiedades actúan de forma coordinada:
-- Schema
CREATE TABLE cuentas (
id SERIAL PRIMARY KEY,
titular VARCHAR(100) NOT NULL,
saldo DECIMAL(10,2) NOT NULL,
CONSTRAINT saldo_no_negativo CHECK (saldo >= 0) -- Consistencia
);
-- Transferencia de 300€ de cuenta 1 a cuenta 2
BEGIN; -- Inicio de la transacción atómica
-- Comprobar saldo suficiente
SELECT saldo FROM cuentas WHERE id = 1 FOR UPDATE; -- Aislamiento: bloqueo
-- Debitar cuenta origen
UPDATE cuentas SET saldo = saldo - 300 WHERE id = 1;
-- Si saldo < 300, la restricción CHECK lanza error → ROLLBACK automático
-- Acreditar cuenta destino
UPDATE cuentas SET saldo = saldo + 300 WHERE id = 2;
COMMIT; -- Durabilidad: cambios permanentes
-- Si falla entre el UPDATE 1 y el UPDATE 2 → ROLLBACK automático (Atomicidad)Qué bases de datos implementan ACID
Las bases de datos relacionales implementan ACID por diseño. Las principales:
- PostgreSQL: implementación ACID completa, reconocida como la más rigurosa entre las bases de datos open source. Soporta todos los niveles de aislamiento con MVCC (Multi-Version Concurrency Control).
- MySQL / MariaDB con el motor InnoDB: implementación ACID completa. El motor MyISAM (legacy) no es ACID.
- Oracle Database: implementación ACID con MVCC desde las primeras versiones.
- Microsoft SQL Server: ACID completo con múltiples niveles de aislamiento.
- SQLite: ACID completo para operaciones locales. Limitaciones en concurrencia.
Algunas bases de datos NoSQL también ofrecen garantías ACID en contextos específicos:
- MongoDB (desde la versión 4.0): transacciones ACID multi-documento dentro de un mismo replica set.
- Google Spanner: ACID distribuido a escala global usando relojes atómicos.
- CockroachDB: ACID distribuido compatible con PostgreSQL.
ACID vs BASE: cuándo usar cada modelo
BASE (Basically Available, Soft state, Eventually consistent) es el modelo alternativo a ACID que adoptan muchas bases de datos NoSQL. No es un modelo inferior: es una elección de diseño con trade-offs distintos según el problema que se resuelve.
Cuando la integridad de los datos es crítica y no se puede tolerar inconsistencia temporal. Banca, pagos, sistemas de reservas, inventarios, datos médicos o cualquier sistema donde una inconsistencia tenga consecuencias graves.
Cuando la disponibilidad y la escalabilidad horizontal son prioritarias y se tolera consistencia eventual. Redes sociales, catálogos de productos, contadores de visitas, análisis de logs o sistemas donde una inconsistencia temporal no tiene consecuencias graves.
El Teorema CAP (Consistency, Availability, Partition tolerance) formaliza este trade-off: en un sistema distribuido es imposible garantizar simultáneamente consistencia total, disponibilidad total y tolerancia a particiones de red. ACID elige consistencia. BASE elige disponibilidad.
Eva llegó al Bootcamp de Desarrollo Web Full Stack de KeepCoding con casi 25 años de experiencia en programación orientada al backend. Buscaba actualizarse, salir de tecnologías obsoletas y volver a sentirse competitiva en un mercado que cambia rápido.
El bootcamp le permitió afianzar los conocimientos de backend que ya tenía y ampliar su visión técnica hacia el desarrollo frontend con React. Lo que valoró fue la combinación de profesores en activo con proyectos que simulan el trabajo real, no ejercicios académicos desconectados del mercado.
Cómo aprender bases de datos con criterio profesional
Entender ACID a nivel superficial (el acrónimo y la definición de cada propiedad) toma una tarde. Lo que requiere más práctica es el criterio para diseñar transacciones correctamente: elegir el nivel de aislamiento adecuado para cada caso de uso.
Detectar cuándo un diseño de base de datos puede generar deadlocks bajo alta concurrencia, y saber cuándo el modelo ACID es el correcto y cuándo una base de datos con consistencia eventual resuelve mejor el problema.
Conclusión
Las propiedades ACID son el fundamento de la confiabilidad en los sistemas de bases de datos transaccionales. La atomicidad garantiza que no hay transacciones parciales. Desarrollo Web Full Stack Bootcamp.
La consistencia garantiza que los datos siempre cumplen las reglas definidas. El aislamiento garantiza que la concurrencia no produce datos corruptos. Y la durabilidad garantiza que los datos confirmados sobreviven a cualquier fallo.
Estas propiedades tienen un coste: mayor contención en acceso concurrente y menor escalabilidad horizontal respecto a modelos de consistencia eventual. Por eso el modelo BASE existe y tiene sus casos de uso legítimos. La decisión entre ACID y BASE no es técnica en primera instancia: es una decisión sobre qué consecuencias son aceptables cuando el sistema falla o cuando hay datos inconsistentes.
Para sistemas donde un dato inconsistente puede significar dinero perdido, un paciente con la dosis incorrecta o un vuelo sobrevendido, ACID no es una opción. Es un requisito.
La referencia técnica más completa sobre transacciones ACID, niveles de aislamiento y MVCC está en la documentación oficial de PostgreSQL sobre aislamiento de transacciones, que es la implementación de referencia para entender estos conceptos en profundidad.
