SaaS App - Multi-Tenancy with n DB's or Multi-instance?

We're looking to get our product as an MVP to demonstrate to clients and I'm doing a little future planning for the best architecture for the future (plus a little self-learning).

Basically the product we're designing will have a base Laravel SPA app that all customers will use. This would be fine as multi-tenant and could easily implement a multi-DB approach (rather than single DB), as the data-sets for some clients will likely be in the millions, so extracting them possibly to a different server could be beneficial.

Anyway the complicated part is that we want to offer high feature customisation for each client that's tailored for their business, so features specific to their industry/niche, this will be the initial attraction and USP, then over time we will have a set of packages we can reuse with the customisation for new clients already built.

How would you do this with multi-tenancy?

• 1 Multi-Tenancy with unique assets/features. I know packages like laravel-tenancy have things like unique composer vendor folders and config per tenant etc. But this will require different migrations, js and css possibly (which will need to be compiled) for each tenant and updates to the software/packages. (possibly the cheapest option, at least at the start)

No. 1 just sounds like it's not possible, or at the very least highly discouraged with different DB schema and dependencies per tenant? I guess a way around this is have the app and DB schema the same with the full feature set and just not use them on some clients with flags, but it just doesn't sit right that each client will have loads of unused tables, with potential conflicts in similar features needing slightly different implementations.

• 2 Multi-Instance for each client. The above to me sounds really messy with multi-tenancy and could easily break with a migration conflict or something as the databases will all have slightly different schema's. So might it be better to use multi-instance, spin up a new server/container per client and have their own Laravel instance with their own composer.json, assets, migrations etc. Then for each 'feature' just include them as a private composer package (which would include the migrations and assets for that package), and possibly one for the base application that everyone shares. (this will probably be costly mostly in dev time)

No. 2 to me sounds like it could get out of hand with 100's of custom git repositories and something relatively straight forward like upgrading from 5.5 to 5.6 would be hell having to repeat on hundreds of unique applications. Maybe not?

• 3 Multi-Tenancy for each niche/industry. This option seems like a good candidate. We create a multi-tenant app for each industry so maybe 10-20 instances of a multi tenant app under a unique domain, each with ~100 clients on each and a fixed set of features for each instance. This means all schema's are the same per industry and updates/downtime/problems will be limited to a group of clients at a time rather than everyone (in theory). The only problem with this one is that there will be no customisation per client, just per niche.

No. 3 is probably looking like the best of everything in my head currently. It keeps it as simple as it can be without putting everything in one place with massively complex system and still allows customisation. Easier to run in development that 1 too I suppose. Also requested features per niche are more likely to be appreciated by everyone on the instance. Hard part is choosing which niches to focus on first.

Any thoughts? Or anyone else experienced something similar?