Pith. sign in

REVIEW 3 major objections 4 minor 3 cited by

io_uring's benefits in databases are conditional: naive swaps yield 1.06–1.10x, but designs built around batching, async execution, registered buffers, and zero-copy I/O achieve 2.05–2.31x; applying the derived guidelines improves PostgreSQ

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-08-03 18:29 UTC pith:3VLO5ZYV

load-bearing objection Solid, reproducible systems work: io_uring pays off after architectural integration, and the quantitative claims are honestly scoped to one hardware stack. the 3 major comments →

arxiv 2512.04859 v3 pith:3VLO5ZYV submitted 2025-12-04 cs.DB

High-Performance DBMSs with io_uring: When and How to use it

Matthias Jasny , Muhammad El-Hindi , Tobias Ziegler , Viktor Leis , Carsten Binnig This is my paper
classification cs.DB
keywords io_uringasynchronous I/Obuffer managerdatabase systemszero-copy networkingNVMe passthroughPostgreSQLI/O benchmarking
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper asks when and how database systems should adopt Linux's io_uring I/O interface. It argues that simply swapping io_uring in for libaio or epoll yields little—roughly 1.06–1.10x—but redesigning the system around io_uring's distinctive capabilities (batched submission, fully asynchronous execution, registered buffers, polling, and zero-copy networking) can more than double end-to-end performance. The authors demonstrate this in two database use cases: a buffer-managed storage engine and a distributed network shuffle, then distill four practical guidelines and validate them by improving PostgreSQL's io_uring backend by 11–15%. The central message is that io_uring pays off only when I/O is a true bottleneck and the architecture is shaped to expose concurrency, amortize syscalls, and avoid kernel worker-thread fallbacks.

Core claim

The paper's central discovery is an empirical conditional: io_uring's value lies not in the interface itself but in whether the surrounding system is designed to exploit it. In a buffer-managed storage engine with a 70% page-fault workload, a synchronous io_uring buffer manager matches POSIX I/O at 16.5k tx/s; adding batched eviction, cooperative fibers for asynchronous execution, batched reads, registered buffers, NVMe passthrough, IOPoll, and SQPoll raises throughput to 546k tx/s on a single core—2.05x over libaio. For a six-node distributed shuffle, io_uring with zero-copy send and receive halves memory-bandwidth consumption per transferred byte and reaches 400 Gbit/s per node, a 2.31x im

What carries the argument

The load-bearing mechanism is io_uring itself: a Linux asynchronous I/O interface that communicates with the kernel through two shared ring buffers (a submission queue and a completion queue), allowing multiple operations to be submitted with one syscall and completed out of order. Its three execution paths matter for database design—inline completion, poll-set-based non-blocking execution, and a worker-thread fallback for blocking operations (like fsync or oversized I/Os) that the paper shows is slow and should be avoided. The tuning features that carry the argument are registered buffers (pinning user memory to avoid copies), NVMe passthrough (bypassing the generic storage stack), IOPoll a

Load-bearing premise

The guidelines and the reported speedups were measured on one high-end configuration—a recent AMD server with fast PCIe 5 NVMe SSDs, 400 Gbit/s NICs, and Linux 6.15/6.17—and the paper assumes those kernel- and device-dependent behaviors (worker-fallback thresholds, zero-copy crossover sizes, polling latency) are representative enough for production deployments.

What would settle it

