Deciding on a design for multitenancy
There are many reasons why we may want to split groups of tables or applications: security, resource control, convenience, and so on. Whatever the reason, we often need to separate groups of tables (I avoid saying the word database, just to avoid various kinds of confusion).
This topic is frequently referred to as multitenancy, although this is not a fully accepted term yet.
The purpose of this recipe is to discuss the various options or strategies for implementing multitenancy in a database environment so that we can move on to other, more detailed recipes.
How to do it…
If you want to run multiple physical databases on one server, then you have five main options, which are as follows:
- Option 0 (default): Run separate PostgreSQL instances in separate virtual machines on the same physical server. This is the default option in cloud systems such as EDB BigAnimal, as well as in on-premises deployments such as VMware...
