Optimized Locking in SQL Server 2025 -- Concurrency Gets Smarter

For years, blocking chains and lock contention have been part of the DBA’s daily grind. SQL Server 2025 introduces a major shift with Optimized Locking — said to be a smarter mechanism that reduces wasted locks, improves concurrency, and lowers memory pressure. It has two main components:

1. Lock After Qualification (LAQ)
2. Transaction ID (TID) Locking

The Old Way: Lock First, Ask Later

Traditionally, SQL Server grabs locks as rows were scanned before checking whether they matched the query filter:

• Rows that didn’t qualify still got locked
• Unnecessary locks blocked other sessions
• Large scans with selective predicates suffered the most

It was basically 'lock first, ask questions later'.  Things are very different now.

Lock After Qualification (LAQ)

One of the Optimized Locking components is Lock After Qualification (LAQ), where:

• SQL Server first evaluates rows against the query’s predicate
• Only if a row qualifies does the engine acquire the lock
• This reduces blocking, lowers lock memory use, and improves throughput 

 
    EXAMPLE

    -- Session 1
    BEGIN TRAN;
    UPDATE Sales.Orders
    SET Status = 'Closed'
    WHERE OrderDate < '2025-01-01';
    -- (do not commit yet)

    -- Session 2
    SELECT COUNT(*)
    FROM Sales.Orders
    WHERE OrderDate >= '2025-01-01';

      Pre-SQL Server 2025 - Session 2 could block because Session 1                                 locked rows it wasn’t even updating.

      With SQL Server 2025 - Session 2 runs without blocking and only qualifying               rows are locked.

Transaction ID (TID) Locking

The other half of Optimized Locking is TID Locking, where

• Each row carries the ID of the transaction that last modified it.
• Instead of holding thousands of row/page locks until commit, SQL Server can represent them with a single TID lock.
• This prevents lock escalation, reduces lock memory, and improves concurrency.

Requirements (and caveats)

• Accelerated Database Recovery (ADR) must be enabled.
• Read Committed Snapshot Isolation (RCSI) is recommended.
• Some statements are excluded (OUTPUT clauses, variable assignments, certain joins/index patterns).
• If overhead becomes too high, SQL Server can heuristically disable LAQ.

Optimized Locking may not sound as cool as 'AI integration' or 'vector search', but it delivers results every DBA will notice right away, making concurrency management a whole heckuva lot easier than it has ever been!

• Fewer wasted locks -- people, this is HUGE!
• Less blocking under concurrency
• More efficient resource usage
• Simpler troubleshooting with sys.dm_tran_locks

More to read:    Optimized Locking

Accelerated Database Recovery