Block storage

Why it matters

Every database, every filesystem and every virtual machine sits on block storage. When a database's write latency jumps, the cause is often the volume underneath hitting its IOPS limit, not the database. Knowing what a block device promises, how cloud volumes differ from local disks, and what the performance knobs are lets you size the storage tier deliberately instead of discovering its limits in an incident.

The idea

Block storage presents a device as an array of fixed-size blocks (typically 4 KB) that can be read and written by address. It knows nothing about files or records; a filesystem or a database engine imposes structure on top. The interface is low-level and fast, which is exactly what databases want: they manage their own pages and need predictable random I/O.

Local versus network-attached

	Local disk (instance store, bare-metal NVMe)	Network-attached volume (EBS, Persistent Disk, Azure Disk)
Latency	Tens of microseconds	Hundreds of microseconds to a millisecond
Throughput and IOPS	Very high; bounded by the device	Provisioned per volume type and size; hard caps
Durability	Lost when the instance stops or fails	Replicated within a zone; survives instance failure
Mobility	Tied to the machine	Detach and attach to another instance; snapshots to object storage
Fits	Caches, scratch space, databases that replicate themselves (Cassandra, search)	Databases that need the volume to outlive the machine, boot disks, general persistence

The cloud default is network-attached: the volume survives the instance, which makes failover and resizing possible, at the cost of latency and a performance ceiling you must provision. Systems that replicate data themselves can use local disks for speed and treat a lost node as a replica rebuild.

The performance knobs

IOPS (operations per second) bound random small reads and writes, the database pattern; throughput (MB/s) bounds sequential large transfers, the backup and analytics pattern. Cloud volume types fix a ratio and a cap: general-purpose SSD volumes scale IOPS with size or a baseline plus burst credits, provisioned-IOPS volumes let you buy a number, throughput-optimised HDDs are cheap for sequential scans. A database that is slow at the storage layer shows as high I/O wait and queue depth with CPU idle; the fix is a bigger or faster volume, striping several volumes, or fewer I/Os through caching and indexing. Burst credits are a classic trap: a volume that performed well for an hour then collapsed has spent its credits.

Snapshots and durability

Volumes are snapshotted incrementally to object storage, giving point-in-time copies for backup, cloning environments and seeding replicas. A snapshot is crash-consistent (as if the power was cut), so a database should either be quiesced or rely on its write-ahead log to recover cleanly. Durability of the volume itself comes from replication within a zone; cross-zone or cross-region durability needs snapshots or database-level replication.

Where block storage stops

It is a single-attach device (with narrow exceptions), so two machines cannot write the same volume. It does not scale beyond one large volume per workload without striping, and it is priced for performance, not for petabytes. Files that many services need, media, backups and archives belong on object storage; shared POSIX semantics across machines need a distributed or network filesystem, the next lessons.

Trade-offs

Block storage buys low-latency random I/O and the familiar filesystem and database abstractions, and pays with single-attachment, per-volume ceilings and cost per gigabyte. Network-attached volumes trade latency for durability and mobility; local disks trade the reverse. Provision for IOPS where databases live and move bulk data elsewhere.

In an interview

Mention it when sizing a database: "Postgres runs on a provisioned-IOPS SSD volume sized for our 8,000 random writes per second with headroom, with hourly snapshots to object storage and a synchronous replica for failover. The search cluster uses local NVMe because it replicates itself and needs the latency." Catching the burst-credit trap or the IOPS versus throughput distinction shows operational depth.