Start with the trust boundary
A browser's role selector, URL parameters and client-side filters are not authorization controls. In a multi-tenant application, each query must be constrained by a trusted identity and explicit database policy. PostgreSQL row-level security (RLS) can enforce row access even when a caller directly queries an exposed table.
Pair grants with policies
RLS does not replace SQL privileges. Define which database role may access a table at all, enable RLS, and grant only the operations each role needs. Use identity values verified by your authentication stack, and make sure UPDATE rules control both which rows may be changed and the ownership of the resulting rows.
Test the negative cases
A useful test suite verifies not only that an authorized tenant can read a record, but also that a different tenant cannot read, insert, update or infer it. Check views, functions, object storage access and real-time subscriptions separately; not every subsystem inherits database RLS automatically.
How UnDataly approaches it
UnDataly treats RLS verification, signed JWT validation and cross-tenant isolation as release blockers, not optional features. The current local data-plane exercise tests these boundaries; the public service is not yet available.
Frequently asked questions
Are these UnDataly features available now?
Guides explain general architecture patterns. The linked UnDataly managed features are planned or in development unless otherwise marked.