this is essential the key (haha) to all shared/shared scenarios, regardless of what tech they are implemented with. The challenge can be migrating from single tennant to this could be fairly impactful, depending on how you built your original solution.

Not really. Your queries don't have to contain tenant Id if as part of your tenant context they have a connection string to their tenant DB.

Wouldn’t that mean you’re holding lots of non reusable connections?

I have recently been using row level security with a transaction middleware where I set the tenant ID.

Nice article regarding it - https://aws.amazon.com/blogs/database/multi-tenant-data-isol...

We have about 6 physical DB servers, each client has their own db/schema on one of those boxes. Several thousand clients each with 10s of users per client. It brings in $15m ARR.

So, it works.

We're wanting to move off that architecture to something more future proof, but it's not our biggest pain point at this point in time.