SaaS Factory (The Series) — Data Partitioning: Storage Strategies in SaaS (Part 1/3)

In this post, we'll talk about Data Partitioning and Storage Strategies in SaaS.

SaaS storage overview

For software as a service (SaaS) offerings, AWS provides a range of storage solutions, each with its own approach to scoping, provisioning, managing and protecting data. The way each service represents, indexes and stores data adds a unique set of considerations to your multi-tenant strategy. With SaaS, the diversity of these storage options is an opportunity to align your SaaS solution's storage needs with the storage technologies that best fit your business needs.

As you weigh storage options on AWS, you should also consider how your SaaS solution's multi-tenant model fits each storage technology. Just as there are many kinds of storage, there are also many kinds of multi-tenant partitioning strategies. The goal is to find the best intersection between your storage needs and your tenant partitioning needs.

Partitioning models in SaaS

To start, you need a well-defined conceptual model to help you understand the various implementation strategies. The following image shows the three basic models — silo, bridge and pool — that are commonly used when partitioning tenant data in a SaaS environment.

Silo Model

In the silo model, a tenant's data storage is fully isolated from every other tenant. All the constructs used to represent the tenant's data are considered logically “unique” to that customer, which means each tenant will generally have a distinct representation, monitoring, management and security “footprint”.

Bridge Model

The bridge model centralizes all tenant data in a single database, while still allowing some degree of variation and separation for each tenant. Typically, you achieve this by creating separate tables for each tenant and letting each one have its own data representation (schema).

Pool Model

The pool model represents the fully shared, multi-tenant model, in which tenants share all of the system's storage constructs. Tenant data is placed in a common database, and all tenants share a common representation (schema). This approach requires introducing a partition key that is used to scope and control access to tenant data. This model tends to simplify the SaaS solution's provisioning, management and update experience. It also fits well with the continuous delivery and agility goals that are essential for SaaS providers.

It's important to stress that these models are all equally valid. Although we'll discuss the merits of each one, the regulatory, business and legacy dimensions of each specific environment usually play a big role in determining the approach you select. The goal here is simply to bring visibility to the mechanics and trade-offs associated with each approach.

In the next post, we'll continue talking about data partitioning architectures: storage strategies in SaaS.

SaaS Factory (The Series) — How to Build Software as a Service Solutions on AWS

See you then! =)