You could go read the pgmq docs, look at the fifty or so lines of code that make up the thin wrapper around it, and understand it just as well as you understand

You could go read the pgmq docs, look at the fifty or so lines of code that make up the thin wrapper around it, and understand it just as well as you understand BullMQ. Or you could use one of the extensive set of pgmq libraries if you aren't comfortable calling Postgres functions (for some reason). I'm not suggesting that BullMQ and Redis are trivial and that you should rewrite them yourself, I'm telling you that Postgres has multiple existing implementations of a message queue already. And frankly, the fact that something is non-trivial does not automatically mean you can't or shouldn't rewrite it, only that you need a good reason. Even if there was no existing Postgres message queue (there are many), atomicity is a good enough reason on its own. Imagine if you could avoid idempotency issues when calling third party APIs until you had more than ten engineering teams! Well, you can! Just don't add more than one method of storing online data to your architecture.