What is a multi-tenant database architecture? How is it done in dashDB and DB2?

When you have an SQL database that deals with multiple users, there’s a tough choice to make over how you set up and access your tables to provide security. One model that’s growing in adoption is to give each user their own, separate schema, database or set of tables. This is called a multi-tenant architecture, or multi-tenancy.

The alternative to a multi-tenant system is a shared (or single-tenant) architecture, where multiple users query and store data in the same, shared tables. In contrast, in a multi-tenant design, each customer is more isolated.

This makes security less of a headache, and can make it easier to divide and optimize computing resources.

Multi-tenancy Support in IBM dashDB and DB2

Multi-tenancy is easy in DB2 and dashDB. In fact, they are among the few databases that provide enough security functionality to deeply address the issues, and let programmers build a totally contained app.

Keep in mind that, at this time, dashDB only allows multiple schemas, and not multiple databases.

DB2 and dashDB also provide row-level access control, and even column-level access control, to further refine access in both a shared or multi-tenant environment. See Row and Column Access Control in dashDB for more details.

Note for MySQL users: In MySQL, a “database” and a “schema” refer to the same thing. In IBM dashDB and DB2, one database supports multiple schemas inside of it. This helps all schemas benefit from shared configurations and optimizations.

Security levels on a schema have separate permissions for create (CREATEIN), modify existing (ALTERIN) and delete (DROPIN). A basic example would be:

[code]GRANT CREATEIN ON SCHEMA MY_SCHEMA TO JOHN_DOE;[/code]

You can also set up a user that has permissions on a schema and can also grant permissions to other users:

[code]GRANT ALTERIN ON SCHEMA CUSTOMER_COMPANY TO CUSTOMER_ADMIN WITH GRANT OPTION;[/code]

A few tips for building multi-tenant architectures

Remember: Usernames and company names change: A common mistake is to name each database, schema or table according to a company name or username. Factor in that usernames and company names often change. For example, either use a lookup table or have an extra value called “official_name” to use as a company name for login or visual display.

Consider the trade-offs between dividing based on table, schema or database. Each has it’s own advantage. For dashDB for Transactions, the current recommendation is to leverage multiple schemas, which provides a balance between isolation and costs. However, dividing based on tables can provide performance advantages.

Understanding the choice between multi-tenancy and shared tenancy

When the web was younger, shared tenancy ruled the day: Databases had weaker security models built in and it was extremely common to create a single database user who could access anything in the database. The code, written in web languages such as Perl or PHP, would use this single database user to read and write all data for all users to your database tables. It was up to the programmer to think of every corner case to prevent one user from seeing something he or she shouldn’t. Security became a huge problem, especially with SQL injections.

The following on some of the pros/cons of shared tenancy:

Harder to isolate heavy users: Shared tenancy also makes it hard to scale resources based on customer usage. For example, suppose you built an app that does invoicing. Inevitably, some customers would be large organizations with millions of invoices, and require tons of computing power. But scaling for this customer, when all their data is jumbled into the same tables as everyone else, gets very difficult.

Lower development costs: There are so many corner cases with a shared database model and security, that to deal with each and every one would begin to take a toll on development. Initially, progress is faster, but the release to production can be plagued with issues, especially for sensitive business apps.

Is shared tenancy ever desirable? Shared tenancy is sometimes a desired model. The main benefit tends to be performance and a perceived simplification. For heavily consumer-focused apps, where most data is shared, it can be a better choice.

Conclusion

With dashDB and DB2, because your database permissions can perfectly match your actual intention, it can make development, APIs and integration go much, much faster.

In the long term, it’s possible that shared tenancy technologies like ACLs and row-based permissions once again become a better option. But today, a multitenant architecture for SQL is typically a safer bet.

One key aspect of a robust architecture is that it is built to smoothly handle system failures, outages, and configuration changes without violating the data loss and consistency requirements of the use case. To proactively build such solutions needs an understanding of the possible exceptions and risky scenarios and preparedness to manage them efficiently.

Join us at Think 2019, Session #2397 - "Transformation to a Data-Driven Organization," to learn how IBM Cloud built a data platform enabling all team members to drive quality and growth. We will discuss technical and cultural challenges that we have faced and the strategies used to tackle them head on.