Karen was an Oracle DBA for 20 years before starting to work with PostgreSQL databases. She was once described as “quite personable for a DBA” which she decided to take as a compliment. Outside of the world of databases, she lives in the mountains with her family and their two rescue dogs and she loves cycling, mountain biking and skiing. She has also recently started a part-time PhD in Computer Science.
Most organizations or database teams don't have the luxury of looking after just a single database application. Some will manage at least a few applications, others will have hundreds. In most organizations, the question of multi-tenancy will therefore probably arise.
The Postgres environment can be designed in various different ways to accommodate multiple customers and/or applications. For example: - each application could have its own Postgres cluster - we could create a separate database per application within a shared cluster - we could create a single database that contains a separate schema per application - we may allow multiple customers to share a single schema, with the (shared) tables partitioned by customer.
But which of these is the “right” option?
The answer is, as always, “it depends”. The correct method is the one that provides the required balance between performance, security, high availability and manageability.
In this presentation, we'll look at the different multi-tenant architectures and the advantages and disadvantages of each. It should enable you to design the most appropriate database environment for your applications.