envoy

nctions, using validations to ensure the everything that comes in is the right "shape" and using NGINX and it's ilk to apply throttling and sane request limits. At scale there's a decent chance you want a proxy in front of your Couch instance anyway, since Couch is truly multi-master, meaning you probably want to balance your clients across all your nodes anyway. [1] https://docs.couchdb.org/en/stable/ddocs/ddocs.html#validate... [2] https://docs.couchdb.org/en/stable/replication/protocol.html... [3] https://github.com/cloudant-labs/envoy

tems with many users (tens of thousands -> millions) would be stuck replicating an equal number of couch databases constantly. Each replica in 2.0 was an erlang thread, and each database is a separate file. Apparently some of the performance issues were fixed in 2.1, but it still requires a physical file per db and continuous replication. Some promising solutions like envoy [3] from Cloudant, which were based on Mango [4] have been worked on, but don't seem to have much support in the core Couch community and feels to have been abandoned. Another problem is that you can't really throttle or manage pouchDB <-> couchDB replication very well. Eg, if you have a large-ish database that's out of sync, it's just going to try to download itself as soon as you sync, which isn't very mobile friendly, or "PWA" friendly IMO. Net result for me was that I just stuck with my Postgres DB, Rails API, and a bunch of Redux/React code to accomplish what I needed. Still a fan of Couch/Pouch but wouldn't recommend it if your system requires any kind of serious per-user or role-based permissions or aggregated views. [1] https://pouchdb.com/ [2] https://pouchdb.com/2015/04/05/filtered-replication.html [3] https://github.com/cloudant-labs/envoy [4] https://blog.couchdb.org/2016/08/03/feature-mango-query/