How to delete previously uploaded attachments? (currently replaced by some others)

Hi!

Previously, I uploaded an attachment to Airtable (let’s say A), using API. Now, I have replaced it with some other (let’s say B).

Now, generally since A was replaced with B, there should be no trace left of A - right?
But actually, when I go to the URL of A, the image is still visible.

Should I assume it’s still there in my base, still holding 1mb (size of A) of my Attachment space? Since I have replaced it, why is it still viewable?


So, is it possible to make Airtable delete the image permanently, so it doesn’t occupy space in my attachments limit of 5GB? Or any workaround for this?
I don’t want to keep track of previous images, and if user replaces it, the previous one should be permanently deleted, and the new one would appear from then.

Any help would be great :smiley_cat:
Thanks! :)

1 Like

Hey there! I believe it’s actually just version history, if you’re referring to the feed on the right hand side of your record? I don’t believe this counts towards any limits.

Can you share a screenshot so we can see what you mean?

1 Like

I have often wondered this myself but had not run into a use case yet where I needed to know.

The persistence of the attachment might be related to history and the ability to undo/restore data. If you want to restore an earlier snapshot of a base when it had the first attachment, you would expect the prior attachment to still be there. Thus, the prior attachment still needs to be saved somewhere.

It is also possible for the same attachment to be stored in multiple records and possibly even multiple bases. Thus, it can be hard to tell if an attachment is still being used or not.

It would be nice if Airtable created a method of managing files in attachment space so that we could clean up that space if necessary. Of course, the current workaround is to upgrade a workspace to get more attachment space.

2 Likes

Thanks for the replies @kuovonne @andywingrave! :smiley_cat:


I am fine if it keeps the history - but would it occupy my attachment space even if it’s replaced?
For example, if 1st file is A - 5mb, and it’s replaced with B - 7mb.
So, at the end of the day, 7mb of my space would be occupied? I think it would be occupied till my revision time limit - right?

Thanks!

@Kartik
That’s probably a question best answered by Airtable directly.

I would personally expect that you would be using 12mb until you past the revision history time limit for deleting file A. However, I don’t know the details, and it might not work that way.

You can try creating an attachment in a free workspace, storing the url somewhere, deleting the attachment, and then waiting two weeks for the revision history to expire, and checking the url for the attachment again.

@kuovonne Would definitely try this, thanks!


Till the above process how can I catch Airtable’s attention here?

Thanks! :smiley_cat:

The only way I have seen that completely resets the attachment occupation is to delete the record, reinstantiate it as a new record with the new attachment(s).

Thanks @Bill.French for the idea! :smiley_cat:

Unfortunately, this idea/solution won’t be feasible for me, because

  • a) I have a very large audience - 10s of people are accessing the data p/second. So, within the time the row gets deleted, and new row appears, things might go wrong …
  • b) I am keeping record of the rows by their unique _id everywhere - so continuously updating the records will not be easy too.

So, the best thing left for me would be going along with the database, and if I am about to reach my attachment limit, I would upgrade to the next plan. Currently I am on the Plus Plan, which provides 5GB for Attachments, and record history of 6 months.

Thanks!

Yep - not a useful strategy where immutable records are required.