EddytorDocs & API

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 --recursive

Heads 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

On this page