Alternativa caso você esteja iniciando um projeto 100% free

( a estratégia do banco de dados fiat uno )

Essa realidade de tanto dev usando seu banco para guardar arquivos pode ser por causa que as alternativas são serviços e não guias, softwares e outros tipos de ferramentas gratuitos.

Imagina começar um projeto, montando seu React, Node, MySQL e... Onde guardar os arquivos do usuário?

Agora sim vou te dar uma alternativa:

Não pense muito nisso

( você pode mudar mais tarde )

Simples, ao invés de fazer uma tabela perfil_sem_arquivo que segura a url da foto em uma string fotourl, você pode criar uma tabela foto_arquivo que vai segurar o arquivo exatamente como na tabela ERRADA inicial, a diferença é que (desde que você não dê join na tabela foto_arquivo) a velocidade será a mesma se seu arquivo estiver no banco de dados porém fora da sua tabela. (imagens mais a baixo)

Para recuperar a imagem, você pode construir uma rota apenas para a tabela do arquivo, buscando e retornando a imagem de uma vez, separadamente.

Essa estratégia é o equivalente de usar um fiat uno de frete. Geralmente você quer um frete potente, com bastante espaço por ser grande, segurança se possivel e uma equipe para te ajudar.

Porém, como você está começando agora, você só precisa levar uma mochila com roupas e seu PC Gamer até a kitnet no bairro ao lado da casa da sua mãe (sua antiga casa). É por isso que não é muito errado você guardar dados pesados no seu BD, afinal, o nome é banco de dados e não banco de penas. Acontece que hoje em dia, existem serviços tão melhores (e baratos) em distribuir arquivos estáticos que não compensa tentar subir uma startup fazendo isso manualmente.

A estratégia da Rota separada

Quando chegar no momento de contratar um serviço CDN para guardar suas imagens ou arquivos e você for segurar seus arquivos, você vai estar com seu banco já formatado para esse padrão. Será um trabalho de remover a rota (e o controller) antigo de buscar no seu próprio banco, remover a tabela de arquivos (pós transferência) e populando o campo fotourl já existente no seu projeto!

Até quando posso deixar os arquivos dentro do meu banco desta maneira separada?

Até você cansar da performance ruim, mas antes, a performance ruim precisa começar a ser um problema e para isso acontecer, provavelmente sua aplicação já passou da fase de testes e se tornou um MVP ou já está sendo e você está com o investimento necessário para contratar um serviço sério.

Ao utilizar um google cloud storage para armazenar os dados recomendo muito a utilização de links de acesso temporario e não a navegação da imagem por toda sua infra de servidor.

Gerando um link atraves das sdks do google voce vai economizar em armazenamento e trafego de rede, visto que o acesso via api e o acesso via link é o mesmo, retirando seu gasto de deslocamento de imagem pelo servidor.

Isso fecha grande maioria dos usos para compartilhamento e uso de imagem da maioria das aplicações de baixa e media complexidade.

Ref: https://cloud.google.com/storage/docs/samples/storage-generate-signed-url-v4?hl=pt-br

Realmente, é gritante a diferença entre armazenar arquivos e não o fazer. Excelente dica!

Muito bom, o conteúdo.

Brabo demais, não tinha ideia que a diferença de eficiencia seria tão grande.

Parabéns pelo post. Compartilho da ideia que não armazenar binários no banco de dados é a melhor opção.Lembrando que é necessário um controle deste storage para que outros arquivos não possam ser vistos sem a devida autenticação. Parabéns!!!

Bom dia Andre, esse era um assunto que eu estava com dúvidas. Na verdade ainda estou, me ajuda a esclarecer? Você salvaria as imagens em uma CDN e o caminho no banco, seria isso? Desculpe se não entendi direito.

Tópico muito importante, e bem interessante que você também adicionou a parte dos CDNs, hoje temos acesso fácil a essa funcionalidade incrível que é disponibilizar os dados da nossa aplicação para usuários mais próximos através da localização dos datacenters.

Porque estão dando downvote nesse post?

Bom dia,
Em relação a segurança dos dados, usando uma infraestrutura dedicada não pode aplicar camada para apenas pessoas autorizadas baixar as imagens. Em vez de utilizar um url direto para imagem não seria viavel ter uma API sicronizada com back-end onde troca informações de segurança para permitir acesso ao dados?

Post muito esclarecedor! Parabéns.

