HN Reader

At Apple, on iTunes, we used an Oracle database to do job queue stuff. Initially I will admit I made fun of it because I wanted to use a "real" queue like RabbitMQ or ActiveMQ or something, but I have to admit that it worked fine and to be fair it did predate both of those.

Anyway, it made me realize that there's really no reason you can't use a SQL database as a backing store for queue stuff. I should try building my own at some point.

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!