RENAME TABLE instantly changes the table name—or even moves it to another database—without copying data.
Renaming keeps naming conventions consistent, lets you reflect business changes, and helps you test new schemas without duplicating data. ClickHouse performs the change atomically, so queries observe either the old or new name—never an in-between state.
The command supports single or multiple renames in one statement. You can rename inside the same database or move a table between databases as long as the table engines match.
RENAME TABLE ecommerce.Orders TO ecommerce.CustomerOrders;
This updates all metadata references immediately. Existing queries using ecommerce.Orders
fail after the rename, so update application code at the same deploy step.
RENAME TABLE staging.Products TO analytics.Products;
Both databases must reside on the same cluster, and the destination name must be free. Moving large tables is instant because ClickHouse only updates metadata.
RENAME TABLE ecommerce.Orders TO ecommerce.Orders_2023,
ecommerce.OrderItems TO ecommerce.OrderItems_2023;
The operation is transactional—either all names change, or none do—avoiding partial updates during migrations.
Bundle renames with application code changes, document the migration in version control, and back up system.tables
metadata before running bulk renames.
Renaming across clusters or mismatched engines fails; use ATTACH
+ DETACH
or CREATE TABLE AS
instead.
Only a metadata lock is taken, lasting milliseconds. Reads and writes pause briefly but no data is moved.
Yes, but run the command on all replicas or through ZooKeeper-aware DDL replication to keep metadata in sync.
Yes. Grants are tied to UUIDs, not names. After the rename, users retain their privileges.