Onde Começa a Fumaça: O Custo Invisível dos ORMs
Todo dev já caiu nessa: instala um ORM achando que vai ganhar “velocidade” e “produtividade”. Uma semana depois, está lutando com migrations quebradas, consultas que parecem poesia concretista e um acoplamento tão forte que o domínio vira refém do modelo relacional.
É assim que nasce a dívida técnica mais sorrateira do Node.js moderno.
Os tópicos mais discutidos nas comunidades reforçam isso: TypeORM que quebra ao migrar, Prisma gerando SQL gordo, ORMs que tentam ser tudo ao mesmo tempo (camada de dados, validação, DSL e gerador de schema). E cada mágica inserida ali significa uma coisa: você perde o controle direto daquilo que realmente importa — o SQL executado.
O Caminho Sênior: Query Builder Enxuto + Controle Total
Quer evitar over-engineering? Pare de delegar lógica para frameworks que tentam “entender o seu domínio” melhor que você. A saída pragmática é usar ferramentas minimalistas como Kysely ou Drizzle no modo “query builder puro”.
Você controla o SQL. Você controla o custo. Você controla o impacto no negócio.
Sem proxies mágicos, sem decorators que escondem o que está acontecendo, sem migrations que se auto-inventam.
Implementação de Senior na Prática
Aqui está um exemplo real usando Kysely — nada de firula, nada de abstração gourmet:
import { Kysely, PostgresDialect } from 'kysely'
import { Pool } from 'pg'
interface DB {
users: {
id: number
name: string
email: string
}
}
const db = new Kysely<DB>({
dialect: new PostgresDialect({
pool: new Pool({
connectionString: process.env.DATABASE_URL
})
})
})
// Consulta previsível, explícita
const users = await db
.selectFrom('users')
.select(['id', 'name', 'email'])
.where('email', '=', 'teste@acme.com')
.execute()Simples. Rastreável. Fácil de revisar. E o SQL gerado você enxerga — não precisa torcer para que o ORM não invente moda.
O Preço da Escolha: ORMs vs Query Builders
Se você insiste em usar um ORM, aceite os custos:
- Migrations que quebram porque o framework não acompanha sua modelagem.
- Consultas que você não controla e que explodem a conta do Postgres.
- Um acoplamento estrutural que te impede de evoluir o domínio sem reescrever metade da camada de dados.
Se você usa query builder:
- Mais responsabilidade? Sim. Mas mais previsibilidade também.
- Menos mágica? Sim. Mas menos dor também.
- SQL explícito? Obrigatório. E isso é uma vantagem.
Direto das Trincheiras
- Evite ORMs quando o negócio tem regras complexas: eles vão se tornar o gargalo das features.
- Monitore o SQL gerado: se você não consegue explicá-lo em 20 segundos, tem algo errado.
- Mantenha migrations sob seu controle: automatização demais cria inconsistências que cobram juros altos.
Fontes
Qual o melhor ORM para PostgreSQL em Node.js? : r/node, nodebestpractices/README.brazilian-portuguese.md, Qual ORM você usa em produção? : r/node, Migrar ou não migrar – o TypeORM está realmente morrendo? : r/node
Obrigado por acompanhar essa reflexão até o fim!
Espero que esses pontos ajudem você a tomar decisões mais lúcidas no seu próximo projeto. Não deixe de conferir outros artigos aqui no blog, onde descascamos outros hypes da nossa área.
Valeu e até a próxima! 😉
