Muhammad El-Hindi

Grateful to be recognized as a Distinguished Reviewer for ACM SIGMOD/PODS 2026. Reviewing is a quiet academic service, but it matters: feedback helps improve papers and uphold the quality of our research community. Many thanks to the SIGMOD PC chairs @cbinnig and @sudeepa_roy

@eatonphil We recently looked at this question from a database perspective: To see noticeable benefits it’s not sufficient to “just” use io_uring, most of the time architectural changes are required to reap its benefits. Checkout our paper for more details: arxiv.org/abs/2512.04859

Where do you think io_uring will do better than epoll or AIO and where will it not (including having no noticeable benefit, not necessarily being worse)? For disk and for network io, where relevant

BPF filtering support for io_uring, finally got around to doing it. This will help those use cases, like containers, that apply seccomp filters to utilize io_uring. See link below for details, and links to kernel and liburing changes and tests. @kernel.dk/" target="_blank" rel="nofollow noopener">lore.kernel.org/io-uring/20260…

The stagnation of SSD capacity (since 2019) and I/O throughput (since 2016) stands in stark contrast to on-prem trends. Cost-normalized NVMe capacities have increased by roughly 3x in the same time frame and I/O throughput by over 5x.

I'm excited about the database performance io_uring will unlock. Last year I benchmarked Postgres 17 vs 18 to test the initial io_uring upgrades. I was surprised to see they weren't always a clear win for TPC-C. This paper studies the potential, and the future looks good.

Seeing more and more papers that explore advanced I/O techniques for high-performance database management systems (DBMSs), particularly leveraging modern Linux kernel features and NVMe storage. I did write a post on the first one co-authored by @Tobias__Ziegler some time back. Just read the second one today .. Both papers address the challenges of exploiting modern high-speed NVMe SSDs and fast networks in DBMSs, where traditional I/O interfaces (e.g., libaio + epoll) create bottlenecks via overhead, fragmentation, or inability to saturate hardware. Here are some common thoughts from the 2 papers .. • Efficiency on Modern Hardware - NVMe demands low-overhead, highly concurrent async I/O; naive approaches fall short. • Asynchrony and Batching - Critical for overlapping I/O with computation and amortizing costs. • Flexibility and Advanced Features -Direct / passthrough access (e.g., io_uring's NVMe commands) bypasses kernel stacks for better performance; abstraction (xNVMe) enables choosing optimal paths like io_uring. • DBMS-Specific Guidance - Gains in I/O-intensive scenarios (buffer management, shuffling), require architectural changes (e.g., async designs, per-thread rings) rather than drop-in replacement. The first paper directly evaluates and integrates io_uring into database storage engines and systems like PostgreSQL, providing detailed guidance on its optimal configurations, use cases, and performance benefits in I/O-bound DBMS workloads. The second paper (focused on xNVMe) treats io_uring as one of several supported backends within a unified, portable user-space API for NVMe access, emphasizing flexibility to select or switch I/O paths (including io_uring) without locking DBMS code to a specific interface.

Yes

@t_r277 @TigerBeetleDB @m4ttze @Tobias__Ziegler @viktor_leis @cbinnig Note that this is the improvement over the existing io_uring integration, not vs sync. If comparing sync vs io_uring, you're right, 2x is achievable as shown in this performance comparison: pganalyze.com/blog/postgres-…

@TigerBeetleDB @m4ttze @melhindiCS @Tobias__Ziegler @viktor_leis @cbinnig 14% in Postgres is solid, but with proper batching + registered buffers it's 2x+ easy

How modern database systems can leverage the Linux io_uring interface for efficient, low-overhead I/O arxiv.org/pdf/2512.04859… @m4ttze @melhindiCS @Tobias__Ziegler @viktor_leis @cbinnig

Our paper is currently on Hacker News, feel free to join in if you have questions or comments. @melhindiCS @m4ttze and I are happy to take them.

Our post is heavily inspired by the recent study of cloud hardware evolution (vldb.org/cidrdb/2026/cl…) from @maxikuschewski, Till Steinert, and @viktor_leis. The paper will be presented @cidrdb. Give both a read and let us know what you think! 🚀 #CloudComputing

New year brain food? "Our Future in the Cloud" landed on btrblocks.com, our take on where hyperscalers are heading 📊and why it matters. Happy New Year and happy reading! #CloudComputing #TechTrends

PyTorch isn't just for AI. Our new paper introduces PystachIO: a distributed GPU OLAP engine on PyTorch that combines RDMA+NVMe. Great collaboration with Jigao Luo, Nils Boeschen, and @cbinnig. Check it out: arxiv.org/abs/2512.02862 #PyTorch #Databases #GPU #RDMA #NVMe

Great compilation of insights from our (@Tobias__Ziegler @m4ttze @viktor_leis @cbinnig) recent paper on #io_uring! Please take a moment to read it and share your feedback with us.

This one is one of the most easy-to-follow papers on io_uring and its benefits. Highly recommended read!

Interested in io_uring? Check out our new paper, joint work with my former colleagues from TU Darmstadt (@cbinnig and @m4ttze) and from TU Munich (@melhindiCS and @viktor_leis). arxiv.org/abs/2512.04859…