Resolving the DB Tenancy Conundrum for a SaaS Application

Written by Kartikeya Sinha, Chief Product Architect

DB Tenancy in Multi-Cloud Environment

Emergence of SaaS & The Tug of War

The last decade has seen the emergence of the Cloud and the next decade looks promising to make Cloud the most used technology. The widespread adoption of the cloud has enabled small to medium businesses to launch their application as software-as-a-service. Due to this emergence, even large enterprises have started utilizing the offerings in a more fast-tracked manner than ever before. There are many benefits of choosing SaaS over traditional desktop applications but that is not the intention of this article. There are many challenges and design decisions that one must make while building any SaaS application. Every single decision has its implications & contributes to larger challenges in the longer run. If we look at these challenges, at a high level it will look like a tug-of-war among the five pillars of the Well-Architected Framework:

1. Security
2. Cost
3. Reliability
4. Performance
5. Operations

There is a plethora of trade-offs that one must carefully brainstorm about and then only decide the future course of action.

” For example, higher security = more operational overhead, higher reliability = higher cost, lowering costs = degraded performance, etc.”

Amongst all this huss & fuss, there is one decision that is very crucial and that is what level of data isolation should the SaaS product offer. Yes, the decision does require evaluating multiple factors and does depend upon the intended audience of the product, the costing of the product, the security posture of the product, the industry & domain being catered to, and many other business use-cases. Web and application layers of the infrastructure are shared for serving the traffic to multiple customers that is fine, but what about the data layer? Should we keep the customer’s data isolated at query level? Or at database level? Or for every customer should we have a completely new database server provisioned? That’s a dilemma every SaaS product team faces continuously. There’s no perfect solution but there are lot of flawed ones. To be able to choose the best offering & come up with the most suited solution, one should first have answers to these questions:

How do I choose?

1. Who are the product’s customers?
2. For what they will be using the product for?
3. What data the product stores? What is the criticality of the data?
4. Should the product meet any compliance requirements?
5. What level of data isolation will be feasible given the price of the product that we will be charging the customer for?
6. What level of data isolation can my architecture (and cloud provider) support?

What do I choose?

Answering the above is easy & once you have done that it becomes easier to select a data isolation level. Based on the answers to the above, one can select from the following choices:

1. Data isolation at query level

2. Data isolation at DB table level – row level locking or different tables

3. Data isolation at DB level

4. Data isolation at DB instance level.

Data isolation at query level

In this model of data isolation, data of various customers are stored in the same database and tables but with a tag identifying the customer to which the record belongs to.

Pros of data isolation at query level:

1. Easiest to implement

2. Cost effective

3. Schema changes are easy

Cons data isolation at query level:

1. Lowest level of data isolation

2. Programming errors might expose data of one customer to another

3. Noisy neighbours might slow down the DB for others

Data isolation at table level

In this model of data isolation, data of various customers are still stored in the same database and tables but with row level locking in place to restrict one customer from accessing data of another customer.

Pros of data isolation at table level:

1. More robust isolation as the isolation is being handled by the DB engine

2. Nearly same cost as the previous model

3. Schema changes are easy

Cons of data isolation at table level:

1. DB administration mistakes might expose data of one customer to another

2. Noisy neighbours might slow down the DB for others

3. Complicated to implement that the previous model

4. Not all DB engines support row level locking

Data isolation at DB level

In this model of data isolation, we create new databases for each customer. Each database will have same set of tables, but different users configured.

Pros of data isolation at DB level:

1. Better isolation than the above 2 models

2. Effect of noisy neighbor’s is less pronounced

3. Slightly more cost effectiveness

4. DB can be easily horizontally scaled

Cons of data isolation at DB level:

1. Depending on the use-case, it might get slower to provision new databases for each customer.

2. Much more complicated to implement than the previous 2 models

3. Schema changes are complicated to implement

Data isolation at DB instance level

In this model of data isolation, we provision entirely new database instances for each customer.

Pros of data isolation at DB level:

1. Best level of isolation at data layer

2. No effect of noisy neighbours

3. Data layer can be scaled easily

Cons of data isolation at DB level:

1. Most costly solution

2. Depending on the use-case, it might get slower to provision new databases for each customer.

3. Much more complicated to implement than the first 2 models

4. Schema changes are complicated to implement

Managing multiple databases

Managing and monitoring database instances for your SaaS application can become cumbersome quickly. and add a lot of operational overhead. You need to keep a check on:

1. DB Utilization
2. Backups
3. Cost
4. Managing access to DB

One requires a platform to help you keep a check on all these parameters so that the focus is on your application development and not just managing the DB & cloud activities. The platform should help you with below listed activities:

1. Continuously monitor your databases for common misconfigurations like DB being publicly accessible, backups not being enabled, encryption not being enabled etc.
2. Monitor DB utilization and recommend right-sizing proactively to save cost and improve performance
3. Be able to fix the issues in your DB instance in one click using one-click fix, or create a ticket in your ITSM tool so that your Ops team can take care of it.
4. If you are using infrastructure-as-a-code tools like CloudFormation or Terraform to provision infra (DB instances) for newly onboarded customers, it helps you identify the issues proactively so that it can be fixed beforehand keeping your infrastructure always compliant to your requirements.

Now the question arises do we really have something which can take care of all these activities without impacting performance and a hole in the pocket? And the answer is CloudEnsure, an autonomous cloud governance platform that can actually fulfill the listed demands with ease, one doesn’t have to change the way the application team or organization team is structured or working, neither one has to shell out too much to ensure smooth governance of their DB model. With cloud technology emerging and becoming a must for organizations to adopt, tools like CloudEnsure can definitely help resolve the DB tenancy conundrum along with other added advantages.