TRUNCATE TABLE instantly deletes all rows from a ClickHouse table while keeping its schema intact.
Use TRUNCATE TABLE when you need to empty data quickly but still need the table definition, privileges, and metadata. DROP TABLE removes both data and structure, forcing you to recreate the table later.
ClickHouse removes entire data parts from disk in a metadata-only operation, so the command is nearly instantaneous and does not log individual row deletions. Replicated tables broadcast the action to replicas.
Use TRUNCATE TABLE [db.]table. Optional clauses include IF EXISTS, ON CLUSTER, and SYNC/ASYNC/NO DELAY to control cluster propagation speed.
To clear all orders before a bulk reload, run:TRUNCATE TABLE Orders;
Yes. Example:TRUNCATE TABLE Orders ON CLUSTER analytics_cluster SYNC;
guarantees all nodes finish before the statement returns.
Columns, codecs, engine settings, and permissions remain unchanged. Only data parts are removed.
ClickHouse lacks full ACID transactions; TRUNCATE is atomic at the table level but cannot be rolled back after execution.
1. Wrap in a BEGIN/COMMIT block only if your client library requires explicit statement grouping.2. Use IF EXISTS in automation scripts to avoid errors.
3. Add SYNC on clusters to ensure downstream jobs read a consistent state.
Missing ON CLUSTER clause: The command runs only on the local replica, leaving other nodes with stale data. Always specify ON CLUSTER when working in distributed setups.
Accidental production truncation: Lack of a WHERE clause means all rows are dropped. Protect critical tables with separate user roles that do not have TRUNCATE privileges.
Because ClickHouse drops parts instead of rows, TRUNCATE is O(1) relative to table size. The primary cost is metadata update and, on replicated tables, background part removal.
Yes. Use ALTER TABLE [db.]table DROP PARTITION id
instead of TRUNCATE when you need targeted cleanup while keeping other partitions intact.
ClickHouse's engines like MergeTree do not have SQL-level sequences, so there is nothing to reset. Inserts continue with their own generated values.
No. Once executed, the data parts are deleted. Restore from a backup or replicated replica if available.
The action is written to the system.query_log and system.part_log tables, but individual row deletions are not recorded.