At 40:00: Time-based data, horizontally scalable, dumb storage, replicas don't need to be synchronized, you can contact any replica. Sounds like the dream. Bu

At 40:00: Time-based data, horizontally scalable, dumb storage, replicas don't need to be synchronized, you can contact any replica. Sounds like the dream. But that's a drastic over-simplification of time and consistent responses. Consistent responses in particular seems like a hard requirement given how much attention he's given to "why N+1 queries are wrong and you need to do them as a single operation" (which I totally agree with). And I don't think this is something that can be glossed over at all because the whole concept hinges on history being immutable... which means a major synchronization time bottleneck. And while he does address this at 46:40, but he seems to treat inconsistent timestamps as "this is an interesting space, but if you have [inconsistent time in your db] you have a problem" as if it's a solved problem. Spanner has arguably the most sophisticated approach at scale right now, with atomic clocks all over the place, and it still uses MVCC to address the discrepancies because to do otherwise means major scaling problems. --- There's a lot to unpack in here, delivered rapidly and concisely (yay!), and some good detailed chunks of info, but also what feels like a lot of "these are wrong and/or difficult for specific and largely-correct reasons" -> "this could be great because [hands waving furiously] it has none of those problems!". Values are great, documents are terrible, programmability is king, I completely agree. But none of this sounds like it leads to a solution, just a "these are the tradeoffs we're making, how about we stop trading them off?". As a thought-provoker it's interesting, but it doesn't seem to directly lead to anything.