In this lesson, you will learn how the physical speed of your storage hardware directly dictates the duration a user must wait before a transaction is confirmed as "committed."
The Durability Guarantee
To satisfy the "Durability" requirement of ACID, a database must ensure that once a transaction is committed, the changes survive even if the power fails immediately afterward. To achieve this, the database performs a synchronous write of the transaction data to the Write-Ahead Log (WAL) on disk. The database does not send a "success" acknowledgment to your application until the hardware confirms that the data has been physically hardened to non-volatile storage.
The Role of Disk Latency
Because every commit requires a physical write to disk, your transaction latency is effectively bounded by the "seek time" and "write latency" of your storage media. If your disk takes 5 milliseconds to confirm a write, your application is mathematically limited to a maximum of 200 commits per second on a single thread, regardless of how fast your CPU or SQL engine might be.
Imagine this simplified flow of a COMMIT command:
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
COMMIT; -- The DB waits here for the disk to acknowledge the WAL write.
If the storage hardware is slow (e.g., high-latency network-attached storage or an aging magnetic drive), that COMMIT statement will hang. The database engine remains idle, waiting for the I/O subsystem to return a "Success" signal. This is why high-performance database environments prioritize low-latency NVMe drives; they reduce the "waiting time" for every single transaction.
Scaling and Bottlenecks
When storage latency increases, your transactions stay "active" longer. This has a cascading effect: longer transaction times mean locks are held longer, which causes other sessions to block. Eventually, slow disk latency can cause the database to run out of available connections because every session is stuck waiting for the disk to confirm a previous transaction's durability.
When designing systems, always remember that you are not just writing to memory; you are paying a "durability tax" proportional to the latency of your underlying storage.
Key Takeaway: Disk latency creates a physical "floor" for transaction response times, as the database cannot acknowledge a commit until the storage hardware confirms the data is safely written to the transaction log.