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
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
As Esben Skov
suggests, if you dumped all customers' information in a single database
separated only by
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
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.