A techie debate is raging on the relative merits of relational vs. so-called NoSQL databases. I have a techie opinion and a stake in the debate, but in this post I’d like to make a business prediction that has nothing to do with the technical merits of one vs. the other at all. It’s only about Japanese cars and Detroit. And Oracle, which has been making more money off SQL than anybody else. Aka the Innovator’s Dilemma.
First the facts:
- Big Oracle databases can do amazing things with amazing amounts of data, at even more amazing prices (counting software, hardware, people — total cost of ownership).
- NoSQL databases can do somewhat different but also amazing things with perhaps even more amazing amounts of data, at a price close to zero.
- The cool engineers and most innovative projects are at big internet companies and startups. Which rarely spend their money to buy Oracle databases any more, so they use NoSQL for their massive amounts of data.
- The big sales for Big SQL are in enterprises, which by and large have less cool engineers building less cool things.
- Wait a few years, and two things will have happened:
- enterprises are going to play catch-up on the coolness, as they always have. So they will copy NoSQL successes inside the enterprise.
- NoSQL databases will have a lot more features and support. So they will be mature enough for the enterprise.
You see where this is going, and it’s not pretty for Oracle’s market cap:
NoSQL databases are a perfect disruptive technology in Clayton Christensen’s Innovator’s Dilemma model. NoSQL are the cheesy, cheap, toy Japanese cars in the 1970’s. Oracle is Detroit. To rehash the history, some customers decided that a cheesy toy car was just good enough for them. The Japanese took the profits to make their toy car just a little less cheesy and a little less toy. So more customers bought them, which generated more profit that could be invested for a more serious car etc. etc. Detroit almost died (and still might) because it was unable to respond to a low-cost alternative moving upmarket, which is the heart of the innovator’s dilemma.
To the right is the graph from Wikipedia illustrating the innovator’s dilemma. Applying it to SQL/NoSQL, the “most demanding” arrow is the Oracle database. One of the lower arrows is MySQL (now also owned by Oracle). The arrow going across is NoSQL that upsets this very nice equilibrium.
I’m predicting that the relational database is going to die. (Not die as in “vanish”, but die in the same sense that the mainframe died: it became irrelevant for the majority of the industry.)
It’s not going to die because the technology is bad and something better (NoSQL) came along. That point can be made, and has been made many times in the NoSQL debate. But every time it is being made it seems to ignore the possibility that Oracle extend its database to include NoSQL features. That is an almost-certainty a little further down the road: think of it, if you were their product manager, wouldn’t you? My point about the death of the relational database here is a stronger one because it is about money.
The Big SQL business (in particular Oracle’s) is going to die because several major leading market segments (major internet companies, innovative startups, non-internet companies with massive amounts of data) are already massively investing in NoSQL, whose cost is much lower than the total cost of ownership for an Oracle database. So all the innovation is going into stuff that can be downloaded for free on the internet, that scales at infinitum, that can some things SQL can’t do, that does not require support contracts, and that is cool. That might even come included in other products and that does many things (think Map-Reduce) that a SQL database simply is not suited for. In a few years, it will be clear (what isn’t today) how to build the same kinds of enterprise apps against a low-fee NoSQL database and CIOs are going to question Oracle support contracts.
And then watch ORCL tank.
What is Oracle to do? Drop license fees? Open-source their “real” database (not MySQL, it doesn’t figure in this equation). Not going to happen. And if it were, it won’t help because the core problem is that they are too addicted to their fees at the level they are at. Wall Street would kill them. If they built an additional NoSQL product at a low price point it would have the same problem. Focus on their high-value customers is more like it, which Christensen calls “move to the high end” (aka expensive end). That strategy might patch the leaking dam for some time but only delay the inevitable.
I have no ill intent towards Oracle. I just can’t see any other future. Betting on NoSQL is the thing to do today, not because of all the stuff NoSQL does today but because it will move up-market, even if today it is still on the cheesy end. Soon it won’t be cheesy any more, and of course it won’t be called NoSQL by the time it starts winning seriously.
P.S. I realize very well that there are many rather different things on the NoSQL umbrella today. I do have an opinion which will be the ones winning and why, but for the purpose of this post, it doesn’t matter which one does, so I ignore the differences, because any of them will herald the end of Big SQL.
Comments
2 responses to “NoSQL and the End of the SQL Cash Machine”
Your post only addresses the idea that Oracle will tank. I think you over-reach when you extend that to the rise of NoSQL; I think the mature PostgreSQL will be a strong option too.
So while I can see merit in your argument for the demise of Big SQL, I don’t see that as a decline of SQL. Rather, it means one can no longer base a corporation on selling boxed SQL products and consultants.
One can’t base a corporation on selling boxed web browsers, either. They haven’t gone anywhere, nor have they declined in quality. They’re still sold (with the operating system), and increasingly sold as free software, but are no longer a cash cow in themselves.
I haven’t really been paying attention to this, because I feel like I saw the whole “NoSQL” discussion happen over a decade ago. Back then there was this upstart tool called MySQL, which was basically a key value store with a text interface. Kind of like BerkeleyDB, but you got to use syntax like the big boys. Philip Greenspun and other Computer Science people were running around saying “but MySQL isn’t a database, why are’t you using a database?”
Then eventually all those cool things like referential integrity and atomic operations got added to MySQL, and Google exposed the API to a database on their app server which was a simple key value store that used SQL. And SQLite did the same thing for local apps. And those tools grew up and now we’re seeing the cycle revisited.
I think the thing about all of these solutions, especially the ones which are implementing ad-hoc distribution systems, is that they’re great for places where approximate returns to a query are okay. Like some of the weirdness we see Facebook exhibit. But getting that right can be a competitive advantage. And there are applications for which “mostly correct” will never be a solution.
(partial disclosure: about a decade ago I wrote a bunch of code for the kernel of one such that’s been serving circa several million user authenticated fuzzy match queries a day since then. When we implemented it, it was to replace an Oracle database, and the million and a half queries a day that system was serving was *huge* by the standards of the time. I said then that I think we’d do better by putting those same engineering efforts into PostgreSQL. I still think so.)
So, yeah, there’s a big market opportunity here, Oracle’s going to see challenges, but much as all applications evolve until they contain a buggy re-implementation of a lisp interpreter (or, in Python and Ruby, a simple re-implementation of one), I predict that all databases will evolve until they contain a buggy re-implementation of a relational database with an SQL like query interface.
I think there’s a critical difference between the use cases for NoSQL and SQL databases, and it’s something that analyses of the two have missed back before Philip Greenspun’s oft-debated “MySQL is not a database” statements in the late ’90s: NoSQL is great for places where approximate results are acceptable.
However, much as all applications evolve until they have a re-implemented buggy lisp interpreter embedded in them, and until they can send email, people will continue to look askance at Facebook serving up the occasional really whacked out page, and someone else is going to use getting that right as a competitive advantage.
None of this contradicts your assertion that we’re going to see the end of “Big SQL”, but I think what it does mean is that most of the NoSQL developers will eventually be implementing all of the things that make a real SQL database what it is, transactions, enforced referential integrity, etc, and that
I also remember in a previous lifetime working on the kernel of a distributed multithreaded database that replaced Oracle in an application. It was being built to deal with a load that at the time was considered amazingly high, several million authenticated queries per day.