Run the same two optimized designs (the buffer manager and the PostgreSQL modifications) on a different kernel version or filesystem (e.g., an LTS kernel, XFS vs. ext4, or consumer-grade SSDs and NICs) and check whether the 2.05x/2.31x end-to-end gains and the 11–15% PostgreSQL improvement persist; if the worker-fallback thresholds or zero-copy crossover sizes shift enough to erase those gains, the generality claim fails.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • A synchronous database that simply swaps its I/O syscalls for io_uring should expect nearly no gain; real gains require batching writes and reads and overlapping I/O with computation, e.g., via cooperative fibers.
  • Once I/O latency is hidden, CPU cycles per I/O become the bottleneck, and features like registered buffers, NVMe passthrough, IOPoll, and SQPoll can cut that cost substantially—but only in I/O-intensive workloads.
  • Zero-copy send and receive are not universally beneficial: they hurt below roughly 1 KiB messages and only win above device- and NIC-dependent thresholds, while multishot receive wins only for small messages.
  • Durable writes are a special pitfall: fsync is blocking in io_uring and falls back to worker threads, O_SYNC is worse than explicit write-plus-fsync, and only NVMe passthrough with explicit flushes gives a fully asynchronous durability path on raw devices.
  • Applying the derived guidelines to PostgreSQL's existing io_uring backend yields an 11–15% speedup for cold-table scans, and the paper attributes the remaining ceiling to PostgreSQL's multi-process architecture and filesystem dependence, which preclude DeferTR, IOPoll, and passthrough.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Editorial extension: the paper's ordering—bottleneck first, architecture second, tuning third—likely transfers to other asynchronous syscall-batching designs, but the specific thresholds and the 14% PostgreSQL gain are tied to the tested kernel, filesystem, SSD, and NIC; production systems should re-measure rather than assume the same magnitudes.
  • Editorial extension: the strongest reusable pattern is combining io_uring with user-space cooperative scheduling (fibers), which lets a single core hide I/O latency without locks; DBMSs built around thread-per-request blocking I/O may need larger refactors to unlock similar gains.
  • Editorial extension: a natural testable extension is to build a decision rule that predicts io_uring's benefit from measurable workload parameters (page-fault rate, message size, I/O batch depth, and device queue limits), which would let system builders estimate gains before committing to an architectural change.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

3 major / 4 minor

Summary. The paper empirically studies when and how io_uring should be used in database systems. It builds two systems: a single-threaded buffer-managed storage engine evaluated with YCSB and TPC-C, and a morsel-driven distributed shuffle evaluated on a six-node cluster with 400 Gbit/s NICs, supplemented by microbenchmarks. A stepwise design shows that naively replacing libaio/epoll with io_uring yields only 1.06x and 1.10x improvements, whereas architectural integration plus advanced features (asynchronous fibers, batching, registered buffers, NVMe passthrough, IOPoll, SQPoll, zero-copy send/receive) yields 2.05x and 2.31x, respectively. Simple latency- and cycle-based models with independently measured constants predict the measured throughput values closely. From these studies, the paper distills four guidelines and applies them to PostgreSQL 18's io_uring backend, reporting an 11-15% speedup over upstream.

Significance. If the results hold, this is a valuable engineering study that fills a gap in the understanding of io_uring for data-intensive systems. Its main contribution is not a new algorithm but concrete, evidence-based guidance on when io_uring helps and how to integrate it. Strengths include direct end-to-end measurements, an incremental ablation that separates architectural effects from feature tuning, analytical models whose predictions match measurements (e.g., 17.4k vs. 16.5k, 190.8k vs. 183k, 230k vs. 216k tx/s), and a public artifact. The main limitations are that all experiments were performed on one hardware/kernel stack and that no variance information is reported, which limits the quantitative portability of the guidelines.

major comments (3)
  1. [§3.3–3.4, Figures 5–7; §5.2, Figure 17] The paper does not report repeated-run variance or confidence intervals for any of the headline throughput figures. This is load-bearing for the central validation claim: the 11–15% PostgreSQL speedup and the 4–7% component-level gains in Figure 17 could be within run-to-run noise on a single machine. Please state the number of runs, report error bars or at least min/max ranges, and describe the variance behavior. Without this, the quantitative strength of the 'when and how' claim is not established.
  2. [§3.6, §4.6, §5.1] The prescriptive guidelines are derived from a single, carefully tuned environment: Linux 6.15/6.17, AMD 3.7 GHz server, Kioxia CM7-R PCIe 5 SSDs, ConnectX-7 400 Gbit/s NICs. The paper itself identifies mechanisms that make the numbers environment-specific: worker-fallback thresholds determined by max_hw_sectors_kb, nr_requests, and max_segments (§3.6), zero-copy crossover thresholds that 'vary with capabilities and available offloads of the NIC' (§4.6), and SQPoll wake latency of ~30 µs (§2.2). These thresholds are load-bearing for the tuning recommendations. The paper should either validate the guidelines on a second, substantially different configuration or explicitly scope the claims so that the title-level 'when/how' guidance is not presented as universal. This is a limitation rather than an internal inconsistency, but it needs to be addressed.
  3. [§3.4.1, Figure 5 (+SQPoll)] The SQPoll step reports an increase from 376 k to 546 k tx/s, but the text states that SQPoll 'dedicates one CPU core to polling.' The previous configurations are single-threaded on one core, so the +SQPoll configuration consumes two cores in total. On a per-core basis, the SQPoll throughput is approximately 273 k tx/s, which is lower than the +IOPoll result of 376 k tx/s. The figure and the surrounding discussion should clearly state the core count used in each configuration and should not label the final result as single-threaded without this qualification. This affects the interpretation of tuning guideline (3) regarding when SQPoll is actually beneficial.
