The system can run everything in the early stages. With limited data, any architecture built casually won't reveal issues. The real test isn't on day one, but the moment data starts to pile up wildly.

Let's do some calculations with a moderately complex application: generating 50-100KB of state and behavior data daily. In a year? 18-36GB. Plus derived data and backup images, the actual scale doubles. It sounds like just numbers, but the problem isn't in writing; it's that this data simply can't stop. They are read repeatedly, validated, and combined with each other. Once the referencing relationships become chaotic, the entire system's complexity will explode exponentially.

This is the starting point of Walrus's design. It doesn't expect data growth to stop, nor does it assume objects are written only once. Walrus's approach is: when a data object is created, it is assigned a stable identity that never changes. All modifications are recorded as the evolution of the same object's state. The differences may not be apparent at small scales, but over time, this design advantage will be gradually amplified.

Looking at the data disclosed in testing: supporting MB-level object storage, ensuring availability through multi-node redundancy, with overall availability in the test network stable above 99%. Read latency remains at the second level, enabling real applications to call directly, not just cold data archiving.

More importantly, changes at the application layer. When object references no longer change frequently, applications can perform deep optimizations around stable data structures, which is very difficult to achieve in traditional storage models.