Josh Price

Field notes of a software developer

10 December 2012

Multitenant Rails Applications

I recently worked on multi-tenanting a Rails 3 application for a client. We ended up going with the Apartment gem which worked pretty well for us. Despite being stuck with MySQL, we set up a database per tenant and it turns out that this was (for our purposes at least) the same as using Postgres schemas.

To set some context, the requirements were relatively simple. We needed a new version of the application for a different country unit.There was likely to be a maximum of 4 tenants for the foreseeable future. Nor did we need dynamic creation of new tenants, this was pretty static.

Here is a quick rundown of some of the resources I found during my research:

Overviews

There are essentially 3 approaches you can take when multi-tenanting an app:

  1. Completely separate applications and databases (generally not a great idea, but could work in some contexts)
  2. Use a single DB and add a tenant column to each table
  3. Separate databases per tenant (MySQL) or use schemas in Postgres (this is what we went with). It was the best balance of safety, performance, scalability and simplicity for our needs.

Separate DB approach

We ended up using the Apartment Gem with some customised rake tasks to ensure that all the rake db:* tasks worked on all databases.

PostgreSQL schemas

We almost considered moving to Postgres just for namespaced schemas. Then we discovered that separate MySQL databases are effectively the same thing. Who knew?

Shared DB approach

This is probably the simplest approach, but means that you have to scope all models to your current tenant. If you forget, or the scoping is wrong, you'll leak data between tenants. This is bad.

Hope this comes in helpful for someone as I've had to do this for several projects now. Ping me on twitter if you have any questions.

Discuss →

Copyright 2012