Destructive-action safety

By default, NSchema will error on destructive actions like dropping a table or column, so you can’t cause data to be lost without opting in via the --destructive-actions option. It has three settings:

Value	Behaviour
error (default)	A destructive change fails the run. Nothing is applied.
warn	A destructive change is reported as a warning, but the run continues.
allow	Destructive changes are applied without warning.

Setting it

The destructive action policy is set by an environment variable or the command-line flag (the flag wins).

# environment variable
export NSCHEMA_DESTRUCTIVE_ACTION_POLICY=warn

# command-line flag (highest precedence)
nschema apply --destructive-actions allow

The option applies to both plan and apply.

Recommendations

• Keep the default error for normal development and CI, so a destructive change never slips through unnoticed.
• When you intend a destructive change, make it explicit: review the plan, then re-run that specific apply with --destructive-actions allow (or warn).
• Prefer renames over drop+recreate where you can. Using RENAMED FROM tells the comparer to match the existing object instead of dropping it. See the grammar reference.

Related: data hazards

Destructive-action safety guards changes that succeed and lose data. Its counterpart, data-hazard detection, warns about changes that can fail on the data already in a table, like adding a NOT NULL column without a default.

destroy is exempt

nschema destroy is destructive by design and is not protected by this policy, although it does still require the --auto-approve flag.