Papers for

cloud database engineers

Papers whose findings have a practical use for this group, as judged from the abstract. Open a paper to read what it means in practice.

Single-version concurrency control suits cloud transactions better

The Case for Single-Version Concurrency Control in the Cloud

Abstract: Multi-version concurrency control (MVCC) has been the dominant concurrency protocol in modern database management systems (DBMSs). However, cloud-native HTAP architectures shift many of MVCC's traditional advantages from the primary transaction engine to the deployment architecture. Now, transactional and analytical processing are decoupled into loosely synchronized engines, while cloud deployment primitives provide the workload isolation required for this design. In this paper, we challenge the status quo, arguing that single-version concurrency control (SVCC) is better suited to cloud transaction processing than MVCC. Through a systematic analysis of MVCC's limitations, we show that SVCC avoids these shortcomings through a more lightweight and efficient design. Beyond arguing for a lighter transaction processing, we use this SVCC effort as a blueprint to advocate for a broader rethinking of cloud-native architectures and to outline a research roadmap to shape next-generation DBMSs.

Sun 11 OctDatabases
The gist
Many modern databases use a method called multi-version concurrency control (MVCC) to handle multiple users accessing data at the same time. The authors explain that in cloud computing, where database tasks are split between different systems, the usual advantages of MVCC are less important. They argue that a simpler method called single-version concurrency control (SVCC) actually works better in cloud setups because it is lighter and more efficient. The authors suggest rethinking how cloud databases are built and provide ideas for future research based on SVCC.
Open → 2610.15793v1

Kernel I/O flushing limits cloud database speed and latency

Invisible Yet Dominant: Big Stalls of Kernel I/O Mechanisms in Cloud OLTP Databases

Abstract: Most databases, including PostgreSQL, RocksDB, and recent AI KV-cache middleware, rely on buffered I/O, delegating write-back to the Linux kernel. On the distributed block storage standard in the cloud, this delegation inherits a hidden bottleneck: each device is drained by a single kernel flusher thread over a high-latency, shallow-queue path. When the drain falls behind, dirty throttling pauses write() system calls, and even reads that must evict dirty pages stall. These stalls are invisible to iostat and every standard counter. This poster observes the stall from inside the kernel, using the multi-volume data placement proposed in SteelDB as the experimental lever. eBPF probes on writeback and block tracepoints separate write-back by issuing context and count every throttle pause. Across three configurations with identical provisioned IOPS and bandwidth but 1, 2, and 4 devices, we show that adding drains, not bandwidth, cuts throttle pauses by 70%, reduces maximum transaction latency by 59%, and raises throughput by 23%.

Fri 11 SeptDatabasesOperating Systems
The gist
Databases like PostgreSQL depend on the Linux kernel to manage writing data to disk, but the authors found a hidden slowdown in how the kernel handles this in cloud environments. A single thread per device handles flushing data, which can cause delays invisible to standard monitoring tools. The authors used special kernel probes to measure this stall and discovered that adding more of these flushing threads, rather than just increasing bandwidth, significantly cuts delays and speeds up database transactions. This finding could help make cloud databases faster and more reliable.
Open → 2609.12597v1