Is it possible to avoid a deadlock in an update without using select ... for update?
15:46 06 Dec 2025

I have a table in postgres with 3 columns (id, status, work_time). The application that works with the table inserts, updates, and deletes data at a rate of 10,000 tps for each operation.Deletions are performed by id, and updates are based on the status column.

I am trying to write a query that can help me avoid deadlocks. I have written the following query:

 SELECT w.id FROM work_queue AS w
 WHERE w.status = 'ready'
 ORDER BY w.id
 LIMIT 100
)
UPDATE work_queue SET status = 'processing'
 FROM tmp 
 WHERE work_queue.id = tmp.id
 returning *

Is this query still susceptible to deadlocks? I read that postgres does not guarantee the order of rows in an update, but on the other hand, some sources suggest tha that order by in select helps to specify the order for update.

I know that it is recommended to use select ... for update skip locked, but it seems that under high data volume and frequent updates/deletions, it can lead to performance degradation. Is this concern valid?

postgresql multithreading deadlock