[andrew-v]

SKIP LOCKED is a good idea to make sure that the tasks can be processed independently by the workers, but what about a case where you have to guarantee the order of events?

I guess this Postgres queue is a very handy tool for cases like background jobs, but will it work with event sourcing?

[ffsm8]

You're responsible for writing the query that selects the tasks to process, so yes? You can obviously group by a common id, order by inserted and use limit 1. And if every event has to be processed in order, then you've created a system that can't be parallel, so you'll be effectively limited to a single worker.

[dkersten]

You can have multiple workers, but they all need to process all events. So it’s not suitable for parallelisation of work (how can it be, if total ordering is required), but it can be used where different workers consume the queue in different ways (eg for synchronising different services).

[Rapzid]

Order by insert time on some group key(or otherwise figure out the order) and select the top item. Then select that item for update with skip locked. If it's locked you will get zero results.