loading...

Storing Image File (binary) vs Image Base64 in Database

khophi profile image Nkansah Rexford ・1 min read

Using frameworks like Django, the file is saved onto the harddrive, and a link pointing to the file is rather stored in the Database, which is fine.

In my current API approach for uploading content, I submit the form, the part where there are images using the standard form data posting (the usual multipart/form-data).

So I simply cook up a payload that mimics the usual form-data submit using Angular, then push to an endpoint that accepts the form data submission.

Recently, I'm thinking of going full base64 images.

As in,

  • User selects image to upload
  • Behind the scenes (on the browser), I encode the image to base64 string
  • User submits form, then the usual JSON payload is sent with the image field as base64

So something like:

{ data: 'string'
  image: 'base64 string'
}

I've done the base64 image approach some time ago, and it was great (at least to me).

Are there any performance issues with going with base64 image strings for storage in Database? Any caveats to look out for?

Posted on by:

khophi profile

Nkansah Rexford

@khophi

Flutter, Django, Angular, Firebase & YouTubing

Discussion

markdown guide
 

Are there any performance issues with going with base64 image strings for storage in Database? Any caveats to look out for?

I feel like you could lose a few benefits. Here are some things that come to mind:

  • You're no longer making use of databases/services that specialize in storing these kinds of files (like Amazon S3)
  • You're no longer able to serve images via CDN in the same conforming way.
  • Are you planning on sending the base64 images over the wire with the HTML for future use? Depending on the size of the images that could cause problems (you probably don't want the initially request to be the size of many images when you could otherwise send them asynchronously)
  • When in doubt, conforming to a convention is probably better than doing it your own way.

I might not have your full context or could be missing something. Would love others' input to validate or invalidate my thoughts on the issue.

 

Thanks Ben.

You're no longer able to serve images via CDN in the same conforming way.

True, didn't think of that. Scaling with embedded base64 could be catastrophic.

Are you planning on sending the base64 images over the wire with the HTML for future use?

Yes, send the images over the wire along with the HTML.

(you probably don't want the initially request to be the size of many images when you could otherwise send them asynchronously)

Noted.

Great points there, something for me to ponder over. Thanks.

 

Ben pretty much nailed it, in can you are wondering how much space it would take for an image to be saved in db, just upload some small image on this tool codebeautify.net/base64/image-to-b... and count the characters :)

 

Is referential integrity between images and other parts of your data model important? If so, you're probably alright but remember to store and index metadata to make searching the table efficient if you need to do that for any reason. You're not going to power something the scale of Google Image Search out of that but you almost certainly aren't trying to do that anyway.

If you don't need referential integrity or if you have a lot of image data coming, then you might be better off storing them on a distributed filesystem like Mongo's GridFS, or in someone's cloud.

 

You're not going to power something the scale of Google Image Search out of that but you almost certainly aren't trying to do that anyway.

Of course, but from Ben's points below, I imagine even a slight growth in traffic could topple the system with embedded images.

then you might be better off storing them on a distributed filesystem like Mongo's GridFS, or in someone's cloud.

Yep. Thanks.

 

I think caching might be the biggest issue. Normal images from CDNs are cached and the browser, but I dont think the base64 strings are.