Disaggregated memory lets a database pool its memory separately from its compute and scale each independently, but when many transactions fight over the same hot data the system bogs down — largely because existing designs conflict at the granularity of a whole record, so two transactions touching different columns of the same row needlessly abort each other; this paper (Chinese Academy of Sciences and CUHK — Qihan Kang, Mi Zhang, Patrick Lee, Yongkang Hu) presents CREST, which controls concurrency at the level of individual cells, works on local uncommitted results to cut waiting, and commits transactions in parallel, reaching up to 1.92 times the throughput of the state of the art under high contention.
The argument in one glance
-
Problem
Disaggregated transactions scale well, but collapse when data is hot
A distributed transaction system guarantees the familiar database properties — atomicity, consistency, isolation, durability — across many machines, which is what applications like e-commerce and banking depend on. Traditionally each server owns both its compute and its memory, tightly coupled, which makes it hard to scale one without the other. Memory disaggregation breaks that coupling: compute nodes (lots of CPU, little memory) and memory nodes (lots of memory, little CPU) become separate pools connected by a fast network using Remote Direct Memory Access (RDMA), so a compute node can read and write remote memory directly without troubling the memory node's weak CPU. This scales resources flexibly and has been shown to speed up transaction processing under ordinary workloads. But real applications are not ordinary: they have hotspots, where many concurrent transactions fight over the same popular data items. This is called contention, and under high contention these disaggregated systems degrade badly — throughput drops and latencies spike. The very workloads that matter most in practice are the ones where the current designs struggle, so the promise of disaggregated transactions is undercut exactly where it is needed.
-
What people did
Use record-level concurrency control, as the best disaggregated systems do
The leading disaggregated transaction systems, FORD and Motor, resolve contention with record-level concurrency control: to keep transactions correctly serialized, they lock and validate at the granularity of a whole record (a whole database row), acquiring a lock on each record a transaction will touch and holding it for the duration of the transaction. This is the natural, well-understood unit for concurrency control, and it maps cleanly onto RDMA operations.
-
Why it fell short
Whole-record conflicts cause false aborts and long blocking
Record-level control is too coarse for high contention, in two ways. First, it manufactures false conflicts. If two transactions both touch the same record but actually read and write different column fields — one updates the balance, another updates the address — record-level control still sees them as conflicting and aborts one of them, even though they never truly overlap. The paper measures this: under a high-contention benchmark, abort rates climb to around 76 to 85 percent, and a large fraction of those aborts are false conflicts (about 44 percent of aborts for one system), pure wasted work. Second, locking the whole record for the whole transaction prolongs blocking: other transactions that need any part of that record must wait until the holder finishes and commits, and committing to remote memory over the network is itself slow, so the blocking time balloons under contention. So the coarse granularity both aborts transactions that did not really conflict and makes the ones that did conflict wait far too long. What was missing was a disaggregated transaction design that conflicts only when data truly overlaps and that keeps waiting transactions moving.
-
This paper's idea
Conflict at the cell, execute locally, and commit in parallel
CREST is a disaggregated transaction system built for high contention, resting on three techniques. First, cell-level concurrency control resolves conflicts at the granularity of a cell — an individual column field of a record — rather than the whole record, so two transactions touching different fields of the same row proceed concurrently instead of falsely aborting. Because per-cell metadata could mean many separate RDMA calls, CREST uses a metadata-aggregated record structure that packs all of a record's cell metadata (a per-cell version number plus a lock) into a single cacheline, so one RDMA read can validate every cell at once. Second, localized execution lets a compute node operate on its own local, uncommitted results rather than waiting to fetch committed data from remote memory, and pipelines transactions within a node, so a later transaction need not block on an earlier one's remote commit. Third, parallel commits let transactions commit at the same time even when they depend on one another, using dependency-tracking redo-logging and a last-writer-wins rule so that only the latest valid version reaches remote memory and serializability is preserved. Together these cut false aborts, shorten blocking, and remove the serial commit bottleneck, and CREST achieves up to 1.92 times the throughput of state-of-the-art systems under high-contention workloads while maintaining full ACID guarantees.
Why this problem is worth solving
Disaggregated memory is a compelling way to scale databases, and contention is the case that decides whether it is usable in practice. Memory disaggregation is attractive for databases because it lets you provision compute and memory independently, avoid stranding either resource, and grow a pool without migrating data around — real systems from ByteDance, Alibaba, and Huawei already use RDMA-based disaggregated memory for transactions. But a transaction system lives or dies by how it behaves under contention, because contention is not a corner case: real workloads have hotspots — a handful of popular products, accounts, or rows that a large share of transactions all want at once. When the system serializes access to these hot items poorly, throughput collapses and tail latencies explode, which is exactly the situation that hurts an online service most. So the value of solving high-contention performance is not incremental; it determines whether disaggregated transactions can be deployed for the demanding, skewed workloads that dominate production, rather than only the gentle uniform workloads used in early demonstrations.
The deeper issue is that the standard unit of conflict, the record, is coarser than the data transactions actually touch. Concurrency control decides when two transactions conflict and must be ordered or aborted. If it declares a conflict whenever two transactions touch the same record, it will flag conflicts that are not real: a database row often has many columns, and two transactions frequently touch different columns of the same row, which do not actually interfere. Aborting one of them is pure waste — the paper finds a large fraction of aborts under contention are exactly these false conflicts. Coarse granularity also worsens blocking, because a lock on the whole record, held for the whole transaction, forces anyone needing any field of that record to wait, and in disaggregated memory the wait includes slow remote commits over the network. The realization is that both problems stem from the same source: the system reasons about conflicts and holds locks at a granularity coarser than the data actually in use. If concurrency control operated at the granularity of the individual field being touched, and if transactions did not have to sit idle waiting for remote commits, both the false aborts and the excess blocking would shrink. Turning that insight into a correct, RDMA-efficient system is the challenge.
What people did before, and where it broke
- Lock and validate at record granularity (FORD, Motor). Treat a whole database row as the unit of conflict. Where it broke. Two transactions touching different columns of the same row are declared to conflict and one is aborted, producing many false aborts (a large share of all aborts under contention).
- Hold record locks for the whole transaction. Acquire a lock per record and keep it until commit to ensure serializability. Where it broke. Every other transaction needing any field of that record blocks until the holder commits, and remote commits over the network are slow, so blocking time balloons under contention.
- Fetch committed data from remote memory before executing. Read the current committed values from the memory pool for each transaction. Where it broke. Later transactions wait on the remote reads and commits of earlier ones, adding network round-trips to the critical path exactly when contention is high.
- Commit transactions serially to preserve order. Apply commits one at a time so dependent transactions are ordered correctly. Where it broke. Serial commit becomes a bottleneck under contention, since dependent transactions cannot make progress in parallel.
- The gap. No disaggregated transaction system conflicted only at the true granularity of the data, kept blocked transactions progressing on local results, and committed dependent transactions in parallel while preserving serializability.
How CREST works
Resolving contention at the cell, locally, and in parallel
-
-
new
-
new
-
new
-
new
-
new
The idea
Stop aborting transactions that never truly conflicted. CREST’s cell-level concurrency control exists to eliminate the wasteful aborts that record granularity creates, letting transactions that touch different fields of the same row coexist instead of forcing one to retry. Cutting the cost of contention by making conflicts precise, so that concurrent work is not needlessly thrown away and retried, is the same undertaking the work on bounding speculative execution of atomic regions to a single retry (cleAR) covered elsewhere on this site pursues, attacking the waste of repeated aborts in concurrent execution. CREST does it by tracking conflicts at the granularity of the individual cell, so the abort rate under contention drops sharply.
Work on data you already have locally instead of waiting for the network. Localized execution is CREST’s way of keeping transactions moving: a compute node operates on its own cached, uncommitted results rather than stalling on remote reads and commits, hiding the disaggregated network latency behind local progress. Serving a computation from a local, fast copy so it need not repeatedly reach across a slow interconnect is the same principle the work on scaling up memory-disaggregated applications (SMART) covered elsewhere on this site is built on, keeping the working set close to the compute to cut remote round-trips. CREST applies this to transaction execution, pipelining transactions within a node so later ones do not block on earlier ones’ remote commits.
Run commits out of their strict order, but guarantee the order still holds. Parallel commits let CREST finalize dependent transactions concurrently, which would normally risk violating serializability, so it adds dependency tracking and a last-writer-wins rule to ensure the outcome is exactly as if they had committed in order. Extracting parallelism by reordering or overlapping operations while formally preserving the correctness the strict order guaranteed is the same idea the work on formally verified out-of-order execution in dataflow circuits (Graphiti) covered elsewhere on this site develops, reaping concurrency without breaking the ordering semantics. CREST uses dependency-tracking redo-logging so only the latest valid version reaches remote memory and the committed history stays serializable.
Following two contending transactions through CREST
Two transactions on the same hot record, resolved cheaply
A trace, drawn from the paper, of how CREST processes contending transactions on a disaggregated memory database.
Step 1 of 5
Two transactions target the same record, different columns
Both transactions need the same hot database row, but one reads and writes one column field while the other touches a different field. Under record-level control, they would be declared to conflict and one would abort.
This false conflict is a major source of wasted work under high contention.
Why it works
- Cell granularity removes false conflicts. Record-level control aborts transactions touching different columns of one row → but conflicting at the cell means only true overlaps conflict → so the abort rate under contention falls sharply and the retried work disappears.
- Aggregated metadata keeps cell control RDMA-cheap. Per-cell locks and versions could mean many RDMA calls → but packing all cell metadata into one cacheline lets a single RDMA read validate every cell → so fine granularity does not amplify network traffic.
- Local execution hides remote latency. Fetching committed data and waiting on remote commits stalls later transactions → but operating on local uncommitted results lets them progress immediately → so blocking time shrinks even though memory is remote.
- Pipelining overlaps transactions within a node. Running transactions strictly one after another underuses the compute node → but pipelining executes them concurrently → so per-node throughput rises under contention.
- Dependency tracking makes parallel commits safe. Committing dependent transactions at once could violate serializability → but dependency-tracking redo-logging plus last-writer-wins fixes the committed order → so commits parallelize without sacrificing correctness.
What it costs (trade-offs and scope)
- Cell metadata adds space and needs careful bounding. Tracking a version number and lock per cell adds metadata; CREST keeps it cheap by aggregating it into one cacheline and capping the number of cells (its version array supports up to twenty cells), and it handles version-number rollover with a time-threshold fallback that reads the whole record — a modest but real complexity.
- The gains concentrate under high contention with multi-column records. The benefit comes from eliminating false conflicts across columns; workloads that are largely uncontended, or that touch whole records, see little improvement (one benchmark with mostly uncontended transactions shows CREST roughly matching, not beating, the median latency of a rival).
- Localized execution requires per-node caching machinery. Operating on local uncommitted results needs a compute-node record cache with version lists, reference counts, and read-write or read-only modes, plus two-phase locking among local transactions — extra memory and bookkeeping on the compute nodes.
- Correctness under localized execution and parallel commits is intricate. Allowing local uncommitted operation and out-of-order commits means CREST must resolve both local (within a node) and global (across nodes) conflicts and keep remote memory consistent with local state; this is handled by dependency tracking and consistency checks, but it is added correctness-critical logic.
- It targets RDMA one-sided disaggregated memory with specific assumptions. CREST is built for one-sided RDMA primitives and primary-backup replication, and leans on assumptions such as short-lived transactions and knowing in advance which columns a transaction reads or writes; other settings would need adaptation.
The evaluation
Disaggregated transactions under high contention
| Property | FORD / Motor (record-level) | Naive fine-grained locking | CREST |
|---|---|---|---|
| Conflict granularity | |||
| False aborts under contention | |||
| Blocking while others commit | |||
| Commit | |||
| Throughput under high contention |
Check yourself
Check your understanding
1. Why do record-level disaggregated transaction systems degrade under high contention?
2. What is cell-level concurrency control, and how does CREST keep it from flooding the network with RDMA calls?
3. How does localized execution reduce the blocking time of transactions on disaggregated memory?
4. Predict: CREST commits several transactions that depend on one another in parallel rather than one at a time. What danger does this create, and how does CREST avoid it?
Sources
The paper is “CREST: High-Performance Contention Resolution for Disaggregated Transactions” by Qihan Kang, Mi Zhang, Patrick P. C. Lee, and Yongkang Hu (State Key Lab of Processors, Institute of Computing Technology, Chinese Academy of Sciences and University of Chinese Academy of Sciences; and the Department of Computer Science and Engineering, The Chinese University of Hong Kong), published at ASPLOS 2026, DOI 10.1145/3779212.3790148. It is licensed CC BY, with an author copy hosted at CUHK and a prototype open-sourced at github.com/adslabcuhk/crest.
This explainer is written from the paper’s full text (the authors’ hosted copy). CREST is a disaggregated transaction system that efficiently manages high-contention workloads on RDMA-based disaggregated memory via three techniques: cell-level concurrency control, which achieves finer-grained concurrency than record-level approaches and uses a metadata-aggregated record structure (per-cell version and lock in one cacheline) to reduce remote access latencies; localized execution, which lets compute nodes operate on local uncommitted results with pipelined execution to reduce blocking time; and parallel commits, which parallelize commit operations under transaction dependencies using dependency-tracking redo-logging and last-writer-wins to preserve serializability. The paper shows state-of-the-art systems FORD and Motor suffer high abort rates and false conflicts under contention, and reports that CREST achieves a throughput gain of up to 1.92 times over the state of the art (1.92, 1.46, and 1.85 times over Motor and 2.76, 1.89, and 2.58 times over FORD on TPC-C, SmallBank, and YCSB) while maintaining ACID guarantees and redo-log-based crash recovery. Numbers are the paper’s own; exact protocols, correctness arguments, and full results should be confirmed in the paper.