minor comments (4)
  1. [Figure 1] The bar labels in Figure 1 are confusing and the printed values appear out of order with respect to the legend. Please redraw the figure with clear per-bar labels and consistent ordering.
  2. [Figures 5–6] The y-axis label 'Transactions/s [K/s]' mixes units. Use 'Ktx/s' or 'thousands of transactions per second'.
  3. [Reference [20]] Reference [20] cites PostgreSQL 8.4.22 release notes as the source for clock-sweep. This appears to be a misassigned reference; please verify and cite the original or a more appropriate source.
  4. [§5.2] The text says IOPoll is enabled on ext4, while §3.4.1 states that IOPOLL typically requires direct block-device access and needs explicit filesystem support. A short explanation of why IOPoll works in the PostgreSQL/ext4 setting would avoid an apparent contradiction.

Circularity Check

0 steps flagged

No circularity found: the paper's headline numbers are direct measurements, its analytical models use independently measured constants, and the PostgreSQL validation is an external transfer test.

full rationale

The paper's load-bearing results—the 1.06–1.10x naive gains, the 2.05–2.31x optimized gains, and the 11–15% PostgreSQL improvement—are presented as direct measurements of specific system configurations, not as outputs of a model or as consequences of a fitted parameter. The latency/cycle models in Section 3.3 use constants measured independently (c_tx from an in-memory run, c_io from microbenchmarks, device latencies from Table 1) and are used to explain or predict throughput before comparing to measured values; they are not fitted to the headline results. The 'validation' on PostgreSQL is an external codebase and baseline, so applying guidelines derived from the authors' own case studies does not reduce to the inputs by construction. Self-citations (e.g., vmcache, morsel-driven processing, prior DaMoN work) provide baseline systems or background context and are not load-bearing logical premises. The paper itself acknowledges environment dependence—worker-fallback thresholds in Section 3.6 and zero-copy crossover thresholds in Section 4.6 depend on kernel, device, and NIC capabilities, and PostgreSQL's filesystem/process model limits some optimizations in Section 5.2—but these are limitation/external-validity concerns, not circularity. No equation, fitted constant, or cited 'uniqueness' argument embeds the target result.

Axiom & Free-Parameter Ledger

4 free parameters · 4 axioms · 0 invented entities

The central claims are experimental; the analysis uses a small number of measured hardware/kernel constants (latencies, cycle counts) as model inputs, and the workload-dependent page-fault rate is a design choice. None of these are fitted to the headline outputs, and there are no invented entities.

free parameters (4)
  • r_pf = 70% page fault rate (YCSB workload) = 0.7
    Chosen by dataset sizing (10M tuples, 1 GB buffer pool, 4 KiB pages, uniform updates); an input to the throughput model, not fitted to the measured output (Section 3.2).
  • c_tx = 8,264 cycles per transaction = 8264 cycles
    Measured via rdtsc on the test system's in-memory run; used as a constant in the cycle model (Section 3.3.2). Hardware-specific input, not fitted to the I/O-run outcome.
  • Per-I/O cycle costs (single read 10,200; batch read 5,400; batch write 5,700) = 10200/5400/5700 cycles
    Measured in microbenchmarks on the same server (Table 1); model inputs rather than fitted coefficients.
  • I/O latencies (single read 70 µs, single write 12 µs) = 70/12 µs
    Measured on the Kioxia array (Table 1); model inputs used in the latency model (Section 3.3).
