Most SaaS platforms are multi-tenant: they serve several clients from shared infrastructure. There are three main models: single shared database (all clients in one database, separated by an identifier), database-per-tenant (each institution has its own database) and sharded (a mix). The shared database is the market standard, cost-efficient and secure when well designed. The dedicated database offers physical isolation that simplifies export, block deletion, backup and localisation — making it an asset for GDPR and sovereignty. The choice is not "secure vs insecure" but "which guarantee can you prove to your DPO?". The right question to ask any vendor: "Is my alumni data in the same database as other schools'?".
First: what is multi-tenancy?
Almost all alumni platforms are multi-tenant SaaS software: a single service hosts the data of many clients (the "tenants", here the institutions). This is what makes SaaS cost-efficient — the vendor shares infrastructure instead of installing a server at each client. So the question is not "multi-tenant or not", but how each institution's data is stored and separated from the others. Cloud providers document these models precisely; here we use the reference taxonomy from Microsoft Azure.
The three architecture models, explained simply
| Model | How it works | Isolation | Profile |
|---|---|---|---|
| Single shared database (single multi-tenant DB) | All schools in the same database, separated by a tenant ID column. | Logical (enforced by code) | The most cost-efficient, the most common |
| Database-per-tenant | Each school has its own database, centrally managed. | Physical (separate databases) | Strong isolation, more costly to operate |
| Sharded (hybrid) | Several databases, each grouping a subset of clients. | Variable | The most flexible at scale |
None of these models is "good" or "bad" in absolute terms: they answer different trade-offs between cost, operational simplicity and level of isolation. What changes is what you can guarantee and prove.
What the architecture changes concretely for a school
Four very concrete consequences, of direct interest to an IT department and a DPO:
- Isolation. With a dedicated database, a school's data lives in a separate database: an application incident on another scope stays, by construction, outside yours. With a shared database, isolation relies on the rigour of application-level partitioning (row-level access control, testing).
- Right to erasure (Art. 17 GDPR). The right to erasure requires being able to delete data within short timeframes. On a dedicated database, deleting or anonymising an entire institution's scope is done as a block and in a verifiable way.
- Export & reversibility. Retrieving all your data at the end of a contract is simpler when it sits in a database that is only yours. Reversibility — not being locked into a proprietary format — is easier to put into a contract.
- Localisation (data residency). Guaranteeing that data stays hosted in France or Europe is more direct when an institution's database is an identifiable entity, not a fraction of a large shared whole.
"Shared database = risk"? No, and here's the nuance
It would be dishonest to claim a shared database is dangerous. It is an industry standard, used by countless services you rely on every day, and it is perfectly secure when correctly designed: application-level partitioning, row-level access control, code reviews and testing. Be wary of any sales pitch claiming otherwise.
The real difference lies elsewhere: it is the nature of the isolation guarantee. In a dedicated database, isolation is physical — easy to explain and prove to a committee, a DPO or an IT department. In a shared database, it is logical — real, but it depends on the quality and maintenance of the code. For a public institution subject to sovereignty requirements, this difference in "provability" often weighs in the decision.
The right question to ask your vendor
You don't need to be an engineer to decide. A single question does the sorting:
"Is my institution's data in the same database as your other clients'? And if I leave, can you export then delete my entire scope, in a verifiable way?"
Ask it of every solution you compare, and note how precise the answer is. It is also one of the criteria in the guide to choosing alumni software, alongside price transparency and hosting.
Terrilink's approach
Terrilink chose the database-per-tenant model: each school has its own isolated database, hosted in France. Concretely, your alumni data is identifiable, fully exportable and deletable as a block — sovereignty becomes verifiable, not merely declarative. It is a deliberate choice, more demanding to operate, but consistent with the expectations of accredited institutions. Details are on the alumni software for accredited schools page, and the compliance angle in the GDPR guide.
In summary
Shared or dedicated, the question is not which is "secure" — both can be — but which guarantee you can prove. If your institution is subject to sovereignty, accreditation or data-localisation requirements, the dedicated database simplifies isolation, GDPR erasure, export and reversibility. In every case, demand a clear answer from your vendor about where your data lives — and about your ability to retrieve and erase it. It is the most useful sovereignty reflex, and it costs only a question.