From what you have said: Nah, seems fine. The closest thing from my experience is PDFs. For certain small services I’ve run I’ve stored generated PDFs as binary and it’s worked fine.

My only advice is to probably segregate it to a dedicated table where your general model holds a foreign key to it. While Ecto makes it pretty easy to query it even if you put it as a regular column on your table it is often annoying to integrate with other postgres clients, and if your overall row count is as low as you say the cost of having it in another table shouldn’t really matter.

A few other considerations related to the benefits of using a DB are worth considering:

1. Do your binaries have to reside the closest possible to your data ? If the binaries (image, PDF, …) are meaningless without the accompanying data or the other way around, the data is meaningless without the binary, then it might be necessary to store the binary in the DB, close to the data. For example, operators might write reports on the field and take pictures to augment it, which means the report may be unusable if the pictures are not present. The data and the binaries cannot be unlinked contrary to what might happen with a file outside the DB.
2. Data and binary are backed up together. It is due to point 1.
3. You benefit from ACID properties due to using DB transactions.

My only experience of storing images in the DB goes back about 20 years - when we stored (tiny) avatars in the DB. However on further reading I learned that this was only really an option intended for people who could not set the appropriate permissions on the file system (usually because of the type of (more restrictive) hosting they might have had) and that the file system was preferred. Sure enough switching to the file system made everything feel much snappier, even on forums with just a couple thousand members.

Not sure how far DBs have come, or whether the possible bottleneck might effect you in your situation but I always remember what @joeerl said whenever I hear someone talk about storing images in a DB:

On top of that you have to consider things like back-ups, DB size, what happens if the DB becomes corrupted, etc, so personally I would avoid storing images in the DB if at all possible.

^{But you may be ok in your use-case if you take into account what @benwilson512 and @mindok have said above.}

for un-compressable image data, you may want to disable compression:

I’m all for it for small images (e.g. thumbnails). I’ve done quite a lot of extracting and databasing 128x128 images into SQLite, SQL Server & Postgres recently - admittedly the images are relatively small - 5-15k. Everything is self-contained and performance is great for LiveView front ends - you can push the images to LiveViews over web sockets (Base64 encoded first) which reduces chatter over the network connection (at the expense of slightly larger payloads).

As usual, though, there are tradeoffs to consider. Traditional web-serving of the images will be a little trickier from db rather than disk (not much harder, but you would need to write a controller rather than just use Plug.Static), and you won’t be able to edit the images in a normal editor without a bit of fiddling around.