Skip to main content
S3 deletes here are real on-chain deletes. The track comes off the tape’s commitment with a Merkle proof, and the freed capacity returns to the tape (the semantics). The same prerequisites as uploads apply: a write-scoped credential and the tape’s delegation.

​
DeleteObject

Deletes one object by key. It follows the S3 standard for idempotency: deleting a missing key succeeds with 204, so retries and sync tools behave.

​
Deleting many objects

Bulk deletion works through the tools you already use: rclone’s purge or delete against a prefix, the aws CLI’s recursive rm, or a direct DeleteObjects call.
A DeleteObjects request (POST /{bucket}?delete) carries up to 1000 keys and reports a per-key result: <Deleted> on success, <Error> with a code and message when a key fails, and quiet mode returns only the failures. Missing keys count as deleted, matching S3, so retried purges converge. A failing key never fails the batch. Under the hood every key is still its own on-chain delete, and the gateway submits them one at a time: each delete rewrites the tape’s track commitment, so deletes on one tape cannot run in parallel or collapse into fewer transactions. A large purge is many sequential transactions; expect throughput of roughly one object per confirmation, not one request.

​
What deletion means here

Deletion removes the data from storage and serving and frees the capacity. It does not shorten history: the original write remains part of the chain’s record (tracks). Buckets themselves are not deleted through S3. A bucket is a tape, and tapes run to their expiry (tapes).