A Notion database that drives a site or runs a team drifts the moment you stop watching it. Tags get spelled four different ways. The status column has three values that mean the same thing. The rich-text fields fill up with a quarter of inconsistent edits. Notion's own AI helps with one page at a time, and its bulk tools stop short on a real table, so the cleanup stays a row-by-row job nobody wants to start.
Scratch pulls the whole database down as files on your computer. Your AI reads and rewrites every row there, not a sample, and about 10x faster than it works over the Notion API, because it reads the files directly instead of making a call per row. Every change comes back as a word-level diff next to the original. Nothing reaches Notion until you approve it, per row.
Scratch is the companion app to Whalesync: Whalesync keeps your Notion databases in sync with your other tools, and Scratch is where you clean the rows up first, so what syncs is already tidy.
What Scratch edits in Notion
- Database properties: titles, rich-text, select, multi-select, dates
- Relation, people, and files properties
- Cover and icon metadata
How it works
- Scratch pulls your database into files. Each row of the Notion database comes down to one local file on your laptop. Nothing touches the live workspace.
- Your AI edits the property values. 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 the database properties: titles, rich-text, select and multi-select, dates, and the relation, people, and files properties. Page bodies stay out of reach: block trees, toggles, embeds, and callouts are read-only, because the connector edits the database side, not the block side. Computed properties (formula, rollup, created_by, last_edited_by) stay locked too.
- You review every diff and publish. In the Scratch desktop app, each changed property shows next to the original, word by word. Approve what ships, and Scratch writes only the rows you approved back through the Notion API.
What teams use it for
- Clean up database tables that drive a Notion site, so the published version reads consistently.
- Normalize tags across rows, so a multi-select means one thing everywhere.
- Standardize rich-text columns after a long edit cycle of mixed formatting.
- Collapse near-duplicate select values down to one agreed option.
- Reconcile a database after a migration, so titles and properties line up again.
- Tidy relation and people properties that drifted as the table grew.
Why not let AI write straight to Notion?
An MCP server or a direct Notion API write hands the AI the publish button straight to the live workspace. It is also the slow path: every row is an API call, and on a large database it falls over. There is no diff, no review queue, no rule layer, no rollback. One confident pass rewrites every property at once, and a select value the AI invented can quietly break a view or a board that filters on it. By the time you notice, it is live for everyone, and the original property 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 property; 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
Page bodies are read-only: block trees, toggles, embeds, and callouts are never touched, because Scratch edits the database side, not the block side. Computed properties (formula, rollup, created_by, last_edited_by) stay locked and pass through untouched. 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. Optional Python validators, which the AI can author, flag edits that break a rule or touch a property you protected, right next to the diff.
Questions Notion users ask
Can Scratch edit the body of a Notion page?
No. Scratch edits the database side: the row properties like titles, rich-text, select, multi-select, dates, and the relation, people, and files properties. Page bodies stay read-only, so block trees, toggles, embeds, and callouts are never changed. If your content lives in database properties, Scratch edits it. If it lives in the page body blocks, it does not.
Will it overwrite my formula and rollup columns?
No. Computed properties (formula, rollup, created_by, last_edited_by) stay locked. The AI can read them for context, but they pass through untouched and never write back, so the values Notion computes for you are left exactly as they were.
Can the AI invent a select value that breaks my views?
It is guarded against. Optional validators check against your existing option sets, so the AI cannot quietly introduce a new select or multi-select value that breaks a board or a filtered view. Anything questionable is flagged next to the diff, and nothing writes back until you approve it.
Is this faster than Notion's built-in AI on a big database?
Yes, on the work itself. Notion's built-in tools stop short on a real table; on local files the AI reads every row at once and works about 10x faster than over the API, because it reads files directly instead of making a call per row. The exception is write-back, which runs at the Notion API's own speed for the rows you approve.
See it on your own Notion
The fastest way to trust it is to watch it run on one of your own databases. Pull a table down, point your agent at it, and read the first diff.