SQL Server 2025: Using ZSTD Compression for SQL Server Backups

SQL Server 2025 introduces a new compression algorithm, ZSTD (Zstandard), which can help with database backup performance. The implementation of ZSTD gives you more control over your backup performance in terms of CPU consumption and backup runtime. I recently ran some rough benchmarks comparing ZSTD, and its three compression levels, with the existing MS_XPRESS algorithm, and the results are compelling and give you some additional tools for managing performance for database backups.

The Test Setup

I set up two types of tests on a 389.37GB database to highlight the performance characteristics of the backup compression algorithms:

  1. Performance Isolation Tests: First, I isolated the compression algorithm performance by writing backups to a NUL device, allowing precise measurement of read and compression performance without storage write variables. These tests compared:
    • No compression (NONE) - establishing a baseline
    • The established MS_XPRESS algorithm available in previous versions
    • The newly introduced ZSTD algorithm at its default LOW setting

  1. Real-World Performance Tests: Then, I ran complete backups to S3 storage on a Pure Storage FlashBlade to evaluate real-world performance characteristics. These tests compared:
    • No compression (NONE) as a baseline reference
    • MS_XPRESS (the standard option in previous versions of SQL Server)
    • ZSTD LOW (default setting)
    • ZSTD MEDIUM
    • ZSTD HIGH

Compression Speed Results Writing to NUL

When measuring raw compression performance by writing to a NUL device:

Algorithm Time (seconds) Speed (MB/sec) Average CPU %
NONE 94.9 4195.7 7.0
ZSTD 213.3 1867.1 52.9
MS_XPRESS 428.7 929.0 67.8

The results reveal some interesting findings:

  • NONE (no compression) completes performs 4x faster than MS_XPRESS with minimal CPU usage (7.0%). This represents the throughput ceiling for single-threaded reads on this SQL Server instance, but it provides none of the data reduction benefits of compression.

  • ZSTD the backup finishes in half the time when compared to MS_XPRESS, achieving nearly double the throughput while using less CPU (52.9% vs 67.8%). This default LOW compression level shows ZSTD’s superior efficiency in terms of CPU consumption and backup runtime.

  • MS_XPRESS has the slowest performance with the highest CPU utilization, demonstrating why SQL Server 2025’s new compression options are valuable.

The results above are throughput measured with one reader and four writer threads. We can’t measure backup file set size with this test since we’re writing to NUL specifically to isolate the performance of the compression algorithms.

Real-World Backup Results Writing to S3

Testing with actual backups shows the trade-offs between compression levels:

Compression Method Backup Set Size (GB) Time (seconds) Speed (MB/sec) Average CPU %
NONE 389.37 259.8 1532.7 34.6
MS_XPRESS 218.95 441.4 902.4 84.6
ZSTD LOW (Default) 266.97 245.7 1621.1 80.1
ZSTD MEDIUM 210.76 603.1 660.4 83.2
ZSTD HIGH 209.38 1112.5 358.0 85.4

The results reveal some trade-offs:

  • NONE (no compression) provides the second fastest runtime after ZSTD LOW with minimal CPU utilization (34.6%), but results in the largest backup set size (389.37 GB). This represents the baseline for comparing the compression benefits of other algorithms.

  • ZSTD LOW offers an interesting middle ground between NONE and MS_XPRESS. Compared to NONE, it achieves significant space savings (31% smaller backups) while maintaining similar performance (actually running 5% faster). When compared with MS_XPRESS, ZSTD LOW completes in nearly half the time (44% faster) with comparable CPU utilization (80.1% vs 84.6%), though it produces larger backup files (266.97GB vs 218.95GB). This makes ZSTD LOW an excellent choice when backup windows are tight but you still need reasonable compression. The speed improvement is substantial enough that many organizations can justify the additional storage costs, especially in environments where compute resources are more constrained than storage resources.

  • ZSTD MEDIUM produces smaller backups than MS_XPRESS (about 4% smaller) but takes 37% longer. This might be suitable for environments where storage costs outweigh backup window concerns or archive backups.

  • ZSTD HIGH offers minimal additional compression over ZSTD MEDIUM (less than 1%) but takes almost twice as long. This extreme setting is likely only useful in very specific scenarios where every gigabyte matters.

This is me testing in my lab with one database. Your mileage will certainly vary for your database’s contents and infrastructure.

Practical Implications

For most environments, ZSTD LOW appears to offer the best balance of speed improvement without significantly impacting backup windows but at the expense of a slightly larger backup set size.

It’s particularly valuable for:

  • Large databases with tight backup windows
  • Systems where CPU resources are a concern, you can now more easily control CPU impact than in the past with Resource Governor.
  • Environments where backup speed is more critical than storage efficiency

For backups where time is less critical, ZSTD MEDIUM only has a nominal improvement over MS_XPRESS and ZSTD HIGH provided little benefit in terms of storage efficiency and CPU utilization.

Conclusion

SQL Server 2025’s ZSTD compression algorithm represents a much needed step forward in database backup technologies and tuning. The default LOW setting gives you impressive performance gains that will benefit most environments. As always, testing with your specific workloads is recommended to determine the optimal configuration.

For more details on ZSTD compression in SQL Server 2025, check out Microsoft’s official blog post.