Row-level security (RLS)
Row-level security tells the database to return only rows that belong to the current restaurant, blocking cross-tenant leaks. It is a Postgres feature that sits below the application code, so a bug in the app cannot accidentally show one tenant’s data to another.
What it means in operation
Every table in a multi-tenant database carries a tenant id. With RLS turned on, the database adds an automatic where clause to every query: tenant_id equals the current session’s tenant. A developer who writes “select all menu items” gets only the items for the logged-in restaurant. A bug that forgets the where clause still returns the right scope. MobiTaste sets the tenant id at the start of each request from the authenticated user, and the database does the rest. The cost is a small per-query overhead, usually under one millisecond.
Why it matters
The history of SaaS data leaks is mostly forgotten where clauses. App-level filtering works until it does not, and the failure mode is one customer seeing another customer’s data on a routine page. RLS makes that class of bug structurally hard. For hotel IT reviewers and group security teams, “RLS enabled at the database” is a yes-or-no checkbox that means the vendor took isolation seriously. For owners, it means a junior developer cannot ship a bug that exposes your menu to a competitor down the street.
Related terms
- Multi-tenant: the architecture RLS enforces.
- Audit log: the trail that records who saw what.
- Organization: the tenant unit RLS scopes by.