The shootout and the one knob.

That flattening is the whole story of the spectrum. Early on, throughput climbs almost linearly with records-per-fsync, because the flush is the dominant cost and you are dividing it across more records. Past a point, the per-record work (serialize, append) dominates and more batching buys little. Every engine lives somewhere on this curve; the only question is what sets its records-per-fsync.

Read the four-way result as positions, not numbers. Memory has no flush, so it sits at the far ceiling. Oban’s single insert is one record per flush — the strict, slow end; its insert_all puts a transaction’s worth of records behind one flush and jumps up the curve. BullMQ’s bulk add does the same on Redis. Champ never makes the caller hold a batch at all: its checkpoint-every-K keeps records-per-fsync high continuously, so its single-record path already sits where the others only reach with a bulk API.