Define the tenant boundary
When several organisations use one application, a tenant boundary needs to hold across the database, APIs, background jobs, exports and support tools. A filter in the interface alone cannot provide that boundary. The design should state who is allowed to see each record and test those rules at every path into the data.
What RLS can enforce
PostgreSQL row-level security (RLS) can enforce policies on rows read or changed by a database role. It is a useful control for a shared database, but it is not automatic isolation. PostgreSQL documents important exceptions: superusers, roles with BYPASSRLS and, by default, table owners can bypass policies. Application roles, ownership, policy coverage and privileged operations all need review.
Choose the right design
A shared schema with RLS and separate databases per tenant are both viable designs. The right choice depends on the data, isolation requirements, operations and recovery needs. A design review should include migrations, backups, exports and incident response as well as ordinary requests.
Test the boundary
A practical test is to run each sensitive operation as one tenant and try to read or change another tenant's data, including through search, attachments, queued jobs and administrative paths. Keep those tests in the release process. If the system handles regulated records, assess a suspected cross-tenant exposure under the applicable privacy and sector rules rather than assuming any one legal outcome.