Skip to main content
prisma-next db sign stamps a database with a contract marker — a lightweight record stored inside the database that encodes the storageHash and profileHash of the emitted contract. The marker is what db verify reads when it checks whether a database is up to date. Signing is a precondition for using db verify --marker-only, and is automatically performed by db init and migration apply at the end of a successful run. Before writing the marker, db sign always runs a full schema verification pass. If the live database schema does not satisfy the contract, the command exits with code 1 and prints the schema verification tree — the marker is never written in a failure case. This guarantees that a signed database is always one that genuinely matches the contract.

Options

string
Database connection string. Optional when db.connection is set in your config file.
string
Path to prisma-next.config.ts. Defaults to ./prisma-next.config.ts in the current working directory.
string
Output a JSON result envelope to stdout.
boolean
Quiet mode. Suppresses all output except errors.
boolean
Verbose mode. Prints debug information and timing data.
boolean
Trace mode. Prints deep internals and full stack traces.
boolean
Force color output. Use --no-color to disable color output entirely.

Config requirements

db sign requires both a driver entry (to connect to the database) and a contract entry pointing to the emitted contract.json.
prisma-next.config.ts

Signing process

1

Load contract

Reads contract.json from the path specified by config.contract.output.
2

Connect to database

Creates a driver instance using config.driver.create(url).
3

Create family instance

Builds a ControlStack via createControlStack() and passes it to config.family.create(stack).
4

Verify schema (precondition)

Calls familyInstance.schemaVerify() to confirm the live database schema matches the contract. If verification fails, the command prints the schema verification tree and exits with code 1. The marker is not written.
5

Write marker

Calls familyInstance.sign() which ensures the marker schema and table exist, reads any existing marker, and then:
  • Inserts a new marker row if no marker is present.
  • Updates the existing row if the stored hashes differ from the contract.
  • Takes no action if the stored hashes already match (idempotent).

Output formats

JSON output

Error codes

Idempotency

db sign is safe to run multiple times. If the marker already encodes the same hashes as the current contract, no database changes are made and the command reports success. This makes it safe to include in deployment pipelines without guarding against repeated runs.

Relationship to db verify

db sign writes the marker; db verify reads it. After signing, you can confirm the marker was written correctly with:
A full db verify (without --marker-only) additionally re-runs the schema verification that db sign ran as a precondition. If db sign succeeded, db verify should also succeed unless the schema was modified after signing.