The setup<\/h2>\n\n\n\n
The store is Scaleway Managed Database for PostgreSQL<\/strong>. I did not self-host Postgres on a VM; these are managed database nodes, so the numbers reflect the standard managed offering out of the box. Client to database round-trip was about 11 ms.<\/p>\n\n\n\n Two managed-database node types appear in the charts:<\/p>\n\n\n\n The small node does about 2,800 appends\/s with staging; the big node reaches about 5,000\/s. Roughly 150x the price for under 2x the throughput. The ceiling is the database write path, not the core count.<\/p>\n\n\n\n One caveat before the numbers: absolute throughput varied about 3x between hosts<\/strong> at identical spec, purely from commit fsync latency. Benchmark your own target and trust ratios over absolute values.<\/p>\n\n\n\n There is one design rule that makes all of this lockable: an append condition must be scoped to a boundary. It needs at least one event-type-plus-tag combination, for example The global lock is flat across overlap (about 1,250 to 1,580 appends\/s) and does not scale with cores. It serializes everything. That is the baseline.<\/p>\n\n\n\n Per-boundary runs 2x to 5x faster<\/strong> at 0% overlap, and the gap grows with cores and concurrency, up to about 6,900 appends\/s<\/strong> at 512 users on the big node. At 100% overlap it decays back to global, because all keys collapse into one.<\/p>\n\n\n\n The hybrid lands at roughly global speed. It gives up parallel commits to stay gap-free, which is the whole reason per-boundary was fast. Skip it.<\/p>\n\n\n\n Four-way comparison on the small node, condition check on:<\/p>\n\n\n\n <\/p>\n\n\n\n Throughput vs clients on the big node (bars staging, line boundary):<\/p>\n\n\n\n <\/p>\n\n\n\n The ceiling is the database write path, not the lock: WAL plus hot-page index contention. 5K versus 15K IOPS made no difference, and disabling fsync did not raise the per-boundary ceiling.<\/p>\n\n\n\n The problem with per-boundary locks is when<\/em> the sequence number is assigned. It is allocated at insert time, before the transaction commits, and concurrent transactions commit in a different order than they took their numbers. So transaction B can grab sequence 101 and commit while transaction A still holds 100 uncommitted. A consumer tailing This is also why per-boundary is fast: the speed comes from many appends fsync-ing concurrently (group commit), and that concurrency is exactly what lets commit order diverge from assignment order. The hybrid serializes the commit to keep the sequence gap-free, and in doing so throws the speed away.<\/p>\n\n\n\n The per-boundary throughput is the parallel commits, and the parallel commits are the gap.<\/p><\/blockquote>\n\n\n\n So the apparent choice is: consistency and a plain cursor (global, hybrid), or throughput (per-boundary, with opaque That is the staging strategy. Appends land concurrently in a small It is also fast: about 2.8x global<\/strong> on the small node, around 5,000 appends\/s<\/strong> on the big node, and at high client counts it beats per-boundary (5,045 vs 4,165 at 768 clients), because each append hits the small staging buffer instead of the 10M-row On a 100M-event<\/strong> table the numbers barely moved (staging peaked at 6,238\/s at 256 clients) and the single flusher held the backlog at zero. The condition check short-circuits on the primary key regardless of history depth.<\/p>\n\n\n\n Durability holds: It is out of scope by design. In event sourcing the read side is decoupled from the write side: projections are separate consumers that tail the ordered event log at their own pace and scale independently. Staging changes nothing there, since consumers tail Yes, with limits. For spread, human-paced workloads, which is most business event sourcing, you get flexible runtime constraints, single-digit-thousands of appends per second, and full consistency with a plain integer cursor, on managed Postgres. A single hot boundary still serializes everyone, “fast enough” depends on your workload, and staging adds a flusher daemon. But the claim that DCB cannot be fast on commodity infrastructure does not hold up.<\/p>\n","protected":false},"excerpt":{"rendered":" Classic event sourcing has a rule: one aggregate, one stream, one consistency boundary. It is simple and it scales, but it is rigid. The moment you need an invariant that spans two aggregates, you are writing sagas and workarounds. Dynamic Consistency Boundaries (DCB) are meant to remove that constraint. The recurring objection is that they […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[235,161],"tags":[276,226,294,291,231,232,292],"yoast_head":"\ncondition=check<\/code>: the in-lock condition check runs.<\/li>Four locking strategies I compared<\/h2>\n\n\n\n
uint64<\/code> cursor, simple. Throughput-capped.<\/li>(type, tag, value)<\/code>, so different entities append in parallel. Fast, but positions commit out of order, so it needs opaque xid8<\/code> cursors.<\/li>staging<\/code> buffer; a single flusher moves them to events<\/code> in order.<\/li><\/ul>\n\n\n\nUserCreated<\/code> tagged user:123<\/code>, which becomes the lock key. A bare type-level condition like “no UserCreated<\/code> exists anywhere” has no boundary to lock on, so I disallow it. It would force a global lock over the whole type and defeat the per-boundary concurrency the other strategies rely on.<\/p>\n\n\n\nThe results<\/h2>\n\n\n\n
![\"\"](\"https:\/\/denbeke.be\/blog\/wp-content\/uploads\/2026\/06\/DCB-benchmark-small-postgres-database-server-1024x695.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/denbeke.be\/blog\/wp-content\/uploads\/2026\/06\/DCB-benchmark-big-database-server-multiple-users-1024x713.png\")
<\/figure>\n\n\n\nThe key insight<\/h2>\n\n\n\n
events<\/code> by sequence number sees 101 become visible, advances its cursor past 100, and when A finally commits it has already skipped event 100. That is the gap, and it is why a plain monotonic cursor is no longer safe.<\/p>\n\n\n\nxid8<\/code>cursors). Unless you stop serializing the write and serialize only the sequence assignment, which is what staging does.<\/p>\n\n\n\nCan we have all four properties?<\/h2>\n\n\n\n
staging<\/code> buffer; a single flusher moves them into events<\/code> in order. One writer into events<\/code> keeps sequence_number<\/code> gap-free and monotonic, so consumers keep a plain uint64<\/code> cursor. The condition check reads staging<\/code> and events<\/code> together, so it stays consistent across multiple boundaries.<\/p>\n\n\n\nproperty<\/th> global<\/th> boundary<\/th> hybrid<\/th> staging<\/th><\/tr><\/thead> multi-boundary DCB<\/td> \u2713<\/td> \u2713<\/td> \u2713<\/td> \u2713<\/td><\/tr> gap-free consistency<\/td> \u2713<\/td> \u2717<\/strong><\/td> \u2713<\/td> \u2713<\/td><\/tr> plain uint64<\/code> cursor<\/td>\u2713<\/td> \u2713<\/td> \u2713<\/td> \u2713<\/td><\/tr> per-boundary concurrency<\/td> \u2717<\/strong><\/td> \u2713<\/td> \u2717<\/strong><\/td> \u2713<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n events<\/code> indexes. The flusher pays the big-index cost once per batch.<\/p>\n\n\n\nBut it is not free<\/h2>\n\n\n\n
staging<\/code> and appears in events<\/code> on the next flush, tens of milliseconds later. This is the eventual consistency you already have in CQRS: projections and read models always lag the write side. Staging adds a small constant to a lag you already design around. Strong-consistency decisions are unaffected, since the check reads staging<\/code> and events<\/code> together.<\/li>staging<\/code> fills.<\/li>staging<\/code> is logged, so a successful append is on disk before it returns. A crash before the flush leaves the event in staging, flushed on restart.<\/p>\n\n\n\nWhat about the read side?<\/h2>\n\n\n\n
events<\/code> by the same plain cursor. The only read on the write path is the decision read, which this benchmark exercises. The read side is a separate, well-understood concern, not a gap in these numbers.<\/p>\n\n\n\nSo, is DCB fast enough to stay flexible?<\/h2>\n\n\n\n