I have to say, though, while you were busy inching towards 1.0 I've fallen in love with other production-ready NoSQL db's (namely Mongo and Cassandra). I'm excited to play with Couch, just to play with it, but as someone who is already very satisfied with other NoSQL technologies (when I need them), what would be your pitch for why I should give Couch a serious look?
I've got truly offline replication (as in you can run me on Android and your laptop and keep them synced via the cloud).
Also, none of the other NoSQLs are really set up for schemaless queries like I am. Incremental map-reduce lets you normalize a bunch of different heterogenous document structures in your view, which is more flexible than the key-path indexes Mongo has, and more real-time than Hadoop/Google style map reduce.
I hope someone creates mongodb account and responds to your comment. Nothing better to follow than hot, fierce war between databases. Keep'em coming! May the best prevail!
I think we have different definitions of "production-ready." I find Cassandra to considerably immature having weird bugs that cause it to outright crash and both Cassandra and Mongo have seen issues from many people with data loss. Yes, people are using these systems in production but they're both still young and immature and it is in everyone's best interest to continue to evaluate possible solutions that are coming out.
I've been in production without issue for years in some installations. I probably could have raised the "production-ready" flag in 2008/2009 if I held myself to the same standards as a lot of projects.
In both my last job (latexsearch.com) and my current job (smarkets.com) I've worked with couchdb in fairly large scale installations. I haven't experienced a single bug nor had any couchdb-related performance problems. It's pretty solid.
couch hits a number of sweet spots. Documents can have attachments so you can build a complete application out of html,css, and javascript and have the entire app reside in a couch database. Coupled with P2P replication this make for some interesting possibilities.
couch also inherits a lot from it's choice of implementation language, Erlang, and it's append-only storage design. A high level functional language such as Erlang makes for a small manageable code base. So if you want to extend or enhance it there's not as much to get your arms around as you would have in C++.
On the other if you're a web programmer or could just otherwise care less about db internals, the JSON based RESTful API is all you need and there's a client already out there for just about every language I can think of except maybe Rebol.
I've been poking at it for a couple of years now and one thing I have to say is that it is really truly rock solid. Moreover it has an active and supportive community and at least two companies building businesses around it, Cloudant and couch.io, both of which boast committers to the project.
I have to say, though, while you were busy inching towards 1.0 I've fallen in love with other production-ready NoSQL db's (namely Mongo and Cassandra). I'm excited to play with Couch, just to play with it, but as someone who is already very satisfied with other NoSQL technologies (when I need them), what would be your pitch for why I should give Couch a serious look?