Comparing Models for Data Security in Multi-Tenant Analytics

The SaaS revolution has brought numerous advantages in serving end-user reach and flexibility. However, by the inherent nature of its shared environment, it presents challenges to implementing effective data security.

The biggest hurdle to self-service analytics is multi-tenant data security. Your users want more than one-size-fits-all reports. Your product team wants to give it to them.

Your engineering team often stands in the way when they realize just how much they need to build. After all, they know better than any that multi-tenant architectures can be complicated.

Our CTO David Abramson dives into this topic in his latest episode of our series Building Better SaaS which you can watch here.

We typically see companies attempt this on their own in one of three ways we’ll discuss here.

The Three Common Methods for Multi-Tenant Data Security

Isolated Tenant Model

An isolated tenant model involves separate, independent databases and/or hardware environments that store the data. This creates many databases to manage for multi-tenancy.

Pros:

• Easier to comply with legal and contractual requirements rather than technical ones.
• Provides a cleaner path for security logic and encryption mandates from industries or certification stipulations.
• These factors make an isolated tenant model attractive, as it makes implementing strict security a straightforward exercise.

Cons:

• Costs will be higher as each tenant in this model requires a separate database instance for data isolation.
• Ensuring performance can also increase the cost burden as scaling requirements increase.
• Much higher maintenance from engineering. You will have to manage and maintain your analytics functions separately.
• Custom fields per tenant are next to impossible to implement within analytics tools.

Best Use Cases:

• Smaller deployments, on the scale of perhaps tens of clients, where the costs still fall within manageable limits. The reporting capabilities are typically limited with this approach.

Isolated Data Model

An isolated data model leverages the same database but utilizes separate objects or table structures. This model organizes tenant data by giving each tenant their own tables and objects in the same database.

Pros:

• It improves cost efficiency by allowing you to better leverage shared infrastructure.
• Scaling, maintenance, and tenant mapping to multiple tenants are easier to implement.

Cons:

• Offering custom fields is more difficult because the analytics data model must be the same for everyone.
• Forces one-size-fits-all reporting in the SaaS application.
• Harder to collect comprehensive product usage data.

Best Use Cases:

• Typically for implementations of perhaps hundreds of users, where the costs fall within acceptable limits.
• Looking to start scaling an analytics environment with a platform that is starting to grow.

Commingled Model

A commingled model stores tenant data in the same database structure and environment. This model represents a preferred paradigm for implementing multi-tenant analytics. The data resides within the same structure. The fields and records include tenant IDs and/or qualifiers like roles, customer types, etc.

Pros:

• Embedded analytics setup and maintenance are much easier.
• Provides more flexibility in determining data security mapping to user roles.
• This is also the most scalable of all the models for analyzing data.
• Software providers can easily gather and compare product usage data, This is useful for benchmarking across geographies or industries. SaaS companies can in turn offer useful insight into product improvement for complex use cases.

Cons:

• Many of the more stringent security requirements can still be a challenge. Understanding that a semantic layer manages user entitlements is important. This layer is a logical layer that engineering teams must build themselves.

Best Use Cases:

• Better for large SaaS platforms managing thousands of tenants and users in multi-tenant environments.

Examples of Data Breaches

We all know how important data security is today. Using one of these models gives you a path to building a multi-tenant analytics solution on your own. But just how valuable is it?

Data breaches are expensive and here are the top ten data breaches. This list includes their associated fines from CSO Online to show the value of data security:

1. Didi Global: $1.19 billion
2. Amazon: $877 million
3. Equifax: $575 Million+
4. Instagram: $403 million
5. TikTok: $370 million
6. T-Mobile: $350 million
7. Meta: $277 million
8. WhatsApp: $255 million
9. Home Depot: ~$200 million
10. Capital One: $190 million

Qrvey’s Approach to Data Security for Multi-Tenant Analytics

Our goal for Qrvey is to have SaaS teams build less software and deliver more value to customers. We see engineering teams struggle to build and maintain everything between their data warehouse and front-end dashboards. Or worst case, they try to force an embedded BI software into a SaaS application and call it an analytics platform.

Qrvey’s approach to solving this problem is an embedded analytics solution that includes the components engineering teams must build. These include:

• A data lake built on ElasticSearch that scales to billions of records in a single dataset
• A unified data pipeline to simplify the ingestion and transformation of data for analytics
• A semantic layer that makes it easy to map tenant and user access controls to analytics data
• And a suite of APIs to integrate everything into the SaaS environment and platform

All of this backs an intuitive suite of embedded components for reporting and self-service dashboard creation.

To see Qrvey in action, here’s a 5 minute demo video or speak with an expert from our team.