From the article: "CouchDB + Another Layer as Web Server is Redundant". This is very true, and the biggest difference to other databases I've used, NoSQL or not. It ends up being a double-edged sword for CouchDB.

On the one hand, it saves having to context switch between thinking about the database, thinking about the web server, thinking about the web framework, etc.. For a single developer, this is not to be sniffed at. As learning is often done by lone experimentation, it makes CouchDB an excellent system for learning about NoSQL. It's also great for prototyping, where you don't necessarily want to spend a huge amount of time creating an industrial strength back-end.

On the flip-side, it means that if you do run into a situation where you want to use another layer, you've just given up the biggest advantage of CouchDB. For my current project, I found I would need to be able to integrate authentication with an existing Kerberos system - the easiest way to do this was to use Apache.

I also had slight reservations about CouchDB's approach of limiting what you can do - everything has to be a map-reduce - to ensure scalability. The plan as I understand it is to introduce further safe operations down the road. I'm sure that approach will yield dividends, but for now it seems quite limiting - similar to eschewing C in the 70s because it does not have garbage collection.

Didn't mean to beat up on CouchDB too much - it's a fine system, but I prefer the flexibility of MongoDB at this point.

CouchDB is not as limiting as you suggest but it is a total paradigm shift. There is more to CouchDB than map-reduce.

In my view, CouchDB is more at home as a middleware layer than a database layer.

Take your current project as an example. Why not have Apache reverse proxy to CouchDB? You'd give up zero CouchDB functionality and would gain Kerberos authentication.

Putting another web server in front of CouchDB is unnecessary, but putting web proxy servers in front of it is totally useful. In other words, adding HTTP layers on top of CouchDB means you don't have to trade-off anything.

CouchDB lives and breathes HTTP. If you choose to keep your database from talking with the outside world directly, then CouchDB is a poor choice and you're right to go with MongoDB.

Don't let the name fool you, people. CouchDB isn't simply a place to stuff and retrieve JSON data.

You also give up replication, not only of the data, but of the entire web application. CouchDb's replication shouldn't be overlooked not as a technology, but in its various applications of a decentralized system.

This guy Till is awesome, real world examples/strategy to scale with CouchDB

http://till.klampaeckel.de/blog/archives/95-Operating-CouchD...

http://till.klampaeckel.de/blog/archives/84-A-toolchain-for-...

here's his github: http://github.com/till

I have used couchdb in large systems and small systems. CouchDB is at the end of the day a DB use it as a DB don't embedded your webapp in it.

I'd say you can do either, depending on your requirements. Some of the biggest CouchDB users use it as a scalable back-end. But some of the most exciting uses are deploying personal web-apps to the desktop.

I always am annoyed when I read that CouchDB can "scale up and down". CouchDB has NO internal concept of sharding. The only thing it can do is repliaction. Riak and Cassandra can actually scale up and down, CouchDB can scale up and down as much as MySQL can... (or did I miss something?)

There is a recently open-sourced fork of CouchDB that does the sharding thing. With this addition to the capabilities, CouchDB really can scale up to hundred machine clusters.

http://blog.cloudant.com/cloudant-core-is-open-source

update just found a great article on scaling with CouchDB using Lounge http://nosql.mypopescu.com/post/683838234/scaling-couchdb

and a company that provides the service Cloudant: https://cloudant.com/

Here's another shard manager project, Pillow: http://knuthellan.com/2010/07/14/feature-prioritization-for-...

I think the design philosophy for couch is keeping smaller pieces of Big Data synchronized. The sum of all those small pieces is like one larger database.

You just made my day when you quoted my stackoverflow answer. Thanks, man.

You're great answer helped me better understand the app/DB relationship, and added value to the post. I should be thanking you, in fact I will. Thanks shotgun!

Scattered notes and links, trying to soak up as much of the design philosophy as possible. I'll pick up with examples once I'm not such a scrub.

Is the idea supposed to be that a web client (html+js) reads and writes directly to a CouchDB server? Where do you put business logic?

All business logic is in the database itself. It has ACL's and data validation built into one feature (update validation) and as for deciding which data to display and when, the map/reduce-based view API is extremely powerful.

Force yourself to use CouchDB for a project where you're handling large amounts of data and you'll discover how incredible it really is. There's tons of other great features you'l pick up along the way too.

It certainly doesn't fit every application, but it's possible to write a write-controlled app using validation functions[1].

I've written an introduction to using Evently and CouchApp if you're interested in seeing how that works[2].

[1] http://guide.couchdb.org/draft/validation.html

[2] http://mindeavor.com/blog/the-anatomy-of-a-couchapp

Well, in a normal web app you put it where you normally do; it gets shoved in various .rb or .py or whatever and you just call the database as usual.

for an app written in coudb:

http://guide.couchdb.org/editions/1/en/managing.html is a breakdown of the source tree and explains things.

Please note the distinction between high availability writes and lock-free writes. CouchDB offers the former.

As I understand you can always write to a node. Where's the lock?