DEV Community

Cover image for Não use Prisma ORM antes de ler isso!
Dev Doido
Dev Doido

Posted on

1

Não use Prisma ORM antes de ler isso!

Imagina o caos, você cria um banco de dados gratuito no NeonDB com 0.5GB de armazenamento e pensa, "suave, vou usar um free tier pra teste". Aí, horas depois, vem o e-mail fatal: "Seu armazenamento foi consumido!". Uai como assim? Nem deu tempo de esquentar a cadeira! A resposta? Eu usei o glorioso Prisma ORM e, para melhorar , rodei vários migrate ao longo do dia, só na modelagem do schema.

Vamos entender o que rolou e, claro, por que às vezes o velho e bom SQL "na unha" ainda é mil vezes melhor.

Primeiro é preciso te contextualizar. Eu estava gravando a aula 124 do CrazyStack (meu bootcamp de Node e React). E nele é possível usar postgres ou mongodb sem ORMs. No entanto um aluno veio me pedir no zap pra incluir Prisma no projeto. Eai resolvi fazer o experimento.

Prisma ORM: o simples que sai caro

O Prisma é aquele negócio que parece perfeito. "Vou abstrair query de banco, economizar tempo, é o novo hype". Só que, surpresa! Não existe almoço grátis, e esse rango veio em forma de storage torrado. Eu rodei migrates durante o dia, e foi só pesando no neondb. E nem era um projeto enorme.

E o Prisma não só cria as migrations, como deixa umas tabelinhas e logs extras de brinde. Se você, como eu, estiver testando coisas e rodando migrações a torto e a direito, esse presente acaba sendo de grego.

O Prisma é muito bom, mas, quando se trata de armazenamento, ele gosta de se esbaldar:

  1. Migrações a Rodo: Cada vez que eu rodava uma migrate, o Prisma criava e armazenava novas migrações. Cada uma com seu pacotinho de metadados, logs e tabelas.

  2. Logs Que Se Multiplicam: Pra garantir que nada vai dar errado (ou pra facilitar a sua vida quando der), o Prisma grava logs detalhados. Só que esses logs acumulam e, como não estou em um banco "ilimitado", logo viram um problema.

  3. Sobrecarregando com Tabelas Auxiliares: Além das migrações, o Prisma também cria tabelas extras pra manter controle de várias coisas, especialmente em bancos de dados relacionais, como o Postgres.

No fim, o que parecia ser uma ferramenta mágica para simplificar a vida, acabou devorando o meu NeonDB gratuito.

SQL "Na Unha": Porque Menos É Mais

E é aqui que entra a velha e boa abordagem de SQL "na unha". Sim, o Prisma é ótimo e salva tempo, mas às vezes ele só complica. Vamos falar das vantagens de abandonar o ORM e escrever suas consultas na mão:

  1. Controle Absoluto: Não tem surpresa na conta. Você sabe exatamente o que cada linha de código está fazendo e não vai se deparar com logs ou tabelas escondidas devorando seu espaço.

  2. Sem Peso Morto: Usando SQL direto, o que você escreve é o que vai pro banco. Não tem metadados, migrações ou logs pesando a parada.

  3. Mais Desempenho: SQL direto, quando bem feito, consome muito menos espaço e recursos. É ideal pra bancos pequenos como o NeonDB pra quem é freeganista que nem eu.

  4. Sem negócio oculto: Nada de tabelas criadas do nada ou logs de transações que se acumulam. O controle é seu, e só seu.

Moral da história:

Se você, como eu, gosta de testar ferramentas e fazer experimentos rápidos, pense duas vezes antes de jogar um Prisma ORM no seu banco de dados com pouco espaço. O Prisma é uma maravilha? É. Mas, em um banco limitado como o NeonDB, é como dar uma festa e descobrir que a breja que você comprou não vai dar pra galera.

Às vezes, o SQL "na unha" é o caminho mais seguro, te dando o controle exato sobre o que entra no banco. E a lição que fica é: da próxima vez, vou pensar melhor antes de rodar uma migrate atrás da outra em um banco de 0.5GB.

Image of Docusign

🛠️ Bring your solution into Docusign. Reach over 1.6M customers.

Docusign is now extensible. Overcome challenges with disconnected products and inaccessible data by bringing your solutions into Docusign and publishing to 1.6M customers in the App Center.

Learn more

Top comments (1)

Collapse
 
samuel_conradt_9a619c557c profile image
Samuel Conradt

Eu uso o prisma já vai fazer uns 2 anos, nunca tive esse tipo de problema, o lance da migrate é fazer dps de todas as tabelas prontas, eu fazia assim, como eu tive que usar a versão gratuita quando precisava mudar uma tabela em produção fazia migrate e apagava os logs dentro do próprio neon, to com 1 ano de dados em postgress + prisma sem problema e na versão free do neon