How do you store images?
I want to know all the options I have. And cheapest/simplest way.
FYI: I don't use AWS
Right now, I'm storing images as base64 in the database and it's easier because they are among text.
But I need to add files as attachement and I'm not really sure what to choose.
Right now I'm looking at:
- external service https://www.ovhcloud.com/en/public-cloud/object-storage/
- docker volume
- good old folder on the host's hard drive (headache incoming)
- PostgreSQL
What's your goto solution?
Trending on Indie Hackers
You should try S3 from AWS; it's pretty cheap and pretty simple to use. I'm making a service with thousands of assets and images, and I started using S3 for the first time, and it is pretty easy to use. In my case, I'm storing like 30GB, and it costs ~1$/month.
I also use S3 for my projects. I use localstack to have an s3 environment running locally so I don't need to upload images to s3 during local development, which is quite useful.
The only thing I worry about with S3 is that if you don't remove older versions of uploaded images from S3, you are potentially paying for a lot of unused assets, which irks me a bit. That being said, I haven't ever reached the scale where this is an issue.
You can configure to not have old versions, don't you? you can configure also an expire, so if an old version has more than X days, it will be removed
Ah perhaps, haven't delved too much into all the features of S3 and how best to structure things within a bucket.
I use them too. AWS has a great Python library called "boto3" that covers all the functionality and easy to use.
Database
The benefit of storing images in a database is that these are co-located with business data. So, you'd have transactional support for them (given you use a transactional DB). It often makes it easier do reason about the images from a code perspective. However, base64 is quite large and managing backups for blobs might also be more difficult. Manually managing images might also get difficult. Performance might also be worse than file system at some point.
Docker Volume / Host Hard Drive
A docker volume is effectively the same as a folder on the hard drive eventually, you can just mount this folder into a container (or multiple ones). When you're already using Docker, this is probably the best and only way to store images outside of a database without external services.
External Services
I'd say OVH
islooks pretty similar to AWS / Azure / Google Cloud. I'm personally always concerned with testability, integration and not vendor-locking too fast. If you already have an existing server and authentication system, you need to think about how to integrate these services properly. Other than that they scale pretty well and you get a UI to manage files.At SceneLab we use a mixture of cloud services and docker volumes depending on whether the images are user-generated or part of our product. So, no real goto solution. I'd say it depends a bit on the importance of your images, how often they're updated, how much you expect to have and how you can integrate external services. If you don't mind to elaborate on your use-case, I might be able to provide some more specific advice.
You're the second developer I've seen mention OVH as a good alternative to the main players in the cloud space. I was tempted to use it as an alternative to Digital Ocean, but the digital ocean droplets are, from what I've heard, much easier ressources to create/destroy than the servers that OVH can provide.
I've been on OVH for 15 years (for pro or hobby purpose) and always been happy with it.
The thing is, sometime you are on your own. DO gives tons of tutorials where OVH guides are a bit lightweight.
Droplets are VM and OVH VM's are here if you want to get an idea:
https://www.ovhcloud.com/en/public-cloud/compute/
I have a sandbox one and it's cheap and easy to use.
Ok awesome, good to know. Their prices are enticing and I have a former colleague that loves their services (e.g. VMs).
I might've misphrased that. I've no experience with OVH, just assumed that be very similar to the other mentioned cloud solutions.
Ah, ok.
Thanks a lot for you reply.
Right now, I need it for a trello-like dashboard where you can put cards and attach files to them.
The number of files per card will be limited to 3, and file's size limited to ~2mb.
Number of cards is unlimited though.
Right now, my solution is hosted on a VM but I'm thinking of installing Docker on it to add more services easily (Redis, Storage, Messaging ...)
I'm not big on docker (mostly because I work on Windows with my PC's) but I realize now that it would be very useful.
Thanks for your time.
Well, so the images are probably all user-uploaded. Then I'd say just dump them into a bucket (S3, GC, Azure, whatever you see fit) based on a reproducible path e.g. containing the card-id
Maybe DigitalOcean's Spaces are something for you. They are compatible with the S3 API which means every library that supports S3 will also work:
https://www.digitalocean.com/products/spaces/
Spaces is great. I use it for all my personal stuff.
I'd look at https://cloudinary.com/ if you want a hosted service
If you do use S3, I'm not a fan of having to use lambda functions to resize etc... so I put a http://thumbor.org/ instance in front of S3 to satisfy all my image manipulation requirements.
Storing images in a Database will definitely get expensive at scale and impact IO. Unless you are storing a few images and caching aggressively (in your app/edge tier), I would not recommend that approach.
I have used cloudinary and this has worked for me many times. I am also looking at imagekit.io. (To OP) Depends on how many images we are taking about. Terabytes of images is very different storage requirement compared to a few hundred small images. Regardless I would avoid storing in a database at all cost.
If you looking for cheaper S3 storage you can look for https://www.backblaze.com/b2/cloud-storage.html 10GB free, they also have tight integration with Cloudflare.
Other alternative I am using is DigitalOcean Spaces.
https://www.digitalocean.com/products/spaces/ starting with $5.
Don't do that. Base64 encoded images take up a lot of space and they are also computationally heavy.
Can't you use the filesystem of your hosting? If not then I would recommend using Cloudinary or something similar.
you may want to have a look at digital ocean spaces.It's cheaper than s3.
I'd echo a lot of what others are saying regarding AWS S3. I don't think there's really a viable alternative, at least in terms of cost and scale. I have used Cloudinary in the past for smaller projects since they handle almost everything for you, but it can get costly depending on how much media you're dealing with.
Check https://cloudinary.com/pricing (store images + some kind of managing digital assets)
Google Cloud Storage and store the key in firestore.
s3 from aws with presigned url
Cloud Storage from GCP
yes, I use S3 from AWS so I don't need to store them in docker containers or k8s servers.
Maybe write more about your project first. Every project can benefit a bit more from different approaches and hosting solutions. Generally speaking, object storage is a great way to go, especially if you think you will grow really fast. On a small project I prefer to just use a folder on the disk (attached storage). It's cheaper and more simple.
ovh support is non-existent. I would avoid ovh at all costs. When it's working, all is good, but when you have an issue, you have literally no support. I have opened a ticket the May 02, and still no answer. (even for my other 5 others tickets)
That's why they have a very bad score at trustpilot.
Digital Ocean/VULTR is a great alternative
This comment was deleted 4 years ago.
This comment was deleted a year ago.
This comment was deleted 4 years ago.
This comment was deleted a year ago.
This comment was deleted 3 years ago.
I wanted to understand the cost difference between Firebase and AWS when it comes to larger image based applications.
Could anyone put that here!
This comment was deleted 3 years ago.
That was a quick reply @anilkilic. Thanks for this information.
This comment was deleted 4 years ago.