Skip to content(if available)orjump to list(if available)

Show HN: Sidequest.js – Background jobs for Node.js using your database

Show HN: Sidequest.js – Background jobs for Node.js using your database

12 comments

·August 4, 2025

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!

spiffytech

This is great! I sometimes have projects that could use SQLite, but they're just big enough to need a persistent job queue. Great to have an option for that.

I also like that there's a dashboard. That's really important when a project gets serious, and a surprising number of job queue libraries don't have admin tools.

kristianc

I'm not sure I follow with the LGPL requirement.. how do you envision downstream users complying with the relinking requirement, particularly in cases where Sidequest is orchestrating jobs across tightly-coupled backend infrastructure?

drewbitt

https://github.com/timgit/pg-boss https://github.com/hatchet-dev/hatchet are both on top of Postgres, but I like the SQLite here for a project I have in mind.

giovaniguizzo

Nice to know SQLite will be useful. Just be mindful that SQLite does not work well in highly concurrent systems. So, if you have a single job runner process, it will work wonderfully. However, if you have many workers, then you might see a few issues.

shireboy

Excellent! I’m a .NET developer who dabbles in Node and have been looking for a Hangfire alternative for a while. This looks like just what I would want.

MutedEstate45

Really like your approach of using existing Postgres/MySQL instead of dragging in Redis. It feels genuinely drop-in, but still Sidekiq-class. I know it's a bit early to ask about production patterns, but I was curious: if the worker thread flood hits the same Postgres that serves the web API, how do the job-fetch queries avoid contending with OLTP traffic? Does Sidequest follow Oban's advisory-lock approach or use a different throttling strategy?

giovaniguizzo

Hello! One of the creators of Sidequest here.

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 :)

MutedEstate45

Thanks for the clarification. That's a clean approach. I just stared your repo. Looking forward to seeing where sidequest.js goes :)

nip

Looks really neat! Starred on GitHub!

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

merencia

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.

mousetree

I'm a big fan of ActiveJob in Rails. I was considering building a version inspired by it in Node but now it looks like I don't have to. Thank you for building this.

hersko

This looks really cool.