DROP TABLE permanently removes a table definition and all its data from the current database.
Drop a table when it is obsolete, replaced, or created by mistake. Removing it keeps your schema tidy and speeds up backups.
Use DROP TABLE [IF EXISTS] table_name [CASCADE | RESTRICT];
. IF EXISTS prevents an error if the table is missing. CASCADE removes dependent objects such as foreign-key constraints or views; RESTRICT (default) blocks the drop if dependencies exist.
DROP TABLE IF EXISTS ParadeDB;
This avoids an exception in automated scripts.
DROP TABLE IF EXISTS ParadeDB, Customers_Archive, Orders_2022;
Separate table names with commas. All specified tables are removed in one statement.
DROP TABLE ParadeDB CASCADE;
CASCADE also deletes such items as views or foreign keys that reference ParadeDB. Use cautiously in production.
Wrap the command in a transaction: BEGIN; DROP TABLE IF EXISTS ParadeDB; ROLLBACK;
. Verify the impact, then re-run with COMMIT.
Always back up data, run inside a transaction when possible, double-check table names, and prefer IF EXISTS to keep CI/CD pipelines idempotent.
Suppose you copied product data into a staging table during a bulk import:
DROP TABLE IF EXISTS Products_staging;
Removing the staging table frees disk space once the import succeeds.
Yes. Once the command commits, PostgreSQL marks the pages reusable and the operating system eventually reclaims space.
Only by restoring from a backup or running inside a transaction that you roll back before commit. After commit, the data is unrecoverable.
Locking prevents concurrent writes during the drop, but the operation is usually quick. Large tables may hold locks longer, so schedule during low traffic.