Can HCI Run a Database Application on Hard Disk Drives?

Here’s the result, up front: I moved a live SQL Server data drive from NVMe onto hard disk drives. At today’s street prices, that one change cuts the VM’s storage media cost from $263 to $133. No downtime, no maintenance window. One setting on one drive, while the database kept answering queries.

Now imagine that across a whole data center estate. Take 200 TB: if even 75% of it can move from NVMe to hard disk drives, that’s 150 TB at $650 less per terabyte, or $97,500 in raw media saved. Even if you keep a second copy on ioGuardian for better than RF3 redundancy, that’s still more than $50,000 in savings.

Why it matters now: for years the default answer to “which storage?” was “more flash,” because flash got cheaper every quarter. That era is over. At late-September street prices, a 15.36 TB NVMe SSD costs $706 per terabyte and a 24 TB hard drive costs $56, and flash prices keep climbing. I don’t see that reversing. Put everything on flash, just in case has become an expensive habit.

So the real question isn’t can a database run on hard disk drives. It’s what level of performance does each part of that database actually need, and what are you willing to pay for it? Nobody can answer that for your workload but you, and you’ll get there by experimenting. What VergeOS gives you is the ability to put each workload on the right tier, and move it again whenever the numbers, or the business, tell you to.

Take the example VM for the math: SQL Server, five drives, 510 GB total. Look at what each drive actually does and the “databases need flash” rule starts to fall apart.

The transaction log is the drive that decides how the app feels. Every commit waits on it, so its latency shows up directly in response time. tempdb is the other flash-hungry one.

The data drive is the one people get wrong. SQL Server pulls pages into its buffer pool in RAM and serves repeat reads from there. If the active working set fits in memory, the data drive mostly sees checkpoint flushes and the occasional cold page. It isn’t idle, but it’s nowhere near the monster everyone pictures. And backups? Big sequential streams are the one job spinning disks have always been great at.

Most HCI platforms treat storage as one cluster-wide pool run by policy, and that’s where the no comes from. VMware’s current direction, vSAN ESA, requires all-NVMe hardware, so HDD isn’t even on the menu. Hybrid designs put a flash cache in front of disk and, by default, let an algorithm decide what stays hot. Some let you pin specific disks to flash, but the starting assumption is that the cache will figure it out. That cache-first design is a big part of why hybrid storage failed the first time.

When the cache guesses wrong, the database eats full HDD latency at a moment nobody picked. So vendors play it safe and spec all-flash for anything that smells like a database. That means paying flash prices for backup files and cold data pages that a spinning disk would serve just fine.

VergeOS builds storage into the same code base as compute and networking, and its built-in vSAN sorts media into six tiers. Three of them matter here:

• Tier 0 holds metadata on enterprise NVMe, so block lookups never wait on a spinning disk, even when the data itself lives on HDD.
• Tier 1 is performance NVMe, where latency-sensitive drives live.
• Tiers 4 and 5 are high-capacity hard drives.

Placement is a per-drive setting called Preferred Tier. In the example, the OS, log, and tempdb drives stay on Tier 1 NVMe, and the backup drive already lives on Tier 4. Moving the data drive is one change:

1. Open the VM and select the data drive.
2. Change its Preferred Tier from 1 to 4 and save.
3. That’s it. VergeOS starts a live, online background migration, and the VM keeps serving queries while the blocks move.

And placement isn’t a one-time decision. Business needs change, so tiers can too. Quarter-end close coming up? Promote the finance database’s data drive to Tier 1 for the crunch, then drop it back to Tier 4 when it’s over. An app launch, an audit, a seasonal spike: same idea. The move runs live in the background, so storage follows the business instead of the other way around.

I ran exactly this kind of move on a live SQL workload and recorded the whole thing. Here’s the honest part about what to measure. Commit latency is the wrong number to brag about, because the transaction log never left NVMe. The numbers that tell you whether the data drive is happy on HDD are read latency on that drive and PAGEIOLATCH waits in SQL Server. Those are the numbers to watch when you try this on your own database, and What Trips People Up below covers what can push them the wrong way.

Same street prices as our last post: $706 per terabyte for a 15.36 TB NVMe SSD, $56 per terabyte for a 24 TB hard drive. On flash, the 200 GB data drive costs $141.20 in raw media. On HDD, it costs $11.20. That’s 92% less for the same bytes.

One Preferred Tier change saved $130 and cut the VM’s media cost roughly in half (49.5%), with 69% of its capacity now on hard disk drives.

A $130 saving is small. That’s the point. This is one modest VM. Every terabyte you move from flash to HDD saves $650 in raw media, and a redundancy scheme that keeps a second copy doubles it. Move 20 TB of cold data files and backups across a cluster and that’s $13,000 in raw media, or $26,000 with the second copy counted. VergeOS licenses per server, so that money stays in your budget instead of feeding a capacity meter.

• A working set bigger than RAM. Heavy OLTP that can’t fit its hot data in the buffer pool reads from the data drive constantly. That drive stays on Tier 1, full stop.
• Maintenance jobs read everything. Index rebuilds, DBCC CHECKDB, and statistics updates scan the data drive end to end. On HDD they take longer, so test your maintenance window, not just your daytime queries.
• Cold starts. After a restart or failover the buffer pool is empty, and the first wave of queries comes off disk. Expect a slower warm-up on HDD.
• Checkpoints are light, but random. Random writes are a spinning disk’s weak spot. Watch write latency on the data drive during checkpoints, not just reads.
• Guessing instead of experimenting. This is the big one. Nobody, me included, can tell you the right tier for your database from a blog post. The move is live and reversible, so treat it as an experiment: move the data drive to Tier 4, watch read latency and wait stats for a week, and move it back if the numbers disagree with you.

The best candidates for HDD: reporting databases, historical and archive databases, dev and test copies, and apps with a small hot set.

A database isn’t a flash workload. It’s a handful of workloads, and each one deserves the level of performance it actually needs, at a price that makes sense. Flash isn’t getting cheaper, so that tradeoff will matter more with every refresh cycle. You’ll have to experiment to find the right balance for your environment, and VergeOS makes that experiment cheap: change a drive’s Preferred Tier, measure, and change it again whenever the business needs something different. Try it Monday, undo it Friday.

George Crump and I did this live: we moved a running VM from flash to hard drives and back, then walked through the refresh math for a real cluster. The full presentation is online now, with every demo included and no registration required. Watch How to Use HCI and Hard Drives to Fight Data Center Inflation.