How/Why to Sweep Async Tasks Under a Postgres Table

I found this post to be an interesting read, namely because I grew up with learning Database-as-IPC to be an anti-pattern and this reminds me of it.

Yet, especially in the recent years, we started to see more and more advocacy for "Postgres maximalism", where using Postgres with unlogged tables as a Redis replacement is probably the most famous example — something which I am very fond of personally, given that Postgres is a rock-solid piece of software withstanding the newest Javascript framework hype.

Not sure if I would use a database for IPC, but that is probably due to the fact that most of my IPC software has no persistent data and a loss of data due to crash would not mean the end of the world. However, if I were to actually handle messages that NEED to be persistent, I would consider this pattern.

However, there is a thing that makes me a bit thoughtful, namely on how locking and parallelization should be done: On one hand, there is a good reason to somehow obtain an exclusive write-lock, to semantically avoid parallel workers to obtain and process the same item twice, potentially leading to a mail being delivered twice, etc., if one were to parallelize it. On the other hand, this would prevent receiving messages, which is potentially undesirable. A mitigation would need to ensure that a worker process can somehow "lock" a row so it cannot be queried by other workers, without involving mechanisms such as two transactions, as being able to rollback, such as in the event of a crash, is a must-have requirement. But maybe I am just over-engineering this: Not everything benefits from parallelizing.

And as an interesting observation: This pattern has already basically proven to work in SMTP, although not necessarily directly with the use of a database system, but by somehow using persistent storage for queueing and IPC (which sounds like a very common pattern actually when viewing it that way?)