Multi-tenancy – single database vs multiple database

I am asking myself the exact same question at the moment.

I am leaning towards the multi-instance single tenancy solution but have not taken a definitive decision yet. Let me share some of my thoughts :

The main historical advantage of the multi-tenant architecture is a better use of infrastructure resources, by mutualisation (single OS, single Database, single application layer) and better occupying of said resources (when one user is away another can use the same resource).

It also greatly simplifies software lifecycle : you deploy new versions to you one instance, all the customers are updated at the same time.

It seems however, that recent advancements in cloud technology make the first class of advantages largely available in a multi-instance (instance-per-customer) architecture (I am thinking specifically of a platform like Jelastic here but I am sure there are others that provide the same features):

• Container-based PaaS
• Provisioning and auto-scaling of containers (elastic containers)

So hardware and platform management is not the Software provider's concern any more. Resources are mutualised much more efficiently than before at the infrastructure and plaform levels.

There will still be an overhead for multi-instance (some app and middleware will be ran N times instead of just one), but much lower than when using a separate (virtual) machine per instance. The database could be shared anyway (one schema per instance, several schemas per DB server)

Also :

• Automation of creation of new instances is possible via PaaS API
• Automation of deployment of new versions is possible via PaaS API, with zero downtime (takes some work to put in place)
• Scaling is always out, never up. We don't have to worry about huge datasets at the instance level.

Of course, we would need some kind of central service that manages all this automatically (e.g. creation of instance when a new user creates an account). This would also manage payment and licensing issues, interaction between instances etc. This central service might be quite complex and hard to develop, but the good thing is that we don't have to implement it upfront (now that we don't have much resource) whereas multi-tenant would need to be baked into the app from the start.

Which brings me to the final advantages of developing single-tenant for a very early stage (pre-invesment) startup project :

• Same (or almost same) version of the app can be deployed on-premises either as a virtual appliance or docker container or even on customer-managed machine (some companies are still reluctant towards the Cloud and it may help an early stage startup to not push out important early adopters)
• Faster to get a product out with limited resources (the application layer and database schema is quite less complex), can get a "dumb" single instance single tenant product out first (MVP) for early adopters and to show the business value of the app to potential investors, and add all the cloud automation later on
• Can be seen as a selling argument for customers worried about data security : the data is better encapsulated since every customer has his own schema or even database. Much less risk of "spillage"

NB: I am obviously thinking here of a business app where customers would be businesses (each with multiple individual users) and not individuals. It would not make any sense to run a separate instance of an app for each individual user (or would it ?)

You've given scant details on your user base, but it sounds like you do not have a multi-tenant requirement. There are also few details into how your views differ between each other. On instinct, I would guess that you do not have mutli-tenant, but in fact have multiple groups. I would also guess that you are leaning towards a solution which will cause you to be angry with yourself later on. More specifically, separate implementations of each of the search view, grid view, and detail view.

I believe you should use standard user authentication via keystone, or keycloak, or another third party. Take advantage of their users / groups / roles to assign a hierarchy of permissions. Something like USER_BASIC_PERM would grant them access to an object's ID, Name, and Category. USER_CASH_PERM would grant then access to cost, value, profit margin. USER_ADMIN_PERM would let them see fields relating to 3rd party buyer, url to PO, etc. You can use groups to put mutliple role permissions together and manage users more easily with a single group.

Then you can build your three views by including / excluding sub-views based on the user's permissions. When they submit a search, you must validate their fields based on their roles server-side. When returning details, you must put it through a permission filter before returning it to the client. In the long run, this will be easier to maintain than implementing separate views for each of your tenants.

I think that if you consider that it's only permissions of a user that are the difference, then you'll see that the major functionality should be self-contained. 'search' would be one server-side module. Grid data access would be another. Keeping similar functionality together on the server-side will lead towards less repetition. Separating server-side by group would mean that you need to visit 3 separate modules to fix one bug that spans all of your 'grid' queries.

Think about long term - if you add 5 more tenants that are very close to the three you know about, which one will cause less pain to implement later.

Let's say you add a fourth view. Do you want to add it once with permission checks, or once for each of your now 8 tenants - even if most of them share the exact same view?