Postgres durability without having to run Kafka or RabbitMQ clusters seems pretty enticing. May reach for it when I next need an outbox pattern or small fan out.
cout 53 minutes ago [-]
I think it's great that projects like this exist where people are building middleware in different ways than others. Still, as someone who routinely uses shared memory queues, the idea of considering a queue built inside a database to be "zero bloat" leaves me scratching my head a bit. I can see why someone would want that, but once person's feature is bloat to someone else.
pierrekin 39 minutes ago [-]
In Postgres land bloat refers to dead tuples that are left in place during certain operations and need to be vacuumed later.
It’s challenging to write a queue that doesn’t create bloat, hence why this project is citing it as a feature.
saberd 43 minutes ago [-]
I don't understand the latency graph. It says it has 0.25ms consumer latency.
Then in the latency tradeof section it says end to end latency is between 1-2 seconds.
Is this under heavy load or always? How does this compare to pgmq end to end latency?
rgbrgb 3 minutes ago [-]
[dead]
Rendered at 22:55:28 GMT+0000 (Coordinated Universal Time) with Vercel.
It’s challenging to write a queue that doesn’t create bloat, hence why this project is citing it as a feature.
Then in the latency tradeof section it says end to end latency is between 1-2 seconds.
Is this under heavy load or always? How does this compare to pgmq end to end latency?