Why doesn't Supabase recommend using the service_role key on the client?

The service_role key is designed to connect to Postgres as a role that has RLS_bypass privileges built in — it doesn't just have broad permissions, it explicitly skips the Row Level Security checks that every other connection is subject to. That makes it functionally equivalent to a database superuser for the purposes of the API.

If that key ships inside a mobile app binary or a public web bundle, anyone who inspects the network traffic or decompiles the app can extract it and use it to read or write any row in any table, completely ignoring the ownership and access rules the rest of the app depends on. This is categorically different from leaking the anon key, which is meant to be public and is still constrained by RLS — a leaked anon key is a non-event by design, while a leaked service_role key is a full data breach.

In practice, the service_role key should only ever be used from environments a client can't inspect: Edge Functions, a backend server, or CI/CD scripts running migrations, and ideally stored as an encrypted secret rather than an environment variable checked into source control.