Re: Best Strategy for Large Number of Images

From: Bèrto ëd Sèra <berto(dot)d(dot)sera(at)gmail(dot)com>
To: Estevan Rech <softrech(at)gmail(dot)com>
Cc: pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Best Strategy for Large Number of Images
Date: 2021-12-15 22:11:15
Message-ID: CAKwGa_-7D6S4PAYmVUh=TZ7fHy0VhBCoP+w-YuxBzv-s6aWBJA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> I don't currently use PostgreSQL, but I plan to migrate and I have a
question
> about the best way/strategy for storing images. I have about 2 million
images
> with a growth trend of around 1 million images per year. I plan to store
in bytea
> format in an isolated table. Is this recommended? Is there another better
way?

Do you need to edit those images? Or do you need to make sure they are not
edited, and if they are, you want to know who did it?

If so, I'd say make a versioned external repo (a git repo will do), and
have your application store a chain of SHA-1s of the file commits. If
anyone wants to alter your images behind your back, they'll need to gain
access to both the DB and the repo, and know how you pair the two
information levels (how deeply paranoid you need to be is up to
your business requirements).

If you just want to keep the images and no particular security is required,
I'd say just store them in the DB. 1.000.000/year pictures are ~2/minute,
if the flow is regular. As per your later posts they are not so big that
they could not be managed, you don't seem to expect a lot of concurrent
reads and doing it like this all you have to think of is ONE db
backup/restore procedure. This might be more complex if you expect traffic
peaks on the insert phase, of course.

Berto

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Matt Magoffin 2021-12-15 22:14:51 Re: Properly handling aggregate in nested function call
Previous Message Benedict Holland 2021-12-15 21:47:19 Re: Best Strategy for Large Number of Images