[skrebbel]

As a Firebase customer and former CouchDB user, I can tell you that the use cases are really not as similar as you apparently think they are.

Until very recently, Couch/Pouch would only sync entire databases, and recommended a "One database per user" approach. This is improving now, but it's still very coarse-grained. Last time I checked, anything that has data that you couldn't shard easily is basically unfit for Couch/Pouch - e.g. any messaging app or a Twitter clone. How would you select which data goes to which user? Or do you just want to put all tweets, globally, on everybody's phone?

All of this is absolutely peanuts on Firebase.

[david-given]

Personally, I'm looking for a database with:

- strong consistency (cross-node transactions!)

- strong access controls (don't want clients to see data they're not allowed to!)

- the ability to seamlessly replicate a view from the server to a web client without me having to think about it (although only read-only)

So far none of the web nosql databases I've looked at support these. Strong consistency seems to be unfashionable, presumably because it's hard to shard. I was really surprised to discover that CouchDB apparently doesn't support access controls, though --- if a client has access to the database endpoint, it can see everything. Aren't access controls part of the core competency of a multi-user database?

[jchrisa]

The Couchbase Mobile Sync Gateway tackles fine grained access control head on. Basically you write a function that stripes your data into channels, and manages access on a per channel basis.

There are a few things that are challenging to model this way, but for 80% of use cases it's the right simplification. Intro documentation: http://developer.couchbase.com/documentation/mobile/current/...

[david-given]

Sync Gateway looks very plausible... but having to run an extra server just as access control to the main database? That's so ugh.

It also looks like this requires me to annotate each document with ACLs. I was rather hoping to be able to just sync a view, so that changing the database would cause players with changed views to automatically resync. I'm not terribly happy with having to recalculate the views of all players and then update the ACLs of all documents manually on every database mutation; that's a lot of writes.

[jchrisa]

The database speaks a binary database protocol. The Gateway speaks websocket and http.

Access control is managed via channels, and you configure the gateway with a JS function that determines which channels a document belongs to, so you don't ACL annotations, the ACL is determined dynamically by your code at write time.

There's a tiny bit of write amplification as we persist channel membership in an index, but that's to avoid massive read amplification of irrelevant records when clients sync their subset of channels.

[Lazare]

> I was really surprised to discover that CouchDB apparently doesn't support access controls, though --- if a client has access to the database endpoint, it can see everything.

Not sure what you mean; CouchDB has strong access controls, although they are at what in SQL terms we'd call the table level, rather than the row level. But it's not really any different than, eg, MySQL? Or MongoDB, if you want to compare NoSQL to NoSQL.

If you have data in a table that a client shouldn't see, don't give that client access to that table.