1

I'm tasked with investigating the different approaches for multitenancy. Currently I'm expanding my demo application to use the database per tenant approach.

Now where I'm getting unsure is that in a single database server application you're able to create multiple database structures with their own schemas and now I'm wondering what the database per tenant refers to:

Actual database servers running on different ports.

or

Database structures within a single database server.

Improve this question
2
  • 1
    Are you implementing the multitenancy yourself, or are you making use of a framework/library for this? Here is an example of a rails gem github.com/influitive/apartment which allows you to create new tenants, but the database creation varies based on the underlying tech, different approaches for SQLite, Postgres, etc... Have you considered the tradeoffs for using a DB instance per tenant vs new database inside the single instance?
    – Sash
    Commented Jul 18, 2018 at 14:21
  • I found this podcast helpful: fullstackradio.com/80
    – Thomas Junk
    Commented Jul 19, 2018 at 13:51

3 Answers 3

Reset to default
0

I'm wondering what the database per tenant refers to

It can refer to both, there is nothing like "one and only" correct definition of that term.

But if you ask which if the two approaches to prefer, my recommendation is to design your client application in a way the database name and server it connects to is freely configurable. Then start with the most simple solution which the chosen DBMS stack allows, on a single server hardware, and when it turns out this does not meet your requirements any more (in performance or security), then you pick a more complex solution.

TLDR; don't overthink this - think big, start small.

Improve this answer
3
  • The simple solution only works if you include TenantID from the beginning, even if you don't use it at first.
    – Robert Harvey
    Commented Sep 16, 2018 at 23:38
  • @RobertHarvey: correct me if I am wrong, but a TenantID (inside all tenant related tables) is something one needs only when trying to use one db schema for all tenants, inside one database, right? The question, however, is about solutions which all use different databases per tenant. Of course, regardless of the proposed solutions, one needs to assign the different tenants to the different databases (inside one instance), or to the different database instances/ports on one server, or the different database servers. But this can be done, for example, by telling each one different credentials.
    – Doc Brown
    Commented Sep 17, 2018 at 5:36
  • Yeah, reading the question again, it seems that this is another case of someone trying to run before they can walk.
    – Robert Harvey
    Commented Sep 17, 2018 at 15:22
1

That mostly depends on your application requirements.

  • One option is to have a single database server/cluster and have a database per tenant.
  • You could even have a single database, but have the tables arranged so that they provide the multi-tenancy, e.g. there are Organization tables on the top level and everything is attached to that. Security and audits may prove to be more tricky, but this is pretty common too.
  • You can indeed have multiple database servers, but I’d say there has to be a good reason for that, especially if you do use a single backend. Normally that combination wouldn’t make much sense to me. Perhaps in the case where the database cluster itself isn’t easy to set up regionally and you have some requirements regarding latency or where the data is stored, but then I’d expect multiple backends too.
Improve this answer
1

I would recommend against "Actual database servers running on different ports", as this will cause needless configuration trouble (firewalls).

Your second approach "Database structures within a single database server" is a better approach. @Sebastiaan van den Broek suggested having separate tables to provide the multitenancy, but the problem with this is that it doesn't work well the schemas and automatic tools (like ORMs) to map data to/from your database.

Having multiple separate database servers is really overkill unless/until you have enough traffic to warrant it. Then you can split multiple tenants across servers (fairly transparently).

Improve this answer
5
  • A simple argument for separate databases on different machines could be: hard security requirements. And this is independent from actual traffic. "Overkill" is relative. Your overkill is my basic requirement.
    – Thomas Junk
    Commented Jul 19, 2018 at 13:50
  • Agreed in general, that using separate database machines is a good idea in some cases (especially if you use containers to minimize useless overhead/cost). I said as much. But the question was specific "Currently I'm expanding my demo application to use the database per tenant approach.". In his case, my GUESS, is that this level of investment will be overkill.
    – Lewis Pringle
    Commented Jul 19, 2018 at 13:59
  • True it's overkill in the context of my demo application. However I was tasked to investigate multi tenancy without any real requirements. I know a lot of the implementation of multi tenancy depends on the context and the requirements. My issue comes when reading online documentation for the database per tenant concept, when reading it feels like terminology gets mixed hence my confusion. If I understand the comments above me, it looks like both approaches from my question have valid use cases.
    – Viktor Baert
    Commented Jul 20, 2018 at 7:38
  • Not to mince words, but I'm not even sure it would count as multi-tenancy if you had one database (tenant) per server. This just having different instances of your service. The main concept with the 'multii' in multi tenancy an (old world) virtualizaiton multiplexing appraoch. You have multiple 'virtual' databases on one 'database machine'.
    – Lewis Pringle
    Commented Jul 20, 2018 at 15:26
  • But ignoring that detail of nomenclature (which some may disagree about- see Alice in Wonderland) - the basic idea is that you have a spectrum and can store as many 'sites' as you want on any one physical machine (each in a separate database) - and the process of deciding which and how many is just a (slow probably static form of) 'load' balancing. And configuration, to tie the front ends to the right backend databases (on whatever machine they are on).
    – Lewis Pringle
    Commented Jul 20, 2018 at 15:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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