The paper is premised on a dichotomy that doesn't hold in real database systems. Specifically, the assertion that "static" shared-nothing architecture performance substantially degrades under skew, which provides a foil for shared-disk architectures that do not. While this is true for many shared-nothing architectures, particularly in open source, robustly skew-tolerant shared-nothing architectures have existed for at least a decade -- highly <i>dynamic</i> shared-nothing architectures are valid (and quite good) designs.<p>A skew-tolerant shared-nothing database has internals that look a bit like "AnyDB" to the extent execution of a type of workload is largely disconnected from the physical architecture -- the storage engines are often identical, for example. This allows you to schedule any mixture of fast-twitch operations concurrent with slow analytic queries. The original motivation for these types of architectures was complex mixed workloads. What is missing from the AnyDB shared-nothing architecture to make it skew-tolerant is a mechanism for continuously and smoothly shedding both data and load across cores/machines while maintaining consistency. Multiple options here, just need to pick one that makes sense and plays nicely with the concurrency control model.<p>Similarly, the synchronization-free streaming concurrency control model described in the paper is a standard design idiom. Most "thread-per-core" style database architectures do something like this -- it is one of the major advantages of being thread-per-core.<p>The database engineering industry has a long history of not publishing design advances and this is illustrative of that. If someone asked me to point to a paper that describes all this, I'd have a difficult time thinking of one. That isn't where this knowledge tends to be stored.