# Using Supabase Studio

> How to open Supabase Studio for a SupaHost project, what works in it (table editor, SQL editor, Auth, Storage, policies), what's switched off, and how sessions work.

Source: https://supahost.app/docs/database/studio · Updated 2026-11-11

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](/docs/platform/team).
- **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](/kb/studio-slow-to-open).

## What you can do in Studio

| Area | What it's for |
|---|---|
| Table editor | Create tables and columns, edit rows, set foreign keys, import CSV |
| SQL editor | Run any SQL as the `postgres` role, save snippets |
| Database | Functions, triggers, indexes, extensions, roles, enumerated types |
| Authentication | Browse, create, invite and delete Auth users; write RLS policies |
| Storage | Create buckets, upload and browse files, write Storage policies |
| API docs | Generated docs for your tables and functions, with supabase-js snippets |
| Edge Functions | A read-only view of the functions deployed to the project |

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.

```sql
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*:

```sql
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:

| You might look for | On SupaHost |
|---|---|
| Logs and Reports | Not available in Studio. See [Studio Logs and Reports pages are missing](/kb/studio-logs-reports-missing). Edge Function logs are on the project's **Functions** tab. |
| API keys and project URL | *Project → **Connect** → **App*** |
| Auth settings (site URL, redirect URLs, OAuth providers, email templates) | *Project → **Auth** tab*. Changes made there are applied within about a minute. |
| Deploying Edge Functions | *Project → **Functions** tab*, or the MCP server. Studio's page is a read-only copy. |
| Backups and restore | *Project → **Backups** tab* |
| Cron jobs | *Project → **Cron** tab*, or `cron.schedule()` in SQL |

## 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](/docs/database/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](/docs/platform/access-tokens).

## Related

- [Connecting to your database](/docs/database/connecting)
- [Tables, columns and data](/docs/database/tables)
- [Row Level Security](/docs/database/row-level-security)