{
  "id": 2388950,
  "title": "How to Drop All Tables in PostgreSQL Safely (2026)",
  "url": "https://urgent.news/2026/08/21/how-to-drop-all-tables-in-postgresql-safely-2026",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-21T14:32:35.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/mahdi_benrhouma_fe1c6005/how-to-drop-all-tables-in-postgresql-safely-2026-1a47"
  },
  "original_language": "en",
  "account": "This article explains how to safely drop all tables, views, sequences and functions in the public schema of a PostgreSQL database. The easiest way is to run the single command DROP SCHEMA public CASCADE; which removes the entire public schema and all its dependent objects. However, this command is destructive and should only be used when resetting a local development database or when a migration has gone wrong.\n\nA key gotcha to be aware of is that starting with PostgreSQL 15, the public schema no longer grants the CREATE privilege by default. This change was made to follow secure-schema best practices. As a result, if you run DROP SCHEMA public CASCADE; on a PostgreSQL 15+ database, it will recreate the empty public schema with the new secure defaults. Your application role or the anon/authenticated Supabase roles will no longer have CREATE privilege on public, causing migration or insert errors.\n\nTo avoid this issue, you need to explicitly grant the CREATE privilege to the roles that actually need it, such as your application role. In addition, Supabase users should note that the anon and authenticated roles also require USAGE on public, otherwise queries will fail. Extensions installed in the public schema, such as uuid-ossp, pgcrypto, and pg_stat_statements, will be dropped along with the schema. If these extensions are needed, they must be reinstalled after recreating the schema.\n\nIf you want to keep extensions and functions intact during a reset, it's better to drop tables individually rather than dropping the entire public schema. This can be done by querying the pg_tables view to iterate over each table in the public schema and dropping it with CASCADE. After reloading data, you can also reset the sequences for any serial columns.\n\nFor production Supabase projects, it's strongly advised not to use DROP SCHEMA public CASCADE on a live database, as it could accidentally delete Supabase's internal objects and break the dashboard or authentication system. Instead, use the controlled reset provided by the Supabase CLI or dashboard, which recreates the schema from your migration files. If a production reset is unavoidable, it's better to restore from a recent backup instead.",
  "summary": "Why you are here You ran a migration that went sideways, or you are resetting a local dev database, or a test suite needs a clean slate. The psql console has 40 tables and you do not want to type DROP TABLE 40 times. There is a one-command way to do it. There is also a PostgreSQL 15 change that silently breaks it the first time you try, and a Supabase-specific caveat that makes the naive command…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}