We Moved a Live SQL Workload from NVMe to Spinning Disk. Here Are the Numbers.

Eight minutes, one SQL Server, and a performance monitor that stays on screen through both migrations.

Presented by David Vincent, Technical Marketing, VergeIO. Roughly eight minutes.

Can you run SQL Server on spinning disk without paying for it in latency? Most storage tiering demos show you the interface rather than the answer. David Vincent moves a live SQL workload across VergeOS tiers, from NVMe down to 10K spinning disk and back, and leaves the throughput and latency graphs running the whole time so you can watch what the move actually does.

Key Takeaways
  • A live SQL workload moves from Tier 1 NVMe to Tier 4 spinning disk with throughput and latency holding flat, since reads are served from RAM cache.
  • At a 10,000 request peak load the application handles about 727 filings per second on NVMe and about 473 on 10K spinning disk, with commit latency under a millisecond on both runs.
  • Tier placement is a volume property an administrator sets. The migration runs through the API in the background and the workload stays online.

What happens when you move SQL Server to spinning disk

The Verge lab runs four tiers in one cluster: Tier 1 NVMe, Tier 2 SAS SSD, and Tiers 4 and 5 on 10K SAS hard drives. Changing a volume’s tier takes one field. Open the drive, set Preferred Tier, submit. TempDB moves from Tier 1 to Tier 4 in seconds.

Then comes the part that matters. The SQL data and log volumes move down to Tier 4 with the monitoring app running, and the latency line holds where it was. A load simulator fires 10,000 filings at a tax application on Tier 1, then repeats the identical run after a migration to Tier 5.

Why SQL Server on spinning disk holds its latency

The Full Session

Can You Afford Your Next Storage Refresh?

George Crump and David Vincent on the first storage refresh in thirty years that prices higher than the original purchase. Available on demand.

Watch the Session

The answer sits in the read path. VergeOS caches the active working set in server memory and in an NVMe read cache. The demo includes an anatomy view of one transaction: the client issues the request, the server checks the pool, finds the page resident in RAM, skips the disk entirely, and returns in 146 microseconds. Tier assignment has no influence on that path.

Most database workloads run read-heavy, commonly around eighty percent reads against twenty percent writes. Those reads come out of the RAM cache rather than off the media, and global inline deduplication lets that cache serve more of the environment from the same memory.

Writes go to the tier the volume currently sits on. The tier therefore governs a minority of the real I/O path, which is why moving a database to spinning disk costs about a third of the throughput rather than falling off a cliff.

Cold reads tell the honest version of the story. A request that misses both RAM and the read cache goes to the media, and spinning disk answers slower than flash. That difference shows up under peak load, and it stays a fraction of the price difference between the two.

Figures come from a single lab run on one workload, shown live in the recording. Read them as the shape of the trade rather than as a benchmark.
MeasureTier 1 NVMeTier 5 10K SAS
Filings per second, peak loadAbout 727About 473
Commit latencyUnder 1 msUnder 1 ms
10,000 filingsAbout 13 secondsAbout 21 seconds at that rate
Single read, RAM hit146 microseconds146 microseconds
Time to change the tierSecondsSeconds
Block migrationBackground, workload onlineBackground, workload online

What this means for a 2026 refresh

Auto-tiering guesses where your data should live. You already know. A tax firm knows in October what April looks like, and the identification algorithm learns that fact weeks late. Tier control turns a capacity purchase into a calendar decision: flash for the busy season, hard drives for the eleven months after it, in the same pool, under the same deduplication.

That matters more this year than it did three years ago. Flash and DRAM prices are climbing into 2027 as the cloud AI build out consumes supply, which makes an all flash refresh the most expensive way to solve a problem the drives in your servers can already solve. The licensing side compounds it, and Storage Switzerland has written about how capacity-based storage licensing breaks the economics of HCI.

The written version of this argument runs in Storage Tiering Is Not the Problem, Losing Control of It Is. To put a number on your own environment, the Refresh Cost Diagnostic is a twenty minute working session and a five page report.

Frequently Asked Questions

Does the workload go offline during a tier migration?

The volume stays online. VergeOS moves the blocks in the background through the API as the application keeps serving requests, and the demo runs a load test across a migration to show it.

How much slower is spinning disk in practice?

In this lab run, peak throughput moved from about 727 filings per second to about 473, with commit latency under a millisecond on both. Your result depends on how much of your working set fits in RAM and read cache, which is the first thing worth measuring.

Can tier assignment be automated?

Preferred Tier is exposed through the API, so the change scripts cleanly against a calendar or a monitoring trigger. Your rules drive it, on your schedule, with a record of what changed.

Do all the servers need matching drives?

Tiers exist wherever drives of that class are installed in the cluster. Nodes can carry different mixes, and capacity grows by adding drives to the servers running the workload.

Watch more videos like this

We Moved a Live SQL Workload from NVMe to Spinning Disk. Here Are the Numbers.

We moved a live SQL database from NVMe to 10K spinning disk with the performance monitor running, and the latency line held where it was. This storage tiering demo puts the numbers on screen: 727 filings per second on flash, 473 on spinning disk, both under a millisecond.
Read More

Kubernetes and VergeOS Demo

VergeIO Principal Engineer David Zarzycki provisions a fresh Kubernetes cluster from inside Rancher, on top of VergeOS, in under three minutes — click to running on a two-core, four-GB lab node. The cluster-create flow proves two things in one motion: Rancher really is the management plane teams already use, and the VergeOS integration ships as standard upstream Kubernetes through three Helm charts in the verge-io Cluster Repository — not a fork, not a proprietary distribution, not a second console.
Read More