There are many positive aspects of Couch's MapReduce implementation. Sure, you can use Hadoop or what not for increased flexibility, but Couch gives you a baked-in storage system, universal HTTP interface, incremental views (big feature!), replication (another biggie) and a structure for it all to sit in, with a nice interface to boot. Sure, you could set that all up separately, but isn't there a lot of value having it all just there and working? And check out the MLs - chained reduce is a constant point of discussion; it's definitely on the roadmap.

The lack of strong authentication is also a puzzling point - how many people implement complex auth at the DB level in a web app?

He does have some good points - the overhead of setting up and pulling down a socket for each connection cannot be denied, but that seems solvable with persistent connections. Furthermore, Couch's stateless API and eTag integration offer powerful caching options.

One point that did strike home for me was about the lack of development direction - this does seem to be a problem. For example, the effort to make applications run directly from CouchDB seems speculative and pretty useless. If you're going to install erlang and CouchDb you may as well install an app server as well. But the BTree rewrite priortisation? There were good reasons for that: it was going to break backwards compatibility, so essential to do it ASAP.

All in all, decent points, but way premature. How about we at least get to beta first?

Then again, if this article rams home the huge importance of speed to the devs, maybe I shouldn't be arguing ...

"Personally I would much rather see feature completeness first"

As I said in my comment, the BTree rewrite was a breaking change. It required all users to dump and reload their DBs. (1)

You do agree that things like that are best done ASAP, right?

I want to see feature completeness too but with more people adopting the project every day, and beginning to use it in semi-serious situations, pushing file format changes through quickly is just good release practise.

(1) if it's the one I'm thinking of. The other you could be referring to just needed a view rebuild; still annoying but nothing like the file format change

5x speedup by integrating with erlang direct, and the HTTP is still there if you need it. So there goes much of the premise of the blog post. Needless to say, the DB itself has still not been optimised for speed - not even close - so this is far from the last word on the project's ultimate speed potential.

This is why you don't read too much into the current performance characteristics of alpha software.

edit: in case it's not clear, I like couchdb a lot and I think it's absurd that people people are backlashing against it because some monkey coder dorks found it highly buzzword compliant and are making it popular, despite not understanding it at all. So you end up with people hating something because it's getting some limelight for whatever reason, and then also many of the people championing it don't know how to use it correctly to build an app or anything. It's like two layers of stupid.

CouchDB solves a subset of information problems. The relational model can solve a vastly greater amount of problems.

Unfortunately, simple and stylish doesn't always win. I see lots of people riding fixed gear bikes in Seattle, for example. Actually, I don't see many people riding them, I see them walking them around because they have the wrong gearing for going up and down Seattle's many hills, and they can't actually ride them. In this case, simple and stylish is the wrong tool for the job -- they need a bike that can change gears. That may be inelegant, but it works really well.

CouchDB is the fixed gear bicycle of the database world.

To push the analogy further, some of the buzz around couchDB reminds me of people obsessed with scaling (racing) without either any real understanding of algorithms (being in shape) or any chance of actually needing it (actually competing). That starts to sound more like a road cyclist with an expensive garage ornament, though... Fixed gear bikes are perhaps more like SQLite than couchDB, in that sense. They're actually really useful on a smaller scale.

I see where you're coming from on the hipster bit, just nitpicking.

His point was that for -his- purposes CouchDB is not a convincing option for the backend object store to KiokuDB, with detailed explanations as to why.

I don't really understand why "this tool doesn't work for me and here's why" makes you a bad person - if he was saying why RDBMSes didn't work for his problem space and thus why he was using an OODB at all, I'm sure the comments would be very different.

You do know that the author of this article wrote an object database, KiokuDB, right?

    Unfortunately you can only create a view from the
    original data, there is no way to create views whose
    input is other views. This means that you cannot do
    anything really interesting with values from multiple
    documents. You can aggregate data from several documents
    using the reduce functionality into buckets, but you
    can't process that data further.

Another idea that couchdb already does that is a necessary pre-requisite to this outcome (from http://jchrisa.net/drl/_design/sofa/_show/post/standalone_ap...):

    Over the last few days I've polished up my
    notion that CouchDB can be a perfectly viable
    application host, all on its own, without any
    3rd tier between database and client. That
    is, CouchDB is capable of serving standalone
    applications. These standalone CouchDB
    applications can be deployed to any working
    CouchDB node and used from any browser.

Never, EVER expose a database to a client! Doesn't matter what types of controls you think you have, you must ALWAYS have some business logic in place to protect the data.

It could be just as flawed, or even worse (e.g. sql injection allows malicious users to run database operations with no restrictions at all. If there were db level restrictions they could only destroy their own data).

This ALWAYS NEVER EVER type of mentality demonstrates exactly why CouchDB is simultaneously overhyped and condemned.