Software multitenancy is a software architecture in which a single instance of software runs on a server and serves multiple tenants. Systems designed in such manner are "shared" (rather than "dedicated" or "isolated"). A tenant is a group of users who share a common access with specific privileges to the software instance. With a multitenant architecture, a software application is designed to provide every tenant a dedicated share of the instance—including its data, configuration, user management, tenant individual functionality and non-functional properties. Multitenancy contrasts with multi-instance architectures, where separate software instances operate on behalf of different tenants.^[1]

Some commentators regard multitenancy as an important feature of cloud computing.^[2][3]

Multitenant applications have evolved from—and combine some characteristics of—three types of services:

1. Timesharing: From the 1960s companies rented space and processing power on mainframe computers (time-sharing) to reduce computing expenses. Often they also reused existing applications, with simply a separate entry field on the logon screen to specify a customer-account ID. On the basis of this ID, the mainframe's accountants could charge the individual customers for CPU, memory and disk/tape usage actually incurred.
2. Hosted applications: From the 1990s traditional application service providers (ASPs) hosted (then-existing) applications on behalf of their customers. Depending on the limitation of the underlying application, ASPs were forced to host applications on separate machines (if multiple instances of the applications could not be executed in the same physical machine) or as separate processes. Multitenant applications represent a more mature architecture^[4] which enables a similar service with lower operational cost.
3. Web applications: Popular consumer-oriented web applications (such as Hotmail) developed with a single application instance serving all customers. Multitenant applications represent a natural evolution from this model, offering additional customization to groups of users within (say) the same client organization.

In a multitenancy environment, multiple customers share the same application, running on the same operating system, on the same hardware, with the same data-storage mechanism. The distinction between the customers is achieved during application design, thus customers do not share or see each other's data. Compare this with virtualization where components are transformed, enabling each customer application to appear to run on a separate virtual machine.^[5]

Some companies actively promote the principle of multitenancy and use it as a source of competitive differentiation. The use of multitenancy is increasing day by day.^[6]

Multitenancy allows for cost savings over and above the basic economies of scale achievable from consolidating IT resources into a single operation.^[7] An application instance usually incurs a certain amount of memory and processing overhead which can be substantial when multiplied by many customers, especially if the customers are small. Multitenancy reduces this overhead by spreading it over many customers. Further cost savings may come from licensing costs of the underlying software (such as operating systems and database management systems). Put crudely, if you can run everything on a single software instance, you only have to buy one software license. The cost savings can be eclipsed by the difficulty of scaling the single instance as demand grows - increasing the performance of the instance on a single server can only be done by buying faster hardware, such as fast CPUs, more memory, and faster disk systems, and typically these costs grow faster than if the load was split between multiple servers with roughly the same aggregate capacity.^{[citation needed]} In addition, development of multitenant systems^[8] is more complex, and security testing is more stringent because multiple customers' data is being commingled.

One of the most compelling reasons for vendors/ISVs to utilize multitenancy is for the inherent data aggregation benefits. Instead of collecting data from multiple data sources, with potentially different database schemas, all data for all customers is stored in a single database schema. Thus, running queries across customers, mining data, and looking for trends is much simpler. This reason is probably overhyped as one of the core multitenancy requirements is the need to prevent Service Provider access to customer (tenant) information. Further, it is common to separate the operational database from the mining database (usually because of different workload characteristics), thus weakening the argument even more.

Because of the additional customization complexity and the need to maintain per-tenant metadata, multitenant applications require a larger development effort. Considerations such as vector-based data sequencing, encryptable algorithm infrastructure, and virtualized control interfaces, must be taken into account.^[9]

Multitenancy simplifies the release management process. In a traditional release management process, packages containing code and database changes are distributed to client desktop and/or server machines; in the single-instance case, this would be one server machine per customer. These packages then have to be installed on each individual machine. With the multitenant model, the package typically only needs to be installed on a single server. This greatly simplifies the release management process, and the scale is no longer dependent on the number of customers.

At the same time, multitenancy increases the risks and impacts inherent in applying a new release version. As there is a single software instance serving multiple tenants, an update on this instance may cause downtime for all tenants even if the update is requested and useful for only one tenant. Also, some bugs and issues resulted from applying the new release could manifest in other tenants' personalized view of the application. Because of possible downtime, the moment of applying the release may be restricted depending on time usage schedule of more than one tenant.

According to Marc Brooker, in a multi tenant architecture, unrelated and uncorrelated workloads should be grouped together. That's because mixing different workloads, with different needs and patterns, hide the patterns of each workload. Grouping workloads reduces the peak-to-average ratio of the overall system; individual workloads can utilize more resources during peak times without significantly increasing the overall cost structure of the system and subsequently helps you to achieve more cost efficiency. Note that multiple workloads from the same application, customer or industry, tend to behave as a single workload. ^[10]

Multitenant applications are typically required to provide a high degree of customization to support each target organization's needs. Customization typically includes the following aspects:

• Branding: allowing each organization to customize the look-and-feel of the application to match their corporate branding (often referred to as a distinct "skin").
• Workflow: accommodating differences in workflow to be used by a wide range of potential customers.
• Extensions to the data model: supporting an extensible data model to give customers the ability to customize the data elements managed by the application to meet their specific needs.
• Access control: letting each client organization independently customize access rights and restrictions for each user.

Multitenant applications are expected to provide adequate security, robustness and performance^[11] between multiple tenants which is provided by the layers below the application in case of multi-instance applications.

The costs of redesigning applications for multitenancy can be significant, especially for software vendors who continue to offer an on-premises single tenant version of their product. They end up being forced to support two distinct products with all the resulting costs.

An increasingly viable alternative route to multitenancy that eliminates the need for significant architectural change is to use virtualization technology to host multiple isolated instances of an application on one or more servers. Indeed, when applications are repackaged as virtual appliances the same appliance image can be deployed in ISV hosted, on-premises or trusted-third party locations and even migrated from one deployment site to another over time.