There are 2 separate things to consider for image and file data types with regard to managing uploads :
- The actual file that was uploaded to Bubble’s servers.
(This is actually Amazon storage behind the scenes - hence the “S3” in some expressions.)
- The field or fields (of type image or file) in the DB which reference the uploaded file.
(Just because an image or file field is set to “empty” - i.e. has been cleared, has no value - that does not mean the actual file it once referenced has been deleted from Bubble’s servers. You must do that explicitly. Just go to the File manager tab to see if the file is still there. If you didn’t explicitly delete it, then it is still there taking up Bubble storage.)
When you, the Bubble developer, explicitly invokes the Delete an uploaded file workflow action.
If your uploads aren’t properly managed, then yes, you will burn through your Bubble storage much faster than you would otherwise for 2 reasons:
- Users might upload images at resolutions (and thus file sizes) much higher than you actually need.
If your images are going to be used only for display on the web, for instance, then photos that are multi-megabyte in size are likely overkill and a waste of storage. If you’re running a fine art printing service, on the other hand, then maybe not. You have to make that call.
- Images that are no longer needed but have not been deleted from Bubble storage will just be sitting there taking up valuable space.
Typically, if an image is no longer needed, then the file should be deleted from Bubble storage before the DB field is cleared (set to empty) - i.e. it’s a 2-step operation.
In short, keeping image files sensibly sized before they’re uploaded and removing them when they’re no longer needed are key to properly managing your Bubble storage. Something like Upload Buddy can help with the former, as it allows client-side (in-browser) downsampling of images files, so they upload quicker and save on storage.