The obvious way to keep schools' data apart is the expensive way: a server per school, a database per school, a bill per school. It scales linearly with your customers, which is a polite way of saying it scales straight into bankruptcy. We needed isolation that's a property of the data, not a line item.
Isolation should be a property of the data, not a line item on the invoice.
Row-level security, not separate servers
Every table carries a tenant id, and PostgreSQL's row-level security enforces — at the database itself — that a query only ever returns the rows for the school you're signed into. The application doesn't have to remember to filter; the database refuses to leak. One deployment serves every school, and the free tier stays free.
The subdomain is the front door
greenfields.valryonedu.com isn't a separate app — it's the same app reading a header, resolving the tenant, and scoping every query from there. Onboarding a school is creating one row; their hub is live in seconds, not sprints.
The payoff is honest pricing. Because the hundredth school costs us almost nothing extra to host, we can charge per student instead of per seat, per module, per "enterprise edition." The architecture is the reason the business model works — and the reason a small school in a small town gets the same platform as a multi-campus network.