And you are here why?

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...

Paul Hammant has an interesting article up about The document as the single source of truth - which made me think about How We Do Things.  Aeons ago, we wrote the first version of our telephony platform, and it was State Of The Art, and It Was Good .  It had turbochargers and coffee-grinders, and a honking huge database into which we dumped all of our data, but first the data was broken up so that it fit well into various tables and columns and it was fast and well thought out and It Was Good . Well, maybe Not So Good , because pretty early on we realized that it would be useful if we had some record of changes - when a user calls up and sez. " I never turned on Call Recording ", its useful to be able to say " Why yes sir, you did indeed, it was on the 17th at 3:30pm, and by the way, Yes, we *are* Big Brother thank you very much ".  So we added _changes tables that logged the updates to user's addresses, and profiles, and parameters, and, well, pret...

There is a thread/vote on LinkedIn asking " Would you consider migrating to couchbase from couchdb " Which would be a useful and relevant data point if you thought of it as " Would you consider migrating to couchbase from another NoSQL store, e.g. couchdb (or mongoDB, Riak, etc.) " However, given the way the question was phrased the thread pretty rapidly devolved to the usual CouchDB vs CouchBase discussion. And that is is a bit of a trick question - CouchDB and CouchBase are different products (bear with me here).  As I allude to here   the NoSQL space is a " solution-oriented " space.  The point is that unlike the SQL space, where you can pretty much use MySQL / PostgreSQL / Oracle / whatever for *any* of your problems (money willing), in a NoSQL environment it is different.  If you've done your homework, you'll have picked the appropriate NoSQL store for your application right off the bat.  If you haven't, well, you'll probabl...

John Wood (of Signal fame) has a post up about Signal's experience moving to, and away from, CouchDB.  Its an interesting real-world example of what I've described in " NoSQL - What you'll find (for sure!) ".  To recap, when first getting into NoSQL, you are sure to find that You didn't understand your own problem-space as well as you thought you did.  You didn't understand the package that you are using as well as you think you do. It will not  scale the way you thought it would.  Oh, it'll scale all right, just not the way you thought it would.  Your object/document/JSON/whatever model really doesn't map exactly the way you expected it to. In John's case, they found that HTTP is a Very Slow Database Protocol MVCC Overhead (is bad) Large Databases Beat Up the Hard Disk CouchDB is not a Distributed Database (by default) map/reduce takes a while to get used to Views take forever to build Views are gigantic on disk Replicati...

There is a case-study for mongoDB at foursquare up on 10gen's site.  Mainly the usual stuff, viz. AutoSharding, GeoIndexing, Replica Sets, and Document Model. Nothing in the case study actually screams out "Yes!  This is why they should have used MongoDB "(over BigCouch for example), which is pretty funny, since one of MongoDB's big differentiators (high write throughput) would have been a key feature. Note :  FWIW, the high write throughput comes with the potential for data loss, but thats not really an issue for foursquare (if your checkin doesnt work, just do it again...). Another Note : The idea that a database doesn't guarantee the writes and can occasionally lose data is, of course, interesting  :-)

Damien Katz writes : What's the future of CouchDB? It's Couchbase. Huh? So what about   Apache CouchDB ? Well, that's a great project. I founded it, coded the earliest versions almost completely myself, I've spent a huge amount of blood, sweat and tears on it. I'm very proud of it and the impact it's had. And now I, and the Couchbase team, are mostly moving on. It's not that we think CouchDB isn't awesome. It's that we are creating the successor to it: Couchbase Server. A product and project with similar capabilities and goals, but more faster, more scalable, more customer and developer focused. And definitely not part of Apache. ... If it sounds like I'm saying Apache was a mistake, I'm not. Apache was a big part in the success of CouchDB, without it CouchDB would not have enjoyed the early success it did. But in my opinion it's reached a point where the consensus based approach has limited the competitiveness of the project...

Kresten Krab Thorup presented Riak Mobile at Erlang Factory (London) .   The consistency model used by Riak is intended to continue operating well even while nodes in your Riak cluster are down or unreachable, a property which also makes it a excellent model for mobile data. [...] Typical usages for Riak Mobile is as a mobile content distribution platform using one-way sync; or with two-way sync to also push updated data back to your Riak cluster when the network is "eventually" available.  ... The client-part of Riak Mobile does not need an Erlang VM.  Rather, it comes as either a Java or an Objective-C component using SQLite for on-device storage, and thus integrates well into the native development environments... Sounds like Riak might actually actually do what CouchDB promised...

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...

This is supposed to be a theoretical comparison of three NoSQL DBs, w/ MarkLogic the hands-down winner.  I'm not so sure about it - there was nothing in the use-case (AFAICT) that couldn't have been handled by either CouchDB or MongoDB, and quite trivially at that. Perhaps it had more to do with learning curves? I suspect if I'd done the same, we'd have ended up with CouchDB as the hands down winner... The only real lesson I drew from the posting was that the days of SQL vs NoSQL are pretty much gone, now its more a case of "Which Is The Best Tool"...