Thanks, Jan and Sam for the very detailed and fast answers. Much appreciated!
Actually from Jan's answer it seems that I will go with per user db for one simple reason - yes, I will be required to be able to delete all data for a departing customer. I believe that doing that in a single DB or per type will be CPU killer. Shall I expect any issues with say, 1000 user db's? Any OS changes required like file handlers, etc.? ------------------------------------------------------------------------ On 4/8/2021 2:07 PM, Jan Lehnardt wrote: > Hi Sam, > > >> On 8. Apr 2021, at 12:24, Sam Lown <sam.l...@gmail.com> wrote: >> >> - create databases for data which will grow infinitely like calendar >> entries or anything that has time as a primary key. > Excellent additions, and one more point on this in particular: > > - database-per-time-unit (say one per month), especially in > offline-replication scenarios, but also useful otherwise. > > This allows you do just delete or stop replicating databases older than > needed, and make, say, an archive feature an online-only feature in the app, > while “current” data stays available for offline replication. > > And if you have loads of data and accumulating it fast, some of that data > might be less important than other data, so you can easily move “archive” > data to a server or cluster that has less performance but higher data storage > capacity, while your “current” data cluster skews towards performance. > > But all that incurs management cost, and is usually a “next level” > optimisation, but if you start with, say, database-per-month now, it is easy > to implement when you need it. > > Best > Jan > —
