Databases are write-heavy and latency-sensitive, so the best RAID minimises the write penalty and keeps latency predictable — which almost always means RAID 10 on flash. Size it in the RAID 10 calculator.
Why RAID 10 wins for databases
Transactional databases (SQL Server, Oracle, PostgreSQL, MySQL) issue lots of small random writes — commits, log flushes, index updates — and care deeply about latency. Parity RAID's write penalty (×4 RAID 5, ×6 RAID 6) directly throttles that, while RAID 10's ×2 penalty roughly doubles write IOPS and keeps latency predictable.
RAID 10 also rebuilds fast (mirror copy, no parity recompute), so performance stays high during a failure — important for an always-on database. The trade-off is 50% capacity, which databases usually justify.
Flash, and separating workloads
Use SSD/NVMe — databases are IOPS- and latency-bound, and flash removes the seek bottleneck. Classic practice separates data files, transaction logs and tempdb onto different volumes so sequential log writes don't contend with random data I/O; on a modern all-flash array this matters less but is still good hygiene for the busiest systems.
On ZFS, use mirror vdevs (not RAIDZ) for database datasets — a RAIDZ vdev only gives one drive's random IOPS. Tune recordsize/volblocksize to the database's block size (see ZFS tuning).
Sizing and protection
Size by peak write IOPS plus headroom, and confirm the delivered write IOPS in the calculator — compare RAID 10 against RAID 6 to see the penalty difference on your drives. For tier-0 databases, all-NVMe arrays (NetApp, Pure, HPE Alletra) are the enterprise route — our finder sizes them.
And databases above all need backups and point-in-time recovery — RAID protects the disk, not the data. See RAID is not a backup.