Authentication and application access
In the hosted service, Clerk issues signed JWTs and PostgREST validates them before authenticated database access. Database grants, organization-membership helpers, row-level security policies and authorization checks in RPC functions scope ordinary application requests.
What FORCE ROW LEVEL SECURITY means
Where enabled, FORCE ROW LEVEL SECURITY subjects ordinary table owners to row policies. PostgreSQL superusers and roles with BYPASSRLS still bypass them. Security-definer functions run with their owner’s privileges and require explicit authorization checks; FORCE RLS is not a guarantee that every function or operational task obeys a tenant policy.
See PostgreSQL’s row-security documentation for these semantics.
Operational access
Database administration, migrations and service maintenance use privileged operational paths. Those permissions are separate from customer application access and must be managed as such.
Credential encryption
Monitored-database credentials are encrypted with pgcrypto. Authorized service paths decrypt them when required. Column encryption does not remove privileged service access or establish that encryption keys are absent from configuration, disks or backups.
Organization switching
The application selects the current organization for requests; server-side membership and permission checks remain authoritative. A client-supplied organization identifier alone does not grant access.