Is there any case where CouchDB authorization alone is sufficient for production apps? They recommend deploying a proxy server in front of Couch but do not recommend an authorization layer / server? See Best Practices. I understand that read access is all or nothing per database. One issue that immediately comes to mind is - what stops a user, or member, from creating an infinite number of databases? It does not appear that design (or validation) documents can query for number of existing DB's? Other concerns exist as well. Below is all I can seem to find in terms of official documentation.
This is not an opinion based question because either Couch can exist by itself in production or it cannot assuming the developer follows the least privilege access principle.
CouchDB recommends the use of HAProxy as a load balancer and reverse proxy. The team’s experience with using it in production has shown it to be superior for configuration and monitoring capabilities, as well as overall performance.
1.1.5. Security and Validation
To protect who can read and update documents, CouchDB has a simple reader access and update validation model that can be extended to implement custom security models.
Each database on a CouchDB server can contain its own set of authorization rules that specify which users are allowed to read and write documents members, who are allowed to read all documents and create and modify any document
4.1.5. Adding client-side security with a translucent database
It is possible to use a modest amount of encryption and one-way functions to obscure the sensitive columns or key-value pairs, a technique often called a translucent database.
No, CoucbDB doesn't have the security system you're accustomed to using in other databases. There are many different approaches people use, here's just one:
At a company I worked for we had a product that provided content to many schools. Schools paid for access to certain content.
We had one DB that was our "global" source of truth, it had all content in it for all schools. It was on its own CouchDB server, not accessible from the internet.
We then had a school-facing server that had one database per school on it. The databases were named using a random UUID, and those DBs only included the content that the school had purchased (query-based filtered replication - the filter used the UUID).
So then the schools had devices which had their own Couchbase-Lite DBs on them, and were configured to use the UUID to replicate the school-specific DB locally from the school-facing server.
I think we also had a validate_doc_update, just to prevent teachers from updating data they shouldn't. Most of that was handled in the app UI though, the DB side of things was just there as a backup (mostly to protect ourselves from app bugs).
Worth noting that we also had some normal RDBMS-based web app for school admin staff to do other things that we weren't interested in replicating, and which needed relational/transactional mechanisms.
So that's just one use case, there are obviously many different ways to skin this cat.