Optimizing MySQL Performance on Hetzner Cloud vs AWS: A Deep Dive into Storage Choices

MySQL performance in production is often constrained by disk I/O characteristics, particularly with small random reads/writes and latency. When choosing cloud infrastructure to host MySQL, understanding the underlying storage capabilities is vital to ensure throughput and responsiveness align with workload demands.

This guide unpacks the key differences between Hetzner Cloud and AWS storage options, focusing on how local NVMe SSDs and network-attached volumes impact MySQL workloads. You’ll learn to evaluate performance tradeoffs, select appropriate storage, and tune deployments for optimal MySQL I/O efficiency.

What You’ll Master

• Differences between Hetzner Cloud Volumes and local NVMe SSDs
• Comparing Hetzner NVMe SSDs with AWS EBS gp3 and io2 volumes
• Choosing and configuring storage to maximize MySQL IOPS and throughput

Why This Matters

MySQL, especially for OLTP-heavy workloads, depends critically on fast, low-latency random I/O. Suboptimal storage can bottleneck transactions, slowing query response and concurrency. Hetzner Cloud offers economical options but has significant differences in storage architecture compared to AWS:

• Hetzner Cloud Volumes are network-attached block storage with triple replication but limited IOPS (~5,000 max) and practical random write throughput often below 500 IOPS.
• Local NVMe SSDs on Hetzner deliver much higher raw I/O performance (30k+ IOPS), saturating PCIe lanes for parallel I/O — however, they are only available on specific instance plans and are not yet offered in U.S. regions.
• AWS offers flexible EBS volumes, from gp3 baseline to high-performance io2 Block Express with tens of thousands of IOPS and guaranteed sub-millisecond latency — configurable with cost tradeoffs.

Understanding these tradeoffs directly impacts how well MySQL runs in each environment and what configurations will drive predictable performance.

Prerequisites and Setup

Before diving into performance tuning and benchmarking MySQL, ensure you have:

• Access to a Hetzner Cloud account with instance types supporting local NVMe SSDs (available only on certain dedicated or cloud server families, primarily in EU data centers such as Falkenstein and Helsinki).
• Access to AWS with permissions to provision EBS volumes (gp3 and io2) and EC2 instances with instance-store or EBS-backed storage.
• Basic Linux command-line familiarity, MySQL 8.x installed, and a benchmarking tool like fio or sysbench for I/O tests.
• MySQL configured with appropriate tuning for I/O performance (e.g., InnoDB parameters, buffer pool size).

# Example: Installing fio for benchmarking on Linux
sudo apt update && sudo apt install -y fio
 
# Verify MySQL version
mysql --version
 
# Sample MySQL tuning for InnoDB on 8GB RAM (adjust per host)
# Edit /etc/mysql/my.cnf or /etc/mysql/mysql.conf.d/mysqld.cnf
# Add or modify:
# innodb_buffer_pool_size=4G
# innodb_log_file_size=512M
# innodb_flush_method=O_DIRECT
# innodb_flush_log_at_trx_commit=1
 
sudo systemctl restart mysql

Implementation Steps

1. Understand Storage Types and Their IOPS Characteristics

• Hetzner Cloud Volumes
  Network-attached, with triple replication across servers, optimized for data availability over raw speed. Official specs cap sustained IOPS at 5,000 and throughput at 200 MB/s, but practical random write tests show ~300 IOPS on 4K write workloads.
• Hetzner Local NVMe SSDs
  Directly attached via PCIe (~32 Gbps), designed for parallelism and high throughput. Benchmarks report 30,000+ 4K IOPS and ~1,100 MB/s sequential throughput.
  Note: Available only on specific server types (e.g., CPX and AX series) and limited to European data centers — Hetzner currently has no U.S. data center presence, making this option geographically constrained.
• AWS gp3 Volumes
  Default baseline 3,000 IOPS and 125 MB/s throughput, provisionable up to 16,000 IOPS and 1,000 MB/s with added cost.
• AWS io2/io2 Block Express Volumes
  High-end with tens of thousands of IOPS, consistent sub-millisecond latencies, and scaling up to hundreds of thousands of IOPS for mission-critical workloads.

2. Benchmark Storage Performance Using fio

Run a controlled fio job with 4K random writes to quantify IOPS and throughput per storage type.

[4k-randwrite]
ioengine=libaio
iodepth=16
rw=randwrite
bs=4k
direct=1
size=4G
numjobs=1
runtime=60
group_reporting

Run this command on both a Hetzner Cloud Volume and a local NVMe disk:

sudo fio fio-4k-randwrite.fio --filename=/dev/sdX

Expected Results:

3. Configure MySQL on Hetzner for Optimal Storage Use

Prefer local NVMe SSDs over Cloud Volumes for high IOPS workloads:

• Deploy Hetzner VM or dedicated server with NVMe SSDs (AX series or CPX with NVMe disks).
• Mount NVMe devices with noatime and discard options to reduce overhead.
• Tune InnoDB parameters as per available memory and storage latency.
• For Cloud Volumes, limit workload or use caching layers (e.g., ProxySQL, buffer pools) to mitigate I/O constraints.

4. On AWS, Select Storage According to Performance Needs and Cost

• For moderate workloads, gp3 volumes offer reasonable performance and cost.
• For heavy OLTP, provision io2 Block Express volumes or consider instance-store SSDs on suitable EC2 instances.
• Utilize Amazon RDS or Aurora for managed MySQL with autoscaling, optimized storage, and IO offload.

5. Monitor and Adjust Based on Workload Characteristics

Use iostat, vmstat, and MySQL performance schema to monitor I/O wait, throughput, and latency live:

iostat -x 1
vmstat 1
mysql -e "SELECT * FROM performance_schema.file_summary_by_instance WHERE FILE_NAME LIKE '/dev/%';"

Adjust buffer pool size and commit frequency to balance durability and throughput.

Advanced Tips or Optimization

• Hetzner Cloud Volumes carry network and replication overhead causing unpredictable latency spikes. Consider using NVMe SSDs with RAID configurations for fault tolerance without network latency.
• AWS io2 Block Express volumes guarantee latency SLAs (~sub-millisecond), crucial for ultra-low-latency MySQL use cases.
• Using local instance-store SSDs in AWS compromises durability unless combined with replication or backups but offers the lowest latency.
• Always complement storage benchmarking with realistic MySQL load testing, such as sysbench OLTP benchmarks.

Conclusion

This guide detailed the critical impact of storage choice on MySQL’s I/O performance, comparing Hetzner Cloud Volumes, local NVMe SSDs, and AWS EBS variants. Hetzner’s local NVMe is a strong, cost-efficient contender for moderate to high I/O workloads — if available in your region — but currently limited to European data centers and select plans. In contrast, AWS’s provisioned IOPS and managed services provide scalable, globally available, ultra-low-latency solutions for mission-critical deployments.

To get the most from your MySQL deployments:

• Prefer Hetzner’s NVMe SSD plans for high-performance needs, if your workloads are EU-based.
• Benchmark with your production workload to inform decisions.
• Leverage AWS’s managed offerings if you need consistent performance and global presence.

Apply these insights to design MySQL infrastructure tuned to both your workload and geographic needs.