Is NoSQL A Premature Optimization?


Several readers have forwarded an article holding NoSQL as a premature optimization. I assume because I’ve written about NoSQL before , with many taking those pieces as anti-NoSQL declarations of war, holding me as an anti-NoSQL crusader.

I respectfully, yet vigorously, disagree with Mr. Warfield’s take on this.

To quote something I said in an entry almost four years ago-

While there is no doubt that there is such a thing as
premature optimization — it is an evil distraction that sidetracks many projects — there are critical decisions made early in a project that can cripple the performance potential (both resource efficiency, and resource maximum), making later optimizations enormously expensive, if not impossible without an entire rewrite.

A premature optimization is wasting time writing functions in assembly early in the code lifecycle, before you’ve run a profiler and found the slow points. It is not premature optimization, however, to make foundational choices based upon realistic deployment and usage scenarios. When the scope of premature optimization is perverted to include “things a well-financed team could change in a year”, well that is just incredibly unreasonable, and is in an entirely different universe than what Knuth intended.

In my various articles on NoSQL, my position has actually been that good SQL implementations offer fantastic performance with great scalability, easily accommodating the overwhelming majority of projects: In fact I would still hold that for many uses contemporary SQL solution on modern hardware offers better performance than the alternatives. If I didn’t think such solutions offered good performance, or that they weren’t
scalable, I would be eagerly waving the NoSQL banner.

There are a lot of benefits to NoSQL solutions that are outside of the realm of performance “optimization”. MongoDB is easy to get started with, and for some classes of projects it’s a very low-friction, natural way of storing and pulling data. Many such solutions offer the ability to painlessly and easily implement many-site redundancy. Any of these drive their adoption for green field projects.

But positions that posit that you can just rewrite almost everything when and if the need arises are irrational. The majority of projects that find themselves overextended with no options (where, Mr. Warfield holds, you just rewrite all of that) will quickly become abandoned failure projects.