High-Performance DBMSs with io_uring: When and How to use it (2512.04859v1)

Abstract: We study how modern database systems can leverage the Linux io_uring interface for efficient, low-overhead I/O. io_uring is an asynchronous system call batching interface that unifies storage and network operations, addressing limitations of existing Linux I/O interfaces. However, naively replacing traditional I/O interfaces with io_uring does not necessarily yield performance benefits. To demonstrate when io_uring delivers the greatest benefits and how to use it effectively in modern database systems, we evaluate it in two use cases: Integrating io_uring into a storage-bound buffer manager and using it for high-throughput data shuffling in network-bound analytical workloads. We further analyze how advanced io_uring features, such as registered buffers and passthrough I/O, affect end-to-end performance. Our study shows when low-level optimizations translate into tangible system-wide gains and how architectural choices influence these benefits. Building on these insights, we derive practical guidelines for designing I/O-intensive systems using io_uring and validate their effectiveness in a case study of PostgreSQL's recent io_uring integration, where applying our guidelines yields a performance improvement of 14%.

• The paper demonstrates that integrating io_uring with DBMS architectures can yield an order-of-magnitude increase in throughput through effective asynchronous execution and batching.
• It shows that advanced io_uring features such as registered buffers, NVMe passthrough, and zero-copy networking are key to reducing syscall overhead and maximizing hardware efficiency.
• It provides practical guidelines and empirical evidence for redesigning DBMS components to overcome I/O bottlenecks and align optimizations with hardware capabilities.

High-Performance DBMSs with io_uring: Design, Integration, and Optimization

Motivation and Overview

The Linux io_uring interface has emerged as a transformative development for asynchronous I/O, aiming to address the widening gap between hardware capabilities—such as multi-million IOPS NVMe SSDs and 400 Gbit/s NICs—and the inefficiencies of legacy I/O APIs (POSIX, libaio, epoll) (2512.04859). The paper systematically investigates how database systems (DBMSs) can benefit from io_uring by analyzing architectural choices, workload characteristics, and fine-grained optimizations across both storage-bound and network-bound scenarios. Considerable emphasis is placed on deriving actionable guidelines for when, how, and how much to use io_uring in the design and deployment of high-throughput DBMSs.

Architectural Foundations of io_uring

io_uring provides three core features that distinguish it from previous Linux I/O interfaces:

• Unified API: Merging storage, network, and system calls within a single asynchronous interface, which is highly advantageous for DBMSs needing tight coordination of disk and network operations.
• Asynchronous, Completion-based Execution: Utilizing completion queues rather than readiness-based polling, and enabling efficient handling of large volumes of I/O requests without blocking user threads.
• Batch Submission/Completion: Allowing multiple I/O operations to be submitted and completed with amortized syscall and context-switch overheads.

The typical user-space DBMS interacts with the kernel via memory-mapped Submission Queues (SQ) and Completion Queues (CQ), enabling efficient data exchange.

Figure 1: Architecture of io_uring showing interaction via SQ/CQ for unified asynchronous I/O.

Crucially, optimal performance is not achieved by simply substituting legacy APIs with io_uring; instead, architectural redesign is needed to expose enough parallelism and batching to saturate hardware.

Case Study: Buffer-Managed Storage Engine Integration

Baseline and Incremental Optimizations

The first use case centers on a transactional buffer manager atop high-performance NVMe SSD arrays. Initially, synchronous operation (one outstanding I/O per transaction) ties DBMS throughput linearly to device latency, with little benefit from io_uring. For heavily I/O-bound YCSB workloads:

• Synchronous implementations using both POSIX and io_uring reach only ~16.5k TPS, matching a simple analytical model based on device latency.

Batching write operations with io_uring provides a modest 14% gain, demonstrating that architectural restructuring is a prerequisite for substantial improvement.

Asynchronous and Cooperative Execution

Utilizing cooperative fibers for concurrent transactions enables asynchronous I/O, leading to an order-of-magnitude throughput increase to ~183k TPS. Here, the bottleneck shifts to CPU cycles expended per transaction, as high concurrency hides I/O latency.

• Adaptive batching of read requests further improves efficiency (~18% gain, up to 216k TPS), exploiting device parallelism and reducing syscall overhead.

  Figure 2: YCSB throughput under different buffer manager and I/O designs; incremental optimizations increase throughput from 16.5k to 546.5k TPS.

Advanced io_uring features—registered buffers, NVMe passthrough, IOPoll, SQPoll—incrementally reduce per-I/O overhead, amping single-threaded throughput to over 546k TPS. Registered buffers (zero-copy DMA) alone yield an 11% improvement, NVMe passthrough adds 20%, and eliminating syscalls with SQPoll increases throughput by 32%.

Multi-Threaded and Block Size Dispatch

