Run EXPLAIN on your Supabase schema at 100,000 rows. In the browser, before you ship.

demo result · computed by the same engine

FAILSEQ_SCAN_AT_SCALEsrc/query.ts:5supabase.from('posts').select('id, title, created_at').eq('author_id', authorId).order('created_at', { ascending: false }).limit(20)

100,000 rows scanned → 10

create index "posts_author_id_idx" on "public"."posts" ("author_id")

rows scanned vs table size, measured at each size (log scale) — current · with fix

Try it on your schema

schema — your migrations, or the output of supabase db dump --schema-only

create extension if not exists pgcrypto;

create table public.profiles (
  id uuid primary key references auth.users (id) on delete cascade,
  username text not null unique,
  display_name text,
  bio text,
  avatar_url text,
  created_at timestamptz not null default now()
);

create table public.posts (
  id uuid primary key default gen_random_uuid(),
  author_id uuid not null references public.profiles (id) on delete cascade,
  title text not null,
  body text not null,
  published boolean not null default true,
  metadata jsonb not null default '{}'::jsonb,
  created_at timestamptz not null default now(),
  updated_at timestamptz not null default now()
);

create index posts_created_at_idx on public.posts (created_at desc);

alter table public.profiles enable row level security;
alter table public.posts enable row level security;

create policy "profiles_select_all" on public.profiles
  for select to anon, authenticated using (true);
create policy "profiles_update_own" on public.profiles
  for update to authenticated using ((select auth.uid()) = id) with check ((select auth.uid()) = id);

create policy "posts_select_published_or_own" on public.posts
  for select to anon, authenticated using (published or (select auth.uid()) = author_id);
create policy "posts_insert_own" on public.posts
  for insert to authenticated with check ((select auth.uid()) = author_id);

query — a Supabase JS chain (.from(…)) or plain SQL

structural layer (fetches splinter.sql from github.com/supabase/splinter — the only network request this page can make)

starting Postgres in your browser (PGlite)…

Nothing to install, no database connection: the whole pipeline runs in a Web Worker on a real Postgres 18 (PGlite), and your schema never leaves this tab.

Deterministic: same input, same report, byte for byte, here and in the CLI. Structural checks are splinter's (Supabase Advisor); fixes are applied to the sandbox and re-explained before they are called fixes.

How it works, the numbers behind it and the CLI / GitHub Action: README · github.com/yilinguo121/pggate (FSL-1.1-MIT).