ByteDance's USDB storage system cuts write latency 85.8% and infrastructure cost 42.1%

What the paper describes

A paper from ByteDance engineers, submitted to arXiv on 2 November 2026 and upvoted to the Hacker News front page the following day, describes USDB, the company's unified sequence storage system for the streaming and batch workloads behind its recommender systems. The submission, listed as arXiv:2611.02618 with authors including Xiaoran Zhu, Jieming Cai and Weiping Yu, frames the core problem as a storage asymmetry: recommendation models now consume increasingly long, attribute-rich user histories, which means the store must absorb small continuous updates on the write side while simultaneously serving repeated large reads on the other.

USDB is ByteDance's answer to that asymmetry: a single system intended to serve ingestion, inference and training from shared sequence data, rather than separate storage paths for each consumer.

Four design elements

According to the paper's abstract, the system rests on four main components:

• CascadeLSM, a time-based compaction design in which staged compactions materialize application-specific histories. In effect, the maintenance work the store has to perform anyway produces the history views the recommender actually reads.
• Differentiated replicas that share persistent files, so replicas serving different duties draw from the same underlying data rather than each holding independent copies.
• Partial dumps, which reconstruct inference inputs by combining a captured recent state with versioned history instead of recomputing everything from scratch.
• A hybrid columnar format that accelerates projected reads, meaning cases where only a subset of a record's attributes is needed.

The connecting idea, the authors write, is reusing the results of storage maintenance across ingestion, inference and training, so that compaction is not pure overhead but a shared substrate serving the workloads layered above it.

The reported numbers

The abstract reports results from both production migration and controlled experiments:

• Production migration records show 85.8% lower mean write latency.
• Normalized deployment accounting shows 42.1% lower infrastructure cost.
• In controlled comparisons against an optimized RocksDB sequence baseline, the system delivered faster long-history reads across projections and client loads.
• Aggregation pushdown sustained 8.5x the throughput of ordinary reads under a constrained receive budget.

The paper also reports production reconstruction and direct-file training results, which the authors present as evidence that shared sequence maintenance can support both fresh serving and repeated historical access.

Why it matters

The workload shape USDB targets is not unique to ByteDance. Long, append-heavy user or event histories that are read repeatedly by online inference and periodically re-read for training are the standard pattern behind feature stores, event stores and sequence databases for machine learning generally. Anyone operating that kind of infrastructure faces the same write-versus-read asymmetry the paper describes.

The specific lesson is architectural rather than incremental: treating compaction and other maintenance work as a first-class product that ingestion, inference and training can all consume appears to pay off in both latency and cost, rather than treating it as background overhead to be minimized. The comparison against a tuned RocksDB baseline also gives practitioners a useful reference point, suggesting the gains come from redesigning storage around the sequence workload instead of further tuning a general-purpose engine.

One caveat is warranted: this is a v1 preprint, and the headline figures are the authors' own measurements from their production environment. The abstract does not describe the scale of the deployment or the migration baseline in detail. Independent verification is not available, which is the usual situation for industrial systems papers, but the numbers are still self-reported. Even with that caveat, the design ideas — compaction that materializes application views, replicas sharing files, reconstruction from recent state plus versioned history, and columnar layouts for projected reads — are directly transferable concepts for teams building large-scale storage for recommendation and other sequence-driven ML workloads.