Managing & deleting at the S3 layer
Last-resort cleanup of orphaned object-store data Eddytor no longer tracks - and why to avoid it.
Almost always, manage tables through Eddytor so the object store and Eddytor's metadata stay in sync. Deleting at the S3 layer is a last resort for orphaned data Eddytor no longer tracks.
Delete through Eddytor (preferred)
# removes the table's Delta files AND deregisters it - storage + metadata stay consistent
eddytor delete table eddytor <schema> <table>Equivalent: DELETE /v1/for-developers/tables/{catalog}/{schema}/{table}, the
drop_table MCP tool, or the Web UI. The catalog is
always eddytor.
Last resort: delete at the S3 layer
Only for orphaned data Eddytor no longer tracks. A table is an object prefix
in the bucket. Point any 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 --recursiveHeads up
Deleting objects behind Eddytor's back leaves stale
discovery/metadata until the next discovery pass. Prefer
eddytor delete table.
Only reach for the S3 layer when Eddytor genuinely no longer tracks the data.See also
- Retire a table - the in-Eddytor delete path.
- Stale discovery / metadata.