Just the way you think it's best. We can not know what is best without knowing every detail, and especially how it might happen in the future. The technology you use or the number of users generally does not matter.
I do not even know if the description is correct, because it's very difficult for someone to tell how many concurrent users they'll have without running the system. Almost always has much less than the person imagines, that is, simultaneous truth is usually 2, 3 or 4, but if there are many, then you can not be very precise, you can speak in 50, in 100, round numbers. Concurrency is not what you think it is. That's why people think they need a much more complex architecture than they really need.
What you're talking about has nothing to do with multi-tenancy , the main reason I answered. This concept is the opposite of what you are describing, it is when the system must adapt to run for several different clients.
The issue of backup is unrelated to this. It is another problem and it is not because of the model itself, but because of the way it is being done and how it has been configured.
Being all together or not, has nothing to do with performance in any engine of MySQL. Other decisions are that they make the performance good or bad. It can influence a minimum, but nothing that makes real difference.
Of course, each model adopted will have advantages and disadvantages and have to put in the balance each one. One of them will make you have more difficulty with some operations and another model will have other operations, there is nothing free of disadvantages.
I prefer whenever possible in a relational database to put everything on the same basis, I see little or no advantage in separating. You have to see, but I obviously disagree with them. Whenever it has a relationship, it needs a transaction between tables, if it is not on the same base it becomes a martyrdom, and if there is something like that in your scenario today, one day it may come to have. It is almost always hard to justify the motivation to separate, not least because it gives so much work in more complex applications that it is not worth the effort, and in the simple things it does, until it ceases to be simple.
Imagine having to think about separating some things and putting others together. The case of the users of your example. Whether it should integrate with everything or do separate and turns to integrate with everything (this case can be simple, not all are) or else put together. But how to put together if there are separate parts? Replicating? It looks awful, close to unfeasible. And if what worked well separated one day changes and needs to be together?
This site is one of the 50 most accessed in the world and has everything together, runs extremely simple and with an absurdly good performance. Unless you work on Facebook, Netflix, these companies, I do not see how separate is a good idea. But the current fashion of the market is to separate (I have a lecture showing how much more problematic than people think).
But I often say that if you do not know what you are doing, if you do not understand the fundamentals, do not master every detail of the technology you are using, there is no point in making an architecture decision, all architectures will go wrong, is at this point.
