Durability in ACID Database Transactions

Direct Answer

Durability means a successfully committed transaction survives a database restart or crash within the storage guarantees the system is configured to provide. Many databases make the commit record durable in a write-ahead or redo log before acknowledging success, then use that log during recovery. Durability settings, replicas, backups, and storage failures still define the real protection boundary.

Code Example

import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;
import java.math.BigDecimal;
import java.time.Instant;

@Service
public class PaymentService {
    private final PaymentRepository paymentRepo;

    public PaymentService(PaymentRepository paymentRepo) {
        this.paymentRepo = paymentRepo;
    }

    @Transactional
    public Payment recordPayment(String providerRef, BigDecimal amount) {
        var payment = new Payment(providerRef, amount, Instant.now());
        return paymentRepo.save(payment);
    }
}

// When the transaction manager successfully commits, durability is supplied
// by the database and its configured commit policy—not by the annotation itself.

Common Mistakes & Pitfalls

• Calling durability a backup: Crash recovery cannot restore data that was deliberately deleted or storage that was destroyed; use tested backups and replication for those failures.
• Assuming a fixed flush path: Commit latency depends on engine, storage, synchronous settings, and group commit. It is not always one fsync per transaction.
• Assuming one WAL design: PostgreSQL recovery is redo-oriented, while InnoDB combines redo with separate undo information. Learn the selected engine's mechanism.