Why Elixir Beat Go and Rust for BlueSky's Data Plane | Chris Beck
Notas do episódio
There's a gap between BlueSky's open reference implementation (handles a few hundred thousand users) and BlueSky's own production system (handles millions, but runs on infrastructure most teams can't replicate). Chris Beck and his team at Bitcrowd set out to close it -and ended up somewhere they didn't expect.
In this episode, Allen Wyma and Francesco Cesarini talk to Chris Beck, founder of Bitcrowd in Berlin, about building an open source alternative to BlueSky's data plane -the component that turns the AT Protocol firehose into the timeline you actually scroll through.
This is the third episode in our "right tool for the job" series, following Rust and Zig.
Topics include:
what the AT Protocol actually is, and why it's closer to an "operating system for social apps" than a single product
why BlueSky's own production solution (similar to Discord's MongoDB → Cassandra → ScyllaDB journey) is out of reach for smaller communities
the real numbers: 200-500 messages/second on a normal day, 6 million active users during the November 2024 US election
the hot path vs. cold path split that shaped the entire architecture
why Go, Rust, and Node were all evaluated and rejected -including why Node's single-threaded event loop was already a dead end for the BlueSky team themselves
why Elixir wasn't the expected choice, and what ETS gave them for free that they'd have had to hand-build everywhere else
using a Rust NIF via Rustler for roaring bitmaps to solve the "social proof" (mutual follows) feature -and what that NIF actually costs in terms of crash isolation
why losing almost every microbenchmark didn't matter once they asked "do we actually need to go there?"
the fan-out architecture that pushes messages directly into user mailboxes, and why that made backpressure a non-issue
what's left to build, and the one sentence Chris wants every team picking a stack to remember
Recorded June 15, 2026.