I'm super interested in a Postgres-only task queue, but I'm still unclear from your post whether the only broker dependency is PostgreSQL. You mention working towards getting rid of the RabbitMQ dependency but the existence of RabbitMQ in your stack is dissonant with the statement 'a conviction that PostgreSQL is the right choice for a task queue'. In my mind, if you are using Postgres as a queue, I'm not sure why you'd also have RabbitMQ.
abelanger|1 year ago
We're eventually going to support a lightweight Postgres-backed messaging table, but the number of pub/sub messages sent through RabbitMQ is typically an order of magnitude higher than the number of tasks sent.
doctorpangloss|1 year ago
(1) you, for free
(2) develop all the functionality of RabbitMQ as a Postgres extension with the most permissive license
(3) in order to have it on RDS
(4) and never hear from you again?
This is a colorful exaggeration. But it’s true. It is playing out with the pgvecto-rs people too.
People don’t want Postgres because it is good. They want it because it is offered by RDS, which makes it good.
metadat|1 year ago
Great job so far- The flow-based UI with triggers is killer! AFAIK, this surpasses what Celery includes.
dalberto|1 year ago