C'mon, you guys can do better than that. Just working is enough to show up Mongo. Seriously, the bar isn't that high.
TLDR: for highly concurrent workloads on a nine node cluster, Couchbase Server handles way more traffic than MongoDB without response times slowing down.
Full disclosure -- We've been locking horns with them for a while now, so of course this feels good.
It kind of puts me off of both of them.
I don't have time to address all of the problems, but let's look at #1 on his list:
1. MongoDB issues writes in unsafe ways by default in order to
This is objectively false. At the time, Mongo chose to turn off write confirmations by default -- this was clearly documented in many places including introductory documentation. Surely no one would have deployed a database without even a cursory skim of the docs, right? The notion that it was done to win benchmarks is baseless. Furthermore, in response to the community's reaction, the default was changed.
This is a recurring problem with the complaints about Mongo. You cannot use ad copy to evaluate a database (or any product for that matter, but definitely not something as important as your primary data store). You must read the documentation. You must do a trial run and make sure it will meet the needs of your use case.
You can't be upset about the results you didn't get from the work you didn't do.
MongoDB probably got a bit ahead of itself too fast - it wasn't mature and took a lot of development shortcuts to get features out fast and people started using it like a mature datastore too fast - and the company behind it didn't help either. But, without a doubt there have been vast improvements across the board and I give them credit for spending the last year and a half not adding many new features but rebuilding the codebase, making it extendable (pluggable storage engines is a cool thing) and addressing numerous issues.
It still has some issues (b-trees aren't the best implementation imo) but the codebase is in a state where I expect over the next few years it will be quite reliable. The tooling around MongoDB has gotten better too. There's still a ton of ways to shoot yourself in the foot too but the defaults are more sensible I think now than then.
What they got right is the clients are awesome and the query language is powerful - especially updates. This matters for a lot of people - it isn't just a drag race always in terms of performance. Now, with increased reliability it's becoming something usable for some use cases.
The complaint isn't about sub-document updates vs. full document updates. The complaint is about conflict checking. Couchbase could have been told to blindly write, but wasn't, and Mongo was told to blindly write.
But does anyone use Apache CouchDB? I still do see it as one of the more unique NoSQL systems. I specifically loved the idea of CouchApps, and using it a neat version-controlled JS web app hosting system and document repository. I have obviously lost track over the years.
Does anyone use CouchDB seriously? Can they mention if the same raggging about giant irrecoverable disk consumption and other gripes still apply? Did anyone consider CouchDB and stick with Couchbase and can explain why?
Our iOS Android Windows and Golang database implementations are all open source. http://developer.couchbase.com/mobile/
Are people directly exposing Couchbase/CouchDB at the frontend? A lot of people poo-pooed that idea (NEVER EXPOSE DB TO THE INTARWEBS!), which was the neatest idea, no matter how dangerous, when I first heard of it a few years ago. Are people doing this?
Thanks for your mobile SDKs. I wanted to learn Erlang for CouchDB, and I saw your mobile clients and thought that, and PouchDB, would make for a mean confluence of rapid desktop web and mobile app development.
It's been a long haul. In my role as an Apache volunteer I added the CouchApp capabilities into CouchDB (thanks Damien and folks for tolerating me!). After that we started a company that eventually merged with another NoSQL company to become Couchbase.
Our technology is inspired by Apache CouchDB (and in some cases compatible with it) but it is all green stack and open source.
Couchbase Server is for when you have a ton of traffic (or spiky traffic) that you can't afford to slow down. We power mission critical apps for use cases like airline booking, market making, social gaming, e-commerce, and CMS. http://www.couchbase.com/case-studies
Couchbase Mobile is a parallel effort creating peer-to-peer capable native mobile (and other edge compute) device embedded database with network aware background sync including conflict management. IBM Cloudant also uses our model and interops with our client libraries (but our Sync Gateway has an application API I think is more fun).
It's been out for a year, plenty of early adopters. Bigger names are getting interested. Ryanair just shipped an app using us, which is fun for me to see: https://twitter.com/zgramana/status/581196081637122048
By the way, on the source, it was never intended "dumping" style but just a bunch of stuff that had been slowly wired together. Yeah, we use repo and gerrit quite a bit. Check out review.couchbase.org sometime.
http://damienkatz.net/2012/01/the_future_of_couchdb.html (An announcement from one of the CouchDB -> Couchbase developers)
EDIT: I think I confused blog posts. That is a guy involved in Couchbase, no? I forget who but one of the other CouchDB only devs who worked with him was pissed and wrote a rantish piece. Too tired to find it now.
When you try to sync stuff (indexes + disk-commit) the performance will take a hit.
I would be interested in seeing the actual results and summary of it.