gcsfuse VS thumbhash

It uses FUSE and there's three types of Kernel cache you could use with FUSE (although, it seems like gcsfuse is exposing only one):

1. Cache of file attributes in the Kernel (this is controlled by "stat-cache-ttl" value - https://github.com/GoogleCloudPlatform/gcsfuse/blob/7dc5c7ff...)

You're looking at Filestore because your software can only write to a mounted file system? If so, you could mount a Google Cloud Storage bucket with Fuse. I haven't used Fuse myself in production, but it may be worth trying out for your workload.

Is this the same gcsfuse that's been around for years, only now with official Google support?

https://github.com/GoogleCloudPlatform/gcsfuse

I'm pretty sure the storage for a stopped VM vs a disk image will be the same. Cheaper if you can store your data in GCS bucket? Take a look at GCS-Fuse to mount storage buckets into a VM.

Currently being tracked here: https://github.com/GoogleCloudPlatform/gcsfuse/issues/961

You may wish to investigate cloudflare's image API: https://developers.cloudflare.com/images/cloudflare-images/

If the reason you were unable to use a CDN cache was because your access patterns require a lot of varying end serializations (due to things like image manipulation, resizing, cropping, watermarking, etc.), then this API could be a huge money saver for you. It was for me.

OTOH if the cost was because compute isn't free and the corresponding cloudflare worker compute cost is too much, then yeah, that's a tough one... I don't have a packaged answer for you, but I would investigate something like ThumbHash: https://evanw.github.io/thumbhash/ - my intuition is that you can probably serve some highly optimized/interlaced/"hashed" placeholder. The advantage of thumbhash here could be that you can optimize the access pattern to be less spendy by simply storing all of your hashes in an optimized way, since they will be extremely small, like small enough to be included in an index for index-only scans ("covering indexes").

note: I haven't had time but I would live to investigate into keeping tiny thumbnails hashes in my db as mentioned in https://evanw.github.io/thumbhash/

Check the script here: https://github.com/evanw/thumbhash/blob/main/examples/browser/index.html

While it's similar to BlurHash, the color performance is much better for the same filesize. Here's a a demonstration of this from the demo page (with ThumbHash in the middle and BlurHash on the right):

Webp took a long time to get some broader adoption but it fulfills the roll of jpeg: a decent enough quality looking picture but at a reduced file size. However, it is based on the VP8 video codec. So in other words, you can think of it as a still frame of a VP8 video. This has some disadvantages because it can only load the image line by line from top to bottom (as opposed to a kind of blurry but progressively improving picture like a slow loading jpeg). So this leads to tricks like storing a very small thumbnails version and loading the actual original image. But tricks are tricks, and they're a bit annoying to deal with. For a very advanced version of this "store a small version and load that first" check this out https://evanw.github.io/thumbhash/ (it creates a blur that has the the appearance of the photo that's loading but it can do it within bytes of data).