Why I think CouchDB is Awesome

Recently I have gotten a little practice at thinking about how awesome CouchDB is. I gave a presentation entirely shot from the hip on this unique technology and the topic its advantages came up recently on the project's main mailing list. I figured trying to summarize some of this would make a good blog post. So... here is the list of my stand outs:

Easy horizontal scale path:

It's HTTP. Guess what there are already a lot of and well understood? HTTP load balancers and caching systems. It has master-master replication built in. Your database logic is in a design document, which is just another document that can be replicated across nodes.

Vertical scaling:

With support for Android and iOS you can now take the same database and use the built in replication to take it up and down from mobile, desktop, and server. Awesome.

HTTP JSON:

Anything can talk to it. You don't have to have a middleware piece to talk to it for many web application scenarios. This can greatly simplify things.

Changes API:

You can have a lot (I mean a lot) of systems monitoring for changes and apply filters to get just what you want. 

Concurrent at it's core:

Thanks to Erlang and the ideas of MVCC you can have many connections to the database with no worries. I think I have read that some test cases found that you would run out of IO bandwidth and ports before CouchDB would stop responding. It might be slow (probably have time outs), but it's up and talking. Write speed is limited since it's serialized on a node, but in either case you could load balance that.

Now this wouldn't be completely fair I suppose if I didn't list some of the pain points:

Documentation is a bit spread out.

You really have to read the book and mix in the wiki and blogs.

Auth/Auth system is pretty primitive:

Sounds like there is some ideas around to improve this and it'll probably get you through most cases. If it doesn't get the job done of course you could just add a middle layer to manage these things. Using other database technologies you would probably have a middle layer anyway that managed auth/auth, so probably not that much of a pain point.

Learning Curve:

You pretty much have to study CouchDB for a little while before you grok it. There aren't a lot of features to make you feel at home when coming from a traditional database technology. Biggest one obviously is that any real querying is done via predefined map/reduce views. These are computed incrementally and have no side effects. It's hard to get a decent mental model of using documents and map/reduce.

There are probably more for both the pro and the con list but that sums up what I tried to hit recently.

CouchDB in the middle?

I have been discussing JavaScript applications with my friend Bryan and naturally we ended up agreeing that Node.js is a technology that simply can't be ignored. I think we are both going to end up playing around with it and deciding where it fits in with how we want to write web applications.


Node.js (Express.js is a simple web framework for it) seems like a nice replacement for say... Python or Java for your middle layer. So:

That would mean you still need some random implementation of a b-tree in a file so your application can remember things. JavaScript on the front end, JavaScript in the middle, why not JavaScript in the backend. This seems perfectly reasonable:

Ah CouchDB, the JavaScript friendly database. TO THE GOOGLE!


I came across this quite nice presentation from Js Conf discussing node.js and couchdb. It has a title you can't refuse: node.js + couchdb = Crazy Delicious. A formula only rivaled by Red Vines and Mr. Pibb. Anyway, this video hit me with this little number:

That's right node.js as your backend and your database as your middle. *starts twitching* Now it seems couchdb is sort of designed for this scenario with a create concurrent connection story, the ability to render html templates, and some kind of built in user security/session model. Also couchdb only speaks HTTP through a REST api. Quite the nice fit for interfacing with web clients it seems, but there are some bumps in this road. Couchdb is a bit of a sandbox.


It seems this model works by node.js listening on the _changes api from couchdb so that it can perform things that require sending e-mails, integrating with external services, manipulating multiple documents; things like that. How intriquing and unconventional.


This _changes api seems to allow for polling for updates since a previous one, long polling to get an single update when it happens, or a continuous streaming of updates as they happen. You can also implement filters for these so you get what you want. Pretty sexy sounding actually.

Node.js as a backend must mean a couple of things (I think). First thing that comes to mind is you could design a system that triggers events off of it's logging. So you log that the user wants to send an e-mail, then node.js picks that up, sends it, updates the document as sent. I'm not sure if that is a good design. It's interesting to think you log what you want to do, then it happens. The client just does a poll for that update and notifies the user it's complete.

Second thing that comes to mind is that you have to design your system around being asynchronous. The client code would write/update the documents, node.js would pick it up, perform the action, update the database. To my knowledge you couldn't do that synchronously. This is probably an advantage that you are forced into this. 

Anyone think of some strange scenarios to show disadvantages of this scenario? In the "enterprise" world we seem to be moving towards message passing and message queuing... basically an asynchronous world.

The simple idea of CouchDB with a Node.js backend hit me pretty good. I want to explore this idea some more and hope to write a little project. Maybe a custom single social posting app thing. Post it once in my database then node.js picks it up and posts it to my Facebook, Twitter, maybe something else. Then have node.js pick up replies/comments and post them back into the database for a single social global view.