Yes, CouchDB is an Apache project and Couchbase Single Server is a Couch One product. Except that they are almost exactly the same. Couchbase Single Server is already pre-built into easily installable rpms, it has GeoCouch integrated, but not a whole lot more compared to CouchDB trunk (Am I wrong?).
So as a developer you want to play around with Couch. Which one do you pick? ... Exactly. Aside from terminology there is basically a fork at the moment and I understand that CouchOne Server eventually will combine membase + CouchDB in it, and it is a great step forward but currently it makes it a bit harder. It is also not exactly easy to find a comparison of exactly which features are in which. So it is sort of a guess work.
However, a document update in CouchDB is fully ACID (including the A of Atomicity). People often confuse transactions around multiple changes with ACID for reasons that I cannot fathom. CouchDB does not have support the former (they don't scale well in clusters) but absolutely supports the latter.
I don't consider redis durable for similar reasons as mongo - yet redis doesn't hide what it is or what it lacks in terms of durability... so it doesn't bother me that it isn't.
but mongo often downplays it's lack of durability, which makes me wary of using it or recommending it because people don't know how to use it.
This is exactly the problem with MongoDB. It's practical use is a semi-durable, in-memory data store, but they advertise it as a data store of record that can be used for large, >RAM sets of any conceivable use case.
It seemed a bit dishonest seeing benchmarks that showed how MongoDB beats CouchDB in write-performance tests when there was no acknowledgement of write requests comming back to the client.
Not saying that MongoDB wouldn't be faster with full commits turn on, it is just that their design decision to pick that as the default and calling their product a 'database' seemed very strange at best, and dishonest at worst.
For the record: we (MongoDB) have a policy of not posting official Benchmarks. Could you clarify what benchmarks you are referring to that were posted and "dishonest"?
The only benchmarks we have ever done have been for internal testing comparisons between different versions.
Previously there were several third party benchmarks on this page, which we recently took down to stand firmer on our benchmark policy. In the interest of full disclosure however, you may examine the page history to verify that we have always clarified these as unaffiliated third party sourced.
Describing Bigcouch as a bit of hack while admitting you've not used it seems a little unfair. That said, it's very valuable to hear how other people see our product.
Without doing a full-on sales pitch (I am not a salesman and do not portray one on TV), I should say that Bigcouch adds a lot of desired features to CouchDB, notably scaling beyond a single machine and sharding (which supports very large databases). We run several clusters of Bigcouch nodes in production and have done for some time, it's a thrill for me personally to see a distributed database take a real pounding and keep on trucking.
I've been meaning to try Riak myself, so you've inspired me to finally pull down the code and give it a proper examination.
What kind of data do you record (number of documents, average size of document) ? We have to use couchdb at my current job, and I have encoutered all those issues for even moderate size (replication failing more often than @ ~30-40 Gb). I wonder if that's an environment issue.
There are several reasons for CouchDB's use of a single, strictly append-only file, but the b-tree is not one of them.
In fact, it's one of CouchDB's most clever tricks to store a b-tree in an append-only fashion (it's far more common to update in place).
Two reasons CouchDB is strictly append only.
1) Safety: By never overwriting data, it avoids a whole class of data corruption issues that plague update-in-place schemes.
2) Performance: Writing at the end of the file allocates new blocks, leading to lower fragmentation and less seeking than an update-in-place scheme.
"durability" does not mean "the file is...never left in an odd state". The right word there is "consistent". CouchDB provides both (In fact it provides all four ACID properties, but the scope of a transaction is constrained to a single document update).
Finally, I should point out that using a single file, as opposed to a series of append-only files (like Berkeley JE, for example) is just a pragmatic choice. Nothing in principle would prevent a JE style approach, it's just a lot of (quite hard) work to do well.
