SQL DELETE Query Generator
Deleting data is the one SQL operation you cannot undo by running another query. This generator turns your conditions into a careful plan: count and preview the rows first, see which other tables are affected through foreign keys, delete child rows in the right order, split large deletes into batches, copy rows to an archive table before removing them, or switch to a soft delete instead.
- Runs in your browser
- No sign-up
- Free to use
How to use SQL DELETE Query Generator
- Enter the table and the conditions, one per line.
- Choose a strategy: direct, batched, archive or soft delete.
- Paste your schema to check foreign keys (optional).
- Run the preview, check the count, then run the delete.
SQL DELETE Query Generator features
Condition lines
status = cancelled, placed_at < 2025-01-01, id in 1, 2, 3.
Preview first
COUNT(*) and a sample of the rows to be deleted.
Foreign key check
CASCADE, SET NULL and blocking references from the schema.
Batches
LIMIT, TOP or key-based batches for large tables.
Archive
INSERT … SELECT into an archive table, then DELETE, in one transaction.
Soft delete
UPDATE … SET deleted_at instead of removing rows.
When to use SQL DELETE Query Generator
- Purging old logs or sessions without locking the table.
- Removing test or cancelled records safely.
- Handling a data deletion request for one customer.
- Archiving old orders before deleting them.
SQL DELETE Query Generator FAQ
Why preview first?
The count tells you how many rows the condition matches. If it is far more than expected, the condition is wrong, and you find out before any data is gone.
What does the schema check do?
It finds tables whose foreign keys reference this one and explains what happens: CASCADE deletes their rows too, SET NULL clears the link and other actions block the delete, so the plan deletes those child rows first.
When should I delete in batches?
For millions of rows. One huge DELETE holds locks for a long time, fills the transaction log and delays replicas. Batches of a few thousand rows avoid that.
What is a soft delete?
Instead of removing a row, a deleted_at timestamp marks it as deleted. Queries must then filter on deleted_at IS NULL, but the row can be restored.
Can it delete everything?
No. At least one condition is required; emptying a table should be a deliberate TRUNCATE, not a generated statement.
Is anything executed?
No. The SQL is generated in your browser for you to review and run.
Deleting data deliberately
A DELETE statement is short to write and impossible to take back once committed. Most data-loss incidents involve a condition that matched more than intended, a forgotten WHERE clause or a cascading foreign key nobody remembered. A deletion plan that previews, checks relations and runs inside a transaction removes most of those risks.
Conditions are written one per line in plain notation and combined with AND. Values are escaped for the chosen database, IN lists and BETWEEN ranges are supported, and = NULL is corrected to IS NULL because it would never match. Negative conditions get a note, since NOT IN and <> also skip rows where the column is NULL.
With the schema pasted, the generator looks at every foreign key that points to the table. ON DELETE CASCADE means the delete removes child rows too, which may be a surprise; SET NULL clears the reference; and RESTRICT or NO ACTION makes the delete fail while children exist. For those, the plan includes a DELETE for the child rows that belong to the rows being removed.
Strategy depends on size and purpose. Small deletes run directly in a transaction. Large ones are split into batches with LIMIT in MySQL, TOP in SQL Server and key-based subqueries elsewhere, keeping locks short. The archive strategy copies the rows into an archive table and deletes them under the same condition in one transaction. Soft deletes keep the rows and set deleted_at.
Whatever the strategy, run the preview first, compare the number of rows deleted with the count, and only then commit.