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.