How teams scaled RocksDB: 4 real case studies
4 of the 94 engineering write-ups in our database mention RocksDB in their stack. They come from 4 companies (Datadog, LinkedIn, Meta and Zalando) and were published between 2016 and 2026. It's often paired with Java (2). 1 of the 4 state concrete scale numbers, for example "up to 200 MB/s on the old pipeline" (Zalando). Each card below links to our short summary and the original post.
From Homegrown to Flink: Migrating a Stateful Ad Event Join at Scale
Zalando Marketing Services replaced a 7-year-old homegrown in-memory join that matched Sponsored Products auction bids to clicks/views within 15 minutes. The old Java service read up to 200 MB/s, could not partition both streams cleanly, and lost up to 15 minutes of state on every deploy or rescale. After Interval Join burned 15-30% CPU on RocksDB seeks and held a ~70M-entry timer queue, they rewrote the match with KeyedCoProcessFunction (point lookups, RocksDB TTL expiry), incremental 3-minute checkpoints, and two-way state. A four-week shadow pipeline hit 99.9% enrichment parity, then a one-week A/B test; average pods fell from 20 to about 5, memory from ~320 GB to ~100 GB, and EC2 cost from about €80 to €30 per day, with enrichment up ~0.5%.
Timeseries indexing at scale
Datadog redesigned its timeseries indexing to handle a large jump in ingested data.
ZippyDB: Facebook's key value store
Meta's general-purpose distributed key-value store built on RocksDB, with shard management and configurable consistency.
FollowFeed: LinkedIn's Feed Made Faster and Smarter
LinkedIn moved its feed to a fan-out-on-read system that keeps member timelines in memory and on RocksDB.