SQL Maxis: Why We Ditched RabbitMQ and Replaced It with a Postgres Queue

Re:SQL Maxis: Why We Ditched RabbitMQ and Replaced It with a... by tracker1 on Tuesday April 11, 2023 @06:00PM (#35532184)

Yeah, my first thought was curiosity about their volume needs. DB based queues are fine if you don't need more than a few messages a second of transport. For that matter, I've found Azure's Storage Queues probably the simplest and most reliable easy button for queues that don't need a lot of complexity. Once you need more than that, it gets... complicated.

Also, sharing queues for multiple types of jobs just feels like frustration waiting to happen.

[ Parent | on HN ]

Re:SQL Maxis: Why We Ditched RabbitMQ and Replaced It with a... by TexanFeller on Tuesday April 11, 2023 @06:47PM (#35532722)

> DB based queues are fine if you don't need more than a few messages a second of transport

I'd estimate more like dozens to hundreds per second should be pretty doable, depending on payload, even on a small DB. More if you can logically partition the events. Have implemented such a queue and haven't gotten close to bottlenecking on it.

[ Parent | on HN ]

Re:SQL Maxis: Why We Ditched RabbitMQ and Replaced It with a... by tracker1 on Tuesday April 11, 2023 @06:51PM (#35532773)

Had meant few hundred... :-)

[ Parent | on HN ]

Re:SQL Maxis: Why We Ditched RabbitMQ and Replaced It with a... by eastern on Wednesday April 12, 2023 @01:20AM (#35535322)

A column in the database identifying which 'queue' is all you need for that. The table is not a queue, it's a structure to store queues.

[ Parent | on HN ]