So everyone is blogging about NoSQL like there was just a divine intervention that handed us this epiphany just 2 weeks ago. Well I guess the term has still sort of fresh so everybody is busy making sure Google, Bing and friends get at least one hit on their blog when people search for NoSQL. Now is my turn.

A lot of the following is stating the obvious (though a lot of NoSQL posts from either side of the fence - why is there even a fence on this topic? - are not mentioning them .. so maybe not so obvious:

• use the right tool for the job (yes I still have use cases for MyISAM)
• NoSQL is a sucky name, because while some people also hate SQL, the key change is in dropping the relational model and/or ACID
• So yes you can take away the SQL interface from a MySQL storage engine and its still not what people think of when they say NoSQL
• You could stick an SQL interface in front of a NoSQL store
• surprise MySQL has been loose when it comes to ACID since forever, which was one of the key reasons it was able to out perform many of the big guys for very specific use cases
• most of us by now have a clear idea of RDBMS, what they do well and what they don't and how to work around that, we do not have the same level of expertise and tool chain for NoSQL
• NoSQL is not just about scaling like Google, it can just as well be about convenience (enjoy EAV much?)
• Yes NoSQL can also help scaling issues for some use cases (especially those PK lookups)
• Some NoSQL is fast for writes, some is fast for reads, even for NoSQL its hard to be fast at both (but easier than for an ACID RDBMS because NoSQL is allowed to take short cuts)
• NoSQL stores can be very different nature, so we will soon have to start coining even more terms (well there is key value store, column store, document store)
• Using NoSQL for problems an RDBMS solves well today is going to be harder work

Hmm ... I guess I could go on, but I gotta run to frisbee practice :)

Had a similar conversation today which also sparked http://www.paulscott.za.net/index.php?module=jabberblog&postid=ps123_63128_1269946762&action=viewsingle

Thanks for confirming (more elegantly) what I said ;)

ultimate or golf?

EAV and NoSQL were meant for each other

hmm .. not funny, just showing that you are against it.

But to complete your list:
- NoSQL does not know about JOIN

But:
- NoSQL can have embeded dataset

It has it advatages and disadvantages. I agree your first statement "use the right tool for the job" .. So NoSQL can be the right tool for some jobs :)

@rudy: I am over 30 but still too young for golf .. ultimate all the way .. off to Rimini freezing my ass off at the biggest beach tournament of the year.

@albert: I am not for or against any tool ..

Via twitter I just proposed #NoRACID as a better alternative for the #NoSQL misnomer.

Hi, good post.

Would you be able to elaborate on "NoSQL is allowed to take short cuts", or point us in the direction of some relevant reading?

That bit caught my attention and I'd be happy to read more about the mechanics there.

@Steven: Hmm I might have gotten your hopes up too much there. I was mainly referring to the fact since adhering to relational theory and the common expectation for RDBMS to follow ACID, they are limited in many ways in terms of optimizations, which do not apply to NoSQL and friends.

What I find very interesting that is enabled by these databases is the Edge Web.

As for NoRACID, CouchDB fulfils ACID in single node setups so that might not be the perfect term either: Documentation and Re: CouchDB's ACID compliance.

Yeah .. but LessRACID instead of NoRACID sounded too stupid :)