End to End multitenancy best practices in play!

[Norman Weisenburger]

Dear Play! community,

we (pulseshift.com) are a young startup building an enterprise grade transformation management application,

using Play! and Postgres.

One of our main cross concerns is multitenancy.

In advance we expected that many other people have/had the same challenges and that

there are best practices available on how to build a multitenancy app with play!.

Our research however, turned out that the topic comes up every now and then but

is very fragmented and diverse.

The objective of this post is to see whether there are more people in the community

that are willed to share and collect best practices on multitenancy with play + database X ?

Additionally we would be interested to know if the topic is interesting for the play team

as well - i.e. if it is interesting to get our feedback on the glitches we faced during the implementation.

I like to conclude with a brief sketch of our approach:

- Technology: Play! + Slick + Postgres

- Approach: Schema per tenant

- Implementation:

    - We have two databases a "system" database and a "tenant" database.

      In simple words the system database contains the table of existing tenants,

      The tenants database contains a schema per tenant

    - For each request we get the tenant from the url and pass it down to the database layer

      via a "context" object.

      From this context object we create a slick table query that targets the tenant specific schema,

      that is used to issue tenant specific SQL statements.

    - We maintain one database evolution for each database.

    - We have overwritten parts of the play evolutions to apply the tenant evolutions

      to each schema one after another.

Looking forward to your replies!!

Bests Norman

Development Architect @PulseShift