My perspective on several points:

1. Your solution can be worked from the same database
2. The dynamism of updating (updated or new structures) will depend on how you structure the relational database
3. You can work with table schemas or namespaces to define your clients in the database, this will help if they need something custom, it will not affect the schemas of the other clients.
4. If in the short or medium term there is no customization or it is minimal, I think it is possible to work without the table schemas/namespaces.
5. It is important to define the indexes of the tables or structures for concurrent data, this will help that when the information grows over time and the critical maintenance is more controlled
6. Using Azure or AWS or any platform as a service will help you manage the demand for access to your data, the cost will depend on the concurrence and the efficiency of your data access queries.
7. If you need all changes in structures to be versioned for new updates or restore changes, in addition to being connected with the development process until they reach production, they must go through a continuous integration process that allows them to go through all the necessary test flows. and test environments for core change control as well as customization. All this is given to you by a platform as a service solution using CI/CD in the development process.

You can't just think only about the database but also about how to move all the development to the production environment.