DELETE removes one or more rows from a Redshift table using an optional WHERE filter.
DELETE keeps the table structure, permissions, and dependent objects intact while removing only the unwanted data. This is safer than DROP and more flexible than TRUNCATE when you need fine-grained control.
Filter on sort key and distribution key columns so Redshift can prune blocks quickly. Batch large deletions, then run VACUUM DELETE
to reclaim space and sort remaining rows.
DELETE targets a table, applies an optional alias, and removes rows that satisfy the WHERE clause. If you omit WHERE, every row is marked for deletion and later vacuumed.
DELETE FROM schema.table_name [AS alias]
WHERE condition;
Yes. Use a USING clause to reference another table, or embed a correlated sub-query inside WHERE. Both methods allow multi-table criteria.
DELETE FROM Orders o
USING Customers c
WHERE o.customer_id = c.id
AND c.email LIKE '%@test.com';
Rows are only marked as deleted. Run VACUUM DELETE
(or VACUUM FULL
) during low-traffic windows to free disk space and keep query plans efficient.
1) Always qualify the table with schema. 2) Test the WHERE clause with SELECT first. 3) Break very large deletes into smaller commit-sized chunks. 4) Schedule vacuum and analyze afterward.
See the next section for a full DELETE statement that removes orphaned orders.
No. Rows are marked for deletion. Space is reclaimed after VACUUM DELETE.
Yes. TRUNCATE is metadata-only and instant but removes all rows. DELETE is row-level and writes to the commit log.
Yes, as long as the transaction is still open. After COMMIT the data is unrecoverable without snapshots.