The hard part of document numbering is not incrementing an integer. It is deciding what happens when the integer is reserved, rendering starts, and the render fails. PostgreSQL sequences are built for speed. They are not built for legal numbering. A sequence advances even if the surrounding transaction rolls back. For most applications that is fine. For invoices and board records, a gap is not invisible. If number 41 exists and number 43 exists, someone will ask what happened to 42. I needed a numbering system that could do three things at once: serialize per entity, type, and year; let different sequences run in parallel; and preserve a reason when a number is skipped. That became the two-phase allocator in src/documents/numbering.ts . Phase one reserves the next number. The allocator locks the tuple (entity_id, document_type, year) with pg_advisory_xact_lock , checks for the oldest unclaimed gap, and only then advances the high-water mark. It writes the reservation to pending_allocations with a TTL.…