For our current product (a multi-tenant SaaS), we chose to create a separate database for each customer. The database is the one true security boundary with CouchDB, so it seemed a good choice for us. Currently, we have the following: - one database per customer - one master database for the platform itself (e.g., to hold metadata about each customer & databases)
It's been working great so far. An aspect that I like about it is the separation for backup/restore. If a customer breaks things, we can restore a single database without worrying about the impact on other customers. It's still early on, so we probably haven't encountered all the difficult cases yet.. kr, Sébastien. On Thu, Apr 8, 2021 at 3:18 PM Kiril Stankov <ki...@open-net.biz> wrote: > Yep, > I thought about that, but unless I do some tests first, I have no idea > how long such a process will take for, say, 10K out of 1M docs and what > impact on performance it will have during that time. > As the option 'Compact database' is no longer available, I am also not > aware how exactly to do that. Replication? Not feasible in prod > environment, I'm afradi. > > Otherwise, yes, the option to have customer ID as doc _id, instead of > UUID is absolutely valid. > > Thanks. > > On 4/8/2021 2:56 PM, Olaf Krueger wrote: > > Hi, > > > >> ... I will be required to be able to delete all data for a departing > customer.... > > Wouldn't it be a valid option to remove all documents which are related > to a particular customer from a single database and (if needed) re-create > the database afterwards in order to get rid of the revisions or > "tombstones"? > > > > Using meaningful _ids instead of anonymous uuids could be helpful here, > e.g. > > > > customer:1 > > customer:1.address > > customer.1.meeting.1.scheduling > > customer.1.meeting.1.result > > customer.1.meeting.2.result > > > > customer:2 > > customer:2.address > > customer.2.meeting.1.scheduling > > customer.2.meeting.1.result > > customer.2.meeting.2.result > > > > By using the leading string of the _id, e.g. "customer:1", you could > fetch or delete all relations for a particular customer. > > Moreover, with the knowledge of the customer-id and meeting-id, you can > easily compose the _id of each document in order to directly fetch it by > its _id. > > > > Maybe this helps, > > > > Olaf > > > > > > > > > > > > > > > > > > > > > >
