How to master multi-tenant data management

Multi-tenant data management is an essential part of a systems architecture designed for massive scale. It underpins countless business platforms, from commercial software-as-a-service CRMs to internal corporate data systems. Its popularity stems from its distinctive ability to support tailored services on a shared infrastructure, maximizing resource utilization and operational efficiency for each service (or tenant) while ensuring data isolation and security.

But while undeniably powerful, multi-tenant data management is a demanding approach. It pushes traditional data management to the limit — sometimes beyond. It requires the ability to segregate and handle data across tenants, and the agility to adapt to evolving requirements. It has to deliver operational efficiencies and compliance with data protection regulations, and the ability to scale in response to customer growth and innovation in service delivery. The greater the scale and diversity of the business, the greater these challenges become. 

There are many ways to approach multi-tenant data management. The key is to find the one that matches the needs of your applications. In this article, we’ll explain how to do that. We’ll explore just what multi-tenant data management is, and how best to implement it for different use cases.

What is multi-tenant architecture and why multi-tenant data management?

First, a definition. Multi-tenancy can be described as an architecture pattern in which a single instance of software serves multiple user groups, or tenants. Each tenant’s data and configuration may be isolated while sharing underlying computing resources, such as servers and storage. This approach is prevalent in cloud computing and SaaS applications, allowing providers to deliver services with optimal efficiency.

IDG

The multi-tenant approach provides a multitude of benefits, including:

Workload isolation: Multi-tenancy addresses the problem of the “noisy neighbor,” in which one tenant over-utilizes resources to the detriment of others. By isolating workloads, tenants can operate independently, ensuring the activity of one does not adversely affect others. Segregation is also integral to supporting tiers of tenancy, allowing service providers to provide different levels of performance according to the service-level agrement (SLA) for each tier, ensuring fair resource distribution and adherence to service agreements.

Data privacy and compliance: To avoid costly data breaches, multi-tenancy must be designed with strict data privacy measures in mind. Isolating tenant data and implementing robust access controls ensure compliance with global data protection regulations, providing peace of mind for providers and their customers.

Cost efficiency: By sharing infrastructure and resources, businesses can significantly reduce operational costs.

Simplified maintenance: In multi-tenant environments, updates and maintenance can be centrally applied, reducing the effort and time required to keep the system up-to-date.

Scalability: Multi-tenant architectures are inherently scalable, allowing for the accommodation of an increasing number of tenants without significant changes to the infrastructure.

Multi-tenant architecture is suited to a wide range of use cases:

Software as a service (SaaS): Platforms like Salesforce and Shopify offer customizable services to multiple businesses on a single platform.

Platform as a Service (PaaS): Cloud platforms such as AWS Elastic Beanstalk and Microsoft Azure provide application hosting environments that support multiple users with different application needs.

Internal corporate environments: Large organizations often employ multi-tenant architectures to manage separate divisions or departments under a unified IT infrastructure, facilitating better resource management and cost savings.

Data serving platforms: In scenarios where multiple tenants need to access and interact with the same data sets, a multi-tenant data serving platform can be crucial. This setup ensures that while the underlying data may be shared, access controls and data views are customized and secured based on tenant-specific requirements.

Use cases, requirements, and challenges in multi-tenant data management

Different multi-tenancy use cases present different challenges. Each requires a distinct strategy.

SaaS application

This category includes most business-to-business (B2B) SaaS applications. Here the tenants are external entities which may need different levels of service customization. A good example is Salesforce.com, which serves multiple businesses with their own users and data.

IDG

In this category of multi-tenant data management, the number of tenants can be huge, especially with freemium applications that need to support a large number of free-tier users. To that end, a multi-tenant architecture for SaaS applications should meet the following requirements (including some we encountered in more general form above).

Requirements

Data isolation: To ensure privacy and compliance with data protection regulations, data must be securely isolated between tenants. This is critical for preventing data leaks and breaches and safeguarding sensitive information.

Workload isolation: SaaS platforms must guarantee a certain level of service (SLAs) for each tenant, regardless of the load imposed by others. Workload isolation ensures the activities of one tenant do not adversely affect the others.

Tenant tiers/priorities: Businesses often offer different service tiers, including premium tiers for higher-paying customers and free tiers for those seeking basic services. The architecture must support this differentiation, allowing for varying levels of access, resources, and functionality.

Efficiency and cost: To serve a potentially vast number of tenants, the system must be efficient and cost-effective. The ability to optimize resource utilization without compromising on performance or security is essential to maintaining profitability and service quality.

Additional considerations

Scalability: The system must be inherently scalable, capable of growing with the customer base without requiring a complete overhaul of the infrastructure.

