Zero Trace

A sandbox pod watches its own timing and calls the Kubernetes API to delete itself — the same delete verb this product's own RBAC grants it (see Kubernetes Install Guide), not a separate cleanup job or an operator watching from outside:

• 5-minute provisioning cap. If a sandbox never confirms it finished starting up, it's torn down after 5 minutes rather than left half-initialized indefinitely.
• 15-minute idle cap. No activity against a ready sandbox for 15 minutes, and it deletes itself. Any real use resets this clock.
• 9-hour hard cap. Unconditional, regardless of activity — a sandbox you're using continuously still goes away after 9 hours. There's no way to extend it from within a session.

All three are enforced the same way whether you're actively rebuilding the same sandbox over and over or leaving it untouched — a repeat build against an already-tracked sandbox refreshes the idle clock but never resets the 9-hour clock, so continuous reuse can't quietly defeat the hard cap.

SQL Simulator's sandboxes do not self-destruct — they're built to persist as a reusable local test environment, and are only ever torn down manually (Destroy Image) or by restarting the container. 00DB's self-destruct is the opposite choice, made deliberately for the same reason as the Zero Trust governance story: a sandbox here can reach production data, so nothing about its cleanup is left to a human remembering to do it, on any tier.

Deleting the pod removes both containers in it together — the 00DB app and its sibling database engine share one pod (see Supported Databases), so there's no separate database container left behind once the pod is gone. What this mechanism does not do: save a snapshot of the sandbox for later reuse before deleting it. If you want to keep what a sandbox produced, capture it before the relevant clock runs out — there's no "save as a test case" step today.