SQL Server 2025 gives you new backup compression algorithms that can dramatically reduce backup size and I/O — often without increasing CPU load.
The “best” algorithm isn’t universal. It depends on your data, your hardware, and your restore-time requirements. The only correct approach is to test:
– How each algorithm affects backup size
– How it affects backup throughput
– How it affects restore speed
– How it impacts CPU usage during both backup and restore
SQL Server 2025 supports:
– **MS_XPRESS** — classic, fast, low CPU
– **QAT** — hardware-accelerated (requires Intel QAT hardware)
– **ZSTD** — modern, higher compression, tunable levels (LOW / MEDIUM / HIGH)
Compression level affects restore time. Higher compression = smaller files = faster I/O = often faster restores, even though decompression uses more CPU. The only way to know the right choice for your environment is to benchmark it.
Durations differ: 6sec to 1mi17, Size 10gb to 2gb.
The full StackOverflow.
And how about cpu usage? ( erikdarlingdata/PerformanceMonitor: Free, open-source SQL Server performance monitoring — 32 collectors, real-time alerts, graphical plan viewer, MCP server for AI analysis. Supports SQL 2016-2025, Azure SQL, AWS RDS. )
Restores look like this, NO_COMPRESSION is fast, ZSTD_HIGH takes 17 seconds longer to restore, but check the sizes of the backup files!
RESTORE DATABASE [StackOverflow_ZSTD_HIGH]
FROM DISK = N'D:\backups\StackOverflow_ZSTD_HIGH_20260519_105836.bak'
WITH REPLACE,
MOVE N'StackOverflow_1' TO N'D:\databases\StackOverflow_ZSTD_HIGH_1.mdf',
MOVE N'StackOverflow_2' TO N'D:\databases\StackOverflow_ZSTD_HIGH_2.ndf',
MOVE N'StackOverflow_3' TO N'D:\databases\StackOverflow_ZSTD_HIGH_3.ndf',
MOVE N'StackOverflow_4' TO N'D:\databases\StackOverflow_ZSTD_HIGH_4.ndf',
MOVE N'StackOverflow_log' TO N'D:\databases\StackOverflow_ZSTD_HIGH_log.ldf',
STATS = 10;
