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.