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.

  • 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 Jul 18 '18 at 14:21
  • I found this podcast helpful: fullstackradio.com/80 – Thomas Junk Jul 19 '18 at 13:51
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.

  • The simple solution only works if you include TenantID from the beginning, even if you don't use it at first. – Robert Harvey Sep 16 '18 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 Sep 17 '18 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 Sep 17 '18 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.
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).

  • 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 Jul 19 '18 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 Jul 19 '18 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 Jul 20 '18 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 Jul 20 '18 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 Jul 20 '18 at 15:28

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.