Neoq (https://github.com/acaloiaro/neoq https://github.com/acaloiaro/neoq) is a background job processor for Go. It began from my desire to have a robust Postg

Neoq (https://github.com/acaloiaro/neoq https://github.com/acaloiaro/neoq) is a background job processor for Go. It began from my desire to have a robust Postgres-backed job processor. What I quickly realized was that the interface in front of the queue was what was really important. This allowed me to add both in-memory and Redis (provided by asynq) backends behind the same interface. Which allows users to switch between different backends depending on their durability and performance constraints. E.g. in-memory for testing/development/low durability requirements, postgres when you're not running Google-scale jobs, and Redis for all the obvious use cases for a Redis-backed queue. This allows me to swap out job queue backends without changing a line of job processor code. I'm familiar with the theory that one shouldn't implement queues on Postgres, and to a large extent, I disagree with those theories. I'm confident you can point out a scenario in which one shouldn't, and I contend that those scenarios are the exception rather than the rule.