It's now clear that Stonebraker's prediction that "one size fits all" DBMSs will fall out of favor (see cacm.acm.org/blogs/blog-cac) was dead wrong. It's hard to say why, exactly - even now. But I have to wonder why ~2009 seemed like more of an "inflection point" than any other time.
Conversation
"One size fits all" was always kind of wrong - he said so himself back then. What changed? You might think that the thesis hung on something about main memory size scaling, but that doesn't seem relevant to many of the specific kinds of workloads he mentions.
2
2
In short, it seems like he was mostly wrong because: 1.) He failed to consider performance _relative to the total cost of ownership_, 2.) Having a memory hierarchy is really helpful when you think about costs in a holistic fashion, and 3.) Minimizing complexity really matters.
Replying to
4) motivated reasoning, because more specialized database companies are a lot easier to start
5) Under-estimated application side scale out techniques that are necessary for pure machine size reasons anyway
1
1
5
I don't think it's so clear. [3)complexity] was always my driver. If one PostgreSQL database does the job, I'd take it over five special-purpose DB technologies and three data streaming stacks... fewer things to break and page me on the weekend please!
3
2
Show replies