Customization: While the core logic remains consistent across tenants, the system should allow for a degree of customization. This could range from branding and workflow alterations to custom features enabled for specific tiers.

Security and compliance: Beyond data isolation, comprehensive security measures including encryption, access controls, and vulnerability management are paramount for protection against external threats.

Centralized storage platform for multiple applications

In organizations with centralized infrastructure, a multi-application storage platform can serve as a data management backbone, providing a cohesive and efficient solution for internal applications. This kind of platform focuses on performance, reliability and user-friendly interaction, ensuring all applications have consistent and uninterrupted access to storage resources. As organizations grow and their data needs evolve, such platforms become pivotal in supporting scalability and innovation.

Architecture

IDG

Each supported application may have a different data model and different access patterns. The platform will generally employ a single database cluster supporting a logical or virtual database layer. Each application—be it order management, customer relationship management, ads, or business intelligence—interacts with a dedicated logical database. This setup provides a standardized data layer across applications, promoting consistency and reducing the complexity of handling data storage across multiple systems.

To meet the needs of this kind of platform, multi-tenant data management should address the following considerations.

Requirements

Scalable and reliable storage: The system must scale horizontally to manage the growing data volume from all applications, ensuring reliability and uninterrupted service delivery according to the agreed SLA.

Performance: Each application will need the storage service to maintain high performance, with low latency and high throughput, even as demand fluctuates.

SLA management: The infrastructure team must define, monitor, and enforce strict SLAs that dictate the performance and availability standards of the storage service.

Cost efficiency: With the potential for extensive resource utilization, the platform must optimize for cost efficiency without sacrificing quality or performance.

Ease of use: Simplified access and interaction with the storage platform are crucial. Developers from various teams should find the system intuitive, with straightforward processes for provisioning, accessing, and managing data.

Data segregation and access control: The platform must ensure strict data segregation for security and compliance. Access controls must be robust and granular to prevent unauthorized access to sensitive information from different applications.

Additional considerations

Data governance: As the central repository for various applications, the storage platform must adhere to data governance policies, ensuring data integrity, quality, and regulatory compliance.

Backup and recovery: A robust backup and disaster recovery strategy is essential, providing guarantees against data loss and enabling quick restoration of services in case of an outage.

Customization and extensibility: Similar to what we saw in the SaaS application use case, the platform should offer customization options that cater to specific application needs, including support for various data types and structures.

Monitoring and optimization: Continuous monitoring for operational health and performance optimization is necessary to maintain the platform’s efficiency and to preemptively address potential issues.

Operational data store

An operational data store, often described as a data-as-a-service (DaaS) model, centralizes data storage and consolidates data from myriad sources, providing a single point of access for different applications. This type of architecture is critical for applications that provide a comprehensive view of data from different domains, such as a “customer 360” application, which amalgamates customer information from CRM, order management, support systems, and more.

Architecture

IDG

This architecture is typically composed of three main components: data sources, a central operational data store (ODS), and data consumers. Data from CRM, ERP, SCM, and other systems is consolidated into the ODS using extract, transform, and load (ETL) processes or change data capture (CDC) methods, where it becomes accessible for queries and analytics by various data consumer applications.

Requirements

Data integration and quality: Effective ETL/CDC processes are essential for integrating data from disparate sources while ensuring its quality and consistency.

Consolidation and transformation: The central data store must efficiently consolidate and transform data, ensuring it’s in the right format and structure for consumption by various applications.

Low-latency access: Applications such as real-time dashboards require immediate access to data, necessitating a low-latency system that can quickly process and serve data requests.

Robust query performance: With multiple consumers accessing the platform — often with complex queries — the system needs to maintain high-performance levels without imposing bottlenecks.

Data security and privacy: The centralized nature of the platform means it must have stringent security measures and privacy controls to protect sensitive data and comply with regulations.

Scalable and reliable infrastructure: As the central hub for organizational data, the infrastructure must be scalable to handle growing data volumes and resilient to ensure constant availability.

Additional considerations

Data governance: There should be clear policies and procedures in place to manage the data life cycle, ensuring accountability and regulatory compliance.

Advanced analytics: The platform should be capable of supporting advanced analytics and business intelligence (BI) applications, providing valuable insights across the organization.

Customizable access patterns: Different applications may require different access patterns; hence, the platform should be flexible to accommodate these variations.

Monitoring and alerts: The system should include comprehensive monitoring capabilities to detect and respond to issues promptly, ensuring system health and data integrity.

Multi-tenant application design patterns

