Impressive, as one might expect. Some reactions:<p>-- Secret sauce<p>A lot of the magic of F1 comes from Spanner, the distributed storage system. The name "F1" itself is an allusion to "inheriting" some of the properties of Spanner.<p>-- Hierarchical tables<p>What they call hierarchical tables, I would think best be viewed as one-to-many relationships. In guess they've privileged this model in their storage because that's what a lot of their AdWords schema looks like.<p>-- Change History<p>I like the observation that keeping full histories is relatively straightforward with atomic, granular timestamping and indeed that it should be baked in. Every database schema I've ever worked with always goes through a similar evolutionary cycle:<p>1. We only need to capture the current state of the model.<p>2. Wait, we do need to capture historical states of the model.<p>3. Wait, the model is changed, we need to capture historical states and the models that were current.<p>(You can think of this as taking progressive differentials of incoming transactions).<p>The F1 designers have baked that right into the database, where it belongs. Weak temporal support has long been the sore point in SQL.<p>-- Remote data<p>I was struck by their observation that most database storage engines are built around the concept of seeks and reads, whereas theirs is necessarily built around batching and pipelining over a network. If I am reading them correctly, their engine takes advantage of having multiple copies of data by sending reads to multiple disk nodes and then working from the first copy that is returned.