Scaling cores linearly increases overall throughput until bottlenecked by the OS storage stack. Larger I/O block sizes amortize costs further but can trigger fallback worker threads when hardware or kernel limits are exceeded, introducing additional latency and overhead.

Figure 3: Scale-out performance for random 4KiB reads/writes showing io_uring's superiority over libaio and strong scaling.

Figure 4: Increasing block sizes improves CPU efficiency, but enables I/O workers (fall-back) at large sizes, limiting passthrough support.

Durability and fsync Behavior

Durable writes (e.g., fsync) are expensive and require blocking execution paths even with io_uring. Only enterprise SSDs with PLP enable microsecond-level durability, while consumer devices remain challenged by millisecond-scale latencies.

Figure 5: Durability via fsync and passthrough; enterprise SSDs avoid the need for explicit fsync.

OLTP Workload Implications

For less I/O-intensive, compute-bound TPC-C workloads, gains from io_uring optimizations are restricted, manifesting only under out-of-memory, storage-heavy conditions.

Figure 6: TPC-C throughput comparison with varying warehouse counts: io_uring-based manager outperforms blocking I/O, strongest gains are storage-intensive.

Case Study: Network-Bound Analytical Shuffle

The second use case focuses on network-centric distributed shuffles, as encountered in distributed joins. A ring-per-thread approach fully overlaps computation (e.g., hash-table builds) and asynchronous network I/O, facilitating scale and cache-locality.

• Zero-copy send/receive (enabled by registered buffers and recent kernel support) provides compelling improvements, roughly halving memory bandwidth consumption per unit of network throughput.

  Figure 7: Shuffle architecture: workers partition tuples and perform I/O with morsel-driven parallelism.

  

  Figure 8: Per-node egress bandwidth: zero-copy networking enables full link utilization with modest core counts.

  

  Figure 9: Memory bandwidth analysis: normalized consumption drops by 2x with zero-copy send/receive.

A head-to-head comparison with epoll shows that batching alone narrows the gap, but only io_uring supports zero-copy receive, yielding up to 2.5x speedup in high-load scenarios.

Figure 10: Speedup of io_uring and zero-copy epoll relative to standard epoll for data shuffling; only io_uring supports zero-copy receive.

Extensive benchmarking details the impact of kernel configuration, buffer registration, message size thresholds, and the efficacy of multi-shot receives for varying workloads.

Practical Guidelines and PostgreSQL Case Study

Derived from detailed analysis, the paper provides four concrete guidelines:

1. Identify I/O bottlenecks: Apply simple analytical models to verify that I/O constitutes the dominant execution cost.
2. Architectural alignment: Redesign DBMS components to overlap asynchronous I/O and computation, and utilize batching.
3. Execution mode tuning: Match io_uring flags and modes (e.g., DeferTR, SQPoll) to workload and hardware characteristics to prevent costly fallback execution.
4. Selective feature adoption: Use optimizations—registered buffers, NVMe passthrough, zero-copy—only above device-dependent thresholds where overhead pays off.

   Figure 11: PostgreSQL scan workload speedup from guideline-driven io_uring optimizations; total throughput improved by 11–15% over vanilla implementation.

Applied to PostgreSQL v18's io_uring backend, these guidelines yield up to 15% additional speedup even within the constraints of a multi-process, filesystem-reliant DBMS architecture.

Contradictory Observations and Limitations

Notably, the paper demonstrates that io_uring offers only modest gains (up to 1.1x) with naive replacement of legacy APIs. Substantial improvements (2x+ in storage, 2.3x+ in network shuffle) accrue exclusively from architectural redesign, concurrency exposure, adaptive batching, and hardware-tuned optimization use. Some advanced features (IOPoll/SQPoll) degrade performance under compute-bound or low-I/O workloads due to unnecessary CPU polling.

Implications and Future Directions

The results decisively indicate that future DBMS design should:

• Prioritize explicit asynchronous architectures over drop-in API swaps.
• Integrate device-level parallelism and batch amortization at every layer of the I/O stack.
• Anticipate emerging kernel capabilities, such as enhanced zero-copy support, for scalable deployment on next-generation hardware.

On the theoretical front, the work formalizes the mapping of performance models from latency-bounds to cycle-bounds in the presence of deep concurrency and batching, supporting analytic prediction of architectural benefit.

Conclusion

The paper establishes that io_uring delivers measurable, sometimes order-of-magnitude performance improvements for I/O-bound database workloads—conditional on holistic architectural redesign, detailed workload analysis, and meticulous configuration tuning. These findings apply across both storage-bound and network-bound engines, informing practical system integration and pointing the way toward future hardware-adaptive database architectures. The guidelines and empirical insights validate that, when correctly leveraged, io_uring significantly narrows the hardware-software performance gap for modern I/O-intensive DBMSs.