SQL · Queries that survive scale
What is the difference between DELETE and TRUNCATE?
Short answer
DELETE removes selected rows, fires row triggers, and can be rolled back. TRUNCATE removes all rows quickly, usually resets storage and identity state, and has different locking and rollback behavior.
DELETE is a DML operation with a WHERE clause. It removes rows one by one logically, can fire row-level triggers, and is fully transactional in most engines. TRUNCATE is a fast bulk operation that deallocates pages instead of visiting every row.
DELETE FROM sessions
WHERE expires_at < now();
TRUNCATE TABLE staging_events;Key differences
- DELETE supports WHERE and can remove a subset; TRUNCATE removes all rows
- DELETE fires row-level delete triggers; TRUNCATE usually does not
- TRUNCATE takes a stronger lock and can block concurrent readers or writers
- TRUNCATE is much faster on large tables because it does not scan row by row
- TRUNCATE often resets identity or sequence state; DELETE does not
- TRUNCATE may be blocked by foreign key references in some engines
- Both can be rolled back in PostgreSQL, but behavior varies by database
Use DELETE when you need row predicates, triggers, or fine-grained control. Use TRUNCATE for staging tables, test resets, or bulk cleanup where removing everything is intended and the locking impact is acceptable.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1Does TRUNCATE fire delete triggers?
- 2Which operation is faster on a large table and why?
- 3Can TRUNCATE be rolled back?
- 4What happens to identity columns after TRUNCATE?
Say it in the interview
DELETE removes rows that match a condition and behaves like normal DML, including row triggers and transactional rollback. TRUNCATE removes everything by deallocating pages, so it is much faster but takes a stronger lock and usually skips row triggers. I use DELETE for targeted cleanup and TRUNCATE for staging resets or full-table clears where the locking trade-off is acceptable. I verify engine-specific behavior around identity reset and foreign keys.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live SQL mock interview and get scored feedback on depth, clarity and confidence.