Using Supabase Studio

Every SupaHost project comes with its own copy of Supabase Studio, the same open-source admin interface you know from Supabase. You use it to design tables, run SQL, manage Auth users, browse Storage and write policies. SupaHost's own dashboard handles the platform side (keys, backups, domains, functions, billing); Studio handles what's inside the database.

Opening Studio

1. Sign in to the SupaHost dashboard.
2. Open the project, then the Database tab.
3. Click Open Studio. The header's Studio button does the same.

Studio opens in a new tab at the project's Studio address, for example https://app-one.studio.acme.supahost.space.

A few things to know about how that works:

• Owner only. Only the instance owner can open Studio. Invited team members can see projects and settings in the SupaHost dashboard, but they can't open Studio. See Team members.
• Signed, single-use link. The button creates a link that's valid for one minute and works once. Bookmarking the Studio URL won't let you in later; always start from the dashboard.
• 12-hour session per project. After you open it, a cookie keeps you signed in to that project's Studio for 12 hours. Each project's Studio needs its own sign-in.
• Starts on demand. Studio isn't kept running. The first visit starts it, which takes about 20 seconds, and it stops after 30 minutes without use. If the page is blank or loading for a while, that's usually why. See Studio takes a while to open.

What you can do in Studio

Studio signs in to Postgres as postgres, for writes and reads alike. In the Supabase image postgres bypasses RLS, so the SQL editor and table editor show every row regardless of your policies. To see what a real user would see, test policies with a role switch, as shown below.

Example: create a table and a policy from the SQL editor

Open SQL editor, paste this and run it. It creates a recipes table where each user only sees their own rows.

create table public.recipes (
  id bigint generated always as identity primary key,
  user_id uuid not null default auth.uid() references auth.users (id) on delete cascade,
  title text not null,
  servings int check (servings > 0),
  created_at timestamptz not null default now()
);

alter table public.recipes enable row level security;

create policy "Owners can read their recipes"
  on public.recipes for select
  to authenticated
  using ((select auth.uid()) = user_id);

create policy "Owners can add recipes"
  on public.recipes for insert
  to authenticated
  with check ((select auth.uid()) = user_id);

Then check the policy as a specific user instead of as postgres. Replace the UUID with a real user id from Authentication → Users:

begin;
set local role authenticated;
select set_config('request.jwt.claims', '{"sub":"6f1c0f7e-2b1d-4c55-9a59-0d7f4c3b8e21","role":"authenticated"}', true);
select id, title from public.recipes;  -- only that user's rows
rollback;

Where SupaHost handles things instead

Some Studio pages exist upstream but are replaced by the SupaHost dashboard, or are switched off:

Tips

• Schema changes you want to keep are better written as migrations than clicked in the table editor, so they can be replayed on a branch or another project. See SQL migrations.
• Large result sets in the SQL editor are slow to render in the browser. Add a limit while exploring.
• Long-running statements such as building an index on a big table are fine to run from the SQL editor, but keep the tab open until they finish.
• Not the owner? Ask the owner to run the SQL, or to give you an MCP access token so your AI agent can use execute_sql. See Access tokens.

Related

• Connecting to your database
• Tables, columns and data
• Row Level Security