Explain the execution flow of a request through Supabase's auto-generated API?

When a client calls supabase.from('posts').select('*'), the request travels through several distinct layers before a row ever comes back.

1. The client SDK builds an HTTP GET request to /rest/v1/posts, attaching the API key and, if the user is signed in, an Authorization: Bearer <jwt> header.
2. The request hits Kong, Supabase's API gateway, which routes it to the PostgREST service and can apply rate limiting.
3. PostgREST verifies the JWT, extracts claims like the user's role and auth.uid(), and opens a Postgres connection as that role rather than as a superuser.
4. Postgres compiles the query, and because the connection is running as the authenticated (or anon) role, every Row Level Security policy on posts is evaluated as part of the query plan — not as a separate check afterward.
5. Only rows that pass the policy are returned, serialized to JSON by PostgREST, and sent back through the gateway to the client.

The key architectural point is that authorization isn't a middleware step bolted onto the API; it's inseparable from the SQL execution itself, which is what makes it consistent no matter which client or tool issues the request.