Alex Miller

[arXiv] Beyond Chunk-Then-Embed arxiv.org/abs/2602.16974 I had assumed that, when chunking (large) documents for embedding, adding context about the document to the chunk would always be superior, and it was interesting to see that's not *always* the case.

[arXiv] Beyond Cosine Similarity arxiv.org/abs/2602.05266 I almost always see cosine, and it was interesting to read about similarity metrics as classes of more and less restrictive similarity measures.

@PThorpe92 @qianl_cs I hadn’t checked in on the event for a little while and the waitlist is 172(?!) people so I closed it entirely. We’re up against room fire code limits, afaik. But welcome to the bay! Hopefully we can get you into the next one!

@qianl_cs @AlexMillerDB don't suppose there's any way to get an invite to the booked up south bay systems meetup tomorrow?

Register at luma.com/ogvfeacv

South Bay Systems returns for its June meetup on June 26th! We'll have two speakers: @thinkingfish will talk about her experiences from working on Caching at Twitter and developing Pelikan, and Eric Liang will talk about Databrick's history-based data clustering feature.

The recording from this event is now available! youtu.be/9LiSWbRASKc

@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.