The problem is not new, and there is no "one size fits all" solution for this. If you want to keep your system maintainable, you need to analyse the different requirements

• for every single attribute

and make a decision how to design it:

• either as a standard attribute which is available for every tenant (and so best modeled as a standard column in your database)

• or an attribute which is available for lots of tenants (so it could be modeled as as a standard column in your database as well, but only shown in the UI for those tenants who require it).

• or a custom attribute which is best modeled using an EAV approach, as suggested by @FrustratedWithFormsDesigner (this is typically the case when the tenant wants to add this kind of attribute by himself)

• or, if the attribute fits best into a "child" table, as suggested by @pfuetz (maybe a tenant-specific child table, but I recommend to have such child tables associated with a named feature of your application, and then decide which tenant gets access to this feature)

Note that standard columns are often much easier to manage than EAV approaches: it will be easier to implement business logic for them, standard SQL queries will be simpler, user interface design can be made more specific to the column, database migrations will often be easier, and so on. So I recommend to use EAV rarely, with caution, only where you really need it.

You will definitely run into maintenance problems when you start to duplicate tables for each tenant and modify each copy a little bit. Do this 10 times, and you will have 10 times the maintenance effort for every copied attribute. So I would heavily recommend against that.

The problem is not new, and there is no "one size fits all" solution for this. If you want to keep your system maintainable, you need to analyse the different requirements for every single attribute and make a decision case-by-case how to design it:

• either as a standard attribute which is available for every tenant (and so best modeled as a standard column in your database)

• or an attribute which is available for lots of tenants (so it could be modeled as as a standard column in your database as well, but only shown in the UI for those tenants who require it).

• or a custom attribute which is best modeled using an EAV approach, as suggested by @FrustratedWithFormsDesigner, or an "XML or JSON" approach (this is typically the case when the tenant wants to add new attributes freely by himself, maybe on a "per record" base)

• or, if the attribute fits best into a "child" table, as suggested by @pfuetz (maybe a tenant-specific child table, but I recommend to have such child tables associated with a named feature of your application, and then decide which tenant gets access to this feature)

Note that standard columns are often much easier to manage than EAV approaches: it will be easier to implement business logic for them, standard SQL queries will be simpler, user interface design can be made more specific to the column, database migrations will often be easier, they are much more self-documenting and so on. So I recommend to use EAV rarely, with caution, only where you really need it.

You will definitely run into maintenance problems when you start to duplicate tables for each tenant and modify each copy a little bit. Do this 10 times, and you will have 10 times the maintenance effort for every copied attribute. So I would heavily recommend against that.