Accelerated Database Recovery (ADR) was introduced in SQL Server 2019. Its main purpose is to allow for faster database recovery in the event of a crash or unexpected shutdown. Traditionally, the database engine handles crash recovery through a series of phases—analysis, redo, and undo—which can be inefficient and slow, especially when dealing with long-running transactions.
To make a long story short, ADR “shortcutsˮ the recovery process by introducing a new approach to handling undo operations. Instead of relying heavily on scanning the transaction log—which can be painfully slow for uncommitted or long-running transactions—ADR maintains a version store within the user database to track row-level changes. This allows SQL Server to quickly roll back uncommitted transactions without scanning the entire log. The result is much faster crash recovery, quicker rollbacks, and improved overall database availability, particularly in high-transaction environments.
Accelerated Database Recovery Through the Years
As I mentioned, ADR was introduced in SQL Server 2019, and in SQL Server 2022, there were some major enhancements made to the database scoped configuration, mainly by improving the functionality and behavior of the persistent version store (VPS).
What’s New in SQL Server 2025?
Starting with SQL Server 2025, we now have the opportunity to utilize Accelerated Database Recovery (ADR) in tempdb. Historically, this was only available as a user-database scoped configuration. ADR can benefit tempdb by enabling instantaneous transaction rollback and more aggressive log truncation. This is especially useful in scenarios where long-running or misbehaving transactions involving temp tables or table variables put excessive pressure on tempdb and its transaction log.
Default Blame Acceptors (DBAs) Beware
While it’s tempting to enable this feature right away, it’s probably wise to give it some time to mature before rolling it out in production when SQL Server 2025 becomes more widely available. Microsoft has called out a known issue related to ADR in tempdb, but oddly enough, they mention it in a separate article rather than in the main documentation (in my opinion, that kind of warning deserves front-and-center placement).
The gist is: enabling ADR in tempdb, especially in environments where temp tables are being rapidly created and dropped or truncated, can cause SQL Server performance problems. Specifically, there’s potential for significant throughput degradation due to latch contention on the sys.sysobjvalues internal system table. Microsoft is currently investigating this and plans to address it in a future release.
Another Nuance to Be Aware of: Disk Footprint
Just like user databases, ADRʼs Persistent Version Store (PVS) is created within tempdbʼs data files. If your server has queries that heavily utilize temp tables, you might need to account for this by adding significantly more tempdb space and faster drives to hold those extra row versions. This is probably where youʼll want to tinker with the ADR Cleaner Thread Count sp_configure setting that can boost the cleaner (the asynchronous process that cleans up page versions that arenʼt needed in PVS) from a single threaded to multi-threaded process.
What to do While We Wait for SQL Server 2025
Considering the fact that we should let this feature bake in for a while before we start to implement it in our environments, it would be worth our while to make sure that tempdb is configured to best practices before we start making configuration changes. The free tool sp_CheckTempdb was written by Straight Pathʼs very own Jeff Iannucci and was designed for this very purpose. Itʼs a quick and easy “deploy and runˮ stored procedure that analyzes your SQL Serverʼs tempdb configuration and provides meaningful recommendations along with identified issues regarding the configuration of tempdb.
Click here to read more about sp_CheckTempdb.
Closing Thoughts on Accelerated Database Recovery
I think this is an exciting new feature in SQL Server 2025 that can help a lot of environments remain available that experience frequent tempdb transaction log issues. However, as mentioned before, we should let Microsoft roll out some quality of life updates relating to ADR and tempdb before we even consider making this a standard practice.