axioms (4)
  • domain assumption io_uring internals on Linux 6.15/6.17 behave as described in §2.2 (inline/poll/worker execution paths, task_work and DEFER_TASKRUN semantics, SQPoll/IPI behavior).
    The analysis and guidelines depend on this specific kernel behavior; changes across kernel versions would alter the thresholds and conclusions.
  • domain assumption Microbenchmark constants measured on the test machine transfer to the integrated buffer manager and shuffle engines.
    Used to 'predict' and explain end-to-end throughput (§3.3.2/3.3.3); confidence rests on same-machine measurement, but the integrated paths include additional runtime logic not in the microbenchmarks.
  • domain assumption The network stack tuning (qdisc, socket buffers, chiplet pinning) and the epoll baseline represent the comparable state of practice.
    The shuffle comparison and the §4.5 takeaways depend on the tuned stack; a differently-tuned default could shift the io_uring-vs-epoll gap.
  • domain assumption PostgreSQL 18's upstream io_uring backend is the correct baseline for the 14% claim.
    The validation compares a patched backend to upstream as merged; the claim is scoped to cold full-table scans of a 32 GiB table with 1–8 workers, not general OLTP (§5.2).

pith-pipeline@v1.3.0-alltime-deepseek · 22614 in / 14840 out tokens · 136885 ms · 2026-08-03T18:29:21.335087+00:00 · methodology

0 comments
read the original 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%.

Figures

Figures reproduced from arXiv: 2512.04859 by Carsten Binnig, Matthias Jasny, Muhammad El-Hindi, Tobias Ziegler, Viktor Leis.

