Pythian Blog: Technical Track

Improving Backup efficiency on SQL Server 2025 with the new ZSTD algorithm

Native backup compression was introduced in SQL Server 2008 and was a game changer as it reduced the data space requirements for any backup operation issued in the Instance. It is even considered a Best Practice to keep the “Compress Database Backup” flag always enabled at the Instance level.

Up until version 2022, SQL Server uses the MS_XPRESS algorithm to natively compress a backup. In version 2025 Microsoft allows DBAs to use the ZSTD algorithm as well.

Why it matters

Having options and controlling the backup operation granularity can be a game changer when:

  • The Backup window is limited;
  • CPU usage might be an issue;
  • (if using compression) Data space requirements are challenging.

Bear in mind that any compress operation will save space and will increase CPU usage as it requires extra cycles to “process” the compress operation.

How to use it?

This parameter is only accessible via T-SQL, there's no extra option added in SSMS to use it. Therefore, we need to use the option ALGORITHM = ZSTD and choose which LEVEL we want the algorithm to consider, either LOW (default), MEDIUM or HIGH on the COMPRESSION option of the BACKUP command.

BACKUP DATABASE ourcooldatabasenamehere

TO DISK = N’LOCATION’

WITH COMPRESSION (ALGORITHM = ZSTD, LEVEL = MEDIUM);

 


A typical Backup operation using T-SQL specifying the Compression options.

Comparing the different options

It is time to get into the test results and all the details of the comparison results when executing a FULL Backup of the same database. 

The target database size is 50 GB. To have a fair enough comparison nothing was executed other than the Backup operation while the tests were running (except the regular O.S. background tasks), the average CPU utilization before each Backup operation was about 2%.

First test: Backing up to the D: drive.

