Most of the contents in this post is taking from Multi-Tenant Data Architecture. This is just a quick reference.
Designing single-instance, multi-tenant architecture is not that easy. It required more work to do. SaaS application is distinguished by three qualities: scalability, configurability, and multi-tenant efficiency.
Three approaches for multi-tenant:
Suitable: For customers that are willing to pay extra for added security and customizability. For example: banking or medical records.
Suitable: For applications that use a relatively small number of database tables, on the order of about 100 tables per tenant or fewer.
Suitable: when it is important that the application be capable of serving a large number of tenants with a small number of servers.
For more details read this topic Choosing an Approach
Two main tools to use when scaling out a database out are replication and partitioning.
Replication involves copying all or part of a database to another location, and then keeping the copy or copies synchronized with the original.
Partitioning involves pruning subsets of the data from a database and moving the pruned data to other databases or other tables in the same database.
Horizontal partitioning means that the database is divided into two or more smaller databases using the same schema and structure, but with fewer rows in each table. The simplest way to scaleout a shared database is through horizontal (row-based) partitioning based on tenant ID. SaaS shared databases are well-suited to horizontal partitioning because each tenant has its own set of data, so you can easily target individual tenant data and move it.
Vertical partitioning means that one or more individual tables are divided into smaller tables with the same number of rows, but with each table containing a subset of the columns from the original.
Database clustur: deplicate databases on multible servers and load balance connection to these servers.