Some NoSQL solutions are general purpose, and some aren't. I think the analysis is accurate for those which aren't (Cassandra), but way off for those which are.
The advantage of NoSQL for the average folk isn't their speed, but rather it's their dynamism. This is especially true if you're coding in a static language. You also gain from the shift to map-reduce vs group by.
There seem to be two other points to the argument. First, someone made a funny Youtube video (and it was funny!). Second some people failed with NoSQL. Not especially good arguments.
The author is an SQL language and MySQL database consultant, and he writes an article questioning NoSQL. Fair enough, and I agree with his point that different NoSQL datastores have different strengths and weaknesses and it can be difficult on a new project to know up front which CAP tradeoffs may be OK to make (e.g., HBase may have better tuning for faster consistency but Cassandra is likely easier to set up across different data centers; MongoDB is very easy to use in simple master slave or replica sets setups if no sharding is required; etc.)
Personally, I use PostgreSQL and MongoDB for most of my work but make a real effort keep up to speed on CouchDB (actually, BigCouch is more interesting), HBase, Cassandra and a few RDF datastores.
I've had a pretty good run at cleaning up after botched database jobs, so caveat emptor...
Two things:
1. Most day-to-day problems involve relationships among entities. It's not stodgy or wrong to use a good RDBMS when that's the problem you're dealing with.
2. Many NoSQL adopters wind up building a relational database on top of something else. That's a fun job, but not everyone can afford to ditch 40 years of R&D and pretend they've invented something. I think a lot of the allure in implementing these solutions comes the hype, promise of a silver bullet-like solution, and the opportunity to dabble the intricacies of creating a database.
You could also arge that adopters 'sql style RDBMS' end up building a NoSQL datastore.
If you find you are using a lot of EAV, polymorphic associations, multicolumn attributes, trees, graphs it might be a better option to go down one the on of the many NoSQL routes. Key/Value, Column Stores, Document and Graph databases. Sometimes you can make huge gains in design simplicity because you persistance and/or queries map far more cleanly.
An interesting example of "NoSQL" on top of an "RDBMS" is Salesforce [1].
A huge upside to RDBMS in my view is that they are 'well understood' in production, and operations know how to deal with them.
It is a big design space out there, and you can make a lot of tradeoffs :)
One of the biggest costs of a NoSQL solution in an early-stage startup: what's hot today may be abandoned by everyone else by the time you're a real company, leaving lots of effort inventing clever solutions to novel problems created entirely by your data.
It's much more feasible to start with a solid database and add caching for hot data than it is to try to build a company and a brand new database technology at the same time.
I took me 3 months or so to finally grok CouchDB map/reduce queries. Now that I've seen the light, I'm not sure I'll go back to an RDBMS any time soon -- at least not for bread and butter webdev.
"...You must know what will be the questions that you will be asking upfront."
Even in SQL land you need to know your queries in advance. Sure you can do table scans on unindexed fields, but you're going to crush i/o.
With Couch you can always deploy new views during a maintenance window for queries you didn't anticipate. Same thing with adding indexes in an RDBMS to handle unanticipated/slow queries.
At least with Couch I know that my queries are more-or-less pre-computed in B-trees. I know I'm not scanning the same tables over and over.
Moreover, if you know what you're doing wrapping conflict handling around Couch's MVCC is straightforward.. and you get all the benefits of offline replication.
In my case, I've built a service that calculates utility-style usage based off Couch range queries that are reduced into a cost calculation. Given any date range I can reduce a utility fee an order of magnitude faster than I could in SQL land.
YMMV, etc.. but I'd say this is a case of "haters gonna hate".
It seems contradictory, since startups thrive on making radical departures from the status quo, but I think there's a strong case to be made to build your foundation (the stuff nobody sees, but plugs along silently in the background) on tried and true technologies, as opposed to the hot new thing.
Of course, in 5-10 years, some NoSQL solutions will be the tried and true tech, and we'll be arguing whether DoublePluSQL is really worth all the hype it's been getting.
> startups thrive on making radical departures from the status quo
Meanwhile, Pinboard.in quietly sucks up the Delicious community, using technology that's as dishwater-dull as possible.
Delicious itself is floundering, due to (among many other things) a problematic migration to a framework that was internally marketed as the sexy new thing. That framework wasn't NoSQL at all (quite the opposite) but the point stands that the cost of new frameworks can be dear.
Do you have any reference for this ? Delicious' problems as far as I've read anywhere are due to Yahoo's cutbacks, plus having to integrate with Yahoo services, making it hard to break off and sell to another company. However I've not heard about any specific technical issues with Delicious itself.
I worked one floor away and have friends who worked on Delicious. Generally they haven't talked about this, so I don't think I should. Plus I'm getting a bit tired of all the TC "scoops" that come out of all of this bitching in public.
This is a terrible article. His three main points:
1. "You find yourself writing lots of code to reinvent the wheels that SQL gives you for free, and before long you’ve unwittingly reinvented the relational database."
NoSQL came about because people were sharding their data and managing relationships outside of the data layer in custom code anyway, and they were well-served by putting some of that complexity back into the data layer. This wasn't a trend because people don't understand the mathematical beauty of normal forms. This was a trend because altering the schema of a heavily accessed MySQL table will bring your website down.
The irony is that most of the arguments for NoSQL have nothing to do with SQL itself and everything to do with the underlying storage mechanism and ACID semantics. A more accurate acronym would be NoB-tree or NoACID.
I have always seen the relational-databases-VS-nosql-databases as a false dichotomy. I think these systems serve different purposes. I use MySQL+memcache for a site now, but I'd have no hesitation to use CouchDB for another site if that's more suited for it. I'd even use them both if that's beneficial for the webapp.
NoSQL is a terrible name for a technology. Why define it by what it isn't, instead of what it is?
I've pretty much ignored NoSQL because of this, and because I haven't had any data storage problems that aren't easily solved with either a relational database or LDAP.
Is there a NoSQL database that claims that? I don't know of one. Rather, they attempt to implement different facets of CAP. Also, the CAP theorem, as it stands, is showing its age, Brewer himself has said it needs to be updated.
I'm one of those who dove head first into NoSQL primarily because of hype. I've learned better. Relational is now my default, and I identify specific cases, specific tables that I know for sure won't need complex querying, and move those to NoSQL.
Though the end effect is that NoSQL still stores 60+% of my data.
The advantage of NoSQL for the average folk isn't their speed, but rather it's their dynamism. This is especially true if you're coding in a static language. You also gain from the shift to map-reduce vs group by.
There seem to be two other points to the argument. First, someone made a funny Youtube video (and it was funny!). Second some people failed with NoSQL. Not especially good arguments.