Having built a number of these, it's not that simple. For example do you put a tenant column on every table, have a separate table per tenant, or have a separate schema or database? There are tradeoffs for each approach and lots of gotchas you wouldn't expect. Like if you use a separate table or database, migrations take forever, you can run into file descriptor limits in your database, etc.
Separate table per tenant? Not unless you have/expect 2 to 5 tenants otherwise you run into the issues you describe above.
Having a database per tenant has always interested me. It make sense if the databases will be different (contain other tables)
Adding a tenant id to the tables that require them makes sense.
The best approach is to create a pivot table between users and tenants that holds user_id and tenant_id. Use the primary id of that table to represent the user at that tenant.
The limit is a lot higher than 2 to 5, but I think sooner or later it will get you. Until then you will suffer a slow death by a thousand migrations.
A separate database is best used if you need an absolute firewall between the tenants for security reasons. Almost no bug can ever let one tenant see the data from another. If they share tables, it's easier to make that mistake.
The downside is you can't have quieres across all your tenants, so you'll want a BI database that brings all the data together anyway.
That there are tradeoffs with each option does not mean all options are equal at all.
Doing a little research first, and thinking about which tradeoffs matter most in your particular case could save you a lot of effort rewriting things down the road.
