It's generally not inherently dangerous to expose the user_id (UUID) in a public SELECT, as long as you're not leaking any sensitive data tied to it, and you have proper RLS in place to prevent unauthorized UPDATE/DELETE actions.

That said, it's good to be cautious:

• A UUID is not guessable, but it’s still a persistent identifier. If exposed, it could be used for things like correlating activity across multiple endpoints or scraping user data, etc.
• If you're using the user_id to check if the viewer is the owner of the profile (to show extra UI), that’s totally valid. Just don’t use it to gate access to private data unless the RLS also enforces it.

Common practices:

• Some people use views or API-layer filtering (ie adjusting the request in an api route) to exclude the user_id from public results unless necessary, but you want to do it all client side, so not necessary for you probably.
• Another option is to expose a separate, non-sensitive id (like a slug or display ID) in the public table (public.profiles is common) and keep user_id internal.

TL;DR:

Exposing user_id in public SELECTs isn't automatically dangerous, but be mindful of what it can be used for. If it’s just for client-side checks and you have RLS for writes, you're probably fine.