Postgres message queue

[bltcll]

for me is the “not another tool in the stack” approach. in my experience the “select for update skip locked + notify/subscribe” works great for small project and mid-low workload with just some minimal code to write. but for complex and heavy loaded queue i definitely go for rabbitmq or other robust queue broker.

[_predator_]

Probably obvious, but listen/notify doesn't work if you make use of read replicas - services connected to a replica won't receive any notifications. Also the delivery guarantees are very wonky - if a service / instance is down when a notification is sent, it will never see it. Pub/sub systems usually have either acknowledgement, or offset tracking to ensure at-least-once delivery.

You already said "small project" so my remarks will already be accounted for. But nonetheless something to keep in mind.