Schema
The spreadsheet that builds your schema
Add a column in the grid and a real column appears in your database — with the migration previewed first, rows, locking behaviour, SQL and all.
Every no-code tool gives you a spreadsheet. The question is what's underneath it. In most of them the answer is a proprietary store, and the spreadsheet is the whole truth. In SchemaStack, the spreadsheet is a view onto a real Postgres or MySQL database you own — and editing it edits the database's structure.
Add a column in the grid: a real column appears, with a real type. Link two tables: a real foreign key, or a real junction table for many-to-many. Add a validation rule: a constraint the database itself enforces. The person shaping the data doesn't need to know they're doing DDL. Their developer colleagues get sensible SQL structures they can point any application at.
Which raises the obvious, correct objection: you're letting non-DBAs run migrations on a production database?
The dry run is the point
No structural change applies blind. Ask for one — through the UI or through an AI agent — and you first get the answer without the change:
- does this need a migration at all, or is it metadata-only?
- how many rows are affected?
- will reads or writes block while it runs, and on which database engine?
- the exact SQL that would run.
Locking behaviour differs by engine, and the preview is honest about it:
| Migration | Postgres | MySQL |
|---|---|---|
| Column type change | blocks reads & writes | blocks writes only |
Add NOT NULL | blocks reads & writes | non-blocking |
| Add unique constraint | blocks writes | blocks writes |
Most migrations take seconds. The preview exists for the ones that don't — the type change on the ten-million-row table is exactly the change you want to schedule, not discover.
It works on the database you already have
None of this assumes an empty database. Point SchemaStack at an existing Postgres or MySQL and it imports the schema — tables, columns, keys, relationships — and the same grid-edits-schema loop continues from there. If something else alters the database behind our back, drift detection notices and sync reconciles it.
Agents get the same discipline
The same dry run is a tool on the MCP surface (preview_column_change), which changes what it's sane to let an AI assistant do. An agent with schema access can propose a change, show you the impact report, and only then apply it — and an agent without schema access (which is every agent connected via OAuth) can't get past the preview at all.
What it doesn't do (yet)
- No undo after apply. The preview is a look before the leap, not a rollback. Applied DDL is applied; plan type changes on large tables like the production operations they are.
- Some renames — primary keys in particular — aren't supported as in-place operations.
- Computed columns are virtual (evaluated at query time); syncing them after external schema changes has rough edges we're still working through.
- The dry run reports; it doesn't yet schedule ("run this at 02:00").
The schema migrations guide covers the mechanics, and database compatibility lists exactly which database features are fully, partially or not yet supported — in those words.
Verified 20 Aug 2026: backend MCP schema, data and constraint tool suites run against a real Postgres (Testcontainers); the live schema + query journey re-checked every 5 minutes by production synthetics; engine locking matrix as documented in the schema-migrations guide.