NoSQL is a bullshit marketing term

All marketing terms are bullshit, but what is the point?<p>The point is to use a single word that people can rally behind to be disruptive. In my world, NoSQL is a movement about using the right tool (especially open source) for the job. It is a movement about building these tools to the point where they can be consumed and put into production quickly.<p>There is no value in being precise (in marketing) since then we are just cats that need to be managed. By being imprecise and use a bullshit marketing term, we gain collective market power.

NoSQL = "We don't have to solve every damn Database problem with Oracle 10G, despite what our (brought up in enterprise IT) tech-services group keeps insisting to our COO every time the engineering group rolls out a new product that uses something different. It does mean that we can't rely on the crutch of (1) optimizer/statistics gather, (2) RAC, (3) Dataguard, (4) MASSIVE spindle group SANs w/ vertically scaled Sun M9000/IBM P795 Database Server and our small group of DBAs to solve all of our query, HA, DR and scaling problems, but instead have to shift the responsibility for solving those problems onto the Engineering team, which may or may not make sense depending on whether we believe our core competence should be solving those problems with engineering instead of (1),(2),(3), (4).<p>NoSQL is a phrase that means "use the right tool for the job" instead of just throwing endless amounts of money at low-risk, but 100x (1000x?) more expensive solutions that will eventually fail at internet scale load anyways.<p>NoSQL means taking on more of the engineering risk, rather than shifting it to your vendor.

I thought the whole point of the term was not to refer to products which solve a particular problem, but to simply refer to anything other than the traditional relational databases that use SQL.

In my opinion, NoSQL is bullshit because it markets itself on what it's not rather than what it is, which is not so easily explained in one simply buzzword.<p>Grouping Cassandra, CouchDB, MongoDB, Redis, etc. is the same as grouping MySQL with git - they all store data in one way or another, but the data they store and the way they store it varies wildly.<p>It's also sad, because all these "alternative" databases offer a lot of features that RDBMS' don't, and they should be promoted instead of stuck under an "umbrella" term to protest against SQL databases.

Quite frankly, the anti-NoSQL-as-a-term is getting a bit tiring. As someone who has been working on "NoSQL" systems since 2000, I have been extremely thankful that there is finally a broad-based movement exploring alternative datastore architectures. It used to be extremely depressing to have discussions with fellow engineers on the benefits of alternative architectures and for them to simply reject it on the grounds that "SQL DBMS must be the best since they've had decades of work behind them". At the very best, someone might have been radical enough to contemplate the use of an Object Database.<p>In contrast, thanks to the NoSQL movement and the exploration of alternative models that it has encouraged, the quality of discussions is extremely different today. More and more engineers are aware of the benefits and issues with various models and are much more open to alternatives. So when I say that I am extremely thankful to whoever coined the damn term and for efforts like NoSQL Summer, I really mean it. It has really improved my quality of life.<p>Now I get that "NoSQL" isn't a 100% accurate term. But what marketing term ever is? Take something like AJAX — most "AJAX" apps have never dealt with XML, yet the term has been extremely useful. It helped solidify a broad-based effort to explore using JavaScript and thanks to the "AJAX movement" of a few years ago, we now have XHR in all modern browsers and awesome libraries like jQuery!<p>The real issue as I see it is that projects are keen to differentiate and are thus reacting to being lumped together with extremely different systems. Now no-one who understands the technologies is ever going to compare the likes of Redis, CouchDB, Neo4j, Cassandra and Hadoop as equivalents, but it is understandable that projects are afraid of being considered equivalent by those who are simply choosing <i>a</i> NoSQL system for their project without understanding the differences.<p>This follows onto another issue — a leader (or two) often emerge once a new domain has been established and the "smaller" projects are cautious of being sidelined by "big boys" like Cassandra/MongoDB/Hadoop. To continue with the AJAX example, in the early days there used to be a whole bunch of options regarding JavaScript libraries: Prototype, jsolait, MochiKit, MooTools, jQuery, Dojo, etc. In contrast, nowadays, jQuery is the default choice for the vast majority of developers. I don't think that there is such a clear winner in the NoSQL field yet. In fact, given the massive fragmentation, we probably haven't even heard of the final winner yet!<p>That is not to say that the concerns of the various projects aren't totally valid. But the issue is not with the "NoSQL" term but rather with differentiation and understanding — both of which can only be solved by better communication. Phrases like "Online Request Processing Systems (ORPS)" or even "Alternative Datastores" aren't exactly catchy marketing terms. NoSQL may not be perfect, but it's here and it's more than good enough. So can we please stop bashing it and focus on coming up with clearer differentiators? Thanks!

