Database

SDK Reference

These commands manage your app's database. Use them to push the schema, create and apply migrations, check status, seed data and run SQL.

On this pageSync your schema during development · Create and apply migrations · Seed, reset or query the database

void db push

Applies your Drizzle schema straight to the dev database. No migration files are created. D1 updates the local database. PostgreSQL and MySQL use DATABASE_URL from .env.

Use it to try schema changes quickly while prototyping. Before you deploy, create and review migration files with void db generate.

void db generate

Creates SQL migration files from schema changes.

It compares your schema with the last Drizzle snapshot and writes migrations to db/migrations/. It includes SDK-managed auth tables and auth plugins, even with no app schema. Review and commit the files before you deploy.

For SQLite, the SDK checks that the full migration history applies to a fresh database. If the check fails, the previous SQL, snapshots and journal are restored. If an existing migration fails, fix that unapplied migration first. Running generation again only compares snapshots. It does not fix existing SQL. The check does not prove that existing data is kept. Review table rebuilds and foreign-key actions with care.

void db status

Shows migration status. First it lists which migrations are applied or pending locally. Then it reads remote status from the saved deploy target:

• SDK projects use the hosted API.
• Direct Cloudflare SQLite projects use the pinned D1 database and its migration table.
• Direct Cloudflare PostgreSQL and MySQL projects use DATABASE_URL from the shell.

If the remote credential or service is not available, local status still shows. If the local PostgreSQL or MySQL database cannot be read, local status shows unknown. The command fails only when remote status is also missing.

void db reset

void db reset [--yes]

Drops the dev database and applies all migrations again. D1 resets the local database. MySQL drops every table and view in the database.

PostgreSQL drops the tables, views, sequences and custom types in the public schema of the DATABASE_URL database from .env. Installed extensions stay. If an object in another schema uses one of those views, sequences or types, reset stops before dropping anything. It lists those objects.

If DATABASE_URL points to a host other than localhost, the SDK names the database and asks before it drops tables. Pass --yes to skip the prompt in scripts and CI. Without a terminal, the command stops unless --yes is set.

Careful: if .env uses the same URL as your deployment, reset drops the deployed tables. This can happen after void db connect.

void db seed

void db seed [--file <path>] [--yes]

Resets the local database, applies all migrations again, then runs a seed file. The reset works like void db reset, including the prompt and --yes.

Without --file, the SDK looks for a default seed file in this order: db/seed.ts, db/seed.mts, db/seed.js, db/seed.mjs, db/seed.sql.

If more than one default seed file exists, the CLI stops. Pass --file <path> to pick one.

A seed module must export a default function or a named seed function.

void db execute

void db execute <sql>
void db execute --file <path>
void db execute --remote <sql>

Runs ad-hoc SQL against the database. Pass SQL inline or from a file. SELECT queries show results as a table. Other statements run without output.

It targets the local database by default. Pass --remote to use the deployed database selected in .void/project.json:

• SDK platform D1 projects: the query goes through the platform's registered proxy with your auth token.
• Direct Cloudflare D1 projects: the query runs on the pinned D1 binding from void.config.ts or void.lock.json.
• Hosted PostgreSQL and MySQL projects: the CLI fetches the stored connection string from the platform and connects directly.
• Direct Cloudflare PostgreSQL and MySQL projects: the CLI uses DATABASE_URL from the current shell. Cloudflare cannot return the password from Hyperdrive.

In a terminal, destructive statements such as DELETE, UPDATE and DROP ask for confirmation before they reach the deployed database. Non-interactive runs, such as CI, skip the prompt.

void db migrate

void db migrate [--remote]

Applies pending migrations to the local database without a reset. Unlike void db reset, it keeps existing data. It only runs migrations that are not applied yet.

Pass --remote to apply pending migrations to the saved target. Hosted projects need an SDK login and a linked project. Direct Cloudflare D1 projects use the binding's migration folder, table and pattern. The D1 binding must set migrations_dir. Direct PostgreSQL and MySQL projects use DATABASE_URL from the shell.

void db studio

void db studio [--remote]

Open Drizzle Studio for the database. It is a web GUI for browsing and editing your data.

It targets the local database by default. Pass --remote to open Studio on the deployed database:

• Hosted PostgreSQL and MySQL projects: the CLI fetches the stored connection string and opens Studio on it. If no URL is stored yet, run void db set-url first.
• Direct Cloudflare PostgreSQL and MySQL projects: the CLI uses DATABASE_URL from the current shell.
• D1 projects: remote Studio is not available. Use void db execute --remote to query the deployed D1 database.

void db rename-migrations

Renames existing migrations from the old number prefix (0001_name.sql) to the timestamp format (20260410161500_name.sql). It updates the local tracking table. If you are signed in with a linked project, it also updates remote records. A project that deploys to an SDK platform must be linked first with void project link. Otherwise the command stops and changes nothing.

Direct Cloudflare deploys are not supported. The SDK cannot rename records in the deployed database, so the command stops and changes nothing. Keep the existing names. New migrations use timestamps and run after them.

void db connect

This command connects an existing PostgreSQL or MySQL database, or creates one through an adapter.

Requires: database credentials

The connection string and provider keys are secrets. Pass them from your secret store or a prompt. The CLI never prints provider-created credentials.

Now you will connect a database.

void db connect 'postgresql://user:password@host/database'
NEON_API_KEY=... void db connect --provider neon --name my-app

Example output: the CLI confirms the database connection and saves it to the project.

Next, connect with a provider adapter instead. Pass the provider key as an env variable for that command only.

void db connect --provider @acme/void-db-provider --region region-id

Example output: the CLI confirms the database connection and saves it to the project.

The command saves DATABASE_URL in .env. If you are signed in with a linked SDK project, it also updates the encrypted deploy URL. Pass --local-only to skip that sync. neon is built in. Other adapters are project dependencies or local modules that export a DatabaseProviderAdapter from void/database-provider.

Credentials created by a provider are never printed. For direct Cloudflare deploys, set the same URL as a protected DATABASE_URL in the shell or CI that runs the deploy.

void db set-url

Updates the PostgreSQL or MySQL connection string for deploys. It works for projects with "database": "pg" or "database": "mysql".

It asks for a connection string. It sends the value to the platform API, which creates or updates the Hyperdrive config.

void db export

void db export [--output <path>] [--no-data] [--no-schema] [--table <name>]

Dumps the local database as SQL. It writes to stdout by default, so you can pipe it. Use --output to write a file.

Data exports keep SQLite AUTOINCREMENT and PostgreSQL SERIAL and identity counters. This includes IDs used by deleted rows. SQLite schema exports include indexes, views and triggers. PostgreSQL schema exports keep column types, generated columns, identity definitions, serial sequences, constraints and indexes. --no-schema restores counter values into an existing schema. --no-data starts counters at the values the schema defines.

For PostgreSQL schemas with views, triggers, custom types, functions or standalone sequences, use pg_dump for a full backup. void db export lists these objects before it writes a schema dump.

Flag	Purpose
--output <path>	Write to a file instead of stdout
--no-data	Schema only (no INSERT statements)
--no-schema	Data only (no CREATE TABLE)
--table <name>	Export a single table

Next steps

NextCode GenerationPreviousDeploymentZoneAll SDK Reference pages