SaaS Databases: The Future of Cloud Data Management

Definition

A tenant is a group of people or organizations that share the same database. Multi-tenancy is a single application that serves multiple customers or tenants.

Well-known examples of this architecture include Azure SQL Database, Amazon Web Services (AWS), and Google Cloud Platform (GCP).

Components of Multi-Tenancy Architecture

To work effectively, multi-tenancy entails a number of crucial components:

• Shared Resources: Sharing resources is the core of this architecture. Tenants share databases, applications, and infrastructures.
• Data Isolation: Even though the software hosts multiple tenants, the tenant’s data should be kept both secure and separate. This is achieved via database schema or multi-instance architecture.
• Centralized Management: Any software updates and patches only need to be done once, and it will be available to everyone.
• Scalability: This model is built to be scalable - new tenants can be added to the application without much impact on the overall structure.
• Customization: Despite sharing the same resources, tenants can customize their space to a certain degree to meet their specific needs and business model.

Tenant Table

• TenantID (Primary Key): Unique tenant identifier
• Tenant name and domain: Specific information regarding the tenant, like domain or organization name
• SubscriptionPlan: Information on the subscription plan and data limits.
• StorageQuota: Storage quota for each tenant.

User Table

• UserId (Primary Key): Unique user identifier
• Username, email: User’s login credentials and information
• TenantID: Tenant’s unique identifier linked to the user.
• Role: A user’s position or set of rights within a SaaS program.

Table of Configurations

• The primary key, or ConfigID, is a special designation for every configuration option.
• SettingName, SettingValue: Per tenant configurable settings and options.

Shared Database, Shared Schema

In this pattern, just as its name suggests, all tenants share the same database and database schema. It is often easy to set up and simple to manage.

• Resource Optimization: This is the highest level of resource optimization, and every tenant shares the same storage resources and server.
• Uniformity: The same storage resource and server means the data structure is the same, making maintenance and updating easy.
• Data Isolation: Data is kept separate for each tenant by using unique tenant identifiers within the database. These identifiers are typically included in the primary key of sharded tables (a table divided into manageable pieces), ensuring that each tenant’s data remains distinct and secure.
• Cost-Effectiveness: The most cost-effective design pattern due to its high degree of sharing. It is easily scalable as new tenants added don’t affect the data structure.
• Potential drawbacks: Poor data isolation may lead to security issues. Also, customization is limited, as one configuration can easily affect the rest. Performance might become a problem.
• This pattern is suitable for you when:
  • The number of tenants is small.
  • Similar data structure and security requirements.
  • Priorities are resource efficiency and simplicity.

Shared Database, Separate Schemas

This pattern is a slight upgrade from the previous pattern. While still sharing the same database, each tenant has their own schema. Data isolation is improved as each tenant has a unique schema structure.

• Improved data isolation and customization: Each tenant’s database structure is kept separately with a higher level of customization.
• Balance: This pattern strikes a balance between resource sharing and the ability to cater to different tenant’s needs.
• Potential drawbacks: The need to maintain multiple schemas increases the complexity.
• This pattern is suitable for you when:
  • Tenants have diverse data structures and security needs.
  • Priorities lie in tenant isolation and customization.
  • Resource efficiency and simplicity aren’t emphasized as much.

Separate Databases

This is the highest level of tenant isolation. Every tenant has a completely separate and dedicated database.

• Maximum flexibility: tenants have the highest degree of freedom to design and customize their data schema and how they choose to manage data.
• Independent scaling: Maxim isolation allows tenants to scale separately and have more freedom in resource allocation.
• Maintenance: Updates and maintenance can be performed per tenant, preventing potential widespread risks.
• Potential drawbacks: Typically, more expensive and the management is often more complex with potentially underutilized resources. StormForge found that an average of 47% of cloud resources are being squandered by organizations.
• This pattern is suitable for you when:
  • You have a small number of tenants, but the data sensitivity and highland security demands are unique.
  • Priorities are data isolation and security.

Hybrid Approach

This data model is a mixed approach of the shared database and a separate database approach. Most SaaS companies choose this hybrid design pattern where larger organizations get their dedicated database while smaller tenants share their resources.

• Flexible: The Saas application can meet everyone’s needs. While one tenant has a dedicated database and schema to customize and enjoy full data isolation, other smaller tenants share more commonalities.
• Scalability and Adaptability: Every tenant’s scaling meets are met, with resources allocated dynamically.
• Potential Drawbacks: Management of shared and shared databases is complex, so it needs to be planned carefully to balance both.
• Maintaining consistent performance can be challenging.
• This pattern is suitable for you when you have tenants with diverse database needs.