Plenty of content lives in Supabase with no CMS in front of it. Blog posts, product copy, and a knowledge base sit in Postgres tables, and editing them means writing SQL by hand or building an admin panel you do not want to maintain. So the cleanup waits. The slugs are inconsistent, the descriptions are half-written, the JSON columns have drifted, and there is no good way to fix a few thousand rows at once without risking the ones you cannot see.
Scratch pulls a table down as files on your computer. Your AI reads and rewrites every row there, not a sample, and about 10x faster than it works against the database, because it reads the files directly instead of running a statement per row. Every change comes back as a word-level diff next to the original. Nothing reaches Supabase until you approve it, per row.
Scratch is the companion app to Whalesync: Whalesync keeps your Supabase tables in sync with your other tools, and Scratch is where you clean the rows up first.
What Scratch edits in Supabase
- Text and rich-text columns in any user-defined table
- JSON and JSONB columns
- Slug, title, and description fields
- Row-level edits without schema changes
How it works
- Scratch pulls a table into files. Each row becomes one local file on your laptop. The Supabase
authandstorageschemas are excluded from discovery, so user accounts and uploaded files are out of scope from the start. - Your AI edits the prose columns. Open the folder in the agent you already use. Try a prompt on a few rows, then let it run across the whole table. The AI edits text and rich-text columns, JSON and JSONB columns, and slug, title, and description fields, row by row, with no schema changes. Primary keys, foreign keys, timestamps, computed columns, and check constraints stay where they are. Validators enforce your column constraints so the AI cannot write something the database would reject.
- You review every diff and publish. In the Scratch desktop app, each changed column shows next to the original, word by word. Approve what ships, and Scratch updates only the rows you approved through the standard Postgres driver.
What teams use it for
- Clean up content tables (blog posts, product copy, knowledge base) that live in Supabase with no CMS layer in front of them.
- Normalize slugs and titles across a table so the published URLs and headings are consistent.
- Fill in or tidy description fields that were left half-written.
- Reshape and standardize JSON and JSONB columns that drifted over time.
- Run a tone or rename pass across every row of a content table in one reviewed batch.
- Reconcile a content table after a migration, so the prose columns line up again.
Why not let AI write straight to Supabase?
An MCP server or a direct database write hands the AI a live connection to production Postgres. It is also the slow path: every row is a statement, and on a large table it falls over. There is no diff, no review queue, no rollback. One confident pass rewrites every row at once, and a single bad UPDATE against a live content table can quietly corrupt copy that your site renders straight to visitors. By the time you notice, it is already serving, and the original column value is often gone.
Scratch gives the AI the same full read and write access, but against a local copy. The publish step is pulled out and handed to you. The AI can change any editable column; only you commit it. And every published row is reversible on its own, so a bad pass is never a one-way door.
What's safe, and what's locked
Primary keys, foreign keys, timestamps, computed columns, and check constraints stay untouched: the AI can read them for context, but they never write back. The Supabase auth and storage schemas are excluded from discovery, so user accounts and uploaded files are out of scope entirely. Validators enforce your column constraints, so the AI cannot write a value the database would reject. You bring your own AI: Scratch holds no AI credentials and runs no model, so you sign into Claude, Claude Code, Codex, Cursor, Copilot, Cline, or Windsurf the way you already do. Nothing leaves your machine until you publish, every published row is reversible per row, and the whole thing is Git-backed from the first sync.
One thing to know: the service role Scratch uses bypasses Row-Level Security, so it can read and write any user-table regardless of the policies on it. If you need a connector that honors RLS, ask Curtis. It is a roadmap question, not a code one yet.
Questions Supabase users ask
Can Scratch touch my auth or storage data?
No. The Supabase auth and storage schemas are excluded from discovery, so user accounts and uploaded files are out of scope. Scratch works on your user-defined tables: the text, rich-text, JSON, JSONB, slug, title, and description columns. Account records and file storage are never pulled and never edited.
Will it change my schema, keys, or constraints?
No. Scratch makes row-level edits with no schema changes. Primary keys, foreign keys, timestamps, computed columns, and check constraints stay where they are and never write back. Validators also enforce your column constraints, so the AI cannot write a value the database would reject.
Does it respect my Row-Level Security policies?
Not yet. The service role Scratch uses bypasses Row-Level Security, so it can read and write any user-table regardless of the policies on it. A connector that honors RLS is a roadmap question, not something that exists in code yet. If you need it, ask Curtis.
Is this faster than running UPDATE statements myself?
Yes, on the work itself. Hand-writing SQL means one statement per change and a careful WHERE clause every time. On local files the AI reads and rewrites every row at once and works about 10x faster than against the database, because it reads files directly instead of running a statement per row. The exception is write-back, which runs at the Postgres driver's own speed for the rows you approve.
See it on your own Supabase
The fastest way to trust it is to watch it run on one of your own content tables. Pull a table down, point your agent at it, and read the first diff.