I don't think you're contradicting the post. He's talking about the meaning of the concepts and you're talking about how to get efficient implementations. Both

I don't think you're contradicting the post. He's talking about the meaning of the concepts and you're talking about how to get efficient implementations. Both are important, but if you didn't have to worry about efficiency, it's pretty obvious that the data/metadata distinction is a logical false turn. (To use your terminology, why wouldn't we want everything to be fast, dynamic, and unified?) The post does hint at this by suggesting that the concept of metadata itself arose from tradeoffs imposed by hardware. Where I think you differ from Terry is that while he implies that it's time we moved beyond all that, you're saying that the tradeoffs (e.g. between scale and dynamism) remain fundamental. That's a legimitate concern. It's not obvious that we can have our cake and eat it too. It will be interesting to see how FluidDB performs at scale over time. We've been thinking a lot about these issues on our startup too, because we need both speed and dynamicness. The solution we're arriving at is to exploit the static (structured) cases to get as much speed out of them as we can, be fast-ish on the most common dynamic cases (which thankfully are relatively simple), and be correct-but-slow on the complex dynamic cases. What we won't do, however, unless absolutely forced to, is introduce architectural distinctions between these. We want a consistent, regular system (no two types of data, no two types of anything) that happens to run very fast when handed common usage patterns but still allows for arbitrary flexibility. What we're betting is that the usage patterns will be something like 90% static, 9% dynamic-but-simple, and 1% dynamic-and-complex; we want that to map to 90% super-fast, 9% fast-enough, and 1% slow.