Would this be considered Single Tenant or Multi-Tenant?

Question

As a company, we lease a managed server from a provider. In that sense, our server is a single tenant server. On this server, we have multiple customer databases. Each customer has its own database.

We have been asked by a customer if we are a single tenant or a multi-tenant solution. From our perspective, we are the sole tenant of the server. But, what is the correct answer to the customer?

Answer 1

You offer a multi-tenant solution.

You place multiple customers' (aka tenants') data and applications on a single server. They share core infrastructure. If that server went down, it would take them all down. Therefore, multi-tenant.

Do not feel bad about this. Essentially all service providers are multi-tenant, by design and necessity. Every organization has some level of shared infrastructure. If your Internet connection, network routers, email system, or phone system went down, multiple customers would still be negatively affected.

Diving Deeper

The issue is not whether you are the only user of your leased server. To be sure, if you were sharing your server with other companies, or if you are/were running on cloud instances from the likes of AWS, Heroku, or Rackspace that are themselves fundamentally multi-tenant, that would move you deeper into "multi-tenant" territory.

As Esben Skov Pedersen suggests, if you dumped all customers' information in a single database separated only by customerId or tenantId columns, that would clearly, unequivocally be multi-tenant.

But consuming your full leased server and separating your customer databases, while good and proper, do not make you a truly single-tenant solution.

The core issue is how much infrastructure your multiple clients' share, how deeply and closely they share it, and what degree of isolation and separation from one another they enjoy. As in the real-estate concept it appropriates, tenancy in IT is a continuum, not a binary single/multiple condition.

Even if you own your own house, pretty much everyone who lives there will have access to all the parts of the house; they probably share meals and watch TV together. In a large apartment building, there are lots of individual units, but the tenants in #231 aren't free to come eat food out of #232's fridge, nor, absent a specific invitation, come plop down on #232's couch to watch Law and Order reruns. While families in their apartments may share exactly like single-tenant houses, it isn't a free-for-all for all tenants; sharing the same roof, parking lot, mail area, and hallways is expected, but apartments are still individual spaces. And there are even more-shared examples, such as boarding houses and shopping malls, where individual tenants may have their own spaces, but there are large public spaces for eating, restrooms, and gathering that are shared communally by everyone. In each of these points along the single/multi continuum, there is some sharing, but with varying scope of what is shared, by whom, with what restrictions.

In your case, all your tenants share a single server. Is each run in its own virtual machine or system partition? You separate the databases for each, but are they managed by a common DBMS engine?

The underlying issue here is isolation. The less isolation and the more sharing, the deeper into multi-tenancy you've delved. So: How separate are one customer's data from anther's? Could a virus, rogue program, or rogue user of one customer's data or apps somehow view or change the data belonging to another customer? If there were a runaway query or infinite loop running in one customer's app, would all the performance in the system be sucked into it, denying other customers quality access to their data/apps?

How much isolation is required will vary by customer. Some will accept deeply multi-tenant services like Google Mail and Google Apps without any qualms. Others balk at anything less than their services running on distinct, unshared hardware and infrastructure--the closest to a pure "single tenant" scenario. For them, even running each customer's apps and data in separate virtual machines (VMs) or hardware partitions (like IBM LPARs) will not be "good enough" separation and isolation.

The reality is that most services today are run with some degree of multi-tenancy. That true even among individual enterprises, where datacenters are increasingly run with high degrees of server consolidation and virtualization. Cloud and other external service providers are fundamentally multi-tenant. And the typical degree of multi-tenancy is increasing. More services are being shared, more intimately, across multiple tenants. Which is why infrastructure providers such as Oracle and NetApp make a special point to offer features aiming to support multiple customers' data under the care of the same storage manager.

To really answer your customer's question, you need to explain what components are shared. If you run every customer in their own unique virtual machine, with their own distinct database engine, but those VMs run on shared hardware--that is probably good enough, these days, to be a credible "primarily single tenant" answer. You still need to disclose your shared infrastructure. Depending on how it's configured, it might also be fair to characterize your solution as "multi-instance"--admitting that there's shared infrastructure, but suggesting more isolation. But if you're running under a single server without each customer in its own VM, or with all customers' individual databases managed by a common database engine or on a common storage farm--then "multi-tenant" is the only possible honest answer.

Answer 2

The answer is single tenant since a multi tenant setup would involve putting multiple customers in the same db. Rule of thumb. If you have a tenantId column all over your database you are probably multi tenant.