Two Schools of Thought on Scaling B2B SaaS App Data

Scaling the data storage for B2B Software-as-a-Service (SaaS) applications typically falls under two schools of thought: one or more fully-contained accounts per database or specialized multi-tenant sub-systems that handle certain types of data. There are pros and cons to each approach.

Fully-Contained Accounts

B2B apps are often simpler than B2C apps when it comes to data storage. In a B2B app, one account/user doesn’t need to know about another, whereas in a B2C app accounts/users have to have a global context for all other accounts/users (think Facebook Friend requests). Fully-contained accounts can be on individual databases or multi-tenant such that one or more accounts are on the same database delineated by an account ID.

One analogy I like to use is housing for people. A fully-contained account on a private database is a like a single family home. Multiple fully-contained accounts on one database is like one building in an apartment complex where everyone gets their own space but there are greater economies of scale having everyone together.

Challenges for fully-contained accounts in a multi-tenant environment arise when the size of the accounts start changing and growing at different rates. Back to the apartment complex example, one family wants a home gym and decides they want a new bedroom for it, only all the other three bedroom apartments in the complex are full. What does the family do? Well if the family can afford it the tendency is to go to a single family home that is suited uniquely to them.

A single family home is much more expensive to maintain, on a per family basis, compared to a building in an apartment complex. Services like landscaping, security, and amenities like a gym or pool are much more affordable when spread out over dozens or hundreds of people. A single family home can have all those accoutrements but the cost structure is no where near the same.

Specialized Sub-Systems

Now, assume some accounts in the multi-tenant fully-contained database approach grow so large that they need their own dedicated database. With the housing analogy, larger families start moving to single family homes from the building in an apartment complex. Assume the apartment complex didn’t have a pool — the app didn’t have that feature yet. Now, the startup decides a new feature is needed — the equivalent of a pool — and adds it to the application. The pool is manageable in the apartment complex that houses 100 families with the cost of chemical treatments, cleaning, etc spread out over a large number of users. For the single family homes that were created by the accounts that got too large, each now has a pool by the nature of SaaS applications having a single code base for all customers, and those pools all need to be managed. Going from pool to pool, even with automated tools and help, becomes less efficient and more costly to do chemical treatments, cleaning, etc.

Specialized storage and application sub-systems are designed to solve this problem. Think of a simple survey application. The info for the accounts, users, billing, survey questions, and more are pretty simple and not storage intensive. What is storage intensive is keeping track of all the survey responses and survey respondents. That information is going to grow exponentially compared to the core account data. It deserves a dedicated sub-system.

Now, back to the housing analogy. Instead of families desiring a home gym moving to single family homes, the apartment complex introduces new buildings in the same complex, only the different buildings serve specific functions like a gym with an indoor pool, parking deck, and storage units for for each family. The individual features and storage needs get dedicated attention such that the regular gym with pool can grow into a 100,000 square foot facility with Olympic-size pool, and all the families can stay put in the apartment building that’s part of the same complex. Areas that change disproportionately can get the necessary attention without affecting other aspects of the application.

Conclusion

When starting out, fully-contained accounts is easier to implement and doesn’t require much overhead, making it the right choice for young B2B SaaS apps. If data grows linearly and everything is tightly related, keep it simple with fully-contained accounts. As the application grows, and certain types of data grow disproportionately faster than others, specialized sub-systems scale better and in a more cost-effective manner, making them the right choice for mature, data-intensive B2B SaaS apps.

What else? What are your thoughts on these two schools of thought for scaling B2B SaaS app data?

2 thoughts on “Two Schools of Thought on Scaling B2B SaaS App Data

  1. Hi David,

    All-in-all another insightful post, but I do need to challenge you on the assumptions held in one of your assertions:


    B2B apps are often simpler than B2C apps when it comes to data storage. In a B2B app, one account/user doesn’t need to know about another, whereas in a B2C app accounts/users have to have a global context for all other accounts/users (think Facebook Friend requests). Fully-contained accounts can be on individual databases or multi-tenant such that one or more accounts are on the same database delineated by an account ID.

    I think that’s a convenient view for the B2B app provider who would like to think things can be easier, but I don’t think it’s true at all, especially as of 2012. I think believing a B2B’s needs a walled-garden account is harmful to both the SaaS vendor and their customers.

    Right now I’m running into issues with a SaaS provider that provides a service our team absolutely loves but they took the above advice to heart (or just didn’t think about doing it differently) and they’ve created accounts that can’t cross users which makes it very difficult for a user to participate in two different accounts (I’m speaking of HipChat.)

    Today it’s possible to “employ” many part timer freelancers who will work for many different companies at many different times. If you implement your accounts as individual databases then a freelancer working with three (3) companies will have to maintain three different logins and will constantly make mistakes by using the wrong account at the wrong time.

    But what’s worse than making the freelancers life difficult freelancers will likely not recommend your solution to another client because they know if they do they’ll have to deal with the troubles of managing multiple logins. And they’ll avoid recommending even if they know your solution offers great value (except for when they are being hired explicitly to select a SaaS.) Scale that up to agencies and consulting firms and they too would avoid recommending a service to their clients they know would help simply because it will make their lives more difficult. And I’d call that “reverse viral”, probably not the effect you’d want to encourage.

    This is especially troublesome because IMO the reason most people don’t sign up for a specific SaaS is they think it won’t give them a reasonable return on their time invested. If you’ve got users who’ve used the system that can attest to its value and who would otherwise proactively champion adoption you’ve got a free outside sales force waiting to happen. But by thinking of each account as a walled garden you will be placing a disincentive ahead of that behavior.

    And lastly, by not implementing B2B systems using a global context you forgo any potential business intelligence from the business social graph. And you’ll simply never be able to implement related functionality if you create those account silos. Loss-loss-loss in my book.

    Or, at least that’s how I see it. 🙂

    • Thanks for the great comment! That’s an interesting use case and I agree that users need to be outside the self-contained account. For us, we have shards that contain multiple accounts and then a “global” database that has users in it so that they can be shared across accounts.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.