ADR-012, from docs/DECISIONS.md in the QuantyKube repository.
Status In force
ADR-010 made every write its own QuantyDB commit, with two fsyncs each. The first benchmark against etcd (16 clients, 256 byte puts, same machine and disk) showed what that costs: 1,409 writes a second against etcd's 7,129, because etcd lets concurrent writes share one sync and this did not. Revision numbers are kept distinct and dense, as etcd's are; what changed is how many of them one commit carries.
How a group forms. A write that arrives while a commit is on its way to disk waits. When the commit lands, the waiting writes apply one after another into a single new transaction, each with the next revision, and the last of them commits for all. A write that fails rolls back to a savepoint and leaves the others alone. Nobody waits for a timer: a lone write commits at once, and groups are exactly as large as the load makes them. Watchers are told about each revision in order, after the commit is durable and before any later one.
Reading at a revision inside a group. The commit index maps each commit to the last revision it holds. Reading at the last one is a plain snapshot. Reading at an earlier one takes that snapshot and sets back the keys changed later in the same commit, using the previous state the change log already stores (ADR-010). A test writes from eight threads at once and checks a scan and every key at every single revision against a model.
Measured afterwards, same benchmark, same machine: 4,200 to 4,800 writes a second with 16 clients, about 8 writes per commit, and half the disk per write. The other half of the gain was not in the store: the gRPC server ran unary calls on 4 threads, so no more than 4 writes were ever in flight. QuantyCore now uses 64. A single client is unchanged at about 950 a second, since it has nobody to share a commit with.
The cost: revision and commit are no longer the same number, so the store keeps an index between them, and reading inside a group costs a scan of that group's log. Bookkeeping commits, such as compaction and leases, no longer take a revision at all, which also makes revisions dense again. etcd is still faster at 16 clients on this machine, by roughly half again; the server is now bound by CPU per write, which is the next thing to profile.