# Apply an explicit retention cutoff

Coordinator DB does not document automatic table TTL processing. Apply retention with an explicit `DELETE` whose predicate expresses the cutoff you intend. Schedule that maintenance in the application or your own operations process if it must recur.

First preview the affected range:

```sql
SELECT count(*) AS expired_rows
FROM events
WHERE day < '2025-01-01';
```

Then use the same predicate for the change:

```sql
BEGIN;
DELETE FROM events WHERE day < '2025-01-01';
SELECT count(*) AS remaining_expired_rows
FROM events
WHERE day < '2025-01-01';
COMMIT;
```

Check the preview and ensure the intended backup or archive exists before executing the deletion. The transaction groups these steps but does not choose a safe business cutoff for you. Use `ROLLBACK` if the verification is wrong.

For timestamp columns, specify the precise timestamp and timezone convention instead of assuming a date label describes every boundary. Deletion takes effect in the current transaction; there is no background TTL queue whose completion makes it final. If using HTTP, all transaction statements must be in the same request.

See [`DELETE`](https://coordinatordb.com/docs/reference/statements/delete), [transactions](https://coordinatordb.com/docs/concepts/features/operations/insert/transactions) and [database copies](https://coordinatordb.com/docs/concepts/features/backup-restore/overview).