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.

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

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

(edit) specify mongodb

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.

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