NuoDB marketing mishegas
I must start by apologizing for giving a quote in a press release whose contents I deplore. Unlike occasions on which I’ve posted about inaccurate quotes, in this case the fault is mine. The quote is quite accurate. And NuoDB didn’t mislead me about the release’s contents; I just neglected to ask.
NuoDB evidently subscribes to the marketing fallacy:
- Big DBMS companies hit people repeatedly with marketing cudgels.
- We want to be a big DBMS company.
- Therefore we will hit people repeatedly with marketing cudgels too.
But to my taste, NuoDB’s worst travesty is not the deafening drumroll before launch (I asked off their mailing list months before), nor the claim that NuoDB’s launch would be a “big day” for the database industry (annoying but ordinary hype), nor the emergent flock of birds foofarah, nor even NuoDB’s overwrought benchmark marketing (distressingly many vendors do that).
Rather, I think NuoDB’s greatest marketing offense to date is its Codd-imitating “12 rules” for cloud database management. Up to a point, they’re everything you’d expect in vendor marketing:
- Self-serving.
- Repetitive.
- Stressing areas where NuoDB’s product does well.
- Glossing over ones where it doesn’t.
- Confusing present and future technologies as much as they think they can get away with.
But pretending NuoDB’s “12 new rules” are anything like Codd’s original rules is going several steps too far.
Let me start with a quick history reminder.
- E. F. “Ted” Codd invented the relational DBMS concept around 1970.
- 15 years later, there were various real or alleged RDBMS on the market.
- Codd published a list of “rules”, basically to separate real RDBMS from pretenders.
- Codd’s rules were widely accepted, and pretender products quickly fizzled in the market. In particular, Computerworld featured them strongly on its front page.
- During all this time, Codd worked at IBM, regarded much more as a theorist than as a software architect or implementer.
- Soon after the 12 rules, Codd retired from IBM.
- In the early 1990s, Codd published 12 more rules for a different kind of DBMS, in marketing support for MOLAP vendor Arbor Software (originator of the Essbase product now owned by Oracle).
- Computerworld featured those rules strongly too … but then apologized when they realized these were just a marketing gambit.
There are two big differences between Codd’s original rules and later imitations (including his own mentioned above). First, Codd was speaking from very clear authority, as the inventor of one of the seminal concepts in all of computer science. Second, the purpose of Codd’s rules was limited; in essence, he was claiming they were necessary to meet his original 1970 goal:
Future users of large data banks must be protected from having to know how the data is organized in the machine (the internal representation).
That’s much different from imitations such as NuoDB’s, which basically boil down to a grab-bag of (biased) suggestions as to what should be on your product selection checklist.
Anyhow, my first take on NuoDB’s “12” rules is:
- Rule 0 is general goodness.
- Rule 1 depends on your application needs.
- Rule 2 is a mess. If you take it literally, it says the entire Internet should run on a single DBMS. If you take it to be more reasonable, it’s obeyed by substantially every product on the market.
- Rule 3 is a nice metric of engineering success. It hardly deserves to be a “rule”.
- I agree with Rule 4.
- Rule 5 is a mess. For one thing, it misuses the term multitenancy. Beyond that, it sounds like a minor performance optimization blown up into a “rule”.
- Rule 6 is a must-have for a few applications and a nice-to-have for many. See my recent post on GenieDB for more discussion.
- Rule 7 is mush. But it does mention the engineering challenge of designing around unpredictable networking.
- Rule 8 is a mess. The basic idea of replication and redundancy is of course good. But the engineering trade-off of sacrificing efficient physical data storage so as to get the most platform portability shouldn’t be regarded as a “rule”; it’s merely an interesting choice that may or may not work out for NuoDB over time.
- Rule 9 is a good but very partial list of desirable features.
- Rule 10 is a NuoDB performance tuning feature that may or may not prove to be important. I’m guessing it won’t, but just in case I’d advise vendors to implement it if they can do so easily enough.
- Rule 11 sounds good, but I’ll confess to not spending much time on security these days.
- Rule 12 is a nice list of ease-of-use goals. I’m not sure how anybody could defend calling it a single “rule”.
If one tries to take a charitable view, certain of NuoDB’s “rules” could be construed as showing how to get physical/topology independence, in line w/ Codd’s efforts to get application-data-model independence — #1, 2, 6, 7, 8 and perhaps 10. But even if they were modified to be both accurate and coherent, it would turn out that extreme physical/topology independence is even less important than the purist application independence advocated by Ted Codd, Chris Date, and others. You develop systems to run in certain ways. Some kinds of future evolution are possible or indeed likely over the system’s lifetime; others are too remote to worry about. Investing in “perfect” insurance is rarely a wise choice. And while it’s likely that you’ll put numerous new applications over your existing database, it’s less likely that your hardware/network infrastructure will change in similarly drastic ways.
Comments
9 Responses to “NuoDB marketing mishegas”
Leave a Reply
I’m reading this writing gem http://www.dbta.com/Articles/ReadArticle.aspx?ArticleID=86896 and wondering who writes this junk, and oh yes, its from NuoDB marketing. Check off that “product launch 101” check box for saturation placed media articles.
Not sure I’d conflate “explode into action” and “flock of birds taking off”.
[…] NuoDB generated some mediocre YCSB results, then made a big fuss because NuoDB got those numbers while operating through SQL. Blech. I guess they proved that NuoDB’s SQL parsing/execution layer is better than the worst thing one can imagine an undergraduate writing as a homework project, but otherwise little substance was demonstrated. […]
Let’s not forget that marketing hype is just that…hype.
The ‘challenge’ is always the same – find out what they don’t talk about and why. What DB companies can’t do is of far more interest, surely?
On a more fundamental level, do all of these DB start-ups really want us to accept that the DB world is so broken that they can find a way to survive and grow beyond a few early friends and family deals? Unlikely.
To answer your last question, Paul, yes — and I agree with them.
Now, we can speculate about how MANY will survive and grow, or how early and how completely the growers and survivors are acquired by big companies. Note that DATAllegro and Netezza were both acquired by top-three DBMS vendors, and Aster was acquired by a top vendor in its space, while Sybase, Greenplum, and Vertica were acquired by big tech companies as well.
[…] has a less favorable view on the 12 rules, or maybe just marks his disagreement in stronger words… an interesting read anyway, as he […]
Ouch. http://dom.as/2013/08/18/on-nuodb-and-falcon
[…] were claiming with some success to be “relational”. But when Computerworld reported Ted Codd’s “rules” for RDBMS, that was that — RDBMS were defined to be what Codd and Computerworld said they were, and the […]
[…] Ted Codd’s 12 rules, not that anybody — even IBM — actually followed them all. […]
[…] even a correct quote can lead to a […]