Tienes básicamente dos opciones. Puede almacenar los datos directamente en la fila o puede usar la función de objetos grandes. Dado que PostgreSQL ahora usa algo llamado TOAST para mover campos grandes fuera de la tabla, no debería haber una penalización de rendimiento asociada con el almacenamiento de datos grandes en la fila directamente. Queda un límite de 1 GB en el tamaño de un campo. Si esto es demasiado limitado o si desea una API de transmisión, puede usar la función de objetos grandes, que le brinda algo más como descriptores de archivos en la base de datos. Almacena la ID de LO en su columna y puede leer y escribir desde esa ID.
Personalmente, le sugiero que evite la instalación de objetos grandes a menos que la necesite absolutamente. Con TOAST, la mayoría de los casos de uso están cubiertos simplemente usando la base de datos de la manera esperada. Con los objetos grandes, se genera una carga de mantenimiento adicional, ya que debe realizar un seguimiento de los ID de LO que ha utilizado y asegurarse de desvincularlos cuando ya no se utilicen (pero no antes) o se quedarán en su directorio de datos ocupando espacio para siempre. También hay muchas instalaciones que tienen un comportamiento excepcional a su alrededor, cuyos detalles se me escapan porque nunca las uso.
Para la mayoría de las personas, la gran penalización de rendimiento asociada con el almacenamiento de grandes datos en la base de datos es que su software ORM extraerá los grandes datos en cada consulta a menos que le indique específicamente que no lo haga. Debe tener cuidado de decirle a Hibernate o lo que sea que esté usando que trate estas columnas como grandes y solo las obtenga cuando se soliciten específicamente.
