Designing for Multi-Tenant Applications
On this page
SingleStoreDB is a great solution for multi-tenant analytical applications because of its unique architecture which provides ultra fast ingest, super low latency queries, and high concurrency.
Workspaces are how SingleStoreDB achieves separation of storage and compute, which makes them idea for use in multi-tenant applications.
Let's assume that one of SingleStore's customers has 10,000 customers with free, standard, premium and dedicated offerings.
Free - S-2 Workspace - 9,000 tenants with low performance requirement and infrequent usage
Standard - S-4 Workspace - 900 tenants, medium performance requirement with infrequent usage
Premium - S-16 Workspace - 99 tenants with high performance requirements and frequent usage
Dedicated - S-4 Workspace - 1 tenant whose data and compute capacity need to be dedicated
Customers have a few options when designing their databases with multi-tenancy in mind.
The most scalable, manageable, and cost effective model is 1 database and set of tables for all tenants: Plan A.
Highlights for Plan A:
The best system in terms of scalability, manageability, and cost control.
Use Plan A unless you have a good reason not to.
Reasons to not use Plan A:
Another great approach is to put all customers in the same database, but use separate sets of tables for each customer: Plan B
Highlights for Plan B:
This system is good, but you will need to carefully manage your memory use as you add customers.
This system is significantly more scalable than Plans C and D, so you should use it unless you can't, due to compliance reasons.
Memory use is proportional to:
# of tables in set * # of sets of tables * # of unique query plans
Use the following strategies to minimize the above formula:
Use views instead of tables.
Use fewer unique queries (queries that require individual query plans to be compiled).
Decrease the number of tables via merging (wider tables are ok).
Other memory minimization strategies include:
Turn off table autostats
Use fewer partitions
You can view your memory usage in the Cloud Portal.
Use RBAC to keep customer data separated.
This system can be extended to any number of users or user groups for a tenant (customer).
Some customers might want the highest possible level of isolation.
Highlights for Plan C:
If some customers must be totally walled off, Workspace Groups provide the greatest isolation.
For example, if all your customers in AWS Europe needed to be separated, you could have an AWS Europe Workspace Group
You would need to use this in conjunction with a Plan A / Plan B setup as having every customer in its own workspace group will not scale well in terms of operational complexity or cost.
It’s also possible to put each customer in its own database: Plan D
This is easy to set up and great for prototyping, but will not scale to a significant number of customers due to persistent cache constraints.
Highlights for Plan D:
If every customer must be isolated at the database level for compliance reasons, Plan D may be your best option.
This option will work well for small numbers of customers, but because each database has significant Local Disk space overhead, you will need to scale up your Workspace Group as you add customers and databases.
Each database, on average, will use 4 GB for transactions logs for each partition, so if you have a lot of databases, this can add up quickly.
When deciding which approach is best for your particular circumstances, consider which factors are most important to you and your different offerings.
Last modified: July 5, 2023