couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <>
Subject Re: Two Concerns
Date Thu, 31 Dec 2009 02:55:37 GMT
Chris, is the CouchDB "vision" and focus going to be more on the
localhost/CouchApp type of solution, or more on a robust, scalable
distributed document database?  My sense is the former, even though I think
CouchDB has a lot of advantages in the latter.

In particular, CouchDB is easy to understand, easy to set up, easy to use,
is free, and has strong community support.  None of the other distributed
solutions have all those advantages, be it sharded MySQL, Hadoop, Neo4j or

Is there room for CouchDB to go in both directions, or should those of us
looking for a good distributed DB solution be looking elsewhere?



On Wed, Dec 30, 2009 at 5:07 PM, Chris Anderson <> wrote:

> On Wed, Dec 30, 2009 at 3:51 PM, Sean Clark Hess <>
> wrote:
> > Thanks Tim.
> >
> > One more thing I thought of. I don't remember having this impression
> before,
> > but as I read the Oreilly Book, it seems that the idea of running Couch
> on
> > devices and local computers is a major feature. There are many features
> > designed to make CouchDB able to function without middleware.
> >
> > My question is: why? That's what middleware is for...
> The answer is not that Couch is trying to do everything. Really, we
> have one thing we do extremely well, and that is robust JSON storage
> with p2p replication, accessed over HTTP.
> Because we do that already, the ability to serve apps directly from
> the Couch to the browser is low-hanging-fruit. It is also the best way
> to take advantage of replication. Other NoSQL stores may be able to
> rival our capabilities as a scalable database, but no database running
> in a remote datacenter will be as fast for users as a Couch running on
> localhost.
> Middleware is fine even for apps that run at the edge, but if your app
> requires middleware, that is yet another thing that will need to be
> installed on the users's machine. CouchDB's eventual goal is to part
> of the standard desktop stack -- just another feature of web browsers.
> It is this vision that led to the code that supports HTML rendering.
> Ajax apps are nearly good enough for most cases, but fall down badly
> when accessibility and searchability come into play. Also,
> link-following is an essential part of the REST architecture, and it
> is absent from a JSON-only interface.
> There are apps which can be written against the local Couch and
> browser stack, that can't be written any other way.
> If you aren't trying to write one of those, the CouchApp feature set
> is still useful. See for instance the people using _list to filter
> view responses according to user authentication information, or
> _update to provide update-in-place like semantics.
> I hope this helps to answer your question.
> Chris
> --
> Chris Anderson

David W. Van Couvering

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message