EddytorDocs & API
07 · Tables A→ZN · Retire (irreversible)

Last resort: orphaned data at the S3 layer

Cleaning up object-store data Eddytor no longer tracks - and why to avoid doing it.

Almost always, retire a table through Eddytor so storage and metadata stay in sync. Deleting at the S3 layer is a last resort for orphaned data Eddytor no longer tracks.

Prefer the in-Eddytor delete

eddytor delete table eddytor <schema> <table>

This removes the table's Delta files and deregisters it - consistent. Equivalent: drop_table (MCP), DELETE /v1/for-developers/tables/{catalog}/{schema}/{table} (REST), or the Web UI.

Last resort: the S3 layer

Only for orphaned data Eddytor no longer tracks. A table is an object prefix. Point an S3 client at the endpoint - for bundled Garage that's http://127.0.0.1:3900, region us-east-1, creds = GARAGE_ACCESS_KEY / GARAGE_SECRET_KEY from .env:

export AWS_ACCESS_KEY_ID="$GARAGE_ACCESS_KEY" AWS_SECRET_ACCESS_KEY="$GARAGE_SECRET_KEY"
EP="--endpoint-url http://127.0.0.1:3900 --region us-east-1"
aws s3 ls s3://eddytor/ $EP --recursive            # find the table prefix
aws s3 rm s3://eddytor/<path-to-table>/ $EP --recursive

Heads up

Deleting objects behind Eddytor's back leaves stale discovery/metadata until the next discovery pass. Prefer eddytor delete table; reach for the S3 layer only when Eddytor genuinely no longer tracks the data. See Stale discovery / metadata.

This is the table-lifecycle view of the same operation covered, from the storage side, in Managing & deleting at the S3 layer.

Next

On this page