In multi-tenant software architecture—also called software multitenancy—a single instance of a software application (and its underlying database and hardware) serves multiple tenants (or user accounts). A tenant can be an individual user, but more frequently, it’s a group of users—such as a customer organization—that shares common access to and privileges within the application instance. Each tenant’s data is isolated from, and invisible to, the other tenants sharing the application instance, ensuring data security and privacy for all tenants.

Software multitenancy is the architecture on which Software-as-a-Service (SaaS) is delivered. If your organization uses salesforce.com, HubSpot, or another cloud-based SaaS offering, you’re a tenant in a multi-tenant offering.

Somewhat confusingly, multi-tenant can also refer to cloud hosting offerings. In multi-tenant hosting—also called shared hosting—a single physical computer or virtual machine (VM) is shared among multiple users or client organizations. Multi-tenant hosting solutions are offered by cloud service providers typically as a lower-cost alternative to single-tenant or dedicated hosting solutions.

The remainder of this article will focus on software multitenancy. Learn more about types of multi-tenant and single-tenant hosting here.

Compared to single-tenant architecture—in which each tenant gets its own instance of the application, database, and supporting hardware infrastructure—multi-tenant architecture offers significant benefits to software providers and tenant customers, including the following:

• Lower costs: Because the software provider can serve multiple tenants from a single application instance and supporting infrastructure (and because tenants share the burden of software maintenance, infrastructure, and data center operations), ongoing costs tend to be lower than those of a single-tenant arrangement. SaaS software is typically offered for a predictable monthly or annual subscription price based on number of users, usage level, or data volumes managed within the application.
  
  
• Scalability: Tenants can scale on demand—new users get access to the same instance in the software, typically for an incremental subscription rate increase.
  
  
• Customization without coding: SaaS multi-tenant offerings are highly configurable so that each tenant customer can tailor the application to its specific business purposes without expensive, time-consuming, and sometimes risky custom development.
  
  
• Continuous, consistent updates and maintenance: The multi-tenant software provider is responsible for updates and patches. New features are added and/or fixes applied without any effort on the customer's part and just once (as opposed to single-tenant architecture, where providers must update every instance of the software).
  
  
• Improved productivity for tenants. Not having to manage infrastructure or software means tenants are free to focus on more important tasks.

Multi-tenant cloud was often (but now less frequently) used as a synonym for shared hosting or for any architecture in which customers share computing resources in a public or private cloud. Today, it’s understood that most leading cloud service providers deliver most of their offerings—everything other than dedicated hosting service—based on the multi-tenant model, which allows providers to maximize utilization of their data center hardware and infrastructure and, consequently, offer cloud services to customers for the lowest possible costs.

When choosing a database for multi-tenant applications, developers have to strike a balance between customers’ need or desire for data isolation and a solution that scales quickly and affordably in response to growth or spikes in application traffic.

To ensure complete isolation, the developer can allocate a separate database instance for each tenant; at the other extreme, to ensure maximum scalability, the developer can have all tenants share the same database instance. But, most developers opt to use a data store such as PostgreSQL, which enables each tenant to have its own schema within the same database instance (sometimes called ‘soft isolation’) and provides the best of both worlds.