Late answer stating an obvious thing, but... not all SQL database loads are equal.
For read-heavy workloads, increasing RAM probably is the most valuable path, followed by using fast NVMe disks (even consumer-level ones). The reason is simple: reads can be easily cached in RAM, which is much faster than any block devices.
Write-centric workloads are different. While writes can (and are) cached, persistency needs to write things to disks. A basic INSERT
or UPDATE
with autocommit
will create many synchronous IOPs which returns only after data was actually writes to stable storage. This kind of load requires fast block devices and, more importantly, ones designed to be fast for synchronous requests - which generally means "enterprise SSD drives and/or RAID controllers equipped with powerloss protected writeback cache".
The last point is a key difference between consumer-level and enterprise-level SSDs: even when the former can sustain +1M 4K "normal" (async) writes, they often struggle to provide 500 4K sync writes. Enterprise SSDs equipped with persistent write cache can ignore the "cache flush" command, providing much higher synch write performance.
Finally, a note about the RAID level to choose. When dealing with HDDs do not even consider RAID5 (due to reliability issues) and do not use RAID6 unless using an high-end controller with plenty of persistent cache, and avoid it altogether if you space requirement are satisfied by RAID10.
When using fast NVMe drives, parity RAIDs become more applicable. But for the highest performance, again select RAID10.