2

Based on this explanation of multi-tenant architectures here:

A multi-tenant architecture is one where a single software instance and database serves multiple customers

I cannot fathom how it is preferable to have a single database instead of spawning a single/multiple databases per tenant?

I would think that it should be since resources for single-tenant architectures are hardly a fraction of its multi-tenant counterpart.

Why is it preferable to have a single database?

1
  • 2
    The biggest reason why it is preferable is cost. A single database serving 50 tenants is cheaper than 50 databases each server 1 tenant.
    – Jon Raynor
    Sep 23 at 19:41
3

You've misunderstood the article

You've taken "multi-tenant" to mean "an application which is used by more than one tenant". I'm actually on your side here and I interpret multi-tenancy the same way, but the article uses a slightly different definition, which you seem to have missed.

In the article, and I admit I agree they should've pointed this out a bit more explicitly to avoid ambiguity, "multi-tenant" is being used to mean "more than one tenant using the same resource":

A multi-tenant architecture is one where a single software instance and database serves multiple customers (i.e. tenants).

Contrast this to the previous paragraph about single-tenancy:

Single-tenant cloud architecture is one where a single software instance and its supporting infrastructure/database serve only one customer. In a single-tenant environment, all customer data and interactions are separate from every other customer. Customer data is not housed in the same database and there’s no sharing of data in any way.

Circling back to your question:

I cannot fathom how it is preferable to have a single database (A) instead of spawning a single/multiple databases per tenant (B)?

The article doesn't claim that sharing resources is better. But when not sharing resources, the article calls it single-tenancy (B) and not multi-tenancy (A).


Single-database multitenancy

I also want to address your comment on why someone would ever use multi-tenancy (as per the article's definition of multi-tenancy).

I cannot fathom how it is preferable to have a single database instead of spawning a single/multiple databases per tenant?

Why is it preferable to have a single database?

If you allow an analogy, I cannot fathom how my parents can buy a $200 desktop and use that for all their computer activities. The desktops I build cost ten times that.

But the simple conclusion here is that not everyone needs the same specs. My parents are not power users or gamers. If they can open word/excel files and browse the internet they're happy because that's all they really need. Spending more on a better desktop would be a waste of resources for them.

Similarly, multi-tenanted applications with a small footprint and no reasonable need to think about scalability don't need a multi-database setup. Spending more time, effort and complexity on implementing it anyway is just a waste of resources.

"Better" is a very vague criterium. You intend it to mean "more robust and scalable", but you're glossing over the fact that it also costs extra time and effort. If you don't need the robustness and scalability, then using it is just a waste of resources, which means it's not "better" for your particular scenario.

8

Multi-tenant systems seem more complicated to develop, but are vastly easier to manage and are much more flexible.

In principle, it is easy to have multiple “databases”. More precisely, it is easy to have multiple schemas/namespaces on one database server. In practice, this complicates stuff a lot. For example, you might have separate connection strings for each database. This will make it more difficult to maintain connection pools, making your application slower overall. When you change your application you occasionally want to run schema migrations in the database. If you have separate databases, you must migrate them separately. This cannot be done atomically, so you must architecture your application to deal with multiple schema versions simultaneously (or have some setup that lets you gradually move connections over to new versions).

Often, you want to keep the data of multiple tenants separate. But not always. For example, if you have some feature to share content (e.g. as in Google Drive, or with shared Slack channels) then a multi-tenant setup makes this trivial, whereas having multiple single-tenant databases makes this very difficult.

It's also possible to change the viewpoint: every SaaS system is single-tenant: the sole relevant tenant is the SaaS provider. How customer data shall be managed is part of the business logic, but those customers might not have to be treated as tenants. The SaaS provider has cross-cutting concerns that benefit from using a single database, in particular issues like billing and user management. How the business logic is implemented is an implementation detail. Sometimes, it makes sense to use built-in database features to keep data separate (single-tenant). Sometimes, that is an issue that should be managed as part of the application (and use a multi-tenant database).

Moving security and access controls to the application is of course more risky – a bug in the application logic might show data to the wrong people. But that is something that can happen regardless of the database configuration. For example, you'd get the same problem if the application confuses which database instance relates to which tenant. You can build reasonably secure systems either way, but I concede that single-tenant resources can allow for stronger isolation where this is necessary.

Above, I define a single-tenant system to involve multiple database schemas on one database server. You could also run separate server processes for different tenants, or possibly even use separate virtual machines for separate tenants. Typically, this level of isolation is not needed. The less isolation you need, the higher density and cost-effectiveness you can achieve for your infrastructure.

2

The key requirement in multi-tenancy is that you can add additional tenants at run-time.

If you want to have a separate database per tenant, you will have to devise some scheme to provision a database server, or at least a database instance, while the application is running, automatically, without developer intervention. Once the database instance is added, somehow you will also need to update the rest of your code to use it (e.g. add additional connection strings, users, or permissions). If you want backup or disaster recovery, your code must be clever enough to set those up as well.

If you use a single database, you merely need to add a tenant record, and use its foreign key throughout your other tables to differentiate between tenants.

I suppose you could devise some sort of "multi-tenancy lite" where you still have a certain amount of manual intervention whenever a tenant is added. This can work when the pace of your business is slow, but as your business grows, this kind of solution cannot scale.

-2

Consider an on-line store as an example. Should each customer manage their order in a separate database that is spun-up when the customer creates an account, or one database.

defining the scope of the customer is relevant to deciding which strategy is needed. as well as differentiating between a database and database server.

4
  • 1
    This is not what tenancy is about. The customer of a web shop is not its tenant. A better example would be webshop software that is being used by several different shops, where your answer is not as applicable. Secondly, the distinction between a database and a database server isn't relevant to the current discussion.
    – Flater
    Sep 24 at 8:11
  • you've missed the generalization and the analogy. If you selling sunglasses online, you would spawn separate instances, if your e-commerce site is a public cloud provider then yes you may very well might. Also quoting the above " separate database per tenant, you will have to devise some scheme to provision a database server," databases vs database servers is actually part of the discussion
    – Chris
    Sep 30 at 21:22
  • "if your e-commerce site is a public cloud provider" is a disproportionately specific fringe case, and even in those cases the provisioning and deployment of the product is not strictly related to the e-commerce aspect of purchasing said product.
    – Flater
    Oct 1 at 7:47
  • That's how you know it's correct. It is still part of the general case.
    – Chris
    Oct 1 at 13:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.