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:
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.