The full specs of the system used are detailed in the following section. In this test a regular backup vanilla backup operation was performed with each Compression option generating a different file for each (there's no way to combine backup sets that were generated using different compression options and levels in the same file).

Compression 

Time elapsed

Throughput

CPU usage

File size

None

24 s

1882 MB/s

4%

50 GB

MS_XPRESS

4 min 30 s

179 MB/s

17%

13.8 GB

ZSTD Low

2 min 10 s

362 MB/s

15%

13.5 GB

ZSTD Medium

3 min 30 s

226 MB/s

15%

11 GB

ZSTD High

18 min 10 s

43 MB/s

11%

10.4 GB

 

Backup file space usage for each distinct operation.

Second test: Backing up to ‘NUL’

Essentially a dummy backup, just to rule out any kind of I/O bottleneck. Other than for benchmarking, there's no real usage for that type of backup operation.

Compression 

Time elapsed

Throughput

CPU usage

None

11 s

4124 MB/s

2%

MS_XPRESS

4 min 30 s

179 MB/s

15%

ZSTD Low

2 min 10 s

357 MB/s

13%

ZSTD Medium

3 min

265 MB/s

12%

ZSTD High

17 min 30 s

45 MB/s

11%



System specs

  • Intel CPU 13th Gen Core i7-13700HX Base speed: 2.1 GHz (16 cores with 24 logical processors)
  • 64 GB of RAM
  • Storage: SSD M2 Samsung EVO 990 PRO 2 TB

Verifying and testing the Backup file

By using the RESTORE HEADERONLY command we're able to identify which algorithm was used in theBackup with Compression operation. The column we're looking for is called CompressionAlgorithm. There's no way to verify (yet) which mode of operation was selected when using the ZSTD operation though. 

 

Does my Backup file work?

Essentially, there’s no way to fully validate the usefulness of a Backup file unless it is restored.

In this case we tested the Restore operation with the file that was generated from ZSTD Low compression as a source - worked with no issues, as expected.

Restoring a Backup file that is compressed by the brand new ZSTD algorithm.

Conclusion

It is clear that the ZSTD algorithm provides an updated and more optimized approach to natively compressing a SQL Server backup.

While the resulting file size is barely the same between the regular MS_XPRESS algorithm and the LOW mode in ZSTD (approximately 13 GB), we can see that CPU usage is a bit lower (15% against 17%), throughput is higher (362 MB/s against 179 MB/s) and time is almost half (2 against 4 minutes).

If we are looking for even better numbers the ZSTD MEDIUM mode can be leveraged, time and CPU usage are still lower than the regular MS_XPRESS algorithms. This mode seems to be the go to choice when looking for a balanced backup compression performance, resource usage and data space savings.

Lastly, if time is not a problem, the ZSTD HIGH mode provides the highest compression savings while resource usage is lower but takes a long time to complete (much slower than the regular MS_XPRESS mode).

In conclusion, by adding the ZSTD algorithm for compressing backups Microsoft allows DBAs to further improve their Backup routines while saving on resources like CPU and disk usage. As DBAs, we love having options! (the more knobs the better!).

Needless to say results will vary and will be different in YOUR environment, make sure you test and validate thoroughly and extensively before implementing changes to your Production environment. 

The listing below shows the compiled results:

File Size (GB)

MS_XPRESS   | ████████████████ 13

ZSTD LOW    | ████████████████ 13

ZSTD MEDIUM | ██████████████   ~12.5

ZSTD HIGH   | ████████████     Smallest

 

CPU Usage (%)

MS_XPRESS   | ██████████████   17

ZSTD LOW    | ████████████     15

ZSTD MEDIUM | ███████████      <17

ZSTD HIGH   | █████████        Lower

 

Throughput (MB/s)

MS_XPRESS   | ████████         179

ZSTD LOW    | ██████████████   362

ZSTD MEDIUM | ███████████      >179

ZSTD HIGH   | ███              Slower

 

Backup Time (min)

MS_XPRESS   | ███████          4

ZSTD LOW    | ███              2

ZSTD MEDIUM | ████             <4

ZSTD HIGH   | █████████████    Much longer

 

Scripts

You can use this set of scripts to execute the tests in your own environment. Needless to say that we are absolutely not responsible for any results or issues that you may encounter when executing them.

--Backups to disk




--Backup with no compression

BACKUP DATABASE StackOverflow50

TO DISK = N'd:\temp\StackOverflow50_nocompress.bak'

WITH STATS=5,NO_COMPRESSION;




--Backup with default compression (MS_XPRESS)

BACKUP DATABASE StackOverflow50

TO DISK = N'd:\temp\StackOverflow50_msxpress.bak'

WITH STATS=5,COMPRESSION;




--Backup with ZSTD Low compression (default for ZSTD)

BACKUP DATABASE StackOverflow50

TO DISK = N'd:\temp\StackOverflow50_zstd_low.bak'

WITH STATS=5,COMPRESSION (ALGORITHM = ZSTD, LEVEL = LOW);




--Backup with ZSTD Medium compression 

BACKUP DATABASE StackOverflow50

TO DISK = N'd:\temp\StackOverflow50_zstd_medium.bak'

WITH STATS=5,COMPRESSION (ALGORITHM = ZSTD, LEVEL = MEDIUM);




--Backup with ZSTD High compression 

BACKUP DATABASE StackOverflow50

TO DISK = N'd:\temp\StackOverflow50_zstd_high.bak'

WITH STATS=5,COMPRESSION (ALGORITHM = ZSTD, LEVEL = HIGH);




--Backup to NUL (removing I/O bottleneck from the benchmark)




--Backup with no compression

BACKUP DATABASE StackOverflow50

TO DISK = N'NUL'

WITH STATS=5,NO_COMPRESSION;




--Backup with default compression (MS_XPRESS)

BACKUP DATABASE StackOverflow50

TO DISK = N'NUL'

WITH STATS=5,COMPRESSION;




--Backup with ZSTD Low compression (default for ZSTD)

BACKUP DATABASE StackOverflow50

TO DISK = N'NUL'

WITH STATS=5,COMPRESSION (ALGORITHM = ZSTD, LEVEL = LOW);




--Backup with ZSTD Medium compression 

BACKUP DATABASE StackOverflow50

TO DISK = N'NUL'

WITH STATS=5,COMPRESSION (ALGORITHM = ZSTD, LEVEL = MEDIUM);




--Backup with ZSTD High compression 

BACKUP DATABASE StackOverflow50

TO DISK = N'NUL'

WITH STATS=5,COMPRESSION (ALGORITHM = ZSTD, LEVEL = HIGH);




------------------------------------------------------------------------------




--Restore operations




--checking Backup file header information




RESTORE HEADERONLY FROM DISK = N'd:\temp\StackOverflow50_nocompress.bak';




--Backup with default compression (MS_XPRESS)

RESTORE HEADERONLY FROM DISK = N'd:\temp\StackOverflow50_msxpress.bak';




--Backup with ZSTD Low compression (default for ZSTD)

RESTORE HEADERONLY FROM DISK = N'd:\temp\StackOverflow50_zstd_low.bak';




--Backup with ZSTD Medium compression 

RESTORE HEADERONLY FROM DISK = N'd:\temp\StackOverflow50_zstd_medium.bak';




--Backup with ZSTD High compression 

RESTORE HEADERONLY FROM DISK = N'd:\temp\StackOverflow50_zstd_high.bak';





--Restore database to validate the Backup file




RESTORE FILELISTONLY FROM DISK = N'd:\temp\StackOverflow50_zstd_low.bak';




--RESTORE with ZSTD Low compression (default for ZSTD)

RESTORE DATABASE StackOverflow50_zstdlow 

FROM DISK = N'd:\temp\StackOverflow50_zstd_low.bak'

WITH STATS=5,

MOVE 'StackOverflow2013_1' TO 'D:\SQLINSTALL\MSSQL17.SQL202520\MSSQL\DATA\StackOverflow2013_zstdlow_1.mdf',

MOVE 'StackOverflow2013_2' TO 'D:\SQLINSTALL\MSSQL17.SQL202520\MSSQL\DATA\StackOverflow2013_zstdlow_2.mdf',

MOVE 'StackOverflow2013_3' TO 'D:\SQLINSTALL\MSSQL17.SQL202520\MSSQL\DATA\StackOverflow2013_zstdlow_3.mdf',

MOVE 'StackOverflow2013_4' TO 'D:\SQLINSTALL\MSSQL17.SQL202520\MSSQL\DATA\StackOverflow2013_zstdlow_4.mdf',

MOVE 'StackOverflow2013_log' TO 'D:\SQLINSTALL\MSSQL17.SQL202520\MSSQL\DATA\StackOverflow2013_zstdlow_log.ldf'

;

 

References

 

No Comments Yet

Let us know what you think

Subscribe by email