Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

To drop all tables in PostgreSQL, first decide whether you need to remove the table objects or only empty their rows. DROP TABLE removes table definitions and associated objects; TRUNCATE clears rows while keeping the tables. For a wholly disposable schema, DROP SCHEMA ... CASCADE removes every object in that schema, not just its tables. The examples below make the scope explicit so you can choose the least destructive operation that achieves your goal.

Choose the operation by what you need to remove

Operation What it removes Dependency and operational effects
DROP TABLE The named table objects, including associated indexes, rules, triggers, and constraints. By default, PostgreSQL restricts the drop if other objects depend on a table. CASCADE recursively removes dependent objects.
DROP SCHEMA ... CASCADE All objects contained in the named schema, including non-table objects. Can also remove dependent objects outside that schema.
TRUNCATE Rows in the named tables; table definitions remain. Takes ACCESS EXCLUSIVE locks, does not fire ON DELETE triggers, and can include referencing tables when used with CASCADE.

PostgreSQL’s DROP TABLE documentation distinguishes dropping a table from emptying it: use DELETE or TRUNCATE to remove rows without destroying the table. PostgreSQL documents the dependency and locking behavior in its dependency-tracking guide and TRUNCATE reference.

Drop a known list of tables

If only specific table objects should go, name them explicitly. PostgreSQL accepts multiple table names in one statement. The default behavior is RESTRICT, which refuses to drop a table when dependent objects remain.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
DROP TABLE app_schema.old_orders, app_schema.old_customers;

Schema-qualifying names helps make the intended boundary visible. If PostgreSQL reports a dependency, read the DETAIL output and decide what should happen to that object. Do not add CASCADE just to suppress the error: it can remove dependents recursively. For a foreign key that references the dropped table, the referencing table remains; its foreign-key constraint is removed.

Only use CASCADE when you have reviewed and intend to remove the dependent objects too:

DROP TABLE app_schema.old_orders CASCADE;

The PostgreSQL 18 DROP TABLE reference documents the command’s object effects, while the dependency-tracking guide explains RESTRICT and recursive CASCADE behavior. Check the documentation for the PostgreSQL version installed on your server before running production DDL; the cited command references are versioned, and the dependency guide is for PostgreSQL 17.

Remove everything in a dedicated schema

If the schema itself is disposable, dropping it can be simpler than listing its tables. This command removes every object within app_schema, not merely tables, and may remove objects in other schemas that depend on those objects:

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
DROP SCHEMA app_schema CASCADE;

Confirm that the name is the intended schema and that its contents and dependencies are within the deletion boundary. PostgreSQL’s DROP SCHEMA reference describes the objects removed by CASCADE and warns that dependent objects can be affected.

Stage destructive DDL in a transaction

A transaction can give you an opportunity to inspect the result before making it permanent. Run the operation and inspection in the same session; if the result is wrong, issue ROLLBACK instead of COMMIT.

BEGIN;
DROP SCHEMA app_schema CASCADE;
-- Inspect the result in this session using catalog views,
-- or use the appropriate client commands.
-- If correct:
COMMIT;
-- If incorrect, issue ROLLBACK instead of COMMIT.

PostgreSQL documents ROLLBACK as canceling changes in the current transaction. This protection ends when the transaction is committed; it is not a substitute for a backup. Confirm how your SQL client handles transactions and autocommit before relying on this workflow.

Clear rows while keeping the tables

Use TRUNCATE when the goal is an empty table, not a deleted table definition:

What’s actually slowing this PC down?

Pick the symptom - the matching free tool is one click away.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
TRUNCATE TABLE app_schema.events, app_schema.audit_log;

To restart sequences owned by truncated columns, add RESTART IDENTITY:

Best Value
Postgresql: Developer's Handbook
  • Used Book in Good Condition
TRUNCATE TABLE app_schema.events RESTART IDENTITY;

By default, PostgreSQL refuses to truncate a table if other tables have foreign-key references to it. CASCADE can include those referencing tables, so inspect that scope before using it. Truncation takes ACCESS EXCLUSIVE locks and does not fire ON DELETE triggers; account for those effects if applications or other sessions may be using the tables. PostgreSQL documents these details in its TRUNCATE reference.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Verify scope and recovery before committing

  1. Confirm the connection. Verify that your client is connected to the intended database, not merely a database with a familiar schema name.
  2. Review the target boundary. List the tables or confirm the schema name and its contents before choosing a table-level or schema-level operation.
  3. Inspect dependencies. Prefer the default RESTRICT behavior while discovering what depends on the targets. Treat every reported dependency as a decision, not an obstacle to bypass.
  4. Check your recovery route. PostgreSQL supports SQL dumps, file-system-level backups, and continuous archiving as distinct backup approaches. pg_dump exports one database; its custom and directory archive formats support selective restoration. A completed dump command alone does not establish that your backup is restorable or meets your recovery-point needs.
  5. Commit only after inspection. If using a transaction, verify the result in that transaction and commit only when it is correct. Otherwise, make sure the recovery plan is available before executing the change.

See PostgreSQL’s backup and restore documentation for the documented backup methods and recovery options. A database-level pg_dump is not a cluster-wide backup.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.