NVMe vs SSD Hosting: Real Database Performance Tests

An NVMe label describes a storage interface, not the speed of your application's queries. A database answering from RAM may barely touch the disk, while a busy transactional workload can spend much of its time waiting for durable writes.

Compare hosting plans with a repeatable experiment that measures both storage behavior and database latency. The goal is to learn whether storage is your bottleneck and whether the offered NVMe plan improves the workload enough to justify a migration.

Separate transfer speed from query latency

Start with workload shape: data size, hot working set, query mix, concurrency, and durability requirements. Small indexed reads often behave differently from broad scans, temporary-table spills, and commits that require synchronization. A faster sequential read benchmark cannot predict all these cases.

Use the Bandwidth & Transfer Time Calculator below to estimate how long a database export or backup will take to move between hosts. It helps plan the migration window, not predict queries per second. Network throughput can dominate a move even when local storage is fast.

List the limits of both candidates: vCPU count, RAM, storage capacity, region, advertised IOPS ceilings, and burst policies. Cloud disks may use remote or shared storage despite the plan's branding. Consult the provider's infrastructure documentation, such as DigitalOcean documentation, for the specific product's constraints.

Treat interface names and marketing language as clues rather than proof. Observed latency under your workload is the useful comparison. Also record filesystem, database version, and whether encryption or backups add competing I/O during testing.

Build a disposable, comparable test environment

Use isolated benchmark instances, never a production database host. Both candidates should have equivalent CPU and RAM where possible, identical database versions, and matching configuration. Restore the same sanitized snapshot or generate the same synthetic dataset. Keep customer information and real credentials out of test systems.

Document durability settings. Comparing a database that synchronizes each transaction with one that defers durable writes creates a misleading storage result. Check engine-specific settings against the MySQL documentation or MariaDB documentation, depending on the actual server.

Record buffer-pool size, binary logging, connection count, and isolation level. Stop unrelated scheduled jobs only in the disposable environment and note that decision. Real production performance will include backup activity, monitoring, and noisy neighbors that a quiet benchmark may miss.

Choose a representative data footprint

Run one dataset that fits comfortably in the database cache and another whose active working set exceeds it, if your budget allows. Dataset size alone is not enough: a huge database with a tiny hot index can still behave like a memory-resident workload.

Use the same random-access pattern and concurrency on both hosts. Keep the benchmark driver separate if client CPU becomes saturated, and place it consistently so network differences do not masquerade as disk differences.

Measure file I/O safely before testing queries

Install fio on the disposable machine and choose a scratch directory on the filesystem actually used for database storage. Confirm enough free space and permission first. The following command creates or overwrites a dedicated test file; never point it at a raw device or a database file:

mkdir -p /var/tmp/storage-bench
fio --name=db-random-read   --filename=/var/tmp/storage-bench/fio-test.dat   --size=2G --rw=randread --bs=16k   --ioengine=libaio --direct=1 --iodepth=1   --runtime=60 --time_based --group_reporting

The test file may require initialization before measurement; disregard setup time when interpreting the timed workload. Verify that this scratch directory is on the intended mount. Direct I/O reduces filesystem page-cache effects where supported, but it does not eliminate device caches or recreate database behavior.

Inspect average and percentile completion latency alongside IOPS. Increase queue depth in a separate run only if the real workload produces comparable outstanding I/O. High queue-depth throughput can look impressive while single-request latency remains poor. Do not generalize a read-only test to durable transaction commits.

Repeat the run several times and inspect whether performance degrades after an initial burst. A single short sample can measure temporary credits rather than sustainable capacity. Remove only the named scratch file when finished, after confirming no test process is using it.

Run an explicit database workload

On a disposable MySQL-compatible instance with sysbench installed, create a dedicated database and least-privilege benchmark user. Put its credentials in a protected client configuration file rather than the command line. This example uses sysbench's standard OLTP read/write script and its --config-file option:

# /home/bench/sysbench.conf; restrict permissions to the bench user
mysql-host=127.0.0.1
mysql-user=bench
mysql-password=<BENCHMARK_PASSWORD>
mysql-db=bench

Prepare once, then run the same command sequence on each candidate:

chmod 600 /home/bench/sysbench.conf
sysbench --config-file=/home/bench/sysbench.conf   oltp_read_write --tables=8 --table-size=100000 prepare
sysbench --config-file=/home/bench/sysbench.conf   oltp_read_write --tables=8 --table-size=100000   --threads=8 --time=120 --report-interval=10 --percentile=95 run
sysbench --config-file=/home/bench/sysbench.conf   oltp_read_write --tables=8 --table-size=100000 cleanup

Cleanup removes benchmark tables, so check the database name carefully. Consult the sysbench project for installation and available workloads. These inputs are illustrative test parameters, not a recommended production sizing formula.

Repeat at low concurrency and at your expected busy concurrency. Capture transaction throughput, reported percentile latency, errors, CPU utilization, and I/O wait. Compare early intervals with later intervals for cache warming. Restarting a database does not necessarily empty operating-system or storage caches, so label such tests honestly rather than calling them fully cold.

Interpret results before paying for an upgrade

If both hosts perform similarly when warm but diverge with a larger active working set, storage may matter primarily during cache misses. If CPU is saturated and disk wait stays low, faster disks may not help. Profile expensive queries before buying a different storage label.

Use the low-RAM database tuning guide to investigate memory pressure, and the hosting speed audit to connect database timings to user-visible behavior. Application latency also includes PHP, network paths, external APIs, and response generation.

Return to the transfer-time calculator with the measured backup size and achievable upload speed. Add restore, index-building, validation, and replication catch-up time separately. Migration transfer time is only one part of the outage or cutover budget.

Keep raw results and configuration notes. Prefer consistent gains across repeated trials over one exceptional run, and retest under normal background activity before moving real traffic.

Finally, compare operational guarantees alongside the measurements. A faster disk with weak recovery options may be a poor trade for a store that needs reliable restoration. Verify snapshots, replacement procedures, monitoring visibility, and capacity expansion before selecting the destination. Benchmark speed is valuable only when the surrounding service can support the application reliably.

Key takeaways

• Compare matching workloads and durability guarantees, not storage labels alone.
• Separate memory-resident queries, disk-dependent reads, and durable writes.
• Use disposable data and inspect latency percentiles as well as throughput.
• Measure migration networking independently from local storage performance.
• Upgrade when repeatable evidence identifies storage as a meaningful bottleneck.