[cout]

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]

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.

[what]

Can’t you just partition the table by time (or whatever) and drop old partitions and not worry about vacuuming? Why do you need to keep around completed jobs forever?

[perrygeo]

If you're looking for kafka-like semantics, you might want to keep messages around.

Your temporal partition idea is spot on. But instead of dropping old partitions, you can instead archive them.

[victorbjorklund]

What about old failed jobs? You might wanna keep them around? And maybe you have retries that have a backoff.

[pierrekin]

Yes you can, and at the risk of sounding a little snarky; if you do something like that and then release it as open source, people may even discuss it on HN!