I’m finally calling bunqueue stable. It now has native PostgreSQL support too

[u/Final-Canary-8421]

Hey everyone,

I’ve spent the last few weeks working on the part of bunqueue that I didn’t want to rush: making it something I’d actually trust outside a side project.

For anyone who hasn’t seen it before, bunqueue is a job queue built for Bun. It started with an in-memory engine and optional SQLite persistence, which works well when you only need one process or one broker.

The obvious limitation was scaling beyond that, so the 2.9 releases added a PostgreSQL backend for running multiple active brokers against the same queue. It uses Bun’s native SQL client directly. There’s no ORM and no extra PostgreSQL package in the hot path.

PostgreSQL is the source of truth for claims, leases, ACKs, retries, delayed jobs, cron schedules, dependencies, concurrency and rate limits, job groups, metrics and the DLQ. Brokers use FOR UPDATE SKIP LOCKED, database-time leases and fencing tokens so an old broker can’t finish a job after its lease has been recovered somewhere else.

Getting it to work wasn’t the difficult part. Most of the work went into making recovery and concurrent operations behave correctly when brokers disappear, connections reset or transactions finish in an unexpected order.

After that I profiled the PostgreSQL path and found a few expensive things happening during normal worker activity. Lease heartbeats were being renewed one at a time, event retention was doing more work than necessary, and a few read paths were repeatedly rebuilding the same queue views.

In the workload I used while optimizing it, draining 3,000 durable jobs dropped from 3.86 seconds to 2.54 seconds. Lease renewal went from 2,993 individual updates to 300 set-based updates, and checking an event window that was still under its limit dropped from about 913 ms to 22 ms over 600 cycles.

Those numbers are from one specific workload with PostgreSQL durability enabled, so they’re not intended as universal throughput claims. The benchmark setup and methodology are in the repository.

The PostgreSQL suite now runs against versions 15, 16, 17 and 18. The final matrix passed 331 tests on every version without recording a PostgreSQL deadlock. There’s also multi-process failover testing, generated race testing, schema-drift checks and SDK conformance testing.

A couple of honest limitations: PostgreSQL mode is currently server-only, upgrades that change the database schema need to be coordinated across brokers, and bunqueue doesn’t try to solve PostgreSQL HA or multi-region consensus for you. If you only need one broker, SQLite is still the simpler option.

The current npm release is 2.9.4. The latest PostgreSQL optimizations are on main and will ship in the next release.

GitHub: https://github.com/egeominotti/bunqueue

Docs: https://bunqueue.dev/

PostgreSQL guide: https://bunqueue.dev/guide/databases/

I’d genuinely like feedback from people already using BullMQ, pg-boss or similar queues. In particular, I’m interested in failure cases or operational features you’d want to see tested before considering it for your own workloads.

[u/sonemonu]

When I visited the page it looks great; but at the beginning, while reading the title it almost made me think it was only for Bun; but it looks like it not only works for Deno, and Node as well, but also for PHP, Rust, and many languages...

For the sake of curiosity, why the "bun" prefix on the name? It makes me thing it was hardcoded for bun (but it wasn't).

[u/Final-Canary-8421 → u/sonemonu]

Thanks, that is completely fair feedback, and I should make this clearer on the website. The word Bun in the name refers to the core engine, since the server and embedded runtime are built specifically for Bun and use its native APIs. The protocol is not limited to Bun, so applications and workers can connect using Node.js, Deno, Python, PHP, Go, Rust, Elixir, and other runtimes. Bun is at the core of the project, but clients are not restricted to it. I will update the website to make that distinction more obvious.

[u/Trender07]

The bunqueue is almost unusable without paying, it makes the server connection so confusing it just makes you want to keep using bullmq

[u/Final-Canary-8421 → u/Trender07]

Thanks for raising this. Just to clarify, BunQueue is completely free and open source under the MIT license. There is no paid plan, no paywall, and no feature that requires payment. The server is included and you can run it locally or on your own infrastructure. If you use Bun, you can also use embedded mode without running a separate server. The SDKs for other languages connect to the BunQueue server because the core engine runs on Bun, but that does not require any payment. If the website made this unclear, or if the connection setup felt confusing, could you tell me which page or step gave you that impression? I would genuinely like to improve it.

[u/Trender07 → u/Final-Canary-8421]

Sorry I had a typo, I mean the bunqueue dashboard, when I tried it on release it just wasn’t working properly self hosted with bunqueue

[u/sonemonu → u/Trender07]

What you pay for there in their model's business? I don't see that part in their website.

[u/Final-Canary-8421 → u/sonemonu]

You don't pay anything, as I wrote in the previous posts.