Multi-tenancy
Multi-tenancy is the practice of serving many independent customers — tenants — from one running system. In K-12 the tenants are districts, and the question the model answers is a narrow one: what specifically prevents one district's data being returned to another district's user?
| Model | What separates tenants | A leak requires | Operational cost | Upgrade risk |
|---|---|---|---|---|
| Shared schema, tenant column | A WHERE org_id = ? in every query | One missing clause in one query | Lowest | One migration for everyone |
| Shared schema, ORM scope | A default scope in the data layer | One raw query, one scope bypass, one report | Low | One migration |
| Shared schema, row-level security | Policies enforced by the database | Misconfiguration of the policy or the session role — not an application bug | Low | One migration |
| Schema per tenant | Separate namespaces in one database | A wrong search path, or a cross-schema query | Moderate; migrations run per schema | Partial failures possible |
| Database or instance per tenant | Separate databases, possibly separate hosts | A connection-routing error | Highest; per-tenant backups, patching, capacity | Long tail of version drift |
The column that matters is 'a leak requires'
Districts are usually offered this decision as "shared versus dedicated", with dedicated presented as more secure and priced accordingly. That framing hides the useful question, which is what has to go wrong.
In the first two models, a leak requires an ordinary application bug — a missing filter in one endpoint out of several hundred, a report written against raw SQL, a caching layer keyed without the tenant. These are the most common mistakes in software and they are made continuously by competent teams. In the third model, the same bug produces zero rows instead of another tenant's rows, because the filter is applied by the database beneath the application rather than by the application.
Instance-per-tenant does give the strongest theoretical isolation, and it also produces version drift, per-tenant patching backlogs and a security fix that reaches your instance three weeks after it reaches the vendor's newest customer. For most districts the realistic risk of running an unpatched dedicated instance exceeds the realistic risk of database-enforced isolation in a shared one.
The K-12 hierarchy problem
General multi-tenancy assumes tenants are flat and disjoint. Districts are neither, and three access patterns have to work simultaneously:
- District-wide. A superintendent's office sends to every household across every building. The tenant boundary is the district.
- School-scoped. A principal or front-office administrator sees their building and no other. The boundary is one level below the district, and it must be a real boundary rather than an interface filter — the whole point is that a building administrator cannot see another building's families.
- Cross-school family. A guardian with children in the elementary, middle and high school must be one person with one contact record and one set of preferences, seeing all three children. This access pattern cuts across the school boundary that the previous one enforces.
Systems that model tenancy as a single flat column handle the first two and break the third, usually by duplicating the guardian once per school — which is why so many districts have parents receiving three copies of a district-wide message. Kastr's isolation is hierarchy-aware: an organisation sees itself and its descendants and never a sibling, while people are modelled once with effective-dated roles that can span buildings.
Six procurement questions, and what a vague answer means
- What mechanism prevents a query returning another district's rows? If the answer is "our application always filters", the mechanism is developer discipline.
- What does a query return if the tenant context is missing? "It would error" is fine; "everything" is the fail-open design and it is the one that produces headlines.
- Under what database role do application queries run? If it is the table owner, any row-level security in place is exempted unless explicitly forced, and the control may be decorative.
- Is cross-tenant isolation tested automatically? A test that runs in continuous integration on every commit is a control. A penetration test from eighteen months ago is a snapshot.
- How is a guardian with children at three schools represented? The answer reveals whether people are modelled once or duplicated per building.
- Can your support staff see our data, and is that access recorded? Every vendor's support can see something. The question is whether it is scoped, time-bounded and logged.
How Kastr does it
Shared schema with Postgres row-level security, which is model three. Application queries run inside a transaction under a non-owner, DML-only role via SET LOCAL ROLE kastr_app, so the owner exemption that silently defeats RLS elsewhere does not apply. Policies are hierarchy-aware. They fail closed: with no app.current_org_id set, policies evaluate against NULL and return zero rows rather than all rows. A cross-tenant leakage suite runs in continuous integration against real Postgres 16, including a regression check specifically for owner bypass.
Identity is modelled once per person with many effective-dated role rows, so a guardian across three schools — or a person who is both a guardian and a teacher — is one record. The audit chain is per-organisation rather than one global sequence filtered by a column, which means each district's history is independently verifiable. The mechanism itself is covered at row-level security.
Questions people actually ask
Is single-tenant hosting more secure than multi-tenant?
In theory yes, in practice often not. A dedicated instance removes the cross-tenant query risk and introduces version drift, delayed patching and per-tenant operational error. Database-enforced isolation in a shared system, tested continuously, frequently produces a better real-world outcome than a dedicated instance running a build from fourteen months ago.
How is a guardian with children at three schools handled?
Correctly, only if people are modelled once and roles are separate. Kastr uses one person row with many effective-dated role rows, so the guardian has one phone number, one language preference and one consent state across all three buildings. Systems that duplicate the guardian per school are why parents receive three copies of district-wide messages.
What questions should a district ask about tenant isolation?
What mechanism enforces it; what a query returns when tenant context is missing; which database role the application runs as; whether isolation is tested in continuous integration; how a cross-school guardian is represented; and whether vendor support access is scoped and logged. Vague answers to the second and third are the most informative.
What is the most common cause of a cross-tenant data leak?
A query path that misses the tenant filter — usually a report, an export, a bulk operation or a caching layer keyed without the tenant identifier, rather than the main application code that gets the most review. This is precisely the class of mistake that database-enforced isolation converts from a leak into an empty result.
One price. Every feature. Locked for three years.
$3.50 per student per year under 5,000 students. No tiers, no add-on modules, no per-message fees. Published on the site because you should not have to book a call to learn a price.