Many degrees of multi-tenancy

Many degrees of multi-tenancy

Summary: In SaaS circles, suggesting that a vendor's architecture is anything less than fully multi-tenant is tantamount to questioning a man's virility or impugning an American's patriotism.


For SaaS purists, multi-tenancy — the architectural model that allows them to serve multiple customers from a single shared instance of the application — is an article of faith, the one thing that marks them as a tribe apart from traditional software vendors. Suggesting that they're anything other than fully multi-tenant, then, is tantamount to questioning a man's virility or impugning an American's patriotism. It's not the done thing.

Oracle director of platform products Milan ThanawalaPerhaps, therefore, Milan Thanawala (pictured), director of platform products at Oracle, might have chosen his words a little more carefully in a panel session last week at the SIIA OnDemand Europe conference in Amsterdam [disclosure: I was a keynote speaker at the conference and participate in agenda planning for the SIIA's SaaS events. I spoke — for a fee — at an Oracle event in January, and, mentioned below, is also a client].

In the midst of a discussion of security, Thanawala made a passing comment that multi-tenancy isn't a prerequisite for SaaS. Panel chair Bill McNee, CEO of analyst group Saugatuck Technology, immediately challenged this assertion with his own observation that multi-tenancy was fundamantal to SaaS. Now under pressure to defend his position, the Oracle spokesman responded that SaaS ISVs in Oracle's partner network employ a range of different architectures. He went on to cite Intacct in support of his case, saying that the on-demand financials vendor runs its customers on separate pods, each with its own separate Oracle database.

It was a fateful example to choose. Incarnating every conference speaker's worst nightmare, up stepped conference organizer David Thomas, executive director of the SIIA's software division, taking a microphone to flatly contradict Thanawala: "I'm the former CEO of Intacct and I can tell you for a fact that's not the case. Intacct's architecture is completely multi-tenant," he said.

Having participated in a webinar only the previous month with Intacct's CTO Aaron Harris, Thanawala was disconcerted by Thomas' intervention but held his ground — as did Thomas. In the coffee break afterwards, the two of them could be seen locked in discussion as they sought to settle their differences.

The simple explanation for Thanawala's discomfort is that there are many degrees of multi-tenancy, whereas he was using the term solely in its purest sense, as implemented by Intacct's model — espoused by many leading SaaS vendors including NetSuite — is equally valid (although not in's eyes). There are lesser-degree variations below these purist implementations. Here's a rundown of the main differences between the model, the Intacct model and Oracle's own preferred 'pod' approach: First-degree multi-tenancy. In this model, 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 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. In an ideal world, a first-degree multi-tenant architecture runs on a single logical system or instance. But in the real world, when you get to the size of, not even Oracle can offer you a database that's capable of scaling that big. So replicates its architecture across (currently) five instances in North America, plus separate instances in Europe and Asia.

Intacct: Second-degree multi-tenancy. Like many SaaS pureplays, Intacct uses replication much more broadly than to distribute its shared-schema instances across large numbers of server clusters. This means it can use commodity hardware rather than big-iron systems, and has less exposure to a single system failure, while still remaining true to the shared-schema model. Within each Intacct cluster, a single Oracle database instance serves a shared schema to a minimum of 10 customers. The main difference from the model is one of scale: operates just eight instances (for more than 43,000 customers, a ratio of 1:5000) whereas Intacct operates a hundred or so ten (for around 2,500 clients, a ratio of 1:250). But there's another critical difference that purists see as a major dilution of the multi-tenant principle: Intacct allows customers to choose when they upgrade between releases (within a three-month time window), whereas upgrades everyone simultaneously at a time of its own choosing. [UPDATE added June 18th: I have since learnt that this is wrong. Intacct upgrades all its customers at the same time, so is closer to the model than I'd realized — see Why multi-tenancy matters.]

Oracle and others: Lesser-degree multi-tenancy. There are a lot of terms floating around for these lower levels of multi-tenancy, including isolated tenancy, mega-tenancy or hybrid tenancy. Many purists will be scandalized that I even continue to use the term multi-tenancy for this type of implementation. There are many variations, but the primary characteristic is the abandonment of the shared-schema principle. There's still some element of shared-server infrastructure, but each server cluster (Oracle calls them 'pods') is configured somewhat differently from the next. Although this makes it easier to fine-tune each pod to different customer needs using conventional customization processes, it adds immense complexity when co-ordinating the roll-out of new software releases — as SAP recently discovered with its Business ByDesign project.

It's not only the upgrade process that benefits from the consolidation achievable at the massive scale delivered by's top-degree multi-tenancy model. It makes it far less complex to monitor application performance and thus to hone aspects such as security, availability, response times and other service quality characteristics. It's also much easier to collect aggregate data about customer behavior and to establish benchmarks for best practice. Finally, integration is simpler to shared back-end infrastructure, such as identity management systems, APIs and interfaces to third-party services. The more clusters a vendor has, and the more variation between clusters, then the more middleware and management software it will have to buy.

Perhaps that's why Oracle likes to promote the multiple pod model — especially at lesser degrees of shared tenancy, where the management and oversight challenges expand exponentially — Oracle not only gets to sell lots of database licenses, but also lots of different technology infrastructure product licenses as well.

Purists argue that, even if in principle you're prepared to pay the cost of managing multiple implementations, there comes a point at which there are so many variables it's simply not technically feasible to deliver the same degree of oversight they're achieving with large-scale shared-schema instances. In the long run that means their performance, security and reliability will just pull so far in front of their competitors that their model will triumph.

A much larger number of SaaS vendors prefer the slightly more hybrid model pursued by Intacct, either to take advantage of commodity hardware or to allow a degree of customer flexibility when implementing upgrades (which is more of an issue for transactional applications like financials than it is for data management applications such as salesforce automation). [UPDATE: for more on this, see the follow-up post, Why multi-tenancy matters.]

Both camps, however, agree on the principle of shared schema. Their differences of opinion are around implementation of shared-schema multi-tenancy. Any lesser form of multi-tenancy — such as, for example, having shared application servers but housing each customer's data in separately customizable database instances — is a quite different architecture. Be warned: in the SaaS world, pretending or assuming otherwise may cause offense.

Topics: Cloud, Emerging Tech, Enterprise Software, Oracle

Phil Wainewright

About Phil Wainewright

Since 1998, Phil Wainewright has been a thought leader in cloud computing as a blogger, analyst and consultant.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Good points, what many people miss is ...

    The cost of the more expensive hardware required to run fewer "clusters" far offsets the added licensing costs, management software costs, and people costs of running many varied smaller configurations. Think TCO, not hardware cost.
    Basic Logic
  • RE: Many degrees of multi-tenancy

    I believe both of these models have their applications in real world. After all, customer requirements are of perennial importance. In my experience, for (some of ) very large customer upgrade flexibility and extensions are more important than cost , and they don't mind paying extra $$ for the increased flexibility, especially in Finance and SCM portfolios. However, low cost and operational efficiencies are important for small-mid size customers.
  • RE: Many degrees of multi-tenancy

    I am so glad we are talking about this issue - finally! This issue (Multi-tenancy or MT) is the core factor that differentiates the SaaS model from the ASP models.

    Oracle's hosting itself is just ASP on juice - zero MT at the Apps and DB levels. And this is perhaps where I disagree with your third level of MT as well. Oracle has dedicated servers for their customers - not shared as you mentioned it. (And please - virtualization does not count as MT - as some will make us believe).

    For ISVs, of course there is a level of incentive to sell their DB and Apps licenses first and hence yet another differentiator between SaaS and ASP models - ISVs, like Oracle, sell their DB and Apps licenses first and hosting second. Two separate agreements!

    SaaS models, on the other hand - whether you talk about Salesforce or Intacct - include true MT and DB/Apps licenses in one rolled up price.

    Now I am not saying that Oracle (or other ISVs like them) cannot "SaaS" themselves, but there doesn't exist a SaaS revenue model today that can match, leave alone surpass, the revenues generated through selling DB and Apps licenses.

    So finally coming to Mr Thanawala's assertion that SaaS models do not need to be MT - this probably comes from his experiences at Oracle where the mantra has been to call their hosting model you guessed it, "SaaS". Oracle believes that to be a SaaS provider one doesn't have to be MT nor do you have to bundle the DB and Apps licenses into the price. This is a blunder and hence my opinion - Oracle hosting is just ASP on juice!
  • RE: Many degrees of multi-tenancy

    multitenancy is related with reducing hard cost and mantenance cost but if you can obtain a competitive price it doesn?t matter multitenancy grade. The most important thing is offer software AS A SERVICE

    PD Phill, how you get it to enter in wiki? I am trying to enter in Spanish wiki and they don?t allow me because a blog is a personal opinion. ??????
    Thank you
    • RE: Many degrees of multi-tenancy

      @enhasmen [url=]SWF Converter Mac[/url]
      [url=]SWF to Video Converter Mac[/url]
      [url=]SWF to MP3 Converter Mac[/url]
      [url=]SWF to MP4 Converter Mac[/url]
      [url=]SWF to MOV Converter Mac[/url]
      [url=]SWF to AVI Converter Mac[/url]
      [url=]SWF to FLV Converter Mac[/url]
      [url=]SWF to MPEG Converter Mac[/url]
      [url=]SWF to WMV Converter Mac[/url]
      [url=]SWF to GIF Converter Mac[/url]
      [url=]SWF to DVD Converter Mac[/url]
      [url=]SWF to 3GP Converter Mac[/url]
      [url=]Video to SWF Converter Mac[/url]
      [url=]MP3 to SWF Converter Mac[/url]
      [url=]AVI to SWF Converter Mac[/url]
      [url=]FLV to SWF Converter Mac[/url]
      [url=]MOV to SWF Converter Mac[/url]
      [url=]GIF to SWF Converter Mac[/url]
      [url=]VOB to SWF Converter Mac[/url]
      [url=]VOB to SWF Converter Mac[/url]
  • RE: Many degrees of multi-tenancy

    Thank you for bringing this discussion to the forefront. As you have rightly pointed out, there are pros & cons to each approach with their varying degrees of multi-tenancy.

    Oracle has a large number of ISV partners that are looking to SaaS as an additional revenue stream without giving up their traditional license revenue model. These ISV's are not pureplay SaaS ISV's & probably never will be. A number of these cannot afford to rewrite or redesign their application completely.

    When designing the right architectural approach for your SaaS offering, Which degree of multi-tenancy is right for you depends on the cost of re-writing or updating your software, cost of technology, cost of maintenance & support of the infrastructure, along with your customer needs.

    To say that "Oracle likes to promote the multiple pod model ? especially at lesser degrees of shared tenancy" is to not be fair to Oracle or to its large customer & partner base. Oracle has a large number of partners that offer SaaS in every tenancy model possible (including the companies you menioned). The approach that makes sense for one may not make sense for the other. Each would-be SaaS company has to look at their needs and decide on the right approach for them. Oracle is agnostic and wants to educate their partners and make sure they understand the pros & cons with each approach.

    As seen by various SaaS implementations, Oracle technology works in any tenancy model. Oracle wants partners and customers to be successful regardless of the approach they undertake.
  • RE: Many degrees of multi-tenancy

    "The simple explanation for Thanawala???s discomfort is that there are many degrees of multi-tenancy, whereas he was using the term solely in its purest sense, as implemented by" - that's not true. Saleforce has multiple instances and some SI's are running their own data center instances.
    • RE: Many degrees of multi-tenancy

      @dahowlett@... [url=]YouTube Converter Mac[/url]
      [url=]YouTube to AVI for Mac [/url]
      [url=]YouTube to iPod for Mac [/url]
      [url=]YouTube to MP4 for Mac [/url]
      [url=]YouTube to iPhone for Mac[/url]
      [url=]YouTube to Apple TV Mac[/url]
      [url=]YouTube to PSP for Mac[/url]
      [url=]YouTube to PS3 for Mac[/url]
      [url=]YouTube to M4V for Mac[/url]
      [url=]YouTube to MOV for Mac[/url]
      [url=]YouTube to 3GP for Mac[/url]
      [url=]YouTube to ASF for Mac [/url]
      [url=]YouTube to MPEG for Mac[/url]
      [url=]YouTube to M4A for Mac[/url]
      [url=]YouTube to AAC for Mac[/url]
      [url=]YouTube to MP3 for Mac[/url]
      [url=]YouTube to WAV for Mac[/url]
      [url=]YouTube to OGG for Mac[/url]
  • Why pure multi-tenant SaaS matters

    The reason "purists" argue for pure multi-tenancy is that it takes effort to maintain multiple versions, run multiple infrastructures, maintain customer-specific code, and perform upgrades. Fake-SaaS providers multiply their development and maintenance efforts across multiple versions/infrastructures/customizations/upgrades, greatly reducing their capacity to add more functional value to their solution.

    Over time, a provider's extra effort spent on maintenance translates into two things that customers care a lot about: 1) increased total cost of ownership and 2) lower functionality/value of the solution.

    The other side of the coin is that fake-SaaS providers will simply fall behind in keeping their solutions up to date. Customers should ask carefully about how many versions a provider maintains, how many instances/infrastructures, and how customizations are done, to ensure they get full value from the SaaS solution and aren't eventually orphaned by fake-SaaS providers.

    - John Martin
    John F. Martin
  • RE: Many degrees of multi-tenancy

    Multi-Tenancy is a fundamentally defining attribute of the SaaS platform definition. Having said that, as a SaaS provider with a multi-tenant architecture I can tell you that when approached by a large organization we are happy to consider standing up their own instance of the system. That's the power of cloud computing.
  • RE: Many degrees of multi-tenancy

    In my opinion, I don't believe in tying down the definition of SaaS with a specific application architecture. The best analogy I can think of is that SaaS is like renting property. It does not matter if you are renting a townhouse shared by 10 other tenants or an apartment which is shared by 100 tenants. Heck, it doesn't even matter if you rent a house. The point is, you're paying a monthly fee for a service (i.e. shelter, maintenance & facility).

    SaaS is like renting software, regardless of whether you are sharing the server with 10 or 10 000 other customers. Even if a vendor is hosting isolated servers for each customer I would still consider that SaaS. Ultimately, the user is paying for the hosting, maintenance and the use of software, regardless of what form it takes.

    I think it would be more productive to discuss which multi-tenant architecture is better ... I absolutely agree with what John F. Martin is saying.

  • RE: Many degrees of multi-tenancy

    Yet, enterprise SaaS clients will always be unsatisfied with
    what is offered, no matter how mature the platform
    becomes. They solution to this is for the SaaS company to
    have a core set of multi-tenant services that are shared
    and allow SI's and clients create customization server that
    interface with the core services through well defined API's
    and data indirection layers.

    These customization servers need to be able to support
    custom services that do not need to be upgraded and
    unless the API's or data indirection layers are modified.
    This moves the smart SaaS provider to a PaaS model but
    ultimately allows it to successfully remain a true multi-
    tenant environment while also allowing customizations that
    will be required as SaaS moves deeper into enterprise

    Arthur Lawida
  • RE: Many degrees of multi-tenancy

    I'm surprised that no one has mentioned the 'greening' savings of SaaS with Multi-Tenancy. I would like to believe that having customers share the same database schema, applications, services, hardware and networks is more energy efficient than a separate DB server (and the rest of the stack) per customer.

    Also, MT is something you need to design for 'up-front'. It is really hard and costly to add MT into an application that was originally intended to be single customer solution.

    Steve Willcox - Rally Software.
  • Multi-tenancy has another advantage

    Phil, as usual this is an excellent post. However, I think this discussion misses one of the major advantages of multi-tenancy: it allows for more rapid development and deployment of new features and functions. Rather than having to upgrade hundreds (thousands?) of installations of the software, as required in single tenancy, updating a single instance on a single architecture is markedly more simple task. This means that companies using the multi-tenancy model do faster development (less testing), and in the long run, the product gets better faster - and customers are happier with the faster release cycle for requested features.
  • RE: Many degrees of multi-tenancy

    Hi, great article.
    <a href="">legit paid survey</a>
    <a href="">Flash Games Internet</a>
    <a href="">Golfing Games</a>
    <a href="">Best electronic cigarette</a>
    <a href="">wholesale dropshipping</a>
    <a href=" ">Wikihorse Paarden</a>
    <a href="">fiverr like sites</a>
    <a href="">Igrice Games</a>