A week with CouchDB

I’ve been watching the NoSQL movement closely over the last year and after the 1.0 release of CouchDB I decided to take a closer look at this distribution.

CouchDB

I’ve been watching the NoSQL movement closely over the last year and after the 1.0 release of CouchDB last week I decided to take a closer look at this particular distribution.

MySQL has always been my favorite RDBMS, especially after a few Microsoft SQL Server adventures. But over the years I’ve been using less and less constraints ( like unique ) on database fields. Mostly because nowadays we all want prettier error messages when we try to perform a data insert instead of a nasty SQL error and ofcourse this is easily achieved by checking the input through some AJAX/PHP. So in some cases I don’t need a database that offers joins and constraints anymore. I, and my fellow developers ( and our clients ), crave speed and scalability for our applications. Modern databases like CouchDB, MongoDB and Cassandra all offer this with each their own specialties but also their own handicaps. But for this article I’d like to compare CouchDB to MySQL.

Pros

  • CouchDB is somewhat faster on read, at least until it reaches about 1000 queries.
  • You can easily change the schema of your data.
  • CouchDB is highly scalable because of it’s “shared nothing” clustering. This allows for individual server failures with zero downtime in larger environements.
  • You can easily retrieve and manipulate data with client-side languages like jQuery, however this should be handled with care!

Cons

  • CouchDB performs a much slower write, especially when the PUTting a lot of data for one document.
  • You can’t really perform complex dynamic queries, which results in having to perform joins and sorting logic yourself.
  • We have 30 years of knowledge about relational databases, NoSQL solutions like CouchDB aren’t that mature yet and could be risky to adopt.

Conclusion
If you’re planning on running a simple web application or website across multiple servers CouchDB might be the way to go. However if you need to do a lot of sorting or use complex queries, a relational database is still likely to be the right choice for the majority of cases. In one case or the other using a caching method will still speed up your application quite a bit and is highly recommended if you want to provide your users with the swiftest user experience.

Author: Luc De Brouwer

Mild-mannered software engineer, Nine Inch Nails lover, gin drinker, cat person, and somewhat of a geek. Ron Swanson is my spirit animal.

5 thoughts on “A week with CouchDB”

  1. Hey, thanks for the nice review 🙂 — The Cons are all well taken, I’d like to comment on write speed though, if you ramp up concurrency on writes, you’ll see that CouchDB can max out your server’s IO bandwidth (which is a different metric than query latency, but still a good metric 🙂

    Cheers
    Jan

  2. For mysql… I have been adding more and more constraints to stop people from manipulating the data directly in the database… it makes for a nicer time for all.

    1. I used to do that too. But I want people to use the app/website itself, not to let them manipulate the data in the database, I like to control their actions. To me, there’s nothing more stressful than database inconsistency in an app or website.

Comments are closed.