Rationale for storing resources/images as blobs in DB?

[tconroy]

Typically, it's been considered "bad practice" to store images as blobs within the DB itself - instead it's often recommended to just store identifiers or string paths and not the asset itself.

What is the rationale for storing assets in the database in the epic stack? I tried to look through this discussion community as well as the documentation in the repo but didn't find it (feel free to link me if I missed it though!)

[kentcdodds]

Hi @tconroy,

We actually have a decision doc about this that should answer your questions: https://github.com/epicweb-dev/epic-stack/blob/main/docs/decisions/018-images.md

Recently, Fly launched https://fly.io/blog/tigris-public-beta/ which I think would be an appropriate replacement for anyone who has bigger files or would prefer to not put the images in their database.

When I get a chance to try tigris myself, I may update the epic stack to use it instead if I'm satisfied that it keeps the complexity down.

[tconroy]

D'oh -- not sure how I missed that one. Thanks for the link Kent!

I'd be really curious to try out Tigris (first I am hearing of it). Was considering adding some sort of S3 store to the mix but would prefer to stay in the Fly "ecosystem" if possible. This sounds like it would be exactly what I need.

[swalker326]

I've been very happy with cloudflare d2 for assets. Very fast and leverages all the s3 tooling from aws.