Supporting bun:sql (Postgres/MySQL)?

[khromov]

👋 Would it be an idea to support bun:sql so that Postgres/MySQL would be supported for queues? The background is I'm building a Bun-based framework and I've implemented queue support via bunqueue but some people want to run it on "serverless containers" and there is only ephemeral filesystem available, so something like sqlite or in-memory won't work, but Postgres/MySQL would work well.

[egeominotti]

Thanks for the thoughtful request! Short answer: it's technically feasible but a large change, and, more importantly, it wouldn't actually solve the deployment problem you describe. Two reasons:

1. Async blocker. bunqueue's persistence is built entirely on bun:sqlite, which is synchronous. bun:sql (Postgres/MySQL) is async-only. Swapping it means turning the whole storage layer + write buffer + startup recovery async and propagating await through the hot path, which is invasive and adds latency to the core push/ack path.

2. It wouldn't unlock serverless anyway. bunqueue is a single-process engine: the in-memory sharded queues are the source of truth at runtime, and SQLite is just a write-behind durability log. There's no distributed locking or cross-instance coordination. So even backed by Postgres, running two instances against the same DB would double-execute jobs and race on state transitions. Postgres by itself doesn't give you horizontal/serverless scaling, and that would need a much deeper rearchitecture.

For an ephemeral-filesystem serverless target, two options fit today with zero changes:

• Persistent volume: most "serverless container" platforms (Fly.io volumes, Railway, Render disks) let you mount a disk. Point BUNQUEUE_DATA_PATH at it and SQLite works normally.
• Store-and-forward: queue.forward({ to: { host, port } }) drains local jobs to a central durable bunqueue server. The ephemeral instance holds nothing long-term; the central node owns persistence. This is arguably the cleanest fit for scale-to-zero edge workers.

Keeping bunqueue free of external runtime infra (no Redis, no Postgres) is a core design goal, so I'm inclined not to add a DB backend unless there's strong demand for Postgres specifically as a durability target. Happy to keep this open to gauge interest though!

[khromov]

Thanks for the answer, that makes sense!