One instance per institution

The decision starts with operations

For a platform serving several institutions, data separation is a fundamental architectural decision. A shared database with tenant identifiers is one model; separate databases or instances are others. The right choice depends on requirements, operations and available resources.

At Schulmittag we use a separate instance and database for each institution. This makes responsibility for data and operations tangible: which institution is affected, what version is running and how can its data be restored?

What separation achieves

A separate database reduces certain opportunities for accidentally combining different institutions’ data in an ordinary application query. It can also help plan changes and restorations for each institution.

But it is not an absolute security boundary. Shared administrator access, infrastructure, deployment tools and misconfigured backups can affect multiple instances. Responsibility therefore does not end with creating a second database.

Nor is a shared database automatically insecure. PostgreSQL, for example, provides Row-Level Security, which restricts row access through policies. Privileged roles and correct configuration must be considered. The comparison is: which model can we operate transparently and reliably for our requirements?

The questions behind the architecture

A school or municipality needs to know where its data is, who may access it and how work resumes after a failure. That requires concrete answers: responsibilities, tested permissions, backups and a restoration process that has actually been tried.

OWASP describes tenant isolation as a task spanning several layers. Beyond the database, these include authentication, authorisation, files and caches. An architecture diagram alone does not answer these questions.

The cost of the decision

Many instances mean more deployment, updating and monitoring work. Automation helps, but itself needs understandable processes and error handling. Our open tool fleetdeck is part of that work on software deployment.

For me, this illustrates how theory and practice belong together. A separation model is a good starting idea. Whether it holds up also becomes clear during updates, permission tests and backup restoration. That is where our decision must prove itself.