Alex Miller

@melhindiCS @eatonphil I also liked atlarge-research.com/pdfs/2022-syst… if you want the cpu utilization comparison

@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

@kingprotty @eatonphil For network, the async interface did make it a lot easier for them to implement zero-copy blog.tohojo.dk/2026/02/the-in…

@eatonphil for disk, dispatching it off control plane is main benefit, ideally low cost dispatch: SQPOLL or ringbuf->another thread for network, idk. Less syscalls, but is that better? Registered buffers vs mlock? Needs bench. Usually u just skip as much of kernel as u can instead e.g. XDP

@andrew_rogers @eatonphil "overall, the *API* itself is, I dare to say, not a total trainwreck." #l41" target="_blank" rel="nofollow noopener">cvs.schmorp.de/libev/ev_iouri… compare with #l41" target="_blank" rel="nofollow noopener">cvs.schmorp.de/libev/ev_linux…

@eatonphil io_uring's strength is generality across use cases and eliminating many poorly documented edge cases. The performance advantages are overstated. You can get close using old APIs but that knowledge is arcane and difficult to wield. io_uring makes this performance accessible.

Our next South Bay Systems meetup is on May 26! This time, we're covering one of my favorite topics: databases, and how to use them to make better architectural decisions and build reliable systems. We have two great talks lined up: - "Building a Distributed Persistent Queue on FoundationDB": @HimankChaudhary will walk through how the queuing infrastructure at @TigrisData was designed and implemented. - "Decisions, Principles, and Lessons from a Year of Teaching MySQL New Tricks": Steve Schirripa will share lessons and challenges around extending relational database systems at @VillageSQL. Food and drinks will be provided courtesy of our hosts at @PingCAP. Registration link below.

And the recording from this talk is now available! youtu.be/BG1zqnTGpyc Thanks again to @cliff_click for the great talk, and LinkedIn for the great venue!

South Bay Systems returns for its April meetup on the 30th. This time we have @cliff_click giving a walkthrough of his teaching language for Sea of Nodes! Sign up now! luma.com/nnq9aq27

If you're an RSS user and a South Bay Systems attendee, I've added an RSS feed for the events at southbaysystems.xyz/atom.xml

Our next South Bay Systems meetup will be on March 31. We've got two awesome deep-dive talks: - @ssougou will present deconstructing consensus and its application to Multigres - @stuhood will talk about how modern full-text search is evolving toward columnar systems (and the tricky optimization challenges) Food and beverages will be provided, courtesy of our hosts, @Snowflake Come hang out with the systems crowd 👇

There's a few papers which argue that DBMSs do page eviction wrong, and they always feel like incredibly compelling arguments. As a bonus, "Writeback-Aware Caching" pdl.cmu.edu/PDL-FTP/Storag… points out that evicting a dirty page is more expensive than evicting a clean page.

[CIDR '25] Linear Elastic Caching via Ski Rental vldb.org/cidrdb/papers/… You should consider that holding a page in cache costs you, because RAM itself is expensive, and existing page replacement algorithms look at sizing cache independently (via miss-ratio curves).

I continue to have a weakness for papers that show B-Trees and LSM-Trees as just two opposite tradeoffs along a continuum. x.com/AlexMillerDB/s…

[arXiv] Dynamic read & write optimization with TurtleKV arxiv.org/pdf/2509.10714 TurtleKV shows a way to elastically move around the RUM conjecture space depending on what is important at the moment.

@sunbains Sort of the point of accord though is to avoid having to establish leadership. The key part is that the leader is necessary for good performance to ordering (conflicting) proposals, and accord does that by timestamping the proposals on the client instead.

Some type of dynamic “leadership “ for hot ranges will probably prevent the worst case being worse than leadership protocols I suppose. Need to study the Casandra implementation I think. This seems obvious.

I’ve been intrigued by Accord, trying to understand it a little deeper. The “fast path” use case is very compelling, in a uniform distribution I can see it working really well. However, real world workloads often exhibit Zipfian distributions. The LSM use case relies on this reality. For such use cases Accord seems to have a worst case that can be slower than leadership based protocols because it’s “slow path” requires renegotiation of the timestamps (and dependencies). I’m wondering if this intuition is correct?

[VLDB '26] Garnet: A Next-Generation Cache-Store for Accelerating Applications and Services vldb.org/pvldb/vol19/p2… It's fast, durable redis, brought to you by Badrish Chandramouli (et. al), known for other 🔥 work like FASTER and Bf-tree.

[CIDR '25] Adaptive Factorization Using Linear-Chained Hash Tables vldb.org/cidrdb/papers/… Adaptive execution + factorization + WCOJ = great paper. The best intro to factorized databases I know of is youtube.com/watch?v=-XmJ7a….

If you make an account you can seed your lists of interest off of my own: @linearizable/interests" target="_blank" rel="nofollow noopener">scour.ing/@linearizable/…

scour.ing has gotten pretty good at surfacing what new stuff I actually want to read on the internet, better than following subreddits. You can see my feed of mostly database things at @linearizable" target="_blank" rel="nofollow noopener">scour.ing/@linearizable. It surfaces small personal blogs particularly well.

[VLDB '25] MD-MVCC: Multi-version Concurrency Control for Schema Changes in Azure SQL Database vldb.org/pvldb/vol18/p4… A great discussion of the end-to-end impact of allowing multiple versions of schema metadata information to be live concurrently, in a real, production system.

@samlafer Hadn't seen! I'll take a look and add it to the list of pending changes if it pushes the frontier of any of the reconfiguration efficiencies. Thanks!

@AlexMillerDB just stumbled upon news.ycombinator.com/item?id=231306…, which talks about the LCR protocol, which seems to be a ring-topology variant of chain replication. Curious why you didn't include it in your transactional.blog/blog/2024-data…. Any specific reason or you just didn't know about it?

The recording from our last South Bay Systems meetup is up! youtu.be/8j1Dqi2M_pI