Recover a dropped table

A destructive migration moves a dropped table aside with its rows intact, keeping it recoverable for 30 days before a background job removes it for good.

A destructive migration parks what it removes instead of dropping it: a table moves aside with its rows intact, a dropped column is renamed in place, and either is preserved for 30 days before a background job drops it for good.

1. Check what is preserved

tide parkedtideout

KIND     OBJECT                          RECOVERABLE FOR    STATE
table    atlantis.consumer_cart          22d                recoverable
column   atlantis.consumer_order.notes   6d                 recoverable

The console’s Parked page shows the same objects, with the date each one was parked. An object under 7 days from reaping is highlighted. tide parked --all includes objects already reaped — those rows are gone, and only a platform backup restore brings them back.

The window is an absolute instant fixed when the object is parked; changing the retention setting later does not move it.

2. Restore it

Re-add the entity or field to the .atl file exactly as it was — git revert the commit that dropped it — then:

tide plan
tide apply

The apply moves the parked object back: the entity exists again, with its API, its generated types, and the rows it held when it was dropped.

Two conditions on the restore:

The re-declared columns must match the parked object’s. A declaration whose column set differs is refused, naming the mismatch — restore first with the original declaration, then change it in a second apply.
The window must still be open. Re-declaring after the reaper has run creates a fresh, empty object; the rows are gone, and only a platform backup restore brings them back.

Verify

A query through the generated client returns the pre-drop rows, and the object no longer appears in tide parked.

tide parked — flags and output.
Schema history — finding the version that dropped the object.
Change approval — why destructive changes wait for a decision.