Figure 1
Figure 1. Figure 1: Performance comparison between traditional I/O in [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: io_uring architecture. The database system in user space communicates with the kernel via two shared ring buffers: the Submission Queue (SQ) for enqueuing I/O re￾quests and the Completion Queue (CQ) for receiving results [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 4
Figure 4. Figure 4: Overview of the buffer-managed storage engine [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗
Figure 6
Figure 6. Figure 6: TPC-C with 1 warehouse (left) and 100 warehouses [PITH_FULL_IMAGE:figures/full_fig_p006_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Scale-out performance for random 4 KiB reads & [PITH_FULL_IMAGE:figures/full_fig_p007_7.png] view at source ↗
Figure 10
Figure 10. Figure 10: Overview of the shuffle architecture with scan [PITH_FULL_IMAGE:figures/full_fig_p008_10.png] view at source ↗
Figure 12
Figure 12. Figure 12: Memory bandwidth for the data shuffle in Fig. 11 [PITH_FULL_IMAGE:figures/full_fig_p009_12.png] view at source ↗
Figure 13
Figure 13. Figure 13: Speedup of io_uring and zero-copy send epoll vs. plain epoll for data shuffling across six nodes and different tuple sizes. Zero-copy receive is only available with io_uring. above [PITH_FULL_IMAGE:figures/full_fig_p009_13.png] view at source ↗
Figure 14
Figure 14. Figure 14: Careful tuning of the networking setup is required [PITH_FULL_IMAGE:figures/full_fig_p010_14.png] view at source ↗
Figure 16
Figure 16. Figure 16: Impact of incremental io_uring optimizations on the cycle cost for a single TCP connection. The best-performing configuration depends on the shown thresholds. Registered file descriptors offer minimal benefit and are therefore omitted. Optimizing kernel execution for sockets. Recall how io_uring executes task_work inside the kernel. By default, it first attempts to complete an I/O operation inline in non-… view at source ↗
Figure 17
Figure 17. Figure 17: PostgreSQL speedup from io_uring optimizations. Sharing the SQPoll kernel thread between rings has negligi￾ble performance impact. Improvements remain limited by the filesystem and PostgreSQL’s multi-process architecture. per thread with exclusive ownership and no cross-process shar￾ing. PostgreSQL also relies on filesystems for data storage, which prevents low-level optimizations for guideline (4), such … view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Forward citations

Cited by 3 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. The Bi-Channel Networking Paradigm for Database Systems in the Cloud

    cs.DB 2026-06 unverdicted novelty 7.0

    The bi-channel paradigm separates database networking into a high-performance UDP data path and a TCP control path to reduce kernel overhead while preserving reliability on fast cloud networks.

  2. BtrLog: Low-Latency Logging for Cloud Database Systems

    cs.DB 2026-06 unverdicted novelty 6.0

    BtrLog provides low-latency durable appends via quorum replication on SSD log nodes with asynchronous low-cost archiving to object storage for single-writer cloud database architectures.

  3. BtrLog: Low-Latency Logging for Cloud Database Systems

    cs.DB 2026-06 unverdicted novelty 6.0

    BtrLog delivers low-latency durable appends for single-writer cloud DBMS via quorum SSD replication plus asynchronous object-storage archiving, outperforming EBS in latency and throughput.

Reference graph

Works this paper leans on

45 extracted references · 6 canonical work pages · cited by 2 Pith papers · 1 internal anchor

  1. [1]

    Amazon EC2 Instances

    2025. Amazon EC2 Instances. https://aws.amazon.com/ec2/instance-types/. Accessed: 2025-11-27

    2025

  2. [2]

    Boost.fiber framework

    2025. Boost.fiber framework. https://github.com/boostorg/fiber

    2025

  3. [3]

    MySQL 8.4 Reference Manual

    2025. MySQL 8.4 Reference Manual . https://dev.mysql.com/doc/refman/8.4/en/ innodb-linux-native-aio.html

    2025

  4. [4]

    Jens Axboe. 2019. Efficient I/O with io_uring. https://kernel.dk/io_uring.pdf. Accessed: 2025-10-17

    2019

  5. [5]

    Jens Axboe. 2020. Re: io_uring is slower than epoll (issue #189 comment) . GitHub issue comment on the liburing repository

    2020

  6. [6]

    Jens Axboe. 2021. Re: unexpected high count of io_worker threads by using the IOSQE _ASYNC flag (issue #349 comment). GitHub issue comment on the liburing repository

    2021

  7. [7]

    Jens Axboe. 2024. Re: EAGAINs impacting the performance of io_uring (issue #1175 comment). GitHub issue comment on the liburing repository

    2024

  8. [8]

    Jens Axboe. 2025. io_uring and networking in 2023 . https://github.com/axboe/ liburing/wiki/io_uring-and-networking-in-2023#task-work

    2025

  9. [9]

    Jens Axboe. 2025. io_uring library liburing. https://github.com/axboe/liburing/. Accessed: 2025-10-17

    2025

  10. [10]

    Altan Birler, Tobias Schmidt, Philipp Fent, and Thomas Neumann. 2024. Simple, Efficient, and Robust Hash Tables for Join Processing. In Proceedings of the 20th International Workshop on Data Management on New Hardware, DaMoN 2024, Santiago, Chile, 10 June 2024 , Carsten Binnig and Nesime Tatbul (Eds.). ACM, 4:1–4:9. https://doi.org/10.1145/3662010.3663442

    arXiv 2024

  11. [11]

    Matthew Butrovich, Karthik Ramanathan, John Rollinson, Wan Shen Lim, William Zhang, Justine Sherry, and Andrew Pavlo. 2023. Tigger: A Database Proxy That Bounces With User-Bypass. Proc. VLDB Endow. 16, 11 (2023), 3335–

    2023

  12. [12]

    Le-Gao Chen, Yanzhi Li, Tipporn Laohakangvalvit, and Midori Sugaya. 2024. Asynchronous I/O Persistence for In-Memory Database Servers: Leveraging io_uring to Optimize Redis Persistence. In CLOUD Computing - CLOUD 2024 - 17th International Conference, Held as Part of the Services Conference Federation, SCF 2024, Bangkok, Thailand, November 16-19, 2024, Pro...

    doi:10.1007/978-3- 2024

  13. [13]

    Diego Didona, Jonas Pfefferle, Nikolas Ioannou, Bernard Metzler, and Animesh Trivedi. 2022. Understanding modern storage APIs: a systematic study of libaio, SPDK, and io_uring. In SYSTOR ’22: The 15th ACM International Systems and Storage Conference, Haifa, Israel, June 13 - 15, 2022 , Michal Malka, Hillel Kolodner, Frank Bellosa, and Moshe Gabel (Eds.). ...

    arXiv 2022

  14. [14]

    Aleksandar Dragojevic, Dushyanth Narayanan, Miguel Castro, and Orion Hod- son. 2014. FaRM: Fast Remote Memory. In Proceedings of the 11th USENIX Symposium on Networked Systems Design and Implementation, NSDI 2014, Seat- tle, W A, USA, April 2-4, 2014 , Ratul Mahajan and Ion Stoica (Eds.). USENIX Association, 401–414. https://www.usenix.org/conference/nsdi...

    2014

  15. [15]

    Dominik Durner, Viktor Leis, and Thomas Neumann. 2023. Exploiting Cloud Object Storage for High-Performance Analytics. Proc. VLDB Endow. 16, 11 (2023), 2769–2782. https://doi.org/10.14778/3611479.3611486

    arXiv 2023

  16. [16]

    Wolfgang Effelsberg and Theo Härder. 1984. Principles of Database Buffer Management. ACM Trans. Database Syst. 9, 4 (1984), 560–595. https://doi.org/10. 1145/1994.2022

    arXiv 1984

  17. [17]

    Pietzuch, Maximilian Bandle, and Jana Giceva

    Alessandro Fogli, Bo Zhao, Peter R. Pietzuch, Maximilian Bandle, and Jana Giceva

  18. [18]

    Joshua Fried, Gohar Irfan Chaudhry, Enrique Saurez, Esha Choukse, Íñigo Goiri, Sameh Elnikety, Rodrigo Fonseca, and Adam Belay. 2024. Making Kernel Bypass Practical for the Cloud with Junction. In 21st USENIX Symposium on Networked Systems Design and Implementation, NSDI 2024, Santa Clara, CA, April 15-17, 2024, Laurent Vanbever and Irene Zhang (Eds.). US...

    2024

  19. [19]

    PostgreSQL Global Development Group. 2025. PostgreSQL 18 Released. https: //www.postgresql.org/about/news/postgresql-18-released-3142/

    2025

  20. [20]

    The PostgreSQL Global Development Group. 2005. PostgreSQL 8.4.22 Documen- tation - Appendix E. Release Notes. https://www.postgresql.org/docs/8.4/release- 8-1.html

    2005

  21. [21]

    Gabriel Haas, Adnan Alhomssi, and Viktor Leis. 2025. Managing Very Large Datasets on Directly Attached NVMe Arrays . In Scalable Data Management for Future Hardware, Kai-Uwe Sattler, Alfons Kemper, Thomas Neumann, and Jens Teubner (Eds.). Springer Nature Switzerland, Cham, 223–240. https://doi.org/10. 1007/978-3-031-74097-8_9

    2025

  22. [22]

    Gabriel Haas, Michael Haubenschild, and Viktor Leis. 2020. Exploiting Directly- Attached NVMe Arrays in DBMS. In 10th Conference on Innovative Data Systems Research, CIDR 2020, Amsterdam, The Netherlands, January 12-15, 2020, Online Proceedings. www.cidrdb.org. http://cidrdb.org/cidr2020/papers/p16-haas-cidr20. pdf

    2020

  23. [23]

    Gabriel Haas and Viktor Leis. 2023. What Modern NVMe Storage Can Do, And How To Exploit It: High-Performance I/O for High-Performance Storage Engines. Proc. VLDB Endow. 16, 9 (2023), 2090–2102. https://doi.org/10.14778/3598581. 3598584

    work page doi:10.14778/3598581 2023

  24. [24]

    Haochen He, Erci Xu, Shanshan Li, Zhouyang Jia, Si Zheng, Yue Yu, Jun Ma, and Xiangke Liao. 2023. When Database Meets New Storage Devices: Understanding and Exposing Performance Mismatches via Configurations. Proc. VLDB Endow. 16, 7 (2023), 1712–1725. https://doi.org/10.14778/3587136.3587145

    arXiv 2023

  25. [25]

    Wanning He, Hongyi Lu, Fengwei Zhang, and Shuai Wang. 2023. RingGuard: Guard io_uring with eBPF. In Proceedings of the 1st Workshop on eBPF and Kernel Extensions, eBPF 2023, New York, NY, USA, 10 September 2023 . ACM, 56–62. https: //doi.org/10.1145/3609021.3609304

    arXiv 2023

  26. [26]

    Brynjar Ingimarsson. 2024. Exploring the Performance of the Io_uring Kernel I/O Interface. Master’s thesis. Universiteit van Amsterdam, Amsterdam

    2024

  27. [27]

    Matthias Jasny, Muhammad El-Hindi, Tobias Ziegler, and Carsten Binnig. 2025. A Wake-Up Call for Kernel-Bypass on Modern Hardware. In Proceedings of the 21st International Workshop on Data Management on New Hardware, DaMoN 2025, Berlin, Germany, June 22-27, 2025 . ACM, 14:1–14:5. https://doi.org/10.1145/ 3736227.3736235

    arXiv 2025

  28. [28]

    Theo Jepsen, Alberto Lerner, Fernando Pedone, Robert Soul é, and Philippe Cudré-Mauroux. 2021. In-Network Support for Transaction Triaging. Proc. VLDB Endow. 14, 9 (2021), 1626–1639. https://doi.org/10.14778/3461535.3461551

    arXiv 2021

  29. [29]

    Andersen

    Anuj Kalia, Michael Kaminsky, and David G. Andersen. 2019. Datacenter RPCs can be General and Fast. In 16th USENIX Symposium on Networked Systems Design and Implementation, NSDI 2019, Boston, MA, February 26-28, 2019 , Jay R. Lorch and Minlan Yu (Eds.). USENIX Association, 1–16. https://www.usenix. org/conference/nsdi19/presentation/kalia

    2019

  30. [30]

    Daehyeok Kim, Amir Saman Memaripour, Anirudh Badam, Yibo Zhu, Hongqiang Harry Liu, Jitu Padhye, Shachar Raindel, Steven Swanson, Vyas Sekar, and Srinivasan Seshan. 2018. Hyperloop: group-based NIC-offloading to accelerate replicated transactions in multi-tenant storage systems. InProceedings of the 2018 Conference of the ACM Special Interest Group on Data...

    arXiv 2018

  31. [31]

    Microsoft Learn. 2024. Optimize network throughput for Azure virtual machines. https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network- optimize-network-bandwidth#achieving-consistent-transfer-speeds-in-linux- vms-in-azure. Accessed: 2025-10-17

    2024

  32. [32]

    Viktor Leis, Adnan Alhomssi, Tobias Ziegler, Yannick Loeck, and Christian Dietrich. 2023. Virtual-Memory Assisted Buffer Management. Proc. ACM Manag. Data 1, 1 (2023), 7:1–7:25. https://doi.org/10.1145/3588687

    work page doi:10.1145/3588687 2023

  33. [33]

    Viktor Leis, Peter Boncz, Alfons Kemper, and Thomas Neumann. 2014. Morsel- driven parallelism: a NUMA-aware query evaluation framework for the many- core age. In International Conference on Management of Data, SIGMOD 2014, Snowbird, UT, USA, June 22-27, 2014 , Curtis E. Dyreson, Feifei Li, and M. Tamer Özsu (Eds.). ACM, 743–754. https://doi.org/10.1145/25...

    arXiv 2014

  34. [34]

    Viktor Leis and Christian Dietrich. 2024. Cloud-Native Database Systems and Unikernels: Reimagining OS Abstractions for Modern Hardware. Proc. VLDB Endow. 17, 8 (2024), 2115–2122. https://doi.org/10.14778/3659437.3659462

    arXiv 2024

  35. [35]

    Narasayya

    Feng Li, Sudipto Das, Manoj Syamala, and Vivek R. Narasayya. 2016. Accelerating Relational Databases by Leveraging Remote Memory and RDMA. In Proceedings of the 2016 International Conference on Management of Data, SIGMOD Conference 2016, San Francisco, CA, USA, June 26 - July 01, 2016 , Fatma Özcan, Georgia Koutrika, and Sam Madden (Eds.). ACM, 355–370. h...

    arXiv 2016

  36. [36]

    Narasayya, Ishai Menache, Mohit Singh, Feng Li, Manoj Syamala, and Surajit Chaudhuri

    Vivek R. Narasayya, Ishai Menache, Mohit Singh, Feng Li, Manoj Syamala, and Surajit Chaudhuri. 2015. Sharing Buffer Pool Memory in Multi-Tenant Relational Database-as-a-Service. Proc. VLDB Endow. 8, 7 (2015), 726–737. https://doi.org/ 10.14778/2752939.2752942

    arXiv 2015

  37. [37]

    Lam-Duy Nguyen, Adnan Alhomssi, Tobias Ziegler, and Viktor Leis. 2025. Mov- ing on From Group Commit: Autonomous Commit Enables High Throughput and Low Latency on NVMe SSDs. Proc. ACM Manag. Data 3, 3 (2025), 191:1–191:24. https://doi.org/10.1145/3725328

    work page doi:10.1145/3725328 2025

  38. [38]

    NVIDIA. 2021. NVIDIA ConnectX-7 Datasheet. https://www.nvidia.com/content/ dam/en-zz/Solutions/networking/infiniband-adapters/infiniband-connectx7- data-sheet.pdf

    2021

  39. [39]

    Constantin Pestka and Marcus Paradies. 2025. Tutorial: Dreaming of Syscall-less I/O with io\_uring - Some Assembly Required, Feaver Dreams and Nightmares included. In Datenbanksysteme für Business, Technologie und Web (BTW 2025) Workshopband, Bamberg, Germany, March 3-7, 2025 (LNI, Vol. P-363) , Carsten Binnig, Andreas Henrich, Daniela Nicklas, Maximilian...

    work page doi:10.18420/btw2025-143 2025

  40. [40]

    Constantin Pestka, Marcus Paradies, and Matthias Pohl. 2024. Asynchronous I/O - With Great Power Comes Great Responsibility. CoRR abs/2411.16254 (2024). https://doi.org/10.48550/ARXIV.2411.16254 arXiv:2411.16254

    work page internal anchor Pith review Pith/arXiv arXiv doi:10.48550/arxiv.2411.16254 2024

  41. [41]

    Zebin Ren and Animesh Trivedi. 2023. Performance Characterization of Modern Storage Stacks: POSIX I/O, libaio, SPDK, and io_uring. In Proceedings of the 3rd 13 Workshop on Challenges and Opportunities of Efficient and Performant Storage Systems, CHEOPS 2023, Rome , Italy, 8 May 2023 , Jean-Thomas Acquaviva, Shadi Ibrahim, and Suren Byna (Eds.). ACM, 35–45...

    work page doi:10.1145/3578353 2023

  42. [42]

    Bowen Wu, Wei Cui, Carlo Curino, Matteo Interlandi, and Rathijit Sen. 2025. Terabyte-Scale Analytics in the Blink of an Eye. CoRR abs/2506.09226 (2025). https://doi.org/10.48550/ARXIV.2506.09226 arXiv:2506.09226

    Pith/arXiv arXiv doi:10.48550/arxiv.2506.09226 2025

  43. [43]

    Xinjing Zhou, Viktor Leis, Xiangyao Yu, and Michael Stonebraker. 2025. OLTP Through the Looking Glass 16 Years Later: Communication Is the New Bottle- neck. In 15th Annual Conference on Innovative Data Systems Research (CIDR’25) . 14

    2025

  44. [2024]

    OLAP on Modern Chiplet-Based Processors. Proc. VLDB Endow. 17, 11 (2024), 3428–3441. https://doi.org/10.14778/3681954.3682011

    arXiv 2024

  45. [3348]

    https://doi.org/10.14778/3611479.3611530

    arXiv