Use caseTenant typeTenant countRequirementsChallengesSaaS applicationExternal tenantThousands to hundreds of thousandsManage a huge number of customer/user data with scalability, multi-tenant isolation and protection, SLA compliance, and agility1. Huge tenant count 2. Tenant Isolation 3. Total cost 4. Schema changes 5. Availability 6. Scalability of large number of (usually large) tenantsCentralized storage platformInternal tenantTens to hundredManage a massive number of database instances in a safe and cost-efficient way. This is database consolidation. 1. Scalability for large services 2. Reliability for critical services 3. Cost efficiency for large numbers of small/non-critical services 4. Maintenance cost of the database platformOperational data storeMultiple tenants share the same data set. Must isolate write/ingestion and read workloads and read workloads from different tenants  1. Scalability 2. Flexibility in querying data 3. Ingestion speed and the impact to read 4. Handling complex queries against a large data set 5. Isolation between the services1. Scalability 2. Flexibility in querying data 3. Ingestion speed and the impact to read 4. Handling complex queries against a large data set 5. Isolation between the services

Multi-tenant data management design patterns

Now that we’ve outlined the main use cases for multi-tenancy, we can explore architectural designs that meet different needs.

Share-nothing deployment model

In a share-nothing architecture, each tenants data and services operate independently, completely isolated from others. This pattern is akin to having separate instances of the application for each tenant, with no shared components between them.

IDG

Characteristics and advantages

Isolation: Offers the highest level of data privacy and operational isolation between tenants.

Customization: Easy to customize the application at the tenant level without affecting others.

Scalability: Simple to scale horizontally by adding more instances to accommodate new tenants.

Maintenance: Upgrades or maintenance can be performed per tenant, minimizing the risk of widespread impact.

Challenges

Resource utilization: Can lead to underutilized resources, as each tenant is allocated dedicated resources.

Cost: Typically the most expensive option due to the lack of shared resources.

Operational overhead: Managing multiple separate instances can be complex and time-consuming.

Share-everything deployment model

In contrast with the share-nothing architecture, a share-everything architecture uses a single, multi-tenant database and application instance for all tenants, pooling all resources and components.

In this model, as its name suggests, tenants share all resources, including the physical environment, logical database schemas, and tables. Share-everything is easier to scale when adding a new tenant, as the infrastructure does not need to change. However, customization of any tenant will affect the rest, and performance will be affected by noisy neighbors.

IDG

Characteristics and advantages

Efficiency: Highly efficient resource utilization, as all tenants share the same infrastructure and application.

Cost-effectiveness: Can be more cost-effective due to economies of scale.

Simplified management: Centralized management for updates, maintenance, and scaling operations.

Challenges

Data isolation: More complex to achieve strict data isolation and may pose higher security and privacy risks.

Performance: Potential performance bottlenecks if not managed carefully, as one tenant’s load can impact others.

Customization: Less flexibility for tenant-specific customizations at the infrastructure level.

Hybrid deployment model

Most SaaS applications use a hybrid model in which large tenants are provided dedicated environments and smaller tenants share instances.

If certain tenants start to disproportionately consume resources, the hybrid model might be the solution. In this model, larger tenants can customize their application and database schema as they see fit, while smaller tenants share more resources in common. The noisy neighbors are physically isolated, and onboarding a new tenant is simple and straightforward.

IDG

The hybrid model combines elements of share-nothing and shared-everything architectures, aiming to balance isolation with efficiency.

Characteristics and advantages

Flexibility: Can decide which components to share and which to isolate, allowing for a balanced approach.

Customizability with efficiency: Offers the possibility of tenant-specific customizations while maintaining resource efficiency.

Scalable and adaptable: Scales based on tenant needs and allows for a more adaptive resource management approach.

Challenges

Complexity: Managing a hybrid system can be complex, requiring careful planning and execution to ensure the correct balance between shared and isolated resources.

Consistency: Maintaining consistent performance across tenants can be challenging due to the varied sharing configurations.

Getting multi-tenant data management right

As we’ve seen, multi-tenant data management encompasses many different approaches, each with its own benefits and trade-offs. Similarly, it can be implemented with a wide range of data solutions, as long as the solution meets the needs of your use case, as described above.

That said, it’s important to note that multi-tenant data management is a demanding design pattern. It really wants high performance, reliability, and scalability. It doesn’t do well with “pick two.”  For that reason, distributed SQL solutions like TiDB are often chosen for this purpose, as they provide strong operational efficiency and the ability to scale out as needed.

The key to success here is the close alignment of design, use case, and underlying technology. The tolerances are slim. There’s not a lot of room for error. But when you get it right — and with a bit of planning, you absolutely can — multi-tenant data management can help you do things no other design pattern can.

Li Shen is senior vice president at PingCAP, the company behind TiDB.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.