Why I Switched to CouchDB for Web Applications

Top Reasons to Take A Closer Look at CouchDB for Your Next Project

I had been looking at MySQL alternatives for some time, and have been watching the “No SQL” movement grow.  About a month ago I finally decided to take the plunge and selected CouchDB as the default storage mechanism for my applications moving forward.

I was originally drawn to CouchDB because of its use of JSON directly and its amazing replication.  As I started migrating my code I quickly discovered what web-dev life was like without SQL.   And I liked it.

What I Realized About SQL

Here are some issues I have with SQL, a lot of which I never really thought about because I had always used it for web applications:

• I was spending a lot of time managing the DB schema.  This includes setting data types and sizes, table structures, constraints, and so forth.  Adding and removing new fields and indexes to match my code.  Journaling any changes during development so when I pushed the code live I made them on the live db as well.
• I was normalizing all pieces of data as if it was scientific in nature, sometimes comically so.  This is because all content must be type casted into specific definitions and limitations.  VARCHAR(30) needs to become VARCHAR(255) or TEXT, etc.  Doing this incorrectly can yield headaches and performance issues.
• I realized how tedious the act of cramming multidimensional data (ie; real life) into SQL’s two dimensional “row vs. col” system was.  Not only was it tedious, it was also time consuming due to the need for linking tables, JOIN statements and so forth.

What I Like About CouchDB

• Once you get the knack of it, web development is simplified.  To add a field to an existing document or create a new document type entirely, I just start saving it that way.
• CouchDB trades off consistency in return for vastly superior availability and partition tolerance.  The CouchDB Guide has a great diagram showing how this compares to SQL/RDBMS.
• I do not have to perform any data normalization unless I want to in my code.  There I can do it in a consistent, automatic and modular way that is user friendly.  Nothing is less user friendly than a SQL error.
• Why constrain the data in 3 places: the browser (JavaScript), the app server (PHP), and the DB (DB constraints and stored procedures)?  Using JSON and AJAX I can do it all on the app server, with the best possible user experience.
• CouchDB documents are stored and managed as JSON documents.  Being able to load and store nested arrays directly is awesome.  This is doubly true since I use JSON between the server and browser.  This uniformity greatly simplifies all aspects of development.
• Performance is great.  CouchDB trades slower writing for fast reading which is ideal for a huge range of applications: from web CMS to data warehousing.
• Not only is CouchDB ACID compliant, but it uses a ‘crash-only’ design where the data on disk is always consistent.  You can read more about this on the CouchDB overview page.  If you’ve ever had to recover a SQL DB after a server crash you know how time consuming and hair raising that can be.  This avoids it entirely.
• CouchDB is designed from the ground up to do multi-master replication.  It will become consistent even if peers are disconnected for long periods of time and working independently.  For simplier apps no extra work is needed to scale it across multiple servers.
• You can set up PHP to use CouchDB as the storage medium for session information, allowing you to cluster PHP app servers even over long distances and fail users over seamlessly.
• It’s licensed under the Apache 2.0 License and is not owned by a corporation.  It places minimal burden on me as a developer to use and distribute with my software.

Retooling to use CouchDB instead of SQL was not a quick process, but the rewards of easier development and greatly improved scalability and reliability made it hugely worth it.  I highly recommend checking it out!