Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Implementation Challenges With a Multi-tenant SaaS Database

DZone's Guide to

Implementation Challenges With a Multi-tenant SaaS Database

· Cloud Zone
Free Resource

Production-proven Mesosphere DC/OS is now even better with GPU scheduling, pods, troubleshooting, enhanced security, and over 100+ integrated services deployed in one-click.

This 2006 MSDN article points out some key aspects of designing a multi-tenant database for SaaS applications. As you can read in the article, SaaS databases need to pick one of the following three configurations:

  1. separate databases
  2. shared database, separate schema and
  3. shared database, shared schema

A number of factors, including economic, security, skill set, etc., contribute to the selection of the best suitable configuration. In this post, from my experience, I’ll share the following practical requirements that introduce additional implementation challenges:

  1. Each account needs to have a maximum allowed space on the database (economic).
  2. Data from one account should never be accessible to other accounts (security).
  3. However, for backend usage, we need the ability to run queries across all accounts.

Size limiting is quite hard. It almost forces the use of a separate database or schema per account. Even then, most databases today don’t have a clean mechanism to exert such a hard limit.

Separate databases reduce the chance of cross-account data leaks. But backend tasks suffer for this. For example, your monthly billing processor needs to generate a bill for all accounts. With one database per account, it cannot do one simple query to a single database anymore.

Also, most ORM libraries don’t support separate databases for a single type. For example, to fetch the orders from the database, the ORM library needs to connect to database A for account X, but to database B for account Y and so on. At this point, if possible, you’ll need to tweak the ORMs a lot or fall back to your own ORM, which, as I wrote in the past, is almost never a good idea.

Connection pooling is another challenge. It’s generally a good practice to use connection pooling, to save the overhead of establishing a connection before every query. With separate databases, and hundreds, if not thousands, of accounts being served from an app server, the connection pool would either have too many or too few connections in it to be useful.

I don’t know about a clean architecture that would address these requirements while not introducing the dev challenges. Please comment if you have any suggestions.



Simply build, test, and deploy. Mesosphere DC/OS is the best way to run containers and big data anywhere offering production-proven flexibility and reliability.

Topics:

Published at DZone with permission of S M Sohan, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}