Файлы в базе считают плохой идеей. Но в реальности они все равно постоянно там оказываются: нужно хранить запрос с подписью в одной транзакции, тянуть документы ради аудита, мигрировать с Oracle, где файлы уже лежат в БД через DBMS_LOB.

Проблема в том, что если просто сложить файлы в таблицу в PostgreSQL, то вы быстро упретесь в технические барьеры.

Простые таблицы с bytea/text по умолчанию не принимают данные больше 1 ГБ — получите ERROR: file length too large. При массе тяжелых вставок система начинает дробить данные на TOAST-чанки, сжимать их, крутить BufferIO и BufferMapping, и вставка внезапно тормозит.

Хранилище больших объектов pg_largeobject кажется выходом, но и там лимит: до 32 ТБ и примерно 4,2 млрд строк, секционирования нет, удаление строки с OID в пользовательской таблице не чистит сами данные, миграции и обновления усложняются, а при параллельных вставках процессы упираются в блокировку OidGen.

В Postgres Pro Enterprise, начиная с 16 версии, есть специальные модули:

✔️ pgpro_sfile — хранит большие объекты внутри БД, убирает потолки TOAST и pg_largeobject, размер хранилища и число объектов зависят только от диска и bigint.

✔️ pgpro_bfile — работает с файлами на диске, а в базе держит только ссылки на них, по модели Oracle BFILE.

✔️ dbms_lob — эмуляция Oracle DBMS_LOB (CLOB/BLOB/BFILE), которая позволяет переносить приложения с минимальными изменениями кода.

В статье на Хабре рассказали, где в ванильном PostgreSQL начинаются проблемы с файлами и как Postgres Pro Enterprise позволяет хранить сотни терабайт файлов, а не бороться с лимитами.