Voltar para o Blog
Vibe Coding19 / 40
  1. 01O que é vibe coding (e o que não é)
  2. 02De escrever código a dirigir a intenção
  3. 03O ciclo: contexto → plano → geração → revisão
  4. 04O arsenal: visão geral do nosso stack de IA
  5. 05Quando não usar vibe coding
  6. 06Da ideia ao protótipo em horas
  7. 07Claude para brainstorm de produto e PRD
  8. 08Claude Artifacts para mockups instantâneos
  9. 09Lovable: do prompt ao app funcional
  10. 10Google AI Studio: prototipando com Gemini
  11. 11Lovable × Claude × Google Studio: quando usar cada um
  12. 12Claude Code: o par de programação que conhece o monorepo
  13. 13Anatomia de um bom prompt de engenharia
  14. 14Plan mode: planejar antes de gerar
  15. 15Skills e slash commands (/investigate, /review, /ship)
  16. 16Refactors e migrations em massa
  17. 17Debugging com IA: do stack trace à causa raiz
  18. 18Supabase: a espinha dorsal de dados
  19. 19Modelagem com Drizzle ORM
  20. 20RLS na prática: a regra que não tem exceção
  21. 21Migrations SQL à mão e o drift DB↔Drizzle
  22. 22Auth com Google OAuth no Supabase
  23. 23Realtime, Storage e o resto do Supabase
  24. 24Trigger.dev: o piloto automático
  25. 25Seu primeiro job agendado
  26. 26Workflows com retry e observabilidade
  27. 27IA em background: resumos e narrativas
  28. 28Deploy do Trigger.dev e as pegadinhas
  29. 29Evolution API: WhatsApp como canal de produto
  30. 30Instância por usuário e gestão centralizada
  31. 31IA gerando resumos de conversa
  32. 32Boas práticas e armadilhas no WhatsApp
  33. 33Integrando APIs de terceiros com IA
  34. 34Anthropic SDK: Claude dentro do produto
  35. 35Resend: e-mail transacional que chega
  36. 36Google Analytics, Search Console e Ads
  37. 37Rate limit, retry, idempotência e secrets
  38. 38GitHub: CI/CD e AI Code Review como portão de qualidade
  39. 39Deploy no Google Cloud Run
  40. 40A cultura por trás do vibe coding (e o futuro)
Vibe CodingParte 19 de 40

Modelagem com Drizzle ORM

2 min de leitura
Compartilhar
Vibe Coding

Começa de fato o Módulo 3 — Dados com Supabase. No post-âncora (#18) vimos o Supabase como espinha dorsal. Agora descemos pra camada que o time toca todo dia: o Drizzle ORM, a ponte tipada entre o nosso código TypeScript e o PostgreSQL.

Por que Drizzle (e não SQL solto pelo código)

Drizzle nos dá acesso ao banco tipado de ponta a ponta: o schema é TypeScript, as queries são TypeScript, e o compilador pega o erro antes do runtime. Você escreve db.select().from(careerPosts) e o editor já sabe quais colunas existem. Pra vibe coding isso é ouro: a IA gera query e o typecheck valida na hora se ela faz sentido.

Como modelamos no ClubPetro

  • O schema vive em packages/db — 50+ tabelas organizadas por domínio (cs, finance, recruitment, gente…).
  • Cada tabela exporta o objeto Drizzle + os tipos inferidos ($inferSelect / $inferInsert). Ex.: careerPosts, CareerPost, NewCareerPost.
  • Schemas Postgres nomeados quando faz sentido (ex.: recruitment.career_posts via recruitmentSchema.table(...)).
  • Índices e enums declarados junto da tabela, perto de onde importam.

O que a IA faz bem aqui

  • Espelhar padrão. "Cria a tabela X igual à Y" — ela copia a estrutura, tipos e índices no nosso estilo.
  • Gerar queries. Do select com filtro ao insert ... returning, seguindo os tipos.
  • Inferir tipos. Menos any, mais tipo derivado do schema.

O cuidado que a IA não tem sozinha

Modelagem é decisão de arquitetura de dados — e isso é humano:

  • A relação está certa (FK, cascade, set null)?
  • Esse campo devia ser text com check, ou um enum de verdade?
  • O índice cobre as queries reais ou é peso morto?
  • E a regra inegociável que vem no próximo post: RLS (#20).

A IA escreve o schema; você decide se o modelo está certo. Modelo de dados ruim é caro de mudar depois — perto de irreversível, e irreversível a gente decide devagar.

Uma verdade desconfortável do nosso repo

O schema em TS nem sempre reflete o banco. Há drift conhecido (assunto do #21). Então, antes de criar dado ou confiar no .ts, cheque o banco real (pnpm db:studio ou query direta). A regra da casa: antes de criar qualquer dado, verifique a base existente.

⚠️ Armadilha #19: confiar que o schema Drizzle em TS é a verdade do banco. Não é. Gerar código em cima de um schema desatualizado produz query que compila e quebra em produção.

Próximo da série: #20 — RLS na prática: segurança obrigatória.

Curtiu como a gente pensa?

É assim que trabalhamos todo dia.

Se esse jeito de pensar é o seu, vem construir com a gente — dá uma olhada nas vagas abertas.

Ver vagas