SaaS: degrees of multi-tenancy

Phil Wainewright has a good discussion on the various architectures underlying today's software-as-a-service (SaaS) products, such as Salesforce.com.

I've commented in the past regarding the superiority of a multi-tenant architecture (many customers supported on a single hosted system instance) versus the tradition single-tenant architecture (a separate hosted system instance for each customer). Salesforce.com is an example of a SaaS provider building on a multi-tenant architecture, whereas Oracle's On-Demand offering of its E-Business Suite is an example of a single-tenant architecture. The economics of the multi-tenant architecture are so much more attractive in that each new customer involves minimal marginal cost to the provider, allowing the provider to offer attractive pricing.

Except for protestations by the single-tenant providers, there is little debate about the superiority of the multi-tenant model. Wainewright, however, points out that there are in fact different flavors of the multi-tenant architecture. He lists three main variations:

• First-degree multi-tenancy (e.g. Salesforce.com). Here, "all customers are served from a single infrastructure in which every component is shared, all the way down to the tables in the database" This purist approach is often called "shared schema multi-tenancy because the database structure is defined by the schema and if everyone’s data is stored inside that structure then by definition, everyone is sharing the same schema."

• Second-degree multi-tenancy (e.g. Intacct, a financial systems SaaS provider). This approach is similar to first-degree, but it "uses replication much more broadly than Salesforce.com to distribute its shared-schema instances across large numbers of server clusters." A key advantage of this approach is that it can use low-cost hardware (e.g. Linux on Intel) rather than large Unix or Linux servers with massive databases. It also allows customers to operate on different versions of the system, based on which cluster thay reside upon, giving some flexibility on when they upgrade to newer versions.

• Lesser-degree multi-tenancy (e.g. Oracle, and others). There are many variations of this type, with the shared services primarily involving shared server infrastructure. Each customer has a separate database instance. This approach provides maximum flexibility to the customer but gives up much of the scalability and economic advantages of multi-tenancy. It appears that SAP's greenfield SaaS offering for small business, Business ByDesign, is taking this approach.

Debates about the advantages and disadvantages of the first versus second degree multi-tenancy approach are a bit too much "inside baseball" for most buyers. Selection of an architecture, in my opinion, should be driven by the requirements of the application. I can see where a high volume, small footprint, departmental application might benefit from the first-degree approach, where the economies of scale drive down the price per user, allowing the app to reach a larger number of users. I can also see where a larger, more complex application might be deployed more cost effectively, and with greater flexibility, using the second-degree approach. And applications requiring the greatest flexibility for the customer might be driven to the third category, though, as I pointed out, this approach loses much of the economic rationale of the first two.

Read Wainewright's entire post for a fuller discussion.

Update: Wainewright has a follow-up post where he refines his definitions and provides additional insights on Intacct's architecture. If SaaS platform decisions are important to you, you should read Wainewright's follow-up post.

Related posts
Workday: evidence of SaaS adoption by large firms
Cloud computing: can Microsoft turn from servers to services?
All not sweet with NetSuite
Computer Economics: The Business Case for Software as a Service
Dell acquires SaaS platform Everdream