Na primavera passada eu estava três semanas em um projeto SaaS paralelo, tinha Supabase conectado, e estava olhando para uma encruzilhada: Drizzle ou Prisma. Eu tinha usado Prisma em provavelmente mais de quarenta builds de clientes na Seahawk. Território confortável. Mas um dev júnior no projeto continuava pressionando por Drizzle, e honestamente eu era um pouco dismissivo no começo. "É mais novo. Menos comprovado. Vamos apenas usar Prisma."
Fui errado em descartar tão rapidamente.
Terminamos testando ambos em diferentes partes do mesmo codebase (bagunçado, sim, mas instrutivo). O que aprendi mudou completamente como eu penso sobre a escolha de ORM. Se você está construindo em Supabase e genuinamente não tem certeza qual escolher, este é o post que eu gostaria de ter tido.
---
O Que Você Está Realmente Escolhendo
Essas duas ferramentas resolvem o mesmo problema em nível de superfície: você não quer escrever SQL bruto toda vez que toca o banco de dados. Mas elas vêm de filosofias muito diferentes.
Prisma trata seu schema como a fonte única da verdade. Você define um arquivo schema.prisma, roda prisma generate, e obtém um cliente totalmente tipado. Abstrai SQL quase completamente. Você raramente pensa em tabelas e joins; você pensa em modelos e relações.
Drizzle fica muito mais próximo de SQL. Seu schema é definido em TypeScript, suas queries parecem SQL, e não há cliente gerado separadamente pelo CLI no meio. É descrito como um "ORM TypeScript que se sente como SQL" e isso é genuinamente preciso.
Nenhum é objetivamente melhor. Fim de papo. A escolha depende do seu time, seus padrões de query, e quanto você confia nas próprias ferramentas do Supabase para fazer o trabalho pesado.
---
O Contexto Supabase Muda Tudo
Aqui está a coisa que a maioria dos posts de comparação perde: Supabase não é um banco de dados Postgres em branco. Ele vem com Row Level Security, subscrições em tempo real, APIs REST e GraphQL geradas automaticamente, e seu próprio cliente JavaScript. Você geralmente já está fazendo muito através de supabase-js antes mesmo de tocar um ORM.
Então a verdadeira pergunta não é só "qual ORM é melhor?" É "quanto da minha lógica de consulta deve passar por um ORM versus o cliente Supabase diretamente?"
Vi times escolherem Prisma, ignorarem supabase-js quase completamente e depois se perguntarem por que suas políticas de RLS não estão funcionando. É porque Prisma se conecta ao Postgres diretamente via a string de conexão. Isso contorna a camada PostgREST do Supabase. Suas regras de RLS? Só são executadas se você disser ao Prisma para SET LOCAL role = authenticated no nível da sessão. Não é difícil de configurar, mas você precisa saber que é uma coisa.
Drizzle tem o mesmo problema. Conexão direta com Postgres, mesmo comportamento de bypass. Mas porque Drizzle se sente mais nativo de SQL, desenvolvedores tendem a estar mais cientes de que estão falando com Postgres puro, não através da abstração do Supabase.
---
Tamanho do Bundle e Cold Starts: O Argumento Serverless
Se você está implantando no Vercel Edge Functions, Cloudflare Workers, ou até mesmo Vercel Serverless Functions padrão, o tamanho do bundle é uma preocupação real.
O cliente gerado pelo Prisma é... pesado. O mecanismo de query sozinho é um binário que é incluído na sua implantação. Por um tempo, implantações Prisma no Vercel geravam bundles acima de 40MB. Eles melhoraram isso significativamente com Prisma Accelerate e as opções de engine mais novas, mas você ainda está lidando com uma desvantagem de peso. Cold starts em funções serverless eram notavelmente mais lentos em um projeto fintech que enviamos no final de 2023 na Seahawk. Medimos: aproximadamente 800ms de cold start com Prisma versus menos de 200ms após migrar esse serviço específico para Drizzle.
Drizzle é minúsculo. Literalmente constrangedor. Sem engine binário. Sem geração de código em tempo de execução. Compila para JavaScript mínimo e sua implantação fica enxuta. Para edge runtimes, é a escolha óbvia agora.
Dito isso, se você está rodando um servidor Node.js tradicional (Express, Fastify, um app Next.js padrão em um VPS comum), essa lacuna importa muito menos. Um pool de conexão persistente não se importa com cold starts.
---
Experiência do Desenvolvedor: Onde Prisma Ainda Vence
Vou ser honesto. A DX do Prisma é difícil de superar.
O arquivo de schema é genuinamente agradável de trabalhar. Migrações são tratadas por prisma migrate dev e simplesmente funciona. Prisma Studio (a GUI) me poupou horas fuçando no dashboard do Supabase quando preciso inspecionar dados rápido. E os tipos TypeScript que saem do cliente gerado são completos. Você consegue autocompletar em relações aninhadas, em cláusulas where, em formas select.
O suporte a TypeScript do Drizzle também é excelente, mas requer mais pensamento inicial. Você escreve seu schema em arquivos TypeScript, o que eu na verdade prefiro filosoficamente. Nenhuma sintaxe .prisma separada para aprender. Mas o query builder leva um tempo para se acostumar. Coisas como joins complexos com agregados não são tão intuitivas quanto a sintaxe include do Prisma.
Migrações de Schema: Uma Diferença Real
Prisma gera arquivos SQL de migração automaticamente e os rastreia. Drizzle também, com drizzle-kit, mas o fluxo de trabalho se sente um pouco mais manual. Você executa drizzle-kit generate:pg, consegue um arquivo SQL e o aplica você mesmo (ou usa drizzle-kit push para prototipagem rápida). Menos magia, mais controle.
Para desenvolvedores juniores, Prisma vence aqui toda vez. Para devs solo que querem entender exatamente qual SQL está sendo executado, Drizzle é satisfatório de um jeito que Prisma não é.
---
Poder de Query Puro e Cenários Complexos
Em 2019 um cliente me passou um briefing que exigia agregações extremamente complexas: totais acumulados, window functions, agrupamento condicional. Eu estava usando Prisma na época e atingi o teto quase imediatamente. queryRaw do Prisma existe, mas cair em SQL puro dentro de um codebase abstraído se sente como trapaçear, e você perde toda segurança de tipo.
Drizzle lida com isso muito melhor. Window functions, CTEs, lateral joins: ou tem um builder de primeira classe para eles ou você pode cair em fragmentos SQL sem perder seu contexto TypeScript. Para projetos Supabase com queries de relatórios ou analytics genuinamente complexas, Drizzle te dá mais espaço para crescer.
Dito isso, 80% de aplicações CRUD não precisa de nada disso. Se seu projeto é "usuários criam posts, posts têm comentários", as queries de relação expressivas do Prisma são mais rápidas de escrever e mais fáceis para outros desenvolvedores lerem de relance.
---
Quando Escolher Cada Uma
Deixa eu ser direto sobre isso, porque vi muita gente se complicar tentando encontrar a resposta "objetivamente correta".
Escolha Drizzle se:
- Você está implantando em edge ou serverless runtimes onde tamanho de bundle e cold starts importam
- Seu time está confortável com SQL e você quer transparência no que queries estão realmente rodando
- O projeto tem requisitos complexos de consultas (relatórios, análises, agregações não-padrão)
- Você é um desenvolvedor solo ou um pequeno time que quer overhead de abstração mínimo
Escolha Prisma se:
- Você está rodando uma configuração tradicional de Node.js server-side com connection pooling
- Seu time tem desenvolvedores juniores que se beneficiam do workflow schema-first guiado
- O projeto é pesado em CRUD e a complexidade relacional é moderada
- Você quer um ecossistema maduro com mais ferramentas de terceiros, exemplos e respostas no Stack Overflow
Uma coisa mais que vale mencionar: a documentação do Prisma é melhor. Substancialmente. A documentação do Drizzle melhorou muito no ano passado, mas Prisma teve mais tempo para construir tutoriais, guias e recursos comunitários. Se você está aprendendo enquanto avança, essa diferença é real.
---
Notas de Setup Prático para Supabase Especificamente
Independentemente do que você escolher, algumas coisas se aplicam universalmente ao conectar ao Supabase.
- Use a URI do connection pooler, não a conexão direta. Supabase fornece um connection pooler Supabase via PgBouncer. Para serverless, sempre use este. O
DATABASE_URLrecomendado do Prisma para serverless deve apontar para o endpoint do pooler na porta 6543. - Desabilite prepared statements ao usar PgBouncer. Prisma precisa de
?pgbouncer=trueanexado à URL. Drizzle precisa deprepare: falseconfigurado no Postgres.js ou node-postgres config. Pule isto e você terá erros crípticos em produção. - RLS é seu amigo, mas você precisa configurar sessions. Se você quer que políticas RLS se apliquem a consultas ORM, você precisará definir o papel Postgres e JWT claim no nível da session. Isto não é boilerplate que você ganha de graça.
- Não lute contra os pontos fortes do Supabase. Use
supabase-jspara auth, realtime e storage. Use seu ORM para consultas de dados complexas onde a filtragem do cliente Supabase fica aquém. Eles podem coexistir no mesmo projeto.
---
FAQ
Drizzle está pronto para produção em 2024?
Sim. Está sendo usado em produção por times em empresas que não são apenas projetos de fim de semana. A API foi estável o suficiente para trabalho sério desde final de 2023. Eu ainda chamaria Prisma de mais "battle-tested" simplesmente por questão de idade, mas Drizzle não é mais um risco.
Posso usar ambos no mesmo projeto?
Tecnicamente sim. Fizemos exatamente isto brevemente (acidentalmente, não como estratégia). Não faça. O overhead cognitivo não vale a pena, e ter dois sistemas de migração diferentes tocando o mesmo banco de dados é pedir por um dia ruim. Escolha um.
Prisma funciona com Supabase Edge Functions?
Prisma e Supabase Edge Functions (que rodam em Deno) tiveram um relacionamento complicado. O engine do Prisma não roda nativamente em Deno. Usar Prisma Accelerate ou uma configuração de pooling externa pode contornar isto, mas adiciona partes móveis. Drizzle não tem esses problemas em ambientes Deno.
E quanto type safety? Eles são comparáveis?
Ambos geram tipos TypeScript e ambos se integram bem com projetos TypeScript. Os tipos do Drizzle são derivados de suas definições de schema TypeScript. Os tipos do Prisma vêm do client gerado. Na minha experiência, os tipos de relações aninhadas do Prisma são ligeiramente mais ergonômicos de primeira, mas a inferência do Drizzle alcançou bastante.
Qual é mais rápido em runtime?
Drizzle tem uma vantagem de desempenho genuína porque há menos overhead de runtime entre sua query e o protocolo Postgres wire. Em benchmarks, a diferença é mensurável. Na maioria das aplicações reais é eclipsada pela latência de rede para seu banco de dados. Não escolha um ORM principalmente por velocidade de query bruta.
---
A Resposta Real
Drizzle para projetos Supabase edge/serverless, ou em qualquer lugar que você queira ficar perto do metal. Prisma para ambientes de equipe, apps CRUD-pesados, e situações onde a velocidade de onboarding do desenvolvedor importa.
Uso Drizzle mais agora do que usava um ano atrás. Mas não me arrependo dos anos que passei com Prisma. Isso me tornou um desenvolvedor melhor, em parte por ser opinioso o suficiente para eu ter que entender por que eu estava atingindo seus limites.
Nenhum dos dois vai fazer ou quebrar seu projeto. Seu design de schema vai fazer. Suas decisões de indexação vão fazer. Escolha o que se encaixa nas pessoas do seu time e comece a construir.