Database per tenant approach, single or multiple database server(s)?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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).