Ótimo artigo, eu tive quase que os mesmos problemas com um projeto pessoal que é em base consumido por imagens, na época eu pensava que seria menos custoso tanto para a minha VPS quanto para o usuário se eu salvasse as imagens em formato de base64 e depois eu convertesse para jpg no front.

E sim, eu estava redondamente enganado, não tem nem comparações utilizar um serviço de Object Storage e por cima botar a Cloudflare como cache e ter uma maior performance, tanto a sua página vai ser renderizada mais rápido para o usuário que vai indo baixando os contaúdos aos poucos, quanto vai ser gerada mais rápida também (caso esteja utilizando uma framework para SSG como o NextJS).

Muito top André, essa era uma dúvida que me perseguia desde que aprendi o Back-end. Ficou muito claro o por que não armazenar as imagens diretamente no banco de dados!

Eu lembro que, ao invés de guardar o arquivo direto, eu guardava o resultado do base64 no arquivo.
Se isso era uma boa prática ou não, eu não sei, só sei que parei com isso por que dava muito erro.

Boa Andre, excelente post!

Pra exemplificar, na última API que construi em Node, deixei as imagens na pasta /public e no app.js onde estavam as rotas, coloquei um endpoint da seguinte forma:

app.use('/images', express.static('public'));

No banco, havia um campo imageUrl que tinha uma string tipo essa: "/images/heineken_600ml.jpg"

Dessa forma, no front, ficou bem performático e meu banco no back bem enxuto. Mas essa solução só me veio depois de tentar guardar os arquivos dentro da chave 😂

Conteúdo excelente! Obrigado por compartilhar esse conhecimento!

Realmente o armazenamento de arquivos na base de dados não é tão correto de se fazer, pela performace
Armazenar os arquivos dos usuarios separado da aplicação pode gerar uma certa segurança, pois os arquivos estão separados da aplicação, e só conseguem ser acessados apartir da aplicação
Você concentra o foco da segurança mais ali, e já tem a performace de guardar o arquivo separado do banco

Muito bom o post, não tinha feito testes nesse sentido ainda, então agora, depois de ver os dados, ficou tudo mais claro. Eu sou um iniciante e é interessante ver como os frameworks com suas ORMs já nos guiam nesse sentido, recentemente estava em um projeto pessoal e surgiu a necessidade de lidar com upload de arquivos. A primeira coisa que pensei foi justamente armazenar os arquivos no banco, mas consultando a documentação do Django notei que, no que diz respeito a gerenciamento de arquivos, ele indica usar justamente um campo no banco que armazena o caminho para um arquivo em vez de armazenar o arquivo de fato. Quando vi isso foi que comecei a pensar em como seria custoso armazenar os arquivos no banco e implementei o campo com os caminhos para os arquivos. Se eu não utilizasse um framework provavelmente faria uma burrada. Estudar a documentação dos frameworks pode nos fazer aprender muito.

Banco de Dados foi feito para armazenar dados (Id, Nome, E-mail, ...) e não arquivos. O melhor Banco de Dados que você pode ter para manuzear arquivos é o próprio sistema operacional. Ele foi construído para isso 😊!

Você poderia usar base64 para encodar o arquivo em formato texto antes de passar para o banco de dados, e desencodar quando utilizar. Ou essa pratica não rola?

Sem contar a performance em backups e replicações (em caso de escala horizontal).
Concordo 100%

Concordo com a sugestão, embora não tenha números para validar minha escolha. Desenvolvemos recentemente uma aplicação web para Ministério do Meio Ambiente, que tem no arquivamento de arquivos sua principal vocação. Optamos por fazer o arquivamento do binário em tabelas Postgres, durante o desenvolvimento, por uma questão de comodidade. Para evitar parte dos problemas de perfomance, mencionados no artigo, os arquivos são armazenados em tabela à parte da tabela de dados, sem uso de chave estrangeira entre elas.

Em produção, optamos pelo arquivamento em um volume de dados na rede interna do órgão. O chaveamento das classes responsáveis por definir a estratégia de arquivamento é feito por meio de variáveis de ambiente, que definem qual a classe concreta que será instanciada em tempo de execução, bem como a real localização do volume de dados que conterá os arquivos.

Excelente conteúdo!

Muito bom seu post, tenho feito um projeto pessoal e vou precisar guardar fotos de perfil também e isso ja da uma boa noção do que preciso fazer a respeito do banco de dados.