February 25, 2023
Software as a Service (SaaS) companies are constantly on the lookout for a data platform that scales efficiently, without having to re-platform the data layer of their application, as more and more customers onboard. Each customer in such companies is typically referred to as a tenant by the engineering and IT teams. In a world where privacy and security reign supreme, the onus is on the SaaS company to use a data platform that lets them host a tenant's data securely in their own logically isolated units while ensuring that the cost of managing this data is kept under control.
Open-source databases such as PostgreSQL and MySQL have been very popular choices to achieve data isolation (also known as data tenancy). In this article, we discuss the typical challenges that engineering and IT organizations face when they use these popular engines for tenant data management and how Tessell alleviates these challenges.
When designing the data infrastructure platform, engineering and IT organizations need to consider ways of providing adequate isolation between each tenant's data, while keeping the cost of managing the data platform under control. You can adopt one of the following data hosting options:
Single tenant (also called Dedicated Hosting): In this model, each tenant database is hosted in a dedicated database instance of its own. With both compute and storage being separate, this model provides maximum isolation between tenant data. However, this model is expensive as it requires an entire instance for each tenant, irrespective of the size of the tenant data and the usage pattern.
Multi-tenant (also called Shared Hosting): In this model, one single database instance is shared by multiple tenant databases. The ability to create multiple databases inside a single instance in PostgreSQL and MySQL makes this model a popular choice for deployment. Both PostgreSQL and MySQL have primitives that can be leveraged to build proper isolation in this model. Additionally, this model is cost-effective too. On the flip side, this model too poses some interesting challenges for managing the lifecycle of tenant databases and ensuring the quality of service to each tenant.
Now that we’ve established that the multi-tenant model is a popular choice for hosting the database on the cloud, let’s discuss the shortcomings of this model and how Tessell helps your engineering and IT organizations alleviate these shortcomings.
The most common problem with the multi-tenant model is the “noisy neighbor” problem. Since multiple tenant databases share the same database instance, the activities of one tenant have the potential to degrade the experience of other tenants. A single tenant could be consistently consuming too many compute resources, or the data for a single tenant may be outgrowing the storage of the current database instance. In such scenarios, the usage of each tenant needs to be intelligently controlled to keep it within the resource limits of the instance. However, if a tenant is consistently starved for compute or storage resources, it may be wise to move this tenant to a completely new database instance. Controlling a tenant and moving a tenant to a new instance are both delicate tasks that often become pain points for the service provider.
As tenant data grows, the tenant may require more resources. As a result, you may want to move the tenant to a new database instance that is better sized for the growing requirements in the near future. Unfortunately, this is usually not a one-time activity, and as tenants grow, you need to manually scale as and when needed for different tenants if you are self managing the deployments of the database. If you are using a Database-as-a-service (DBaaS), then scaling up or down can be done automatically for you but could be very costly.
Tessell has all the primitives that you may need to tackle the shortcomings of the multi-tenant model for your data platform. The challenges presented earlier can be mitigated with Tessell by leveraging the following features of Tessell:
Tessell provides database instances that leverage NVMe-backed cloud instances. These cloud instances provide high read/write IOPS, which translates to much better database performance, without the need to purchase additional storage IOPS for your instance. For cases where storage IOPS was a bottleneck, high-performance database instances allow you to add more tenants to a single database instance leading to excessive cost savings.
Tessell exposes top-level control to create and delete databases inside a specific PostgreSQL/MySQL instance using the Tessell API or user interface. This means that you can onboard databases for a new tenant and seamlessly integrate the tenant database creation into the tenant onboarding workflow.
As a multi-tenant service provider, your enterprise could be managing a fleet of database instances. Each such instance might host multiple tenant databases. The ability to predict the usage of each tenant is critical to taking action to meet that tenant's requirements. Tessell has native monitoring dashboards with intelligent statistics at the database (that is, tenant) level that can be used to predict if there should be an increase in the number of allowed connections for a tenant, or if the tenant should be moved to a new instance altogether, and more.
With Tessell, you can export a specific tenant database within an instance, independent of other tenants. These exports can then be imported into a new instance, thereby moving the entire tenant data to a new tenant. The application can then be programmed to use this new instance to serve the tenant. The export and import primitives can be used to seamlessly move your tenants around as a tenant outgrows the existing database instance.
Multi-tenant database model is growing at a fast pace as more and more SaaS enterprises seek to utilize this model. The Tessell DBaaS platform has been designed in a way that makes it a truly unique platform to address and alleviate the shortcomings of a multi-tenant model with such ease.