Is it good practice to provide each CouchDB user with a separate database?

Question

I have a few conceptual questions regarding the structure of users and their documents.

Is it good practice to provide each user in CouchDB with their own database storing their document?

I read that couchDB can process thousands of Databases and that a database is not uncommon for each user.

Cause:

The reason for this question is that I am trying to create a system in which a registered user can only view his document and cannot view any other user document.

Any suggestions.

Thanks in advance.

Answer 1

Its a fairly common scenario for creating a CouchDB (DB) bucket for each user. Although there are some disadvantages:

• You must synchronize ddocs in each custom bucket, so deploying ddoc changes across multiple buckets can be a real adventure.
• If documents are shared among users in some way, you get doc and viewindex in each container.
• You must block _info requests to avoid leaking a list of users (or you must name buckets using hashes).
• In any case, you need a proxy server in front of Couch to create and prepare a new bucket during user registration.
• It's better to protect Couch from running out of capacity when it receives a lot of requests - it also requires a proxy.

Reading ACLs with per-doc can be implemented using _list functions, but this approach has some drawbacks and also requires a proxy server, at least a web server in front of CouchDB. See CouchDb for authentication using lists for more information .

You can also try playing with CoverCouch , which implements a full read-only ACL for reading, while keeping the original CouchDB API intact, but in the early beta.

Answer 2

This is a fairly common use case, especially in mobile environments where the data for each user is synchronized with the device using one of the Android, iOS or JavaScript libraries (pouchdb).

So, in concept, it’s fine, but I would still recommend thorough testing before entering production.

Note that one drawback of multiple databases is that you cannot write queries that span multiple databases. However, there are some workarounds - see Cloudant: Databases Search for more information .

---

March 17, 2017 Patch :

Please see Cloudant Messenger for more information on this approach.

The database for each user is a common template with CouchDB, when there is a requirement for each user of the application to have their own set of documents that can be synchronized (for example, with a mobile device or browser). At first glance, this is a good solution - Cloudant handles a large number of databases in one installation very well. But...

Source: https://github.com/cloudant-labs/envoy

Answer 3

The solution is as old as web applications - if you are thinking about the mySQL database, there is nothing in the database to stop the B entries of users belonging to user A - all this is encoded at the application level.

There is also no absolutely safe way in CouchDB to prevent user B from accessing documents written by user A. You would need to code this at your application level as before.

If you have a web application between CouchDB and users, you have no problem. The problem arises when you allow CouchDB to serve requests directly.

Answer 4

Using multiple databases for multiple users has some important disadvantages:

• Queries on data in different databases are not possible using the couchdb native API. Analysis of the general condition of your site is completely impossible!
• maintenance will soon become very difficult : consider replicating / compacting thousands of databases every time you want to back up.

It depends on your use case, but I think a good approach might be:

• Allow access only through the virtual host . This can be achieved using a proxy server or much easier using couchdb hosting , which allows you to fine-tune your "domains->" display path

• use design documents / couchapps instead of direct CRUD API document for read / write operations

  2.1. using the _rewrite handler to allow only valid requests: this way you can instantly block access to smart handlers like _all_docs, _all_dbs and others.

  2.2. using the _list and _view handlers for read ACLs described in CouchDb to read authentication using a list

  2.3. Using _update handlers for ACLs, write role-based documents / roles

  2.4. using authenticated rewrite rules for role-based read / write ACLs.

  2.3. The filtered _changes handler is another way to get all user data using a read / role ACL. Depending on your use case, this can effectively simplify your reading API , allowing you to focus on your update API.