HackerTrans
TopNewTrendsCommentsPastAskShowJobs

kernelvoid

no profile record

Submissions

[untitled]

1 points·by kernelvoid·7 gün önce·0 comments

Show HN: Bunqueue – Saga workflow engine for Bun with embedded SQLite

bunqueue.dev
3 points·by kernelvoid·3 ay önce·0 comments

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

github.com
39 points·by kernelvoid·5 ay önce·22 comments

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

github.com
2 points·by kernelvoid·5 ay önce·3 comments

comments

kernelvoid
·3 ay önce·discuss
[dead]
kernelvoid
·5 ay önce·discuss
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.
kernelvoid
·5 ay önce·discuss
No magic, just good engineering. That’s it.
kernelvoid
·5 ay önce·discuss
True, most apps will never hit the scale where it matters. But when you do, retrofitting a queue is painful.
kernelvoid
·5 ay önce·discuss
I get the concern, but there’s a spectrum.

Using an LLM to polish grammar vs. having it generate opinions wholesale are different things.
kernelvoid
·5 ay önce·discuss
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.
kernelvoid
·5 ay önce·discuss
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.
kernelvoid
·5 ay önce·discuss
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.
kernelvoid
·5 ay önce·discuss
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!
kernelvoid
·5 ay önce·discuss
thx!
kernelvoid
·5 ay önce·discuss
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.