blog post by Linkfluence's Franck Cuny explains the reasons and sheds some light on the advantages and disadvantages of different non-relational databases.Social analytics company Linkfluence began migrating from CouchDB to Riak recently. A
Linkfluence used CouchDB primarily to store Web content and metadata. It uses other databases such as PostgresSQL, MongoDB and Redis for other purposes.
So why the switch?
- CouchDB stores every revision as a new document, and keeps the entire history of revisions. Linkfluence didn't need this sort of versioning, and the revisions were starting to bloat its database. (However, a Hacker News commenter notes that this can be changed with the '_revs_limit' setting.)
- CouchDB stores the entire database as one file. As Linkfluence's database grew larger than one terrabyte, this became problematic.
- Cuny writes that he had problems with CouchDB crashing randomly, but notes that the last version of the database was "quite stable."
Cuny writes that Linkfluence had the following requirements for a replacement:
- easy to replicate
- no master/slave
- a REST interface
Although the company had to write its own Perl client, Cuny and company were generally impressed with Riak and its sponsor company Basho. For more information on Basho, check out our previous coverage.
Does this mean CouchDB is a bad product? No. It just wasn't the right tool for this job.
Last year, the CouchDB team has focused on solving one problem in particular: offline access to data. The new Couchbase project may go in a different direction, but the classic CouchDB continues to focus on offline access. Meanwhile, BigCouch from Cloudant aims to address some of the scalability issues that Linkfluence faced.
We expect to see a lot more cases like this as developers feel out the strengths of various new technologies.