The fallacy of Bubble's "expensive" storage

I’ve seen reference made to Bubble’s “expensive” storage a number of times across the forums. When it comes to images specifically, I’d like to share some information gleaned from my close look at Bubble’s image handling a while ago.

  • By default, images added to a Bubble site (and which do not have privacy enabled) are NOT served from Amazon AWS S3 storage.

This applies to most (or all) of the images on a “typical” Bubble site - i.e. images used as design elements as well as those uploaded by users to share publicly.

While S3 is used to store the “master” file, Bubble’s tight integration with Imgix ensures that images are automagically processed according to the dimensions of the element and served from Imgix’s optimized servers. This can dramatically improve the performance of a site - especially for mobile users - and it happens automatically, seamlessly, and behind the scenes.

Consider, for example, adding an image to a repeating group. Simply plop an image element into a cell, size it to taste, and you’re good to go. Now click “preview”. When the RG is rendered on the page, the originally uploaded image (which could potentially be megabytes in size) has been automatically converted to a thumbnail (downsampled and scaled) and served from a wicked fast CDN - all without giving “image optimization” a thought.

This is just one way in which Bubble provides value by simplifying and streamlining web app development. That’s not to say it wouldn’t make sense in some instances for certain media types to explore 3rd party storage options, but I’m actually choosing to use Bubble storage for an image intensive app I’m developing. Why? Because I value time and simplicity.

YMMV :slightly_smiling_face:

15 Likes