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?
Respondendo a "Respondendo sua pergunta: uso ORM por produtivi..." dentro da publicação Mudei de Prisma para Drizzle em produção. Aqui está o que ninguém avisa antes
2
3
Utilizo o próprio queryraw e queryrawunsafe.
Mas nos meus projetos atuais não chega a 3% das queries.
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.