Perhaps the biggest drawback of the S3 storage system is lack of support for file systems. Also, S3 retrieval times can be slow when compared to EBS and can vary between requests. S3 will, however, support up to 5 TB of data in a single object and users can store as many objects as they like. EBS volumes are limited to 1 TB and can be attached to only a single EC2 instance. If you want to use the same EBS volume on multiple EC2 instances, you will have to replicate the EBS volume and attach the replicas to the other instances. This is a reasonable solution for applications that support primarily read operations, such as business intelligence applications
I can’t say if processor cost will be more - its a test you might want to run… but logically speaking, if everything end-to-end is on your processor, the cost is likely to be greater.
The reason Sole storage is cheaper is that 1mb image, costs 1mb. A 1mb image stored in Mongodb costs 1Mb + data structure and addressing space. This might be minimal on 1 image, but over several thousand it builds up a cost differential. Like i say, its something to consider.
I went and had a quick read of the suggest post and I think it only skims the surface and doesn’t look at potential underlying technologies that can support storage of “files” (e.g. blobs) in a database.
The Mongo GridFS is designed for this and I have been using it via the Meteor File Collection package for a production application to store composed documents and, now, for ALL the files in the system that can be requested (including branding images, replaceable documentation - like Privacy Statements, etc.) and find it performs well.
Basically they wrote GridFS and they still say that if you don’t fit one or more of these three use cases you’re better off storing the files in the filesystem,
That’s a pretty compelling argument against using GridFS just because you can.
In my case, the system has to be able to work across geographically distributed replicas and I really didn’t want to deal with some files as part of the Meteor build, others sitting out on an S3 instance somewhere, and then others (that had to be in the replica) all having completely different maintenance mechanisms.
So, I decided my longer-term use-case fits the 3rd point. It wasn’t a random decision but “need” and “convenience” based. I was previously rolling my own “store the blob in the database” system and GridFS was a clear ‘out-of-the-box’ plugin replacement.