# Switch a table name with explicit renames

Coordinator DB does not provide an `EXCHANGE TABLES` statement. A replacement workflow uses ordinary tables and documented `ALTER TABLE ... RENAME TO` operations. Plan the transaction and dependency checks before changing the name used by clients.

## Prepare the replacement

Create a new table with explicit types and constraints. Populate it, then compare row counts and representative values with the intended source boundary. `CREATE TABLE AS SELECT` does not copy source constraints, so it is not a substitute for reviewing the destination definition.

After coordinating application writes, a name switch can use a transaction:

```sql
BEGIN;
ALTER TABLE current_events RENAME TO previous_events;
ALTER TABLE replacement_events RENAME TO current_events;
COMMIT;
```

The example requires the three names to be available in the expected state. Check views, triggers, indexes and other dependencies; a rename can be rejected or affect dependent definitions. Test the whole procedure on independent data first.

## Validate before cleanup

Query the new `current_events` with application statements and confirm its constraints. Keep the previous table until the rollback decision is clear. Do not immediately drop it solely because the rename succeeded. Later application writes make a rollback a data-reconciliation decision.

See [rename syntax](https://coordinatordb.com/docs/reference/statements/rename), [CREATE TABLE](https://coordinatordb.com/docs/reference/statements/create/table) and [transactions](https://coordinatordb.com/docs/concepts/features/operations/insert/transactions).