typebase-io-cli db

Move your schema in either direction: push the Drizzle schema in your project to a database, or pull a database you already have into your project. Or record your schema changes as migrations and apply those instead.

You often won't need these by hand. deploy pushes or applies migrations for the target it deploys to, and start does the same for the database your local run is using, every time something under typebase/db/ changes.

Pushing your schema

db dev push

Push your schema to the dev database.

npx typebase-io-cli db dev push

db prod push

Push your schema to the production database.

npx typebase-io-cli db prod push

db local push

Push your schema to a Postgres instance running on your own machine (Docker, Postgres.app, a managed Postgres you connect to directly, etc.).

Pass the connection string with --url:

npx typebase-io-cli db local push --url postgres://localhost:5432/mydb

Or set DATABASE_URL (in your shell or in your project-root .env) and omit the flag:

npx typebase-io-cli db local push

Options

What happens

Every db push:

1. Builds your schema files
2. Connects to your database
3. Pushes the schema changes using Drizzle Kit

Push in migrations mode

If typebase/db/migrations/ exists, push refuses to run and names the command to use instead:

This project uses migrations, so pushing would change the schema without recording it.
Run `db dev migrate` to apply your migrations instead.

It does not warn-and-proceed and does not silently redirect: a push would change the schema without recording anything, and the next migration you generated would be diffed against a snapshot that no longer describes the database.

Applying migrations

These commands exist for projects in migrations mode. They refuse to run in a project with no migrations folder, and point at db migrations init.

db dev migrate

Apply pending migrations to the dev database.

npx typebase-io-cli db dev migrate

db prod migrate

Apply pending migrations to the production database.

npx typebase-io-cli db prod migrate

db local migrate

Apply pending migrations to a Postgres running on your own machine.

npx typebase-io-cli db local migrate --url postgres://localhost:5432/mydb

As with db local push, the --url flag falls back to DATABASE_URL from your shell or your project-root .env.

What happens

Each migration runs exactly once per target, so re-running is safe. The command reports what it applied, or that the target was already up to date:

✔ 2 migrations applied.
  20260101120000_add_priority_to_todos
  20260102090000_backfill_priority

If your schema files hold changes no migration records, migrate warns and carries on, since bringing a target up to date is often what you are doing before you continue working on the schema. It never generates the missing migration for you.

Recording migrations

db migrations generate

Diff your schema files against the last recorded migration and write the difference as a new migration. Offline: no database is contacted.

npx typebase-io-cli db migrations generate --name "add priority to todos"

Generating when nothing has changed reports that the schema is up to date and writes nothing. Generating on a forked history refuses and names the competing migrations, unless you pass --ignore-conflicts.

db migrations init

Adopt migrations in a project that has been pushing its schema. Records a baseline holding the creation SQL for your current schema, and marks the databases that already have those tables as having applied it.

npx typebase-io-cli db migrations init

It asks before recording anything, and names the targets it is about to mark:

? Record a baseline for your current schema and mark dev and prod as having applied it? (Y/n)

Only targets that already have a database are inspected. Nothing is ever provisioned, so a target with no database yet is reported and skipped; it replays the baseline for real the first time you migrate it. Each existing target is compared against your schema files first, the comparison applies nothing, and a target that has drifted can be brought in line before the baseline is recorded.

Pulling an existing database

db pull

The opposite direction: read an existing PostgreSQL database and write it into your project as db/schema.ts and db/relations.ts. This is how you start from a database you already have, whether that's a Supabase project, a database from another framework, or one you run yourself.

npx typebase-io-cli db pull

The CLI asks for the connection string of the database to read, or you can pass it directly:

npx typebase-io-cli db pull --url postgres://user:pass@host:5432/mydb

What you get:

• db/schema.ts: every table in the database's public schema, as Drizzle tables written with p. Column types, nullability, defaults, primary keys (including composite ones), unique constraints, indexes, foreign keys with their onDelete behavior, enums, and views all come across.
• db/relations.ts: a q.defineRelations call with a relation for every foreign key, plus an entry for every other table (Typebase needs each table registered, even the ones with no relations).
• Regenerated _generated/ types, so the pulled tables are typed on db inside your actions right away.

A pull gives you a schema that is equivalent to the database, not a copy of the file that created it. Table order follows the database, relation names are derived from foreign keys, and anything that only ever existed in TypeScript ($onUpdate, your own relation names, your comments) cannot be read back out of Postgres. What it does guarantee is that pushing what you pulled reports no changes.

Options

Pull in migrations mode

In migrations mode a pull would orphan the recorded history, since what it writes is equivalent to the source database rather than identical to the files that history describes. So it refuses without --force:

This project records its schema as migrations, and pulling would replace the schema files that
history describes. Re-run with `--force` to pull anyway and rebaseline the history from what was
pulled.

With --force it pulls, then replaces the history with a single baseline built from what it read. Your databases still record the migrations that baseline replaced, so the pull tells you that every target has to be marked again with db migrations init. It changes nothing on any database itself.

In a project with no migrations, pull offers to start using them, since adopting is a natural thing to want at that moment. Declining leaves everything as it was.

What to watch out for

Only the public schema is read, so Supabase's storage.* tables stay behind. The one exception is a table you reference across schemas: a user_id pointing at Supabase's auth.users brings that table along as a p.pgSchema('auth') block, because the reference in the file has to resolve. The CLI tells you when that happens, and those are the lines to clean up first.

The pulled schema describes the database you read, not the one Typebase deploys to. Review it, then push it with db dev push to create the same tables on your own database, or point db local push --url at wherever you want them.