Layers Where Transaction Costs Sit

Four papers from 2026 show designs that put the costs of version management, conflict detection, and replay in layers other than a single engine. This post judges that decisions made inside a single engine, such as MVCC, must be checked again by the layer where each cost accumulates.

Multi-version concurrency control (MVCC) was a choice that let a single engine serve long reads and short writes together. Version management, conflict detection, and log replay all occurred in the same engine, so their costs were calculated in one place. The basic operation of MVCC is covered in Database Transactions and MVCC.

Cloud online transaction processing (OLTP) separates a compute layer for writes, a storage layer for logs and data, and read replicas and analytical engines. Four papers published in 2026 show designs that put version management, conflict detection, and replay costs in layers other than a single engine. Three papers cover cloud OLTP, and Ira covers primary-backup replication in Ethereum.

No paper of the four compares the total cost of the same workload when only the location of a cost changes. But the gains and losses of the same technique can change with the layer that pays its cost. Thus, this post judges that you must find these locations before you select a design.

A Proposal to Remove Versions from the Primary

A paper accepted to CIDR'27 (arXiv:2610.15793, 2026-10) argues that the primary instance of cloud OLTP should not use MVCC. The alternative is single-version concurrency control (SVCC), which keeps only one physical version per object. The argument starts from the single-writer architecture of systems such as Aurora, Socrates, Taurus, and PolarDB.

In a single-writer architecture, one primary instance handles all writes, and replicas or a separate analytical engine run long analytical queries. The paper states that this deployment, not the concurrency control inside the engine, now gives non-blocking reads, the main advantage of MVCC.

In the paper's logic, MVCC on the primary then keeps only its costs: version storage, garbage collection (GC), and tuple metadata. According to the prior work that the paper cites, visibility metadata usually adds 16-32 bytes or more per record.

The authors implemented both protocols on LeanStore to compare complexity. The SVCC version uses two-phase locking (2PL) with Wait-Die deadlock prevention (see Concurrency Control and Synchronization). The MVCC version follows the HyPer style (in-place updates, an undo log, and validation at commit), but it validates per key instead of by predicate.

The authors summarize the engineering cost of MVCC as about 2-3 times higher. The sum of the three items is 1,013 lines and 2,016 lines, which is about 2 times.

The largest ratio is in integration modifications (about 5.9 times), and the largest absolute gap is in tests (660 lines). The authors attribute the core and modification gaps mainly to integrating version chains with indexes.

The throughput comparison supports only narrow conclusions. The paper calls this run a lightweight TPC-C run and states that the comparison focuses on complexity more than performance.

The authors state that both implementations have high overhead from Intel TBB (Threading Building Blocks) concurrent hash tables. They also state that the short run minimizes secondary effects such as GC. Both implementations synchronize per key without range locks, so they permit phantom reads, and the paper does not give the hardware or the warehouse count.

Long transactions remain an open problem. The paper proposes three extensions: limits on transaction size and duration, lightweight snapshots, and speculative execution. All three are left for future work, and the paper has no implementation or measurement for them.

Version Cleanup Costs in Production Data

The SQL Azure version cleaner paper (PVLDB 19(12), 2026) shows, with production telemetry, the MVCC cleanup cost that stays inside the engine. SQL Azure updates a row in place and keeps the previous version in the row or in the Persistent Version Store (PVS). These versions serve snapshot reads under isolation levels such as RCSI (Read Committed Snapshot Isolation), the default. They are also used to remove partial updates that rolled-back transactions left.

This paper cites the Socrates paper as the reference for SQL Azure Hyperscale. Thus, MVCC cleanup stayed an operational problem in the same family of systems that the SVCC paper uses as a single-writer example.

A background cleaner reclaims versions that are no longer necessary, and the authors found three cleaner problems in production telemetry. On Hyperscale databases, which can be larger than 100TB, a full sweep by the single-threaded cleaner sometimes took more than one week under high activity. Under frequent updates, the cleaner could not get locks and delayed cleanup, and aborted or long-running transactions delayed the cleanup watermark.

User-assisted cleanup gives cleanup work to the user transaction that holds the conflicting table lock. This design moves part of the cleanup cost from background work to foreground transactions, and it currently operates only when an exclusive lock is held.

The success rate and failure count in the last row are copied from the paper. The 98.6% rate and about 52K failures agree with each other (52K / 3.76 million ≈ 1.4%). But the paper also gives 3.23 million successes for the same count, which is about 86% and agrees with neither value. Thus, the exact success rate cannot be confirmed from the paper alone.

These improvements run on more than 12 million databases, and their effect was evaluated only with production telemetry. TPC-C and TPC-E transactions are short, so PVS does not reach the cleanup thresholds, and the authors used these benchmarks only for regression checks. The SVCC paper also states that its short TPC-C run reduced GC effects. In both papers, the short benchmarks could not show this cost.

