Generate & run migrations

Schemic generates migrations by diffing your schema against a recorded snapshot. This guide is the loop you run as you evolve a schema: author, preview, generate, apply. For the model behind it, see the migration model. Migrations run against the embedded PGlite engine from your config — there is no server to start.

Preview the change

Before generating anything, schemic diff shows the pending structural change without writing a file. On Postgres it introspects your live database and compares your schema against it — gen, below, diffs against the recorded snapshot instead:

shell
npx schemic diff
driver: postgres
user
+ "bio" text
 
1 change — 1 added, 0 changed, 0 removed.

Generate a migration

Edit your schema, then run schemic gen with a name describing the change. gen diffs the schema against the snapshot and, if anything changed, writes a <timestamp>_<name>.sql file with up and down sections. When nothing changed it tells you so and writes nothing:

shell
npx schemic gen add_bio
1 change — 1 Field.
 
-- schemic:up
ALTER TABLE "user" ADD COLUMN "bio" text;
 
-- schemic:down
ALTER TABLE "user" DROP COLUMN IF EXISTS "bio";
 
✓ 20260626114301_add_bio.sql (+1 up / 1 down)

Commit the generated .sql files. They are the reviewable, version-controlled record of how your schema evolved. The migration contains only the delta — adding a column emits ALTER TABLE "user" ADD COLUMN "bio" text, not a full table rewrite.

Apply pending migrations

schemic migrate (alias up) applies every pending migration in order, against the PGlite database from your config:

shell
npx schemic migrate
↑ 20260626114301_add_bio
 
✓ Applied 1 migration.

Check status

schemic status shows which migrations are applied and which are pending:

shell
npx schemic status
✓ applied 20260601000000_initial
· pending 20260626114301_add_bio
 
2 migrations, 1 pending.

Roll back

schemic rollback (alias down) reverts applied migrations newest-first, running each migration’s down section:

Shell 
npx schemic rollback            # revert the most recent
npx schemic rollback 2          # revert the last two

Seed data

Seeds live in database/seed/ — TypeScript files that each export default defineSeed(async (db, ctx) => { … }). db is the connected client; ctx.file(name) reads a supporting file (raw .sql, JSON, …) sitting next to the seed and returns it as a string, and ctx.dir is the seed’s directory. defineSeed types both db and ctx, so there are no extra type imports. schemic seed runs index.ts (or every seed in filename order if there is none); schemic seed <name> runs one; --all runs them all. A leading NN- prefix orders a seed but is not part of its name (01-users.ts is the seed users).

database/seed/01-users.ts TypeScript 
import { defineSeed } from "@schemic/postgres";

export default defineSeed(async (db, ctx) => {
  await db.exec(ctx.file("schema.sql")); // exec runs the whole .sql script; query is single-statement
});
Shell 
npx schemic seed            # index.ts, or every seed
npx schemic seed users      # one named seed
npx schemic seed --all      # every seed, in filename order

Validate the schema

schemic check --schema validates your schema definitions without touching the database. (Full migration replay is not yet supported on the Postgres driver — check validates the schema only.)

Shell 
npx schemic check --schema

Where to go next