Hi Kiril, first, this is a good question :)
I’d like to add, that you are missing one more approach to consider: use a single database. Let’s first look at the other approaches, and I’ll start with database-per-type: - there is no real benefit of doing this, other than theoretical purity - it won’t allow you to query across types, say: give me all or a part of types for a single user, which is, I assume, going to be a very common thing - to get to all types for a user, you have to make a request to each database - the more types you get, the more queries you have to make - reducing the number of queries, and reducing the number of databases you need to talk to to get your most common operation is beneficial So I would recommend against that. I know of some apps using this pattern successfully, but that’s because they have very strong separation of types, so they will never have to query more than one type at a time. If someone else reading this who is happy with their setup this way, I won’t begrudge them, but I would *not* recommend anyone starts with this pattern. Next, database-per-user: - you always clearly know where a user’s data is. Wanna delete a user: delete their db. Easy for making sure data is separated from other users, easy to comply with legislation about data deletion, etcpp. - if you plan to replicate the data onto a per-user device (like an offline web app, or native app), access control in CouchDB is such that it is per database. So if that’s a requirement for you, then you are already locked into database-per-user. If not, it is still neat from a data organisation point of view. - downsides include not being able to query across multiple user (how many address book entries are there in total, what’s the median per user, etc). Sometimes this doesn’t matter, sometimes it is important. - there are workarounds to query across all databases (replicate all individual databases into a central big database for querying). Again, this is usually the case for setups where there needs to be per-user replication. But it is a workaround. - having many small database requires a bit more work on CouchDB’s side when dealing with many concurrent users being active Finally: single database: - you can query across all users - you can get all data per user in one request - either via _all_docs if your doc _ids are prefixed with the user id - or a view/mango by user-id - you can’t authenticate/replicate by-user (but if you don’t have that requirement, that’s not a downside) - database sharding scales up linearly with your data usage - concurrent users can be handled very efficiently - partitioned databases with a partition key of the user id gives you additional benefits at larger scales (likely matters less with 1000 users), but ymmv, and you know the option is there for later * * * Given the situation you described, I’d strongly recommend a single database for this app, because the benefits are overwhelming. I’d strongly recommend against using db-per-type, just because it doesn’t gain you anything practically. If you need per-user replication, db-per-user is your only choice. It has drawbacks, but no show stoppers at the data sizes you quote. HTH, Jan — > On 8. Apr 2021, at 10:07, Kiril Stankov <ki...@open-net.biz> wrote: > > Hi all, > > I have a design question. > Lets say that my solution will serve hundreds (or even more than 1000) > customers. > For each customer I will need 4 to 6 sets of objects, say: assets, > address book, meetings and meeting results. > I wonder what would be best approach here: > - have userDB's for each customer with documents identified by type > (this means potentially thousands of db's), or: > - have 6 db's, one per document type and filter by customer ID. > > There might be thousands of documents of each type per customer, > eventually bringing the total number of documents to millions. > > How each of the approaches above will affect clustering and what will be > the best cluster setup. > In terms of performance and indexing, does one of the designs > outperforms the other? > > Thanks in advance, > Kiril.
