December 20, 2025
So fast, much drama
What Does a Database for SSDs Look Like?
Dev world squabbles over speed gains vs old‑school tricks
TLDR: A developer proposed rethinking databases for super‑fast SSDs, suggesting 30‑second caches and ~32KB data chunks. Commenters clapped back: old design realities still apply, tiny writes need batching, existing SSD‑optimized systems exist, and drive wear matters—making this a debate about physics and pragmatism, not a clean reboot.
Tech Twitter lit up when Ben Dicken asked if we should redesign databases for lightning‑fast SSDs. He crunched numbers and claimed modern storage and networks change the game: cache your hot data for ~30 seconds and aim for ~32KB chunks to hit the sweet spot. The crowd? Not having a simple reboot. mrkeen slammed the brakes: “Overall speed is irrelevant,” insisting the real fight is still sequential vs. random access—physics hasn’t changed. londons_explore brought practical reality: most updates are tiny, but drives make you write a full 4KB block, so we still need write‑ahead logs (a safety ledger that batches writes) to avoid chaos. Meanwhile, zokier threw shade at the premise, arguing the industry didn’t nap through the 2010s—point to MyRocks on ZenFS and other SSD‑savvy engines doing the work already. danielfalbo posted a throwback 2010 SSD tuning guide, and raggi warned the cloud can ignore costs, but SSD wear (how fast drives burn out) still matters. The memes were spicy: “You can’t out‑optimize physics,” “WAL or wall?” and “Reinventing the wheel, now with RGB.” The vibe: bold ideas meet seasoned skepticism—and nobody is throwing Postgres in the bin just yet.
Key Points
- •Modern NVMe SSDs offer ~1000x improvements in throughput and latency compared to spinning disks, challenging legacy DB design assumptions.
- •Cloud datacenter networks and large-memory, many-core servers change operational constraints, emphasizing uptime, compliance, and rapid deployment.
- •Applying the Five Minute Rule with 32kB pages on an EC2 i8g.48xlarge suggests an optimal cost-based cache retention of about 30 seconds.
- •The EC2 i8g.48xlarge is estimated at ~1.8 million 32kB read IOPS and roughly one dollar per billion reads, with RAM for ~50 million pages.
- •For SSDs, transfers >32kB are throughput-limited and <32kB are IOPS-limited; larger-than-32kB transfers yield little throughput gain and reduce IOPS.