Amazon S3 now offers strong consistency, and S3 Express hits single-digit ms access. Learn how databases tier NVMe, SSD, and object storage. Read now.
Why databases now span three storage tiers
Modern database systems rarely pin every byte to one device class. Hot paths need low latency and high IOPS; cold history, backups, and large analytical scans need capacity and durability at a lower cost per gigabyte. Tiered storage maps those needs onto hardware and services with different performance and cost profiles: local NVMe for the working set, attached SSD for warm data that still needs random access, and object storage for bulk durable retention.
The design goal is not “move everything to the cheapest tier.” It is to keep latency-sensitive reads and writes on fast media while still making large volumes of data queryable, restorable, and cheap to keep. Getting the placement rules wrong either burns money on over-provisioned fast disks or tanks query performance when cold data is treated as if it were local.
What strong consistency on object storage changes
For years, many teams treated object storage as “eventual” enough that databases could not safely use it as a primary durability layer without extra coordination. Strong consistency on Amazon S3 removes a major class of read-after-write surprises: after a successful write, subsequent reads see that version without application-level retry loops or second-guessing caches.
That property matters for redo logs, snapshots, remote segments, and recovery catalogs. A database can land a segment or checkpoint, then have followers, rebuild jobs, or another region read the same key with confidence that they are not seeing a stale absence. You still design for partial failures and concurrent writers, but you no longer build elaborate workarounds solely because the object store might return outdated data after a confirmed put.
S3 Express and where object storage sits in the latency stack
S3 Express targets single-digit millisecond access for object storage workloads that previously felt too slow for anything near the hot path. That does not make object storage a drop-in replacement for NVMe. Network hops, request overhead, and coarser access patterns still favor block and local storage for small random I/O and tight transactions. What it does is shrink the gap between “warm SSD” and “archive in the cloud,” so more tiers of database data can live as objects without forcing multi-second cold starts on every miss.
In practice, treat S3 Express as a high-performance object tier: good for larger pages, columnar segments, and materializations that tolerate object-sized I/O, not for every row-level lock or index probe. NVMe remains the place for active indexes, buffer pools, and WAL-like structures that need microsecond-class local media. SSD bridges the middle—replicated volumes, local spill, and data that is accessed often enough to justify block semantics but not full residency in the hottest pool.
- NVMe: working set, indexes, and write-ahead or commit-critical paths.
- SSD: warm tables, replicas, and spill that still needs block-style random access.
- Object storage (including S3 Express): segments, snapshots, history, and bulk scan-friendly layouts with durable, shared access.
Practical tiering rules for operators and builders
Define tiers by access pattern, not by age alone. Age-based lifecycle rules are a useful default, but a six-month-old fact table that every dashboard hits is still hot; yesterday’s debug dump is not. Track read frequency, scan size, and whether the workload is point-lookup, range scan, or full-segment reconstruction. Promote and demote on those signals, with hysteresis so thrashing does not move the same objects back and forth every hour.
Keep metadata and control plane data on the fastest reliable tier you control. Catalog entries, allocation maps, and transaction state must stay consistent even when bulk data lives in objects. Prefer immutable, versioned object keys for segments so recovery is “read this snapshot ID” rather than “mutate this file in place.” Compress and column-orient cold data so object GETs pull useful bytes per request. Finally, test failure modes explicitly: partial upload, lost cache, region failover, and rebuild from object storage alone. Tiering only pays off when demotion is reversible and recovery paths are as boring as the hot path.