And you are here why?

Throwing JSON documents into a NoSQL database is not going to automatically allow your system to scale. Corollary No, MongoDB is not  the answer. Note OK, MongoDB is  pretty good from a prototyping perspective, but it will  end up biting you in the butt... In fact, the general response for anything  other than prototyping should really be in two parts " Do you really know what you are doing?" " No you don't ." I'm getting pretty seriously curmudgeonly about this nowadays (" Get off my lawn" , etc.).  People probably shouldn't be using anything NoSQL  at all - they invariably end up shooting themselves in the foot...

Curt Monash talks to James Phillips at Couchbase about their future, and comes away, well pretty much where he was before. There is nothing drastically new in the article as far as Couch (Base/DB) is concerned, there is plenty of information available through The Googles about whats going on there as far as futures, players, etc. are concerned. The part I found fascinating was at the very end, when he says MongoDB is the big competition. He believes Couchbase has an excellent win rate vs. 10gen for actual paying accounts. DataStax/Cassandra wins over Couchbase only when multi-data-center capability is important. Naturally, multi-data-center capability is planned for Couchbase. (Indeed, that’s one of the benefits of swapping in CouchDB at the back end.) Redis has “dropped off the radar”, presumably because there’s no particular persistence strategy for it. Riak doesn’t show up much. Which is interesting, to say the least. The MongoDB is the big competition part is absolute...

The failure rates for startups is 30 - 90% , depending on how you define "failure".  That said, the failure rate for tech / VC based startups is really pretty far along on the 90% end of the scale .  The point here? MongoDB is remarkably good, useful, and effective at rapid prototyping, and quick development.  Oh, it may have any number of issues at scaling, data integrity, etc., but it is - really - way cool when it comes to Just Getting Something Out There. Putting the two together MongoDB - because if your startup is destined to fail, you may as well Fail Fast

All discussions about MongoDB will eventually include the phrase " It's there in the documentation " Corollary All sins are forgiven if they are documented beforehand Note Seriously, I don't care how bloody carefully it is documented, the default behavior of a database should not include silently losing information.  

Chris Travers has a fairly nifty article up titled O/R Modelling interlude: PostgeSQL vs MySQL , where-in he makes the claim MySQL is what you get when application developers build an RDBMS. PostgreSQL is what you get when database developers build an application development platform. This isn't really flame-bait - its intended as a statement to show how people approach arguments (flame wars?) about MySQL vs PostgreSQL.  To paraphrase Chris, MySQL has been massively disruptive because it tends to really, really look at the world from a Use Case perspective, answering the questions " What problem are you trying to solve ", while Postgres has been massively disruptive because it tends to look at the world from a theory perspective, answering the question " How should the database work in the solution " I'd add MongoDB to this mix though, and extend the above quote to say MySQL is what you get when application developers build an RDBMS. PostgreS...

Its a pretty serious point since, as far as I can tell, it is rapidly becoming the default DB that everybody uses when they have to do something "cloud-y". Wheres the problem with that? Well, lets think back to SQL databases - by and large MySQL and PosgreSQL really do tend to be "one size fits all".  If you're already thinking relational, then it really doesnt matter which of these two you use (no flames please!)  Yes there are differences in how they replicate, shard, do stored procedures, etc., but they're really the same damn thing (as is Oracle, for what its worth). NoSQL databases? Ah well, thats different.  They come in all sorts of shapes and sizes ( document , column-oriented , key-value , etc.) and each of these has a different sweet-spot.  I tend to think of them as solution-oriented data stores, i.e., each DB is tuned towards a specific solution domain.  Oh yes, they are certainly moving towards each other - Riak has secondary index...

You had to be hiding under a rock to not have seen the (anonymous)  Don't Use MongoDB  post that has been making the rounds.  I've replicated it below, just in case it vanishes. The author is (as of  this writing) unknown, but he/she brings up a lot of points.  For what its worth, I completely agree with the final recommendations, viz. 1. Don't lose data, be very deterministic with data 2. Employ practices to stay available 3. Multi-node scalability 4. Minimize latency at 99% and 95% 5. Raw req/s per resource Obligatory caveat here - I'm a big fan of BigCouch , and have been using it for a while now. That said, to defend Mongo (just a little bit. and yes, it hurts), when we started going down the CouchDB  path, I knew  what I was doing.  I'd read everything, I'd tested the bejeebers out of Couch (especially in the 0.9.0 days), and already had a pretty thorough grounding in NoSQL tech for a variety of unrelated reasons which I won...