DROP TABLE permanently removes one or more tables and their dependent objects from a PostgreSQL database.
Use DROP TABLE
when a table is no longer needed and you want to free storage, clean schema clutter, or recreate it with a new design. The operation is irreversible, so verify that no critical data remains.
The basic form is DROP TABLE [IF EXISTS] table_name [, ...] [CASCADE | RESTRICT];
. Add IF EXISTS
to avoid errors if the table is absent. Choose CASCADE
to drop dependent objects such as views or foreign-key constraints. RESTRICT
(default) blocks the drop when dependencies exist.
List tables comma-separated: DROP TABLE IF EXISTS sales, customers CASCADE;
. PostgreSQL processes all names in a single transaction, ensuring either all tables are removed or none if an error occurs.
Wrap the command in a transaction: BEGIN; DROP TABLE important_data; -- review -- ROLLBACK;
. Commit only after confirming you want the change. Additionally, use role-based privileges to restrict DROP
access.
All indexes, table-owned sequences, and triggers vanish with the table. Sequences referenced from other tables remain unaffected unless CASCADE
is specified and they are dependent.
Yes. Syntax is identical: DROP TABLE IF EXISTS temp_session;
. Temporary tables are session-scoped; they disappear automatically at session end, but you can drop them sooner to reclaim memory.
Create a backup or run CREATE TABLE backup_table AS SELECT * FROM original;
before dropping. This ensures you can restore quickly if you discover you needed the data.
Adding IF EXISTS
keeps scripts idempotent, avoiding fatal errors during automated deployments when the table may already be gone.
Yes. Once committed, the data cannot be recovered unless you have a backup or are using point-in-time recovery.
No. DROP TABLE is usually faster because it simply de-registers the table’s metadata and removes its storage, whereas TRUNCATE preserves the table structure.
Yes. Provide the schema-qualified name: DROP TABLE analytics.events;