SKIP LOCKED is why a queue table is suddenly viable

Two workers selecting the next unprocessed row with FOR UPDATE serialise — the second waits for the first — so adding workers adds no throughput at all.

START TRANSACTION;

SELECT id, payload FROM jobs
WHERE reserved_at IS NULL
ORDER BY id
LIMIT 1
FOR UPDATE SKIP LOCKED;

UPDATE jobs SET reserved_at = NOW() WHERE id = ?;

COMMIT;

SKIP LOCKED passes over rows another transaction holds rather than waiting, so each worker takes a different job and the pool scales. NOWAIT is the other new option and fails immediately instead of skipping, which suits an interactive request that would rather error than hang. The transaction has to stay short — the lock is held until commit, and a worker that does the actual work inside it has recreated the serialisation.