Courtesy: Enterprise Irregulars
Point 1: NoSQL technologies require more investment than Relational to get going with.
The remarks from Netflix are pretty clear on this. From the Netflix “Tech” blog:
Adopting the non-relational model in general is not easy, and Netflix has been paying a steep pioneer tax while integrating these rapidly evolving and still maturing NoSQL products. There is a learning curve and an operational overhead.
Or, as Sid Anand says, “How do you translate relational concepts, where there is an entire industry built up on an understanding of those concepts, to NoSQL?’
Companies embarking on NoSQL are dealing with less mature tools, less available talent that is familiar with the tools, and in general fewer available patterns and know-how with which to apply the new technology. This creates a greater tax on being able to adopt the technology. That sounds a lot like what we expect to see in premature optimizations to me.
Point 2: There is no particular advantage to NoSQL until you reach scales that require it. In fact it is the opposite, given Point 1.
It’s harder to use. You wind up having to do more in your application layer to make up for what Relational does that NoSQL can’t that you may rely on. Take consistency, for example. As Anand says in his video, “Non-relational systems are not consistent. Some, like Cassandra, will heal the data. Some will not. If yours doesn’t, you will spend a lot of time writing consistency checkers to deal with it.” This is just one of many issues involved with being productive with NoSQL.
Point 3: If you are fortunate enough to need the scaling, you will have the time to migrate to NoSQL and it isn’t that expensive or painful to do so when the time comes.
The root of premature optimization is engineers hating the thought of rewriting. Their code has to do everything just exactly right the first time or its crap code. But what about the idea you don’t even understand the problem well enough to write “good” code at first. Maybe you need to see how users interact with it, what sorts of bottlenecks exist, and how the code will evolve. Perhaps your startup will have to pivot a time or two before you’ve even started building the right product. Wouldn’t it be great to be able to use more productive tools while you go through that process? Isn’t that how we think about modern programming?
Yes it is, and the only reason not to think that way is if we have reason to believe that a migration will be, to use Stonebreaker’s words, “a fate worse than death.” The trouble is, it isn’t a fate worse than death. And yes, it will help to have great engineers, but by the time you get to the volumes that require NoSQL, you’ll be able to afford them, and even then, it isn’t that bad.