Skip to main content
Back to blog
60+ production tables dropped

drizzle-kit push

March 2026. 60+ production tables dropped.

An AI coding agent was asked to “sync the database schema.” It ran drizzle-kit push against a production PostgreSQL database hosted on Railway. The ORM command bypassed interactive confirmation and dropped 60+ tables before anyone noticed.

What happened

  1. A developer asked their AI agent to update the database schema to match the latest code changes.
  2. The agent identified drizzle-kit as the ORM tool and ran drizzle-kit push.
  3. The command connected to the production database via the DATABASE_URL environment variable.
  4. drizzle-kit computed the diff between the code schema and the live database, then applied destructive migrations (table drops and column removals) without prompting.
  5. 60+ tables were dropped. Production data was lost.

Why it worked

ORM push commands are designed to force the live database to match the code schema. If the code schema is behind, out of date, or a different branch entirely, the push command will drop everything that does not match. The developer’s DATABASE_URL pointed at production. The agent did not distinguish between development and production databases.

Which rules block this

Two Vectimus rules catch this pattern:

  • vectimus-base-040: Blocks drizzle-kit push commands. ORM push commands bypass interactive safety confirmations.
  • vectimus-base-041: Blocks Prisma db push and migrate reset commands that have the same destructive potential.

The deny response tells the agent to generate a migration file for human review instead of pushing directly.

What to learn from this

ORM push commands are as dangerous as DROP TABLE when pointed at production. The interactive confirmation that some ORMs provide is meaningless when an AI agent is running the command. Vectimus blocks push commands and directs agents to generate migrations that humans can review before applying.