The database on the hot path.

The defining property of the classical durable queue is not that it stores jobs — every queue does — but where it stores the queue’s control state. In Oban, the jobs table holds the work and its lifecycle: a job is enqueued by an insert, claimed by an update under a lock, kept alive by periodic lease heartbeats, and completed by an update or delete. Each of those is a transaction against PostgreSQL, so the database sits on the hot path of every step, not just the durable write. That has two consequences worth stating plainly. The queue’s latency is the database’s latency — a slow commit slows claiming and acking, not only enqueue — and the queue’s availability is the database’s availability, because a worker that cannot reach Postgres cannot even mark progress on a job it already holds. And the durability, real as it is, is single-node: the committed jobs table survives a worker crash, but the loss of that one database is the loss of the queue, unless you run Postgres streaming replication and take on its failover complexity. None of this is a flaw in Oban; it is the direct cost of putting the control plane in the durable store. The platform’s move is to ask whether the durable write has to be on that path at all.

Strip the schema away and a durable queue’s throughput reduces to one number: how many durable records ride a single fsync. The classical single-insert path commits once per job, so it rides one record per fsync — the strictest and the slowest end. The insert_all path writes a transaction’s worth of jobs in one commit, riding a whole batch per fsync, and that single change closes most of the throughput gap — the same durability, far more jobs per second, paid for by holding a batch. This is the dial the hub’s spectrum turns: Memory rides infinitely many records per fsync because it never syncs, Champ rides K because its checkpoint amortizes the fsync over K records, and Oban rides one or a transaction depending on the path. The insight that matters for the next dive is that batching is not unique to any one system — anything that amortizes the fsync over more records moves right on this axis. What batching alone never adds is replication: an insert_all is still single-node. So the open corner, the one the classical queue cannot reach by tuning its batch size, is strict durability that is also replicated and also off the hot path. That corner is the subject of the next dive.