Hacker News Reader

Comment by chuckhend | Hacker News Reader

Simplicity is one of the reasons we started this project. IMO, far less maintenance overhead to running Postgres compared to RabbitMQ, especially if you are already running Postgres in your application stack. If PGMQ fits your requirements, then you do not need to introduce a new technically.

There's definitely use cases where PGMQ wont compare to RabbitMQ, or Kafka, though.

View on HN

> There's definitely use cases where PGMQ wont compare to RabbitMQ, or Kafka, though.

I'd be curious to know more about which sorts of use cases fall into this category.

PGMQ doesn't give you a way to deliver the same message to concurrent consumers the same way that you can with Kafka via consumer groups.

To get this with PGMQ, you'd need to do something like creating multiple queues, then send messages to all the queues within a transaction. e.g. `begin; pgmq.send('queue_a'...); pgmq.send('queue_b'...); commit;`

PGMQ doesn't seem to have functionality for returning a payload to the task submitter.

For example, lets say the task is something like:

    Run a SELECT query on database FOO, returning the results

There would be workarounds (ie store the results in a "results" table or similar) but just being able to directly return the result in a message to the caller is conceptually simpler.

Reply on news.ycombinator.com