[shahinghasemi]

What misbehaving do you mean? If traffic is what you mean, it's okay since at the first stage of the software we have time to test/scale accordingly. Therefore in that stage it might make sense to change the architecture to per-tenant database.

[ozzythecat]

One tenant sends you a flood of traffic, that you might not be scaled to handle. Let’s say your application servers are scaled for this traffic, but your single, shared database is not. All that traffic could cause an outage on your database. If this happens, the impact won’t necessarily be on one tenants but all tenants.

There are ways you can mitigate this. Strong isolation is one. Throttling tenant calls could be another.

We don’t know your specific use case enough, but it’s something to think about now.

This is generally referred to as the noisy neighbor problem.

https://docs.aws.amazon.com/wellarchitected/latest/saas-lens...

[shahinghasemi]

As you mentioned there are easy workaround for this issue on both application and infrastructure level: implementing rate limiters, monitoring/alerting systems for DB resource usages, putting quotas for tenants, etc. After all a postgreSQL instance in 16GB ram and 8core cpu can handle pretty much of the traffic for most SaaS products at their first stage.