CouchOne has become the first of the major NoSQL database vendors to publicly distance itself from the term NoSQL, something we have been expecting for some time.
While the term NoSQL enabled the likes of 10gen, Basho, CouchOne, Membase, Neo Technologies and Riptano to generate significant attention for their various database projects/products it was always something of a flag of convenience.
Somewhat less convenient is the fact that grouping the key-value, document, graph and column family data stores together under the NoSQL banner masked their differentiating features and potential use cases.
As Mikael notes in the post: “The term ‘NoSQL’ continues to lump all the companies together and drowns out the real differences in the problems we try to tackle and the challenges we face.”
It was inevitable, therefore, that as the products and vendors matured the focus would shift towards specific use cases and the NoSQL movement would fragment.
CouchOne is by no means the only vendor thinking about distancing itself from NoSQL, especially since some of them are working on SQL interfaces. Again, we would see this fragmentation as a sign of maturity, rather than crisis.
The ongoing differentiation is something we plan to cover in depth with a report looking at the specific use cases of the “database alternatives” early in 2011.
It is also interesting that CouchOne is distancing itself from NoSQL in part due to the conflation of the term with Big Data. We have observed this ourselves and would agree that it is a mistake.
While some of the use cases for some of the NoSQL databases do involve large distributed data sets not all of them do, and we had noted that the launch of the CouchOne Mobile development environment was designed to play to the specific strengths of Apache CouchDB: peer-based bidirectional replication, including disconnected mode, and a crash-only design.
Incidentally, Big Data is another term we expect to diminish in usage in 2011, since Bigdata is a trademark of a company called SYSTAP.
Witness the fact that the Data Analytics Summit, which I’ll be attending next week, was previously the Big Data Summit. We assume that is also the reason Big Data News has been upgraded to Massive Data News.
The focus on big data sets and solving big data problems will continue, of course, but expect much less use of Big Data as a brand.
Similarly, while we expect many of the “NoSQL” databases have a bright future, expect much less focus on the term NoSQL.
Subscribe via RSS
14 comments ↓
Matt,
Nice post. I agree with you on NoSQL, the term losing meaning (e.g., not only SQL) and grouping together too many different types of DBMSs. I also agree with conflation with both big data (as you note) and open source (as you don’t).
On Big Data, I just have a lot of trouble believing that it will hold up as a trademark — as I recall, trademarks are not supposed to be descriptive and as I recall (from all the letters AT&T used to send us at Ingres about Unix) that the owner of a trademark needs to constantly remind folks who use it generically that they shouldn’t.
Every time you say “pass me a Kleenex” some marketing person at Kimberly Clark is happy but some lawyer wants to tell you to say “pass me a Kleenex-brand tissue” instead.
Thanks Dave,
Good point on the trademark. Clearly nothing is going to stop the use of the term big data, but there does seem to be a decline already in using Big Data. Depends if anyone has enough desire to challenge I suppose.
Matt
I think that what were witnessing is more of a convergence of trends rather then a split into two camps.
In other words that idea from the NoSQL worlds such as de-centralized data structures, relaxed consistency, dynamic schemas, map-reduce starting to merge with the semantics of SQL.
This reminds me the emergence of Object database back in the 90′s. When OO came to the word we started with specialized OO databases but at the end it was the O/R mapping tools that won the war. This is very similar to what we can already see with Google Big Table that is using JPA facade onto of its BiGTable datastore, the same goes with Hive and Hadoop and so forth.
So the right strategy would be having NoSQL backend with SQL front-end on one end, and SQL engines starting to add support for dynamic data structures and map/reduce and de-centralized deployment on other end.
You can find more details on that analysis on my post YeSQL and the NoCAP
Nati S
GigaSpaces
Thanks Nati,
Agreed it is not about splitting into two camps but there are a couple of trends going on at the same time, including the convergence of technologies and the divergence of use cases. The result should be a rich set of options, and the focus then needs to shift towards choosing the right combination of technologies for the particular task at hand. That’s another thing we plan to cover in our report.
Matt
[…] The beginning of the end of NoSQL — Too much information […]
Nice post, Matt. Fully agree that NoSQL is less than illuminating when one is attempting to ascertain fitness of purpose for one of these solutions, for all the reasons you highlight.
I would also suggest that lumping solutions together according to data model (key-value, document, column-oriented, graph, etc.) is almost equally useless.
I started to reply in more detail here this afternoon, but it turned in to a rather lengthy blog post instead: http://blog.membase.com/use-cases-are-driving-divergence-and-convergence-nosql-solutions.
We certainly live in interesting times.
james.
http://www.membase.com
Obviously we are largely agree Nati,
“So the right strategy would be having NoSQL backend with SQL front-end on one end, and SQL engines starting to add support for dynamic data structures and map/reduce and de-centralized deployment on other end.”
Please don’t blame the marketing types for the NoSQL bandwagon used to crash the RDBMS FUD, bigots, and complacency. It was fun for a while, now let’s have the real debate.
Different use cases deserve different persistence paradigms, but interface standards provide interoperability.
Regards, Mike
SQL is wrongly used. In code, there shouldn’t be any SQL. SQL is made for humans to query database and get results. Why are we adding overhead in code to parse SQL statements? is it because there is no standard API among database servers? And because we are using so much SQL there are security leaks in applications (SQL injections).
[…] the425Group的Matt Aslett评论： […]
It should come as no surprise that CouchOne is not the only vendor cringing under the NoSQL umbrella. It was a convenient term for the sake of awareness of other options but has outlived its usefulness.
[…] The beginning of the end of NoSQL notes that Big Data, with which NoSQL has become closely associated, is endangered as well because there’s a trademark on that term. Massive Data and Big Analytics are emerging in its place. […]
[…] http://blogs.the451group.com/information_management/2010/11/12/the-beginning-of-the-end-of-nosql/ […]
[…] the425Group的Matt Aslett评论： […]
[…] The beginning of the end of NoSQL by Matthew Aslett […]