Hacker News Reader

kernelvoidon Show HN: Bunqueue – Job queue for Bun using SQLite instead of Redis

Fair point, that was misleading. bunqueue is single-server only today. “Small clusters” is on the roadmap but I should’ve been clearer it’s not there yet.

kernelvoidon Show HN: Bunqueue – Job queue for Bun using SQLite instead of Redis

No magic, just good engineering. That’s it.

kernelvoidon Show HN: Bunqueue – Job queue for Bun using SQLite instead of Redis

True, most apps will never hit the scale where it matters. But when you do, retrofitting a queue is painful.

kernelvoidon Show HN: Bunqueue – Job queue for Bun using SQLite instead of Redis

I get the concern, but there’s a spectrum.

Using an LLM to polish grammar vs. having it generate opinions wholesale are different things.

kernelvoidon Show HN: Bunqueue – Job queue for Bun using SQLite instead of Redis

The comment sounds "polished" because I've probably described this project dozens of times at this point.

When you repeat the same thing over and over you naturally end up with a tight version of it. That's not an LLM, that's just how it works when you talk about something a lot.

And honestly even if I did use an LLM to write a comment on HN, so what? The code is what matters.

Go run the benchmarks, read the source, open an issue if something breaks.

That's the part that actually counts.

kernelvoidon Show HN: Bunqueue – Job queue for Bun using SQLite instead of Redis

This is exactly why I built bunqueue — a job queue for Bun backed by SQLite. No Redis, no external dependencies, just bun:sqlite with WAL mode for concurrent access. Handles 100k+ jobs/sec on a single node.

The SQL-as-queue pattern is definitely underrated. Great to hear it worked well at that scale.

kernelvoidon Show HN: Bunqueue – Job queue for Bun using SQLite instead of Redis

Transparent answer about bunqueue's architecture.

Current state: bunqueue is single-server with SQLite persistence.

If the server goes down for 5 minutes, clients cannot push/pull during that window. However: the client SDK has automatic reconnection with exponential backoff + jitter, all data is safe on disk (SQLite WAL mode), and on restart active jobs are detected as stalled and re-queued automatically. Delayed/scheduled jobs resume from their run_at timestamps.

For your use case (100k+ scheduled jobs, low throughput): well-optimized. We use MinHeap + SQLite indexes for O(k) refresh where k = jobs becoming ready, not O(n) scan.

What bunqueue does NOT have today: no clustering, no multi-instance with shared state, no automatic failover, no replication.

What it does have: S3 automated backups (compressed, checksummed) for disaster recovery. A "durable: true" option for zero data loss on critical jobs. Zero external dependencies.

Roadmap: HA is something we're actively working toward. Native HA with leader election and replication. Managed cloud offering with automatic failover and geographic distribution.

Bottom line: if you need true HA today, BullMQ + Redis Sentinel/Cluster is the safer choice. bunqueue is for when you want simplicity, high performance (~100k jobs/sec), and can tolerate brief downtime with automatic recovery.

kernelvoidon Show HN: Bunqueue – Job queue for Bun using SQLite instead of Redis

Hi HN! I built bunqueue because I got tired of spinning up Redis just for background jobs.

The idea: for single-server deployments, SQLite can handle 100k+ ops/sec with WAL mode, so why add infrastructure?

  Two modes:                                                                                        
  
  - Embedded: everything in-process, just `import` and go                                           
  - Server: run `bunqueue start`, connect multiple workers via TCP

Features: priorities, delays, retries, cron jobs, DLQ, job dependencies, BullMQ-compatible API.

  Trade-offs vs Redis:                                                                              
 
  - Not for multi-region distributed systems                                                        
  - Best for single server or small clusters                                                        
                                                                                                    
 Happy to answer any questions about the architecture!

kernelvoidon BunQueue – Job queue using Bun and SQLite, no Redis needed

thx!

kernelvoidon BunQueue – Job queue using Bun and SQLite, no Redis needed

Hey, I built this because I needed a simple job queue for a side project but didn't want to set up Redis just for that. BunQueue uses SQLite as the backend with 16 shards for parallelism, so it's easy to deploy with zero external dependencies besides Bun.

Some numbers from my M1 Max:

1.2M+ ops/sec for batch push 494K ops/sec processing with 16 workers 1 million jobs in under 3 seconds with 100% data integrity

It supports delayed jobs, retries, priorities, and concurrent workers. The repo includes a full benchmark suite if you want to test on your own hardware. Would love feedback on the API or any features you'd find useful.