Mitigating ZFS Write Amplification via ZFS Recordsize Optimization for Database Workloads

Technical Briefing | 7/6/2026

In high-transaction environments, ZFS performance often hits a wall due to write amplification caused by mismatched record sizes. When the ZFS recordsize differs significantly from the block size of the underlying database engine, the filesystem performs excessive metadata operations and partial writes, which degrade IOPS and wear out NAND flash storage. By aligning the ZFS recordsize with the database page size, administrators can achieve significant performance gains and extend the longevity of NVMe drives.

Identifying Misalignment Risks

The default ZFS recordsize of 128K is optimal for general file storage but disastrous for typical database workloads like PostgreSQL or MySQL, which usually operate on 8K or 16K pages. Every write operation that does not fill a full ZFS record forces a read-modify-write cycle, essentially doubling the I/O load on your storage subsystem.

zfs set recordsize=16k tank/databases/postgresql
zfs set xattr=sa atime=off tank/databases/postgresql

• Lower latency for synchronous write operations
• Reduction in wear on solid-state drives due to aligned writes
• Improved hit rates for the Adaptive Replacement Cache
• Lower CPU overhead for checksum calculation

Best Practices for Implementation

When tuning, ensure that the recordsize property is adjusted at the specific dataset level where the database files reside, not the pool root. It is also critical to disable access time updates and utilize the SA (System Attribute) feature to store small attributes directly in the inode, which further reduces I/O pressure on the metadata layer.

By aligning your filesystem parameters to match your application’s data access patterns, you create a more predictable storage environment. Testing these changes on a staging dataset before applying them to production ensures that the performance gains match your specific I/O profile requirements.