Resetting a database in ClickHouse removes all objects (tables, views, data) and optionally recreates the database, returning it to a clean state.
Teams reset databases when they need a clean slate for testing, staging refreshes, or after destructive experiments. The operation drops every object in the target database, freeing disk space and eliminating residual data.
ClickHouse has no single RESET keyword. The safe pattern is: DROP DATABASE IF EXISTS, then CREATE DATABASE with the same name. Dropping with the SYNC option guarantees completion before the command returns.
1) Revoke user access to stop new writes. 2) Back up schemas if needed. 3) RUN DROP DATABASE db_name SYNC
. 4) Recreate the database. 5) Restore schemas or run new DDL. 6) Re-grant access.
ecommerce_db
The snippet below drops ecommerce_db
, recreates it, and immediately rebuilds core tables (Customers
, Orders
, Products
, OrderItems
) so applications can reconnect without errors.
You need the DROP DATABASE
and CREATE DATABASE
privileges, or the higher-level ALL
. Grant these to an admin-only role to prevent accidental resets.
Always run resets in a transaction-safe environment such as maintenance windows. Keep recent backups. Use SYNC to block until metadata is removed; otherwise, subsequent CREATE might race and fail.
Dropping the wrong database, forgetting backups, and leaving users connected are typical errors. Double-check the database name, test on staging first, and disable connections during the operation.
Yes. Use TRUNCATE TABLE database_name.*
to empty every table while keeping metadata. This is safer if downstream apps rely on existing schemas.
Files are removed asynchronously, but the SYNC modifier forces the server to wait for completion before returning control.
Run SHOW CREATE TABLE database_name.table_name
for each table and save the output, or copy the metadata files from /var/lib/clickhouse/metadata
.