• Home

  • Custom Ecommerce
  • Application Development
  • Database Consulting
  • Cloud Hosting
  • Systems Integration
  • Legacy Business Systems
  • Security & Compliance
  • GIS

  • Expertise

  • About Us
  • Our Team
  • Clients
  • Blog
  • Careers

  • CasePointer

  • VisionPort

  • Contact
  • Our Blog

    Ongoing observations by End Point Dev people

    Multi-Tenant Architecture

    Gaurav Soni

    By Gaurav Soni
    March 27, 2018

    Multi-tenant living, with grazing cows
    Photo by Rüdiger Stehn, cropped, CC BY-SA 2.0


    Multi-tenant architecture allows one instance of an application to serve multiple customers/​organizations. Each customer/​organization is called a tenant. Each has its own apparent separate application and is not aware of the other tenants. The tenant has the ability to customize their own UI, users and groups, etc. Every tenant typically has these features:

    View: Tenants can define the overall styling to their application.

    Business rules: Tenant can define their own business rules and logic for their application.

    Database schema: Tenant can define their own database schema (real or apparent) for the application. They can add/​remove database tables, rename database fields, etc.

    Users and groups: Tenant can define their own rules to achieve data access control.

    Types of multi-tenancy

    There are 3 main types of multi-tenant architecture:

    (1) Multi-tenancy with a single multi-tenant database: This is the simplest form of multi-tenancy. It uses single application instance and the single database instance to host the tenants and store/​retrieve the data. This architecture is highly scalable, and when more tenants are added the database is easily scaled up with more data storage. This architecture is low-cost due to shared resources. Operational complexity is high, especially during application design and setup.

    Multi-tenancy with a single multi-tenant database

    (2) Multi-tenancy with one database per tenant: This is another type of multi-tenancy. It uses a single application instance and an individual database for each tenant. The scalability of this architecture may be lower and the cost higher than multi-tenancy with a single multi-tenant database because each database adds overhead. We can increase the scalability of this architecture by adding more database nodes but it depends on the workload. Operational complexity is low due to usage of individual databases.

    Multi-tenancy with database-per-tenant

    (3) Standalone single-tenant app with single-tenant database: In this architecture you install the whole application separately for each tenant. Each tenant has its own app instance as well as database instance. This architecture provides highest level of data isolation. The cost of this architecture is high due to the standalone applications and databases.

    Standalone single-tenant app with single-tenant database

    How to achieve multi-tenancy in Rails

    The Apartment Gem provides tools to help you deal with multiple tenants in your Rails application.

    Apartment Gem Installation

    Add the following to your Gemfile:

    gem 'apartment'

    and run

    bundle install

    Then generate your Apartment config file using

    bundle exec rails generate apartment:install

    You can create new tenants like this:


    To switch tenants using Apartment, use the following command:

    Apartment::Tenant.switch('tenant_name') do
      # ...

    When the switch is called, all requests coming to ActiveRecord will be routed to the tenant you specify.

    Multi-tenancy using subdomain with Apartment Gem

    module MyApplication
      class Application < Rails::Application
        config.middleware.use Apartment::Elevators::Subdomain


    Try the Apartment gem! And consider the trade-offs of your application and user needs.

    rails architecture development