6
obrenoalvim
1 min de leitura ·

Mudei de Prisma para Drizzle em produção. Aqui está o que ninguém avisa antes

Prisma é o ORM padrão para Node.js com banco relacional. Drizzle é o challenger que cresceu rápido. Migrei um projeto real e quero documentar o que aprendi.

Por que saí do Prisma

O Prisma gera um cliente opaco a partir do schema. Para queries simples é ótimo. Para joins complexos com filtros dinâmicos, você fica lutando contra a abstração.

O overhead de cold start em funções serverless também foi real. O Prisma carrega mais do que o necessário para ambientes Vercel/Lambda.

O que o Drizzle entrega diferente

SQL com tipos. Você escreve queries que parecem SQL, com autocomplete e validação em tempo de compilação. O resultado é previsível porque você sabe o que está mandando para o banco.

Bundle menor. Para serverless, isso importa.

Flexibilidade. Joins com condições dinâmicas, queries com CTEs, subqueries: tudo é natural porque é SQL com açúcar sintático.

O que ninguém avisa

Migração é mais manual. Você define o schema, gera o SQL e decide quando rodar. Quem está acostumado com prisma migrate dev vai estranhar.

A comunidade é menor. Quando você bate em um caso de uso não documentado, tem menos Stack Overflow e mais leitura de código-fonte.

Se você já sabe SQL, a curva é quase zero. Se você aprendeu banco via Prisma e pouco SQL, vai ser mais íngreme.

Vocês usam ORM por convicção ou por convenção do projeto?

Carregando publicação patrocinada...
4

Como o colega falou, eu tambem uso por produtividade, mas drizzle é brm mais versátil. Eu uso ele em react native com sqlite, e não tem me deixado na mão.

1

React Native com SQLite é exatamente o caso onde Drizzle brilha. Prisma não tem suporte nativo para SQLite no RN, e as alternativas costumavam ser WatermelonDB (complexo) ou queries brutas. Drizzle resolve sem o cliente gerado.

A versatilidade é subestimada. A mesma API funcionando em Serverless, Node tradicional e React Native é um diferencial real que poucos ORMs conseguem. Você usa Expo ou bare RN no projeto?

3

Eu uso o expo, ja que os plugins para o bare estao meio inconsistentes. Eu tenho um app que precisa rodar em ambiente com raro acesso a ibternet. Essa foi a primeira opção.

1

Expo managed workflow simplifica bastante mesmo. Você sentiu alguma limitação com o suporte offline? Pergunto porque usar banco local no app com raro acesso à internet vira ponto crítico, e às vezes o managed workflow complica quando você precisa de controle mais fino sobre armazenamento local. Como você resolve a sincronia quando a conexão volta?

3

A principio coloca uma lib ali pra detectar a conectividade, depois coloca um job no android (aqui é so android). Ele roda esse job a cada 15min no backuground. Se encontrar conectividade, ele sincroniza, mesmo com o app fechado. Mas to querendo mudar pra tanstack, e uma outra lib que achei que performa melhor no offline.

1

Essa abordagem de job periódico funciona bem para casos sem latência crítica. TanStack Query v5 já tem offline mode bem maduro, vale a pena olhar. Qual lib você achou que performa melhor?

2
3

Prisma é ótimo até você precisar usar transaction e precisar do contexto da transaction entre mais de um repositório, exige uma gambiarra absurda com async local storage.

1

É exatamente isso. No Drizzle você passa o objeto de transação como parâmetro explícito entre os repositórios. Sem async local storage, sem magia negra. Fica claro no código quem está dentro da transação e quem não está.

3

Respondendo sua pergunta: uso ORM por produtividade, mas sem forçar a barra. Se a melhor abordagem não cabe na abstração, então faço a query na mão.

Prisma é muito produtivo. Fazer tudo no sql seria bem mais trabalhoso.

Para mim o mundo é muito mais cinza do que preto e branco: não há certo ou errado. São ferramentas e vc escolhe a melhor para cada caso de uso.

2

Concordo com o cinza. O que mudou pra mim no Drizzle é que quando o ORM não comporta a query, você desce para SQL puro sem sair do contexto: mesmo arquivo, mesma conexão, mesma tipagem retornando. No Prisma isso exige $queryRaw com template string e você perde o type safety. Então para casos onde você mistura ORM e SQL bruto com frequência, o Drizzle elimina uma fricção real. Você usa query builder nos casos mais complexos ou vai direto para driver nativo quando o ORM não alcança?

3
2

Faz sentido. Para a maioria dos casos o Drizzle cobre bem com a API padrão. Esse percentual baixo de raw SQL é exatamente o ponto: você mantém controle quando precisa, sem lutar contra abstração no dia a dia. No BloodLink usei o sql`` do Drizzle para uns relatórios específicos e ficou bem mais legível do que o queryRaw do Prisma. Qual é o tipo de query que cai no raw no seu caso: relatórios, agregações complexas ou outra coisa?

3

Geralmente transactions ou um select for update.

Raras vezes é para personalizar uma query que precisa de otimização máxima, ou chamar uma função personalizada (para busca vetorial por exemplo).

2

Transactions foi o primeiro caso que precisei no Drizzle também, e o db.transaction() cobre bem. O SELECT FOR UPDATE é onde aparece o sql tagged template de verdade. Busca vetorial com pgvector foi exatamente o que me forçou ao SQL direto no meu projeto também.

3
3
1

SvelteKit + SQLite é uma stack bem sólida pra projetos menores. O Drizzle tem suporte nativo pro SQLite do libsql (Turso) também, o que abre bastante possibilidade se um dia você quiser escalar sem trocar de ORM. Você usa SQLite local mesmo ou tem algum serviço gerenciado tipo Turso?

3
1

Verdade, e o ciclo vai continuar. A diferença é que no Node cada nova solução costuma vir com um DX diferente e às vezes genuinamente melhor, mesmo que o problema central seja o mesmo de sempre. Não justifica reinventar tudo, mas explica por que o ecossistema não simplesmente adota o que já existe no Java.

2

Não uso ORM e sempre vi isso como muleta para quem não quer aprender SQL de verdade.

Até Drizzle eu acho perfumaria desnecessária. Uso o driver nativo do banco e pronto.

1

Para quem domina SQL, driver nativo faz sentido e não tem overhead desnecessário. Mas o ORM entrega uma coisa que SQL puro não entrega grátis: refactoring com garantia de tipo. Quando eu renomeio uma coluna no schema do Drizzle, o TypeScript me mostra exatamente onde quebrou antes de rodar qualquer query. Com SQL em string, esse erro aparece em produção. O argumento de muleta faz mais sentido contra Prisma, que esconde o SQL atrás de uma abstração opaca. Drizzle é basicamente SQL com tipo. Você tem alguma estratégia pra lidar com refactoring de schema sem ORM?