Comment by gecko | Hacker News Reader

Comment by gecko | Hacker News Reader

CouchDB is so underrated in this space.

I get it: CouchDB was a very early (the first real?) document-based database, and it got some things wrong, or at least weird early on (e.g. map/reduce queries, a reduce step to the map/reduce query that is actually one-to-many (on purpose! there are concrete reasons in real life you want this!), etc.).

But they also got so much right:

   - The database is all HTTP, all the time. Connecting up your
     choice language takes about an hour.
   - Offline replication and database streaming, standardized at the
     protocol level, which allows you to use various combinations of
     CouchDB, Couchbase, Coucbase Lite, and PouchDB without interop
     problems. Plus, it means in the early part of an app (like the 0.X
     bit), I can trivially replicate the prod DB down when I'm trying
     to repro something.
   - You can store your HTTP assets right alongside the DB for 
     Firebase-like asset hosting. Throw it behind a caching service
     for prod if you want.
   - You can store full-blown files, which is great for lots of practical
     app these days.
   - Trivial replication. The scaling of CouchDB itself is honestly a
     bit crappy, but Couchbase has great scaling, and since they speak
     the same protocol, you can easily scale from CouchDB to Couchbase
     without missing a beat.

CouchDB is actually my favorite "I just wanna hack something" database for the above reasons. No, I have not and do not know if I'd seriously recommend using CouchDB 1.6 in prod for something you expected to grow huge, but it's a great "get it done" platform like Parse or Firebase, and you can really trivially move to Couchbase as you scale up if you need to.

PouchDB and CouchDB are great for prototyping of apps, but access restriction in CouchDB is broken by design: it is hard to make it correct, CouchDB is open by default, user can store anything in DB it has access to, including pr0n.

If CouchDB will close DB by default AND it will be easy to specify politics by REST path AND it will be easy to restrict document schema by REST path, then I will use it in production.

Lots of databases are open by default, especially in this space (Mongo, RethinkDB, Redis, Riak, and I believe Cassandra), and Fauxton has huge warnings that you've got access turned on globally if you haven't adjusted the setting, so I'm not sure I agree with you that that's an instant fail, but I get your point.

That said, in CouchDB 2, it'll be easy to programmatically restrict document information in a similar method to Firebase. I can't find the CouchDB 2 documentation itself, but https://github.com/rcouch/rcouch/wiki/Validate-documents-on-... , from rcouch, is the current plan. Do note that CouchDB doesn't do Firebase-like OAuth workflows, so you'd still need a thin shim in prod to handle that if you don't want to have all bespoke user accounts, all the time. (There's probably a clever way to make this work using client-side OAuth workflows, but I've never actually thought about it much.)

> Major security alert as 40,000 MongoDB databases left unsecured on the internet http://www.information-age.com/technology/security/123459001...

Yes, it is great for prototyping, but it is bad for production.

The access control limitations in Apache CouchDB are a big part of what we addressed in Couchbase Sync Gateway. Info about our Sync Function API http://developer.couchbase.com/documentation/mobile/1.1.0/ge...

Oh, that's awesome! I'd never actually looked carefully at the sync layer, but that seems like a really direct equivalent.

Are there any whitepapers or case studies of large-scale production applications using and maintaining a sync function? After using sync gateway with access control for a while, it became more clear to me that writing my own access control API (via node.js or something like that) on top of MongoDB would give better readability and maintainability over a sync function.

(edit) specify mongodb

[Architect from Couchbase]

The formatting and modularization of your sync function code will strongly influence both it's readability and maintainability.

I've published and example of one that is well formatted and modularized. The example includes Navigation Flow, Wireframes, Data Modeling, and a Sync Function (which is the security layer).

https://github.com/waynecarter/couchbase-mobile-examples/wik...

Let me know if you have any other questions around this and I will add it to the example.

I couldn't agree more here and it is sharing the same protocol with Couchbase Mobile. For me, mobile apps and offline storage with Sync is the value add. I know with Parse, push notification was the big thing for them but also it was expensive overall. This is something where you can do with Couchbase and it is all free too.

Yap.

No other database I found has build-in master-to-master replications that works as well.

Another strong aspect is crash-only data storage model. Because it uses append-only file writes, I trust it to handle power loss (VM hard stops), crashes etc.

There is 2.0 coming out which will have a clustered option, so it can allow scaling a db easier (vs say making your own replicated topology + load balancer).

What about Riak?

Reply on news.ycombinator.com