Data Security in Education Software: Why Row-Level Security Matters
Application-level permission checks and database-enforced Row Level Security look similar in a demo. They behave very differently the day a bug ships.
Every ERP vendor will tell you their platform is secure. Almost none will tell you, unprompted, exactly where that security is enforced, and it's worth asking, because two systems that look identical in a sales demo can behave completely differently the day something goes wrong.
Two different places to enforce access control
Most software checks permissions in application code: before showing a page or running a query, the code checks "does this user have permission for this?" and either proceeds or refuses. This works, until a single code path forgets to check, or a new feature is shipped without the same guard the rest of the app has. The database itself never questions the query it's asked to run; it trusts the application layer entirely.
Row Level Security (RLS), a feature of PostgreSQL, among other databases, moves that check into the database itself. Every query, no matter which part of the application issued it, is filtered by policies the database enforces directly. A query that tries to read another institution's data, or another department's, doesn't get an empty result because the application remembered to filter it. It gets refused because the database itself won't return rows the policy doesn't allow.
Why this matters more as a system grows
- New features are added faster than any team can perfectly re-verify every existing permission check by hand. A database-enforced policy doesn't rely on every new code path remembering to check.
- A multi-tenant platform (one system serving many institutions) has the most to lose from an isolation bug. RLS makes that isolation a property of the data itself, not a promise made by application code.
- Audit and compliance conversations get simpler when you can point to a policy enforced at the data layer, not a claim about what the application is supposed to do.
What to actually ask a vendor
"Is tenant and role isolation enforced by the database, or only by the application?" is a question worth asking plainly, and a vendor with a real answer will have one immediately, not a follow-up call. If the answer is "our application checks permissions carefully," that's not the same guarantee, no matter how carefully it's said.