SKIP LOCKED is an option for SELECT ... FOR UPDATE . It tells the database: if another transaction has already locked a row, don’t wait for it. Skip that row and return the next one that is free.

It sounds like a small detail, but it was made for a very specific job: letting many workers take tasks from the same table without blocking each other. Oracle used it internally for its own message queues as early as the late 90s. Postgres added it in version 9.5 (2016), and MySQL in 8.0 (2018). SQL Server has the same idea as the READPAST table hint.

In the last few years it has become popular because of one promise: you may not need Redis or RabbitMQ for background jobs, because your database can be the queue.

I wanted to understand how true that is. Then I noticed that my own side project already used it, and that one of its queues could leave a job stuck forever. The claim used FOR UPDATE SKIP LOCKED , so two workers could never pick up the same job. But nothing handled a worker that crashed after the claim.…