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