Here is another interesting tidbit regarding restoring to Point-In-Time recovery (PITR) --and-- databases.
Mysql allows PITR at the DB level, where postgresql is an all/nothing (i.e. ALL databases) PITR recovery. So, if you want to do multi-tenant on a big gigantic DB server, the way to go is mysql. If you choose to use postgres, you will have to create a mini postgres server (possibly running on a different port/VM) for each tenant. On Wed, Feb 26, 2014 at 1:35 PM, Jacques Le Roux < [email protected]> wrote: > Thanks Mike, > > That's indeed an interesting perspective! > > Jacques > > Le 26/02/2014 20:12, Mike a écrit : > > Shared Database and Shared Schema initially sounds great, until you >> realize >> what a pain it will be to do backups/restores of individual tenants. >> Eventually, a tenant will mess up it's data and will ask you to restore >> back to date/time. Now you are in a real pickle, unless each tenant has >> it's own DB and you have a solid point-in-time DB recovery process. >> Something to think about. >> >> >> On Wed, Feb 26, 2014 at 4:45 AM, Prashant Sankhla <[email protected] >> >wrote: >> >> Hello OFBizers, >>> >>> I am evaluating a proposal for development of a SaaS application using >>> OFBiz framework. As I understood from wiki >>> page< >>> https://cwiki.apache.org/confluence/display/OFBIZ/Multitenancy+support> >>> for >>> every tenant a separate data instance is created. >>> The requirement for us is to be able to scale up to ten thousand tenants >>> and more. Typically each tenant will have 1 to 10 users. >>> >>> This gives me all indication that Shared Database and Shared Schema is >>> the >>> way to go in our use case. >>> >>> My question to OFBiz experts is: >>> >>> 1. Is there any other better design to achieve the use case as stated >>> above? >>> 2. Is there any implementation or guideline available for such a use >>> case anywhere? >>> >>> >>> Best Regards >>> Prashant >>> >>>
