

Why I don't use CouchDB. - jrockway
http://blog.woobling.org/2009/05/why-i-dont-use-couchdb.html

======
tumult
The more of these "software hipsters" that fail to understand CouchDB and
quickly abandon it, the better. Wish I had more to say about this article, but
that's about it.

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.

~~~
jrockway
"software hipster" is an inaccurate characterization. Hipsters tend to choose
something because it is simple and stylish rather than actually useful. As an
example, they like fixed gear bikes.

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.

~~~
silentbicycle
Using a fixed gear bike in Seattle would be asinine, agreed. Within a
relatively flat city, they make a lot of sense, however, and they're
practically _ideal_ for running short (< 3 mi, say) errands. They're
mechanically simple and require practically no maintenance.

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.

------
brendano
Discussions about CouchDB focus on its very large and complicated featureset.
It would be interesting to see examples of actual problems it's good for and
why or how it worked for them. I've seen one example where it wasn't very good
and the developer switched to an SQL database, but nothing beyond that. Their
website doesn't have anything like this, sadly.

~~~
jrockway
_the developer switched to an SQL database_

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

------
cturner

        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.
    

I've come to this idea also - when we do get it the world changes. New era for
hackers. We will be able to operate against a couchdb cloud from a console-in-
a-browser with the power of (and as a full alternative to) a unix system, and
to think in terms of that cloud rather than in terms of services. The barrier
between code and data will be much more blurred in practical terms because the
cloud will host the services.

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...](http://jchrisa.net/drl/_design/sofa/_show/post/standalone_applications_with_co)):

    
    
        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.
    

I wish couch was based on IO rather than javascript, because with IO you can
reverse algorithms out of running code. Hence processes could act as
datasources if the VM was like IO. See
<http://hackety.org/2008/01/05/ioHasAVeryCleanMirror.html>

------
maukdaddy
"If the mechanisms to restrict access were in place the CouchDB backend could
be exposed to the browser directly, removing the server side application code
as a bottleneck."

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.

~~~
nothingmuch
If the business logic is implemented in couchdb or implemented in serverside
code, it's still business logic protecting 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.

------
crc
The biggest advantage of CouchDB - compared with its competition - seems to be
the ability to create views to query the schema less dataset. If I have to do
this in mysql, then I will have to create and maintain seperate columns with
indices; making sure that updates to the data gets propagated to these columns
etc. Do any of the CouchDB alternatives provide a cleaner solution?

~~~
moe
MongoDB shows promise.

------
sho
A bit early to write off the project, isn't it? The CouchDB devs have
repeatedly stated that they're concentrating on getting it working right
before making it fast. It's still in alpha, for crying out loud.

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 ...

~~~
nothingmuch
"... but it does show plenty of promise."

"Personally I would much rather see feature completeness first"

~~~
sho
_"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

~~~
sho
Not sure if anyone will see this, but Matt Aimonetti (yes, _that_ Matt
Aimonetti) just posted to the CouchRest (a ruby library) ML reporting that
with the availability of recent RPC-JSON ruby/erlang direct access libraries,
an estimated 5x speedup was possible over the straight HTTP.

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.

