Most of the points here don't pass the sniff test to me.
The way the claims are worded makes it seem like they're comparing two extremes: completely separated (as in literally separate VMs/K8s clusters/whatever) infra for each customer vs completely shared everything. IMO a much simpler approach is 1 DB (and 1x blob storage space if required) per customer, with N application servers using the appropriate database required (i.e. using subdomain to differentiate the customers).
This massively simplifies security concerns compared to a shared-DB, and despite what they claim, it's easier to scale too, because you aren't trying to host a single giant database in one place - it can be scaled horizontally (effectively sharding by customer) both at the application layer and at the database layer, and outlier customers can be handled with even further dedicated resources if required, without needing some custom setup because it expects to be using one DB for all customers.
The way the claims are worded makes it seem like they're comparing two extremes: completely separated (as in literally separate VMs/K8s clusters/whatever) infra for each customer vs completely shared everything. IMO a much simpler approach is 1 DB (and 1x blob storage space if required) per customer, with N application servers using the appropriate database required (i.e. using subdomain to differentiate the customers).
This massively simplifies security concerns compared to a shared-DB, and despite what they claim, it's easier to scale too, because you aren't trying to host a single giant database in one place - it can be scaled horizontally (effectively sharding by customer) both at the application layer and at the database layer, and outlier customers can be handled with even further dedicated resources if required, without needing some custom setup because it expects to be using one DB for all customers.