This is mostly an "it depends" sort of issue. Most people/sites don't really need a big SQL engine to store their data but follow the path of least-resistance

This is mostly an "it depends" sort of issue. Most people/sites don't really need a big SQL engine to store their data but follow the path of least-resistance in that general direction. CouchDB is a part of a growing movement away from general-purpose RDBMs towards task-specific data engines and from the world where ACID was all that mattered to one where the BASE model can provide an alternative set of benefits. What CouchDB gives you are 1) schema-less data storage (so you can change your data schema on the fly), 2) built-in map-reduce that lets you perform some queries faster (at the cost of needing to re-think how you perform certain SQL JOIN queries), 3) an easy path towards data distribution, and 4) a database that is accessed via HTTP using REST principles. Running your queries in a couple of Javascript functions (or python functions, or ruby functions, or any other language that has a view server) is not necessarily faster than SQL and in fact is probably slower. What makes it faster and more scalable is the built-in map/reduce primitives that these functions are using. Since the db is accessed via HTTP, the data format is JSON, and you can create queries using Javascript this system also introduces the intriguing possibility that you can cut the app server out of the picture and write web apps that interact directly with the data. Different strokes and all that.