Resetting a Redshift database means dropping it (and all objects) and recreating it from scratch, optionally forcing any remaining sessions to disconnect.
Use a reset when test data has grown messy, bulk-load jobs failed, or you need a clean slate before a production back-fill. A reset is destructive, so always verify backups first.
Run DROP DATABASE dbname WITH (FORCE);
in the dev
database or another session. The FORCE
option closes all remaining connections so the drop can succeed.
1️⃣ Take a snapshot. 2️⃣ Terminate user sessions with SELECT pg_terminate_backend()
. 3️⃣ Drop the database with FORCE
. 4️⃣ Recreate the database and restore required schemas or run migration scripts.
Yes. Inside the target database run DROP SCHEMA myschema CASCADE;
followed by CREATE SCHEMA myschema;
. This avoids touching other schemas.
Wrap the DROP DATABASE ... WITH (FORCE)
and CREATE DATABASE ...
statements in a SQL script executed by the Redshift Data API or psql. Gate the script behind an environment variable such as ALLOW_DB_RESET=true
.
• Export critical tables with UNLOAD
to S3.
• Confirm no ETL is still writing.
• Use parameterized scripts to avoid hard-coding database names.
All tables, views, functions, and privileges disappear. Reapply grants and create extension-like objects after the new database is created.
The DROP DATABASE
itself is fast because metadata is removed instantly. Restoring data (COPY, UNLOAD → COPY-back) is the time-consuming step.
No. You simulate a reset by combining DROP DATABASE ... WITH (FORCE)
and CREATE DATABASE
.
User accounts stay at the cluster level, but all object-level grants inside the dropped database are lost. Re-grant after recreation.
Only by restoring from a snapshot taken before the drop. Automated snapshots in RA3 clusters help, but retention may be limited.