Why Generated SQL Is Never Auto-Executed
Quick answer: The modeling package has no executing driver. Every DDL, index, and deployment script is generated for review, and the software cannot run it against the database itself. The deployment script is idempotent
Quick answer: The modeling package has no executing driver. Every DDL, index, and deployment script is generated for review, and the software cannot run it against the database itself. The deployment script is idempotent and forward-only, so a person confirms each change before it is applied. This keeps a proposed migration from reaching the storage without a review.
Why auto-execution is the wrong default
A generated migration can look complete while carrying an assumption the reviewer should catch. An inferred link table, an open question, or a field diff that touches a shared table all need a decision, and running the SQL the moment it is generated would remove the pause where that decision happens.
The blast radius of a schema change is large and hard to reverse, so the default should favor review rather than speed. Keeping the executing driver out of the package enforces that boundary in the tooling rather than relying on discipline alone.
What the package can and cannot do
| Capability | Available? |
|---|---|
| Generate DDL and indexes | Yes |
| Generate deterministic seed data | Yes |
| Write deployment scripts | Yes |
| Execute writes or DDL | No |
| Execute a driver against the database | No |
The same package that produces the SQL deliberately lacks the ability to run it, so there is no hidden path where a generated change reaches the storage unconfirmed.
How a change actually reaches the database
- Review the four-layer reconciliation and the table status.
- Read the field diffs and the impacted operations.
- Resolve the open questions and confirm the inferred items.
- Review the generated SQL and the forward-only deployment script.
- Apply the change through your own controlled process.
The script is idempotent, so running it more than once does not produce duplicate changes, and forward-only means it moves the schema ahead rather than reversing earlier migrations. Those properties make the reviewed script safe to run, but the decision to run it stays with the team.
Picture a migration that adds a link table and a foreign key. The generated SQL is complete and internally consistent, but the link table is inferred from a relationship the business rules actually treat as one-to-many, and the open question is still attached. If the package could execute the script, the wrong join table would be created before anyone reads the note. With the executing driver absent, the reviewer opens the inference, resolves the cardinality, and only then runs the corrected script. The same protection catches a field diff that touches a shared table, because the pause is where the impacted operations get checked. This does not slow the happy path much, since a fully reviewed script still runs in one controlled step, but it removes the path where a confident-looking migration reaches the storage unconfirmed.
How this fits the safety model
This is the same boundary that keeps read-only access and static signals honest. The tool can read a live database through a saved profile and generate precise SQL, but it does not write, and a read-only SELECT is the only query the data layer runs. Writes and DDL are blocked at the connection layer.
Treat the generated SQL as a detailed proposal, not a pending action, and keep the execution step separate and deliberate. A script that cannot be triggered automatically cannot be triggered by accident.
Powerduck keeps the review and the execution separate by design, so every schema change is confirmed before it touches the storage.
Frequently asked questions
Can the tool run the migration for me? No. The modeling package has no executing driver, and SQL is generated for review.
What makes the deployment script safe to run? It is idempotent and forward-only, so it avoids duplicate changes and does not reverse earlier migrations.
Are writes blocked entirely? The data layer runs only a read-only SELECT, and writes and DDL are blocked.
The bottom line
The generated SQL is a reviewed artifact, not an executed action. With no executing driver in the package, every DDL and migration waits for a person to confirm it, and the idempotent, forward-only script makes the eventual run safe without making it automatic. This keeps a hard-to-reverse schema change from reaching the storage by accident. The line between generating and executing is the core safety control. Read more in the API data model guide.
Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.