Você tem basicamente duas opções. Você pode armazenar os dados diretamente na linha ou pode usar o recurso de objeto grande. Como o PostgreSQL agora usa algo chamado TOAST para mover campos grandes para fora da tabela, não deve haver nenhuma penalidade de desempenho associada ao armazenamento de dados grandes na linha diretamente. Permanece um limite de 1 GB no tamanho de um campo. Se isso for muito limitado ou se você quiser uma API de streaming, poderá usar o recurso de objeto grande, que oferece algo mais como descritores de arquivo no banco de dados. Você armazena o ID do LO em sua coluna e pode ler e gravar a partir desse ID.

Pessoalmente, sugiro que você evite a instalação de objetos grandes, a menos que seja absolutamente necessário. Com o TOAST, a maioria dos casos de uso é coberta apenas pelo uso do banco de dados da maneira que você espera. Com objetos grandes, você se sobrecarrega de manutenção adicional, porque você precisa acompanhar os IDs de LO que você usou e certifique-se de desvinculá-los quando eles não forem mais usados ​​(mas não antes) ou eles ficarão no seu diretório de dados ocupando espaço para sempre. Há também muitas instalações que têm um comportamento excepcional ao seu redor, cujos detalhes me escapam porque nunca as uso.

Para a maioria das pessoas, a grande penalidade de desempenho associada ao armazenamento de grandes dados no banco de dados é que seu software ORM extrairá os grandes dados em todas as consultas, a menos que você o instrua especificamente a não fazê-lo. Você deve ter o cuidado de informar ao Hibernate ou o que estiver usando para tratar essas colunas como grandes e buscá-las apenas quando forem solicitadas especificamente.