aside: has anyone read a good discussion of Codd's original relational paper? <a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.98.5286&#38;rep=rep1&#38;type=pdf" rel="nofollow">http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.98....</a> Thanks!<p>I'm confused by his five example for "1.2.3. Access Path Dependence" (page.378), where an app would fail if the data representation changed, because I think an app using a relational store would also fail if the relations were organized differently. I can see some possible resolutions, but the paper doesn't address the issue...<p>I concede that it's hard to assess a proposed approach when it doesn't actually exist yet; but I think that if you raise an issue with the existing approaches in a paper, it's reasonable to also assess your own proposal with respect to that issue.<p>e.g. maybe he imagined automatic views to convert the underlying relations (so that different relations are identical if they represent the same information...); or a manual conversion layer with views (but the same could be done for the other store!); or maybe he was only thinking of different <i>physical</i> representations when he wrote that part and it didn't occur to him that different relations also might be used<p>EDIT <a href="http://www.aisintl.com/case/library/Date_Birth%20of%20the%20Relational%20Model-2.html" rel="nofollow">http://www.aisintl.com/case/library/Date_Birth%20of%20the%20...</a><p>I think he's saying that while the relational model has the same problem of retaining compatibility for old apps when it evolves, it this is * <i>easier</i> * to do this with the relational model. ie. the "number of access paths" for old apps becomes "excessively large" for non-relational models. He talks a bit about the complexity of representing different queries later on, but somewhat obliquely and doesn't draw the connection (and I don't quite follow what he means in the second last paragraph of section 1.5, where he mentions n!, 2n-1 and n+1 - I understand it so little, that I think there might be a typo).<p>Ah! He seems to have addressed it more directly in a previous, less-cited IBM-only paper from 1969... to which I happen to have a link <i>right here</i>: <a href="http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.173.597" rel="nofollow">http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.173.5...</a>

<i>NoSQL is a bullshit marketing term coined to insight ire in the heart of DBA's.</i><p>No it's not. It's a typical human response to needing to give names to groups of items. Collective nouns, even misjudged ones, bring concepts to light and allow us to discuss them collectively without lengthy explanations. The elements behind AJAX existed before the term was coined, but its coining gave everyone a single point to discuss and support and its usage exploded rapidly after its coining.<p>RadioLab's "Words" show - <a href="http://www.radiolab.org/2010/aug/09/" rel="nofollow">http://www.radiolab.org/2010/aug/09/</a> - goes into the value of words as a way to represent concepts and feelings and, specifically, how those things fail to exist <i>without</i> the words to define them.

All marketing terms are bullshit? Wrong. All marketing terms are a way to provide a simplified way for consumers to conceptualize a product. In that respect, "NoSQL" is not bullshit at all, even though it may not be as technically accurate as some would prefer.

I experiment with NoSQL stores because they're fun to work with. Who gives a shit what the proper classification scheme is? Why are people so religious over this?

Funny thing is when you go see the profile of the guy you realise he's a functional alcoholic.

&#62; to insight ire<p>Ouch. Nothing hurts your credibility quite like an egregious spelling mistake just as your rant is taxiing onto the runway.