You don't need different databases for each customer if they are going to have shared schemas anyways. Most SaaS software is multi-tenant and works in this fashion, a common database with application logic to make sure users can only access things they should be allowed to access. E.g. Facebook doesn't have billions of databases, one for each user, to make sure we can't see each other's non-public photos.
Also, the problems you're trying to solve for don't seem as though they should have any bearing on the portability of your application, or your ability to move them to the cloud. If you treat backing services, e.g. database(s), as attached resources then it doesn't really matter if you have one or many (though I still recommend you have just the one).
I'd recommend reading the 12-factor principles for SaaS development and deployment. They are a great starting point for thinking about architecting software that will work easily in a cloud-native environment. I would focus on solving the business problems of your software, and architecting it in a cloud-native way, e.g. per the 12-factor principles.
Nothing about the problems you've described suggest that Docker vs. not-Docker is even a relevant concern at this time. I.e. all your proposed approaches could be done fairly similarly with/without Docker. Docker solves problems of process isolation, packaging OS-level dependencies, reducing compute resource overhead, consistency between development and production, etc. and only seems indirectly related to what you're after.
