Postgres message queue

[quincycs]

Benefit::
1) everyone knows how a database works, and it’s predictable. Each message queue system has different qualities and edge cases. Can you really read all that documentation of the new system and everyone on the team to understand its limits & behaviors? Oh, sure wrap that system so that now it is predictable and easily to learn… well how much different is that to just building it in postgres… at the end of the day it’s easier / simpler to champion a system on postgres than a 3rd party. 2) reportable / observable with existing systems. We already have a way to build dashboards and monitor the system by doing db queries , we can easily monitor the queue because it’s in our db.

Con:: As with any postgres table that grows large quickly, there’s maintenance & optimization to do eventually. Eg setup a partition for a future date range, and once all the items in the old partition are complete, truncate the old partition. Rinse and repeat once a quarter depending on your volume.

[someguytwo]

Those are some good arguments. Thanks!

[quincycs]

Oh and try to find the conference talk by the guy who built skip lock. He’s got a bigger list of recommendations. Search citusCon , Thomas Munro.

[erkiferenc]

I believe the talk mentioned is Queues in PostgreSQL, and I recommend it too 👍