Drop removes a table from ClickHouse but keeps its definition, so you can deploy it again; Delete removes the table itself, and it cannot be undone. This page covers both actions, so you know what stays behind and what to read before you confirm.
A successful drop closes the dialog and confirms with Table dropped from ClickHouse, or with the message the server sends. The table is no longer deployed and keeps its definition, so deploy it again when you need it, as described in Deploy and operate a table. A redeployed table comes back empty.
If the drop fails, the message reads Failed to drop table (or the server's own), and the dialog stays open so you can fix the cause and click Drop table again.
The drop dialog runs no dependant check of its own; it always shows the same standing warning. Before you drop, open the Dependants tab and read the list; Dependants: what uses a table explains every row.
Delete removes the table itself and cannot be undone. Before it runs, the confirmation checks what depends on the table and shows you the result, the same list the table's Dependants tab shows.
<name>" that is still being used by the object(s) below. and lists the dependants, grouped by kind.The dialog also says when its list is not the whole story:
If the check cannot run at all, the dialog reads Dependants could not be determined because the check failed. Deleting may be unsafe. Never read a list like this as "nothing depends on this table".
The check only warns: it does not block the delete and does not change what gets removed, and the server still decides whether the delete is allowed. If the server refuses the delete, the dialog stays open with the reason.
Only the tables you selected are deleted. The objects in the list stay behind and keep pointing at a table that is gone until you fix or remove them.
Dropping removes the table from ClickHouse but keeps its definition, so you can deploy the table again: the data is gone and the definition stays. Deleting removes the table itself. Neither action removes the objects that depend on the table.
No. The definition stays, so the table does not disappear; it is no longer deployed, and you can deploy it again. A redeployed table comes back empty. See Deploy and operate a table.
Nothing is dropped with it. The dialog warns that anything depending on the table will break until you fix it or redeploy the table. Check the Dependants tab before you drop, so you know what to repair afterwards.
The dialog stays open next to the failure message, so you can read the reason, fix the cause, and click Drop table again. The message reads Failed to drop table, or carries the server's own wording.
Click the row, or focus it and press Enter or Space. The dialog closes first, so the object opens in front rather than behind the confirmation. Rows shown as counts (objects outside your access) do not open; ask their owners about them.
Two notices describe a partial list: Could not load every dependant, so the list may be incomplete. when part of the check failed to load, and N are not visible to you. for dependants outside your access, shown as counts instead of names. Treat the list as partial and run the check again later.
Yes, if the server allows it. The check only warns: it does not block the delete and does not change what gets removed. When dependants exist, the confirm button reads Delete anyway; if the server refuses the delete, the dialog stays open with the reason.
The dialog reads Dependants could not be determined because the check failed. Deleting may be unsafe. It means the check did not finish, so the list is short by an unknown amount. It never means the table has no dependants. Cancel and try again later.
Yes. One confirmation covers the whole selection. If you selected more tables than the check covers, the dialog says how many were not checked (N more selected table(s) were not checked.), so delete in smaller batches to have every table checked.