Latches vs Locks in SQL Server: The Difference That Trips Up Even Experienced DBAs

Both sound like “something is blocking something.” They protect completely different things, and misdiagnosing one as the other sends you fixing the wrong problem.

Two Different Jobs

Why the Distinction Matters in Practice

A DBA seeing high PAGELATCH_EX waits and reaching for the usual lock-blocking playbook (shorten transactions, change isolation level) is solving the wrong problem — latch contention is about physical memory structure access, not logical transaction isolation. It needs a completely different fix.

-- Distinguish the two directly from current waits
SELECT wait_type, COUNT(*) AS waiting_now
FROM sys.dm_os_waiting_tasks
WHERE wait_type LIKE 'LCK%' OR wait_type LIKE '%LATCH%'
GROUP BY wait_type;

The Most Common Latch Contention Pattern

PAGELATCH_EX waits on the last page of a table with an ever-increasing key (like an IDENTITY column) under very high concurrent insert load is the single most common latch contention scenario — every session is racing to insert into the same physical page. This exact pattern sets up the tempdb contention lesson next, which is the same underlying phenomenon at a system-table level.