I don't have a ton of experience doing this, but with a lot of multitenant you just give each tenant their own database in the first place. It solves multiple classes of problems.
On a single Postgres instance you can (at least theoretically) have 4 billion databases per instance.
Most of the multi-tenant SaaS products I've worked with do NOT have per tenant databases. I'm sure some do, but the bulk of the multi-tenant products use one (or several) larger databases.
> I'm sure some do, but the bulk of the multi-tenant products use one (or several) larger databases.
In that case, the tradeoff between isolation and ease of development is made. That said, having a schema per user (even if in the same physical database) seems like a nice approach, if you can stomach the overhead and added ops complexity.
It also creates multiple classes of problems. There are known issues with PostgreSQL's handling of databases containing tens of thousands of tables. (you will need a disproportionate amount of memory to handle that use case on a busy db server).
Using a single database with tenant isolation by a discriminator key (preferably enforced by row level security) is a lot more efficient.
