Everyone's first instinct for scaling an in-memory database is a bigger machine. One process, one enormous node, one impressive throughput number. That works right up until it doesn't: a bigger node i… See more

Everyone's first instinct for scaling an in-memory database is a bigger machine. One process, one enormous node, one impressive throughput number. That works right up until it doesn't: a bigger node is a bigger thing to lose, a longer wait when you have to rebuild it, and a bill for capacity your workload never uses. So the advice is to scale out instead, except splitting data across nodes has its own history of pain. Moving data between nodes was slow, adding or removing one left the cluster worse off before it got better, and all of it lands exactly when you least want to touch production. Neither axis is optional. In this talk, learn what the Valkey community did to make both of them boring. Going up, why command execution is still single threaded and will stay that way, and what we moved off that thread instead: network I/O, parsing, and TLS became someone else's problem, and per-key memory overhead came down, so a large node earns its size. Going out, how slot migration became something you can run at peak traffic, and what had to change for adding and removing nodes to stop being an event. And how we measure any of it, because "faster" is not a number, and the metrics you choose decide which tradeoffs you accept. Sobre Madelyn Olson: I work primarily on the open source Valkey project and evangelize the importance of open source software development. Show less