... [I] can't say what exact app (shop, historic info, social media, forum)
This makes this question very difficult to answer. This is because you have two basic types of queries:
OLTP and OLAP queries
Online transaction processing (OLTP) is information systems that facilitate and manage transaction-oriented applications, typically for data entry and retrieval transaction processing.1
These kinds of queries tend to be very high volume, but short, and targeted and are a great fit for a system like MariaDB. On the other hand,
Online analytical processing, or OLAP, is an approach to answering multi-dimensional analytical (MDA) queries swiftly in computing. OLAP is part of the broader category of business intelligence, which also encompasses relational database, report writing and data mining. Typical applications of OLAP include business reporting for sales, marketing, management reporting, business process management (BPM), budgeting and forecasting, financial reporting and similar areas, with new applications coming up, such as agriculture.2
These types of queries perform extremely poorly at scale in Maria DB unless it is properly tuned and certain database management and retrieval techniques are used (such as partitioning, for example). These performance issues are largely a result of a confluence of disk I/O issues and the fact that queries are single-threaded in terms of CPU. While sysbench can do a great job of testing the performance of OLTP queries, for OLAP queries, you will need something else. For example, one programmer forked sysbench to add the ability to do OLAP queries.
Unless we can get a bit more information about how much data you are working with and what kind of I/O operations you will be doing (reporting or transactional) it is hard to say if this specific tool will do the job. Ultimately database management is a complex discipline and there is a reason DBAs are able to make careers out of just database management. I have seen a lot of programmers think that they don't really need to worry about database management and they don't really need to integrate a DBA into their team. As their app scaled, they very quickly found out they were dead wrong. If you are planning a multi-tenancy DBaaS environment, you are going to need to architect your system very carefully in order to prevent one tenant from affecting the performance of the other and consider offering DBA consulting if your customers begin to suffer performance issues - and factor that into the price. If they can't afford their own databases and find that managing that in house is untenable and unaffordable, you will need to provide both the platform and the expertise as part of your service as one customers performance issue can easily become all of your customers' performance issue. That means you are going to really need to know your stuff or make sure you hire people who do. In short, databases are hard.