merencia

There are a few key differences. I plan to write a proper blog post about it soon.

The main conceptual one is that BullMQ enqueues plain objects, and your handler just receives that data. In Sidequest, you enqueue full class instances, so when the job runs you can call this.someMethod() directly inside run().

Sidequest also runs jobs in isolated worker threads out of the box, has a built-in dashboard in the OSS version, and works with Postgres, MySQL, SQLite, or MongoDB.

That said, I still want to explore BullMQ more deeply to write a complete comparison.

Thanks for the question! I just checked out pg-boss. Solid library if you're fully on Postgres. Sidequest.js takes a broader and more flexible approach. Key differences:

Database agnostic: Sidequest isn't tied to Postgres. It also works with MySQL, MongoDB, and SQLite, which helps if your stack isn’t Postgres-based.

Job isolation: Jobs run in worker threads, so heavy tasks won’t block your main Node.js process. Express APIs stay responsive.

Distributed coordination: Designed to run across multiple instances. One node picks up the job, and if it fails, another can retry. This is built-in.

Built-in dashboard: Includes a web UI to inspect, retry, or cancel jobs.

More than queues: Supports cron jobs, uniqueness constraints, per-queue concurrency, and configuration. Some of this overlaps with pg-boss, but the intent behind Sidequest is to provide a complete solution for job processing.

If you just need simple queues in a Postgres-only setup, pg-boss is great. If you want more flexibility, tooling, and backend options, Sidequest may be a better fit.

Some years ago I created a lib named node-cron, but it has a problem, when a blocking I/O is made for example a loop, the main process is blocked.

I tried to create a library for task scheduling using child process, but I don't know if it's a good idea.

Is this useful?