Dennis Zhuang(@killme20082):Read Twenty Years of Bigtable (SIGMOD '26, 50+ Google authors) twice. 10 EB, 7 billion QPS at peak, and the core architecture has barely moved since 2006. The paper's own explanation is one quiet sentence: the newer features depend on asynchronous processing that is not on the foreground write path. Replication, CRDT counters, materialized views, even the full SSTable read-back for correctness — all of it hangs off the side. So here's the question I now ask about any storage architecture: when the next major feature arrives, where does it attach? If the answer keeps being "you rewrite the main read or write path," the system eventually gets crushed by its own history. The new post:

Dennis Zhuang@killme20082

2026.07.31 08:38

Read Twenty Years of Bigtable (SIGMOD '26, 50+ Google authors) twice. 10 EB, 7 billion QPS at peak, and the core architecture has barely moved since 2006. The paper's own explanation is one quiet sentence: the newer features depend on asynchronous processing that is not on the foreground write path. Replication, CRDT counters, materialized views, even the full SSTable read-back for correctness — all of it hangs off the side. So here's the question I now ask about any storage architecture: when the next major feature arrives, where does it attach? If the answer keeps being "you rewrite the main read or write path," the system eventually gets crushed by its own history. The new post: