Show HN: Sidequest.js – Background jobs for Node.js using your database
23 merencia 6 8/4/2025, 3:39:49 PM docs.sidequestjs.com ↗
Hey HN,
I'm the maintainer of node-cron (5M+ downloads/month), and I recently built Sidequest.js, a background job runner for Node.js inspired by Oban (Elixir) and Sidekiq (Rails).
It solves some common problems I saw with libraries like node-cron:
- Jobs don’t block your API: they run in isolated worker threads
- No Redis or vendor lock-in: use Postgres, MySQL, SQLite, or MongoDB
- Supports retries, uniqueness, concurrency, snoozing, prioritization
- Comes with a CLI and a simple dashboard
- Works great in monoliths and doesn’t require extra infra
Quick start (no signup needed): https://docs.sidequestjs.com/quick-start
GitHub: https://github.com/sidequestjs/sidequest
Would love feedback or feature suggestions. Happy to answer any questions here!
If you have heard of pg-boss [1], how does sidequest compare to it? I’m about to embark on some « jobification » on some flows and I’d love to have your opinion (possibly biased, but still)!
[1] https://github.com/timgit/pg-boss
Great question!
Sidequest uses transaction-level row locks (`SELECT ... FOR UPDATE SKIP LOCKED`) when fetching jobs. This means each worker thread only locks the specific job rows it’s about to process, minimizing lock contention and avoiding blocking other queries. This pattern is inspired by Oban’s advisory-lock approach, but instead of using explicit advisory locks, Sidequest relies on the database’s built-in row locking mechanism.
The only drawback is that Sidequest will require one or two connections to your DB. If you enqueue jobs from within other jobs, then each job that requests an enqueue will also connect to your DB (lazily connected upon request - if your job does not enqueue, no connection is created). However, you can configure the number of concurrent workers per queue and globally, so you control how much load Sidequest puts on your database.
I hope that answers your question :)