Coordination at Commit and Time-Based GC

The Aurora DSQL paper (arXiv:2607.13276, 2026-07) describes an architecture that splits compute, storage, and transaction coordination into independent services. A query processor (QP) reads storage nodes at the snapshot of the transaction start time. The QP keeps writes such as UPDATE only in its own buffer. An Adjudicator does conflict detection at commit time, and the Journal makes committed changes durable and replicates them.

flowchart LR
  C["Client"] -->|"SQL"| Q["QP<br/>snapshot reads, write buffer"]
  Q -->|"reads at start time"| S["Storage node<br/>MVCC versions, time-based GC"]
  Q -->|"COMMIT, write set"| A["Adjudicator<br/>write-write conflict detection"]
  A -->|"logical post-image"| J["Journal<br/>durability and replication"]
  J --> X["Crossbar<br/>merge sort per storage shard"]
  X -->|"apply changes"| S

In this architecture, reads and statement execution finish inside one region, and cross-region coordination occurs only at commit. The latencies below are from a microbenchmark with simple primary-key transactions (Figure 6 of the paper).

In a cluster across us-east-1 and us-east-2 with a witness in us-west-2, primary-key SELECT had a p99 of about 2ms, and UPDATE had about 3ms. COMMIT had a p99 of about 30ms in this multi-region setup and 7.4ms in a single-region setup. The p99 round-trip time between the two primary regions is 14.4ms.

Conflict detection uses optimistic concurrency control (OCC). The Adjudicator checks whether another transaction wrote the same keys between the start and the commit of the transaction.

The default and only isolation level is strong snapshot isolation, so read-write conflicts do not cause aborts, and write skew is possible. DSQL adds read-write conflict checks only for exceptions such as the catalog and FOR UPDATE.

The coordination cost appears as aborts and retries at commit time. A transaction across many Adjudicators votes with a variant of two-phase commit (2PC). The paper states that commit latency increases with the number of Adjudicators involved.

Another design that delays coordination to a commit boundary is covered in Epoch-Based Optimistic Concurrency Control. The flow in which a commit log keeps consistency is covered in From 2PC to the Commit Log.

DSQL keeps MVCC versions in the storage layer. The paper states that GC is especially difficult in this architecture, because no component knows the full list of running transactions. Thus, DSQL caps transaction run time, and each storage server discards old versions after a fixed time without coordination with other servers.

The current value of this time is five minutes. If a read arrives with an older start time, the storage node rejects it and the transaction fails. The authors do not consider this approach acceptable for analytics or online analytical processing (OLAP) systems, and DSQL offers change data capture streams for analytics. SQL Azure sets the cleanup point with global watermarks, and DSQL sets it with a transaction length limit.

On a basis different from GC, DSQL limits each transaction to 3,000 modified rows and 10MiB of data. The paper bases this limit on operational experience with bounding tail latency, and it adds Little's Law as a partial reason. The paper states that customer feedback about this limit was larger than expected. The team is working on a change to give more control over transaction size.

The location of replay work is also different. The Journal records logical post-images that include index changes, and the QP calculates these index changes before commit. Storage nodes can apply these records deterministically without a local read-modify-write, and they do not coordinate with each other.

In exchange, a storage node responds only after it confirms that it has received all commits at or before the read time. The Adjudicator uses a heartbeat to move its commit time forward with the physical clock. A read waits if the storage node has not reached that time. The paper compares this with single-writer designs such as Aurora PostgreSQL, which expose eventual consistency on replica reads.

Hints That Move Replay Cost to the Primary

The Ira paper (arXiv:2601.21286, first published 2026-01, v3 2026-08) covers primary-backup replication in reth, an Ethereum execution client. It is not a case of cloud OLTP with separate compute and storage. This post uses it only as evidence for a design that moves replay cost between nodes.

A backup re-executes the transactions that the primary executed to keep the same state. The paper states that consensus latency is bounded by this replay time. In Ira, the primary sends the set of keys it accessed during execution as a hint, and the backup uses the hint to prefetch data.

The experiment used 100,800 Ethereum mainnet blocks and cleared the OS page cache before each run. The hardware was a 10-core Apple M1 Pro, 32GB of memory, and an 8TB NVMe SSD in an external USB enclosure.

The primary and backup baselines are different measurements. The 10.9% in the abstract is the hint construction and serialization time, 1,719 s, divided by the total execution time, 15,717 s. The wall-time increase is 28.6%, and the authors attribute the remaining increase to secondary effects of instrumentation, such as memory pressure and cache interference.

The authors claim that overlapping hint work with execution of the next block brings the effective cost close to zero. They did not measure this pipeline. The median compressed hint size is 46.5KB per block.

The effect was smaller in another block range. In a range of 100,001 blocks from September to October 2024, the backup speedup with 16 threads was 10.1x, and the hint cost was 7.3%. The authors explain this difference as a workload effect.

The tail also remains. With 1 prefetch thread, 3.02% of blocks were slower than the baseline, and with 64 threads, 0.09% were slower. A malicious hint with keys that do not exist was replayed on 1,000 random blocks with 16 threads. The median slowdown was 1.58x, the P99 slowdown was 8.3x, and 81.5% of blocks became slower.

The paper treats hints as advisory, so it states that an incorrect hint affects only performance and not correctness. Its conditions for use are a primary-backup architecture with a node that executes first, replay that is bound by storage I/O, and deterministic execution.

The paper gives database uses, such as PostgreSQL streaming replication and MySQL Group Replication, only as integration sketches without measurement. The authors also state as a limitation that their implementation targets a single-threaded execution model.

Ira moves backup I/O wait to primary execution time, and the authors expect the gain to increase with more backups. In single-writer cloud OLTP, the primary sets the upper limit of write throughput. With this method in that architecture, the primary time increase (28.6% in the Ethereum experiment) adds to the layer whose cost SVCC tries to reduce. This is a judgment.

Conditions Where the Claim Fails

The SVCC paper itself accepts that snapshot reads on the primary are fresher than replica reads with millisecond-scale replication lag. If reads must see the latest snapshot without blocking on writes, non-blocking reads cannot be given to the deployment. The lightweight snapshots that SVCC proposes are not implemented. This is a judgment.

DSQL gives this freshness by making the storage node wait until it reaches the read time. The cost then appears as read wait in the storage layer.

SQL Azure uses its version store for snapshot reads and also for recovery features such as Constant Time Recovery. The SVCC paper does not say what replaces these features when versions are removed. Removing versions from the primary can create costs in other metrics, such as recovery time. This is an estimate.

High contention is also not covered. The related work section of the SVCC paper cites the CCBench study (Tanabe et al., 2020). It states that MVCC is better than SVCC only in limited cases, such as high contention. But the paper has no measurement of the SVCC prototype under a high-contention workload.

SVCC proposes size and duration limits for long transactions, and DSQL limits transactions to five minutes, 3,000 rows, and 10MiB. Instead of a limit, SQL Azure uses statement-level cleanup to reclaim part of the PVS that a long snapshot holds before that snapshot ends. The SVCC and DSQL limits make the application split work such as bulk loads. Thus, they pass the cost to another party instead of removing it. This is a judgment.

The SVCC paper claims that modern engines make serializability practical. As one reason for snapshot isolation, DSQL states that it avoids the read-write conflict aborts that serializability requires. A single primary that locks during execution pays for serializability in a different place than a distributed commit that validates at commit time. Thus, a conclusion from one architecture does not transfer directly to the other. This is a judgment.

The four papers also leave a question open. No paper compares the total cost of the same workload when only the location of version management changes. The SVCC extensions are not implemented, and the Ira database uses are sketches. The SQL Azure numbers measure the effect of improvements inside the same system.

Criteria by Cost Location

This post proposes two criteria to select a concurrency control and replication design. The first is the layer where each cost accumulates, and the second is whether that layer is already a bottleneck. The table shows the cost locations that the four papers propose or observe.

From these locations, the next table gives candidate designs and their costs for each situation. The match between situation and candidate is a judgment, and the cost column contains only costs that each paper reports or accepts.

If the primary is already the write bottleneck, examine options that add work to the primary last. MVCC cleanup and hint generation are such options. This is a judgment.

References

• The Case for Single-Version Concurrency Control in the Cloud, arXiv:2610.15793 (2026-10, accepted to CIDR'27)
• Highly Scalable SQL Azure MVCC Version Cleaner, PVLDB 19(12) (2026)
• Aurora DSQL: Scalable, Multi-Region OLTP, arXiv:2607.13276 (2026-07)
• Ira: Efficient Transaction Replay for Distributed Systems, arXiv:2601.21286 (2026-01, v3 2026-08, accepted to USENIX Security 2026)

Every figure was checked against each original source as of 2026-10.

Summary

Four papers from 2026 show designs that put the costs of version management, conflict detection, and replay in layers other than a single engine. The SVCC paper proposes to remove version management from the primary. The SQL Azure paper shows with production data the MVCC cleanup cost that stays in the engine. DSQL collects conflict detection at commit and decides GC timing with a time cap. Ira moves part of the backup replay cost to the primary in Ethereum primary-backup replication.

The costs of these designs appear as transaction length limits, aborts at commit, read wait on storage nodes, and longer execution time on the primary. The SVCC throughput comparison comes from a short TPC-C run, and the Ira replay gain comes from Ethereum replay. No paper compares the total cost of the same workload. Thus, the conclusion that designs must be checked again by the layer where each cost accumulates is a judgment of this post. Before you change a design, find the layer where each cost will go and check whether that layer is already a bottleneck.