Medida vs coluna calculada em DAX: o que faz e quando usar (com exemplos)

A escolha entre medida e coluna calculada define se o seu modelo voa ou arrasta#

Toda vez que você clica com o botão direito numa tabela do Power BI, aparecem duas opções que parecem intercambiáveis: "Nova medida" e "Nova coluna". Elas não são. A decisão entre medida vs coluna calculada DAX é uma das que mais separam um modelo leve e rápido de um arquivo pesado que trava no refresh e engasga a cada clique do usuário. E o iniciante quase sempre escolhe errado, porque coluna calculada parece mais intuitiva: você vê o resultado na tabela, linha por linha, e isso dá uma falsa sensação de controle.

Neste artigo eu vou destrinchar a diferença real entre as duas: em qual contexto cada uma é avaliada, em que momento ela é calculada, quanto de memória ela consome e, principalmente, quando usar cada uma sem chutar. No fim, você vai ter uma regra prática que resolve a maioria das decisões. Se quiser o panorama maior antes de mergulhar, vale ler nosso guia de modelagem e boas práticas de DAX.

Medida e coluna calculada respondem a perguntas diferentes#

A confusão começa porque as duas são escritas em DAX e as duas produzem números. Mas elas existem para resolver problemas de natureza diferente.

Uma coluna calculada adiciona uma coluna nova a uma tabela existente. Ela é avaliada linha por linha, no momento em que o modelo é atualizado, e o resultado fica gravado fisicamente no arquivo, igual a qualquer outra coluna vinda da fonte. Depois de calculada, o motor nem sabe que ela nasceu de DAX: é só mais uma coluna armazenada.

Uma medida não gera valor por linha. Ela define um cálculo que só produz resultado quando você a coloca num visual, e o número que devolve depende inteiramente do recorte daquela célula: o ano da coluna, a região da linha, os filtros das segmentações. A medida é uma fórmula guardada, não um dado guardado, recalculada a cada interação do usuário.

Essa é a distinção que importa: coluna calculada é dado materializado, medida é cálculo sob demanda. Todo o resto deriva daqui.

Contexto de avaliação: contexto de linha para a coluna, contexto de filtro para a medida#

Aqui está o coração técnico da diferença, o ponto que mais gente ignora.

Uma coluna calculada é avaliada em contexto de linha. Quando o DAX processa a coluna, ele percorre a tabela e, para cada linha, sabe exatamente o valor de cada campo dela. Por isso Pedidos[Quantidade] * Pedidos[PrecoUnitario] funciona numa coluna calculada: existe uma "linha atual" e o motor lê os dois valores. O que a coluna não enxerga são os filtros do relatório, porque no momento do refresh não existe visual nem segmentação selecionada.

Uma medida é avaliada em contexto de filtro. Ela não tem uma "linha atual" para ler, tem um conjunto de filtros ativos, o recorte que vem do visual, das segmentações e dos relacionamentos. Por isso quase sempre usa uma agregação como SUM, AVERAGE ou COUNTROWS: precisa colapsar muitas linhas em um número, respeitando o filtro da célula. Se você escrever Pedidos[Quantidade] * Pedidos[PrecoUnitario] numa medida sem agregação, o DAX reclama, porque não existe uma única linha para ler.

Se esse ponto ainda parece nebuloso, a gente o detalha no guia de boas práticas de DAX. A frase para guardar é esta: coluna calculada nasce olhando uma linha; medida nasce olhando um filtro.

Quando cada uma é calculada: refresh versus tempo de consulta#

O momento do cálculo é o que gera a diferença de desempenho e de memória.

A coluna calculada é processada no refresh do modelo. Toda vez que os dados são atualizados, o motor recalcula a coluna inteira, linha por linha, e grava o resultado, que fica congelado até o próximo refresh. Ler essa coluna num visual é tão barato quanto ler qualquer outra, porque o trabalho pesado já foi feito. O custo dela é pago uma vez por atualização, em tempo de refresh e em espaço de armazenamento.

A medida é calculada em tempo de consulta, no exato instante em que o usuário abre a página, aplica um filtro ou muda uma segmentação. Ela não ocupa espaço no modelo, porque não existe valor armazenado, existe só a fórmula. O custo dela é pago em processamento, toda vez que alguém interage com o relatório.

Isso leva a uma troca fundamental. Coluna calculada empurra o custo para o refresh e para a memória, mas deixa a consulta rápida. Medida mantém o modelo enxuto e paga processamento a cada interação. Na prática, uma medida bem escrita calcula rapidíssimo, e o custo de memória de colunas desnecessárias é o problema que mais aparece em projeto real.

O custo de memória: por que coluna calculada pode envenenar o VertiPaq#

O Power BI armazena os dados num motor colunar chamado VertiPaq, e é impossível decidir bem sem entender como ele comprime.

O VertiPaq guarda cada coluna separadamente e a comprime de acordo com a cardinalidade, o número de valores distintos naquela coluna. Uma coluna com poucos valores únicos, como um status de três opções ou uma categoria com uma dúzia de itens, comprime muito bem e ocupa quase nada. Já uma coluna de altíssima cardinalidade, como um valor decimal com muitas casas, um ID único por linha ou um carimbo de data e hora com segundos, comprime mal e ocupa muito espaço, porque quase toda linha é um valor diferente.

Aqui mora a armadilha das colunas calculadas. Elas costumam ser criadas para materializar cálculos de granularidade fina, e cálculos assim tendem a gerar exatamente o que o VertiPaq odeia: alta cardinalidade. Uma coluna de "margem por pedido" com quatro casas decimais numa tabela de dez milhões de linhas pode gerar milhões de valores distintos e inchar o arquivo, enquanto a medida equivalente ocupa zero byte de armazenamento e calcula o mesmo número na hora. Colunas calculadas ainda nem sempre recebem o melhor algoritmo de compressão que as colunas importadas recebem, o que agrava o custo.

A tabela abaixo resume o comparativo que a gente usa para decidir no dia a dia.

Aspecto	Coluna calculada	Medida
Contexto de avaliação	Contexto de linha	Contexto de filtro
Quando é calculada	No refresh do modelo	Em tempo de consulta
Onde o resultado fica	Materializado e armazenado no VertiPaq	Não é armazenado, só a fórmula
Custo de memória	Alto, cresce com a cardinalidade	Praticamente nulo
Custo no refresh	Recalcula a coluna inteira	Nenhum
Custo por interação	Baixo, só leitura	Processamento na hora
Responde a filtros do usuário	Não muda depois de gravada	Sim, recalcula a cada recorte
Serve como eixo, filtro ou segmentação	Sim	Não

Três exemplos práticos que deixam a diferença concreta#

O padrão fixa na cabeça quando você vê o código. Vamos a três situações que aparecem em todo projeto.

Exemplo 1: a margem que muita gente materializa por engano. Você quer o percentual de margem. O instinto do iniciante é criar uma coluna calculada:

Margem Pct (coluna, evite) =
DIVIDE(
    Pedidos[Receita] - Pedidos[Custo],
    Pedidos[Receita]
)

Isso funciona no nível da linha, mas é uma péssima ideia. Primeiro, gera uma coluna decimal de altíssima cardinalidade que pesa no modelo. Segundo, e mais grave, se você somar essa coluna num visual, o resultado está errado: a soma de percentuais de linha não é a margem do total. A forma correta é uma medida, que respeita o contexto de filtro de cada célula:

Margem % =
DIVIDE(
    SUM( Pedidos[Receita] ) - SUM( Pedidos[Custo] ),
    SUM( Pedidos[Receita] )
)

Essa medida devolve a margem certa em qualquer nível, do produto ao total geral, sempre agregando antes de dividir, sem ocupar memória. Regra: percentual, razão e média quase nunca são coluna calculada.

Exemplo 2: a coluna calculada que é legítima, para classificar e segmentar. Nem toda coluna calculada é erro. Ela é a escolha certa quando você precisa de um atributo por linha para usar como eixo, filtro ou segmentação, e quando esse atributo tem baixa cardinalidade. Classificar cada pedido numa faixa de ticket é o caso clássico:

Faixa de Ticket =
SWITCH(
    TRUE(),
    Pedidos[Valor] < 500, "Até 500",
    Pedidos[Valor] < 2000, "500 a 2.000",
    "Acima de 2.000"
)

Isso gera só três valores distintos, comprime muito bem e serve para o que a medida não consegue: virar um campo que o usuário arrasta para uma segmentação ou para o eixo de um gráfico. Medida não pode ser filtro ou eixo, porque não tem valor por linha. Quando você precisa de uma dimensão nova derivada dos dados, coluna calculada é a ferramenta.

Exemplo 3: o total por cliente que parece precisar de coluna, mas não precisa. Suponha que você queira o faturamento acumulado de cada cliente. Dá para materializar numa coluna com transição de contexto:

Total do Cliente (coluna, quase sempre desnecessária) =
CALCULATE(
    SUM( Pedidos[Valor] ),
    ALLEXCEPT( Pedidos, Pedidos[ClienteID] )
)

Funciona, mas repete o mesmo valor em todas as linhas do cliente, infla o modelo e congela o número no refresh: se o usuário filtrar por período, essa coluna ignora o filtro, porque foi calculada antes de qualquer interação existir. A medida equivalente é mais leve e respeita o que o usuário selecionar:

Total do Cliente =
CALCULATE(
    SUM( Pedidos[Valor] ),
    ALLEXCEPT( Pedidos, Pedidos[ClienteID] )
)

Mesma fórmula, natureza oposta. Como medida, ela reage aos filtros de data, canal e produto do relatório. Como coluna, ela seria um número morto. Sempre que o cálculo precisa reagir ao que o usuário faz, ele é medida.

Medida vs coluna calculada DAX: a decisão cabe em uma tabela#

Depois de muitos projetos, a decisão se resume a poucas perguntas, resumidas no guia rápido abaixo.

Você precisa de...	Escolha	Por quê
Agregar valores, respeitando filtros do visual	Medida	Contexto de filtro, custo de memória nulo
Percentual, razão, média, KPI, comparação de período	Medida	Precisa agregar antes de calcular
Um atributo por linha para usar como filtro, eixo ou segmentação	Coluna calculada	Medida não vira campo de eixo ou filtro
Classificar linhas em faixas ou categorias de baixa cardinalidade	Coluna calculada	Poucos valores distintos, comprime bem
Criar uma chave ou relacionamento entre tabelas	Coluna calculada	Relacionamento exige coluna física
Um valor decimal fino calculado por linha e depois somado	Medida (com SUMX se preciso)	Coluna de alta cardinalidade pesa no VertiPaq
Ordenar uma coluna de texto por um critério customizado	Coluna calculada	"Classificar por coluna" exige coluna real

O resumo é este: se o resultado for consumido como número agregado num visual, é medida. Se for um rótulo ou chave por linha, consumido como dimensão, é coluna calculada. E quando as duas resolvem, como no exemplo 3, prefira a medida.

A regra prática: medida por padrão, coluna calculada por exceção#

Se você quer uma heurística que raramente falha, é esta: use medida por padrão e só crie coluna calculada quando tiver um motivo específico que a medida não atende. Esses motivos são poucos: um campo para segmentar, filtrar ou colocar num eixo; uma chave para relacionamento; ordenar texto por um critério; uma categoria de baixa cardinalidade derivada dos dados.

Fora desses casos, medida vence quase sempre. Ela mantém o modelo leve, porque não materializa nada no VertiPaq. Ela respeita o contexto de filtro, então dá o número certo em qualquer nível de agregação. E ela é honesta com o refresh, porque não adiciona trabalho a cada atualização. Modelos que a gente recebe travados na sustentação de BI quase sempre têm o mesmo padrão: dezenas de colunas calculadas que deveriam ser medidas, inflando o arquivo e derrubando o desempenho.

Uma observação importante sobre a alternativa dentro da própria medida. Quando você precisa de um cálculo por linha que depois será agregado, como quantidade vezes preço, a resposta não é coluna calculada: é um iterador como SUMX, que faz o cálculo linha a linha em tempo de consulta e agrega, sem materializar nada. SUMX( Pedidos, Pedidos[Quantidade] * Pedidos[PrecoUnitario] ) entrega o mesmo resultado de uma coluna somada, sem o custo de memória.

Vale um alerta de escala. Num modelo pequeno, uma coluna calculada extra não quebra nada. O problema aparece quando a tabela fato passa de milhões de linhas e cada coluna de alta cardinalidade vira megabytes de arquivo e segundos de refresh. Como o objetivo é aguentar o crescimento, a disciplina de preferir medida se paga cedo. Em modelos grandes, ela é parte do que a gente trata em projetos de analytics avançado e de engenharia de dados, onde desempenho não é luxo, é requisito.

Perguntas frequentes#

Coluna calculada deixa o Power BI mais lento? Ela não deixa a consulta mais lenta, porque o valor já está pronto para leitura. O que ela faz é aumentar o tempo de refresh e o tamanho do arquivo, principalmente se tiver alta cardinalidade. O impacto é indireto: um modelo inchado de colunas desnecessárias consome mais memória, cabe pior no cache e deixa o ambiente inteiro mais pesado, mesmo que cada consulta continue rápida.

Posso usar uma medida como filtro ou eixo de um gráfico? Não. Medida não tem valor por linha, então não pode ser arrastada para um eixo, para uma segmentação ou usada como coluna de agrupamento. Se você precisa de um campo assim, precisa de uma coluna calculada ou de uma coluna vinda da fonte. É a principal razão legítima para criar uma coluna calculada em vez de uma medida.

Se a coluna calculada dá o número que eu quero, por que trocar por medida? Porque "dar o número certo numa linha" não é o mesmo que dar o número certo no total. Cálculos como percentual e média, quando materializados por linha e depois somados, produzem totais errados. Além disso, a coluna congela o valor no refresh e ignora os filtros do usuário, enquanto a medida recalcula a cada recorte. Mesmo quando a coluna funciona, a medida costuma ser mais leve e mais correta.

Qual das duas comprime melhor na memória? Nenhuma coluna calculada comprime melhor que "não existir". A medida não é armazenada, então seu custo de memória é essencialmente nulo. Entre colunas, a que comprime bem é a de baixa cardinalidade, com poucos valores distintos. Colunas calculadas de valores decimais finos ou chaves únicas são as que mais pesam, e são justamente as que deveriam ser medidas ou iteradores.

Existe caso em que a coluna calculada é obrigatória? Sim. Relacionamentos entre tabelas exigem uma coluna física, então uma chave composta criada em DAX precisa ser coluna calculada. Ordenar uma coluna de texto por outra, com o recurso "Classificar por coluna", também exige uma coluna real. E qualquer atributo que o usuário vá usar como filtro, eixo ou segmentação precisa ser coluna. Nesses casos, coluna calculada é a ferramenta correta, não um desvio.

E se eu precisar de um cálculo por linha que depois será somado? Não crie coluna calculada por reflexo. Use um iterador como SUMX, que percorre a tabela linha a linha em tempo de consulta e agrega sem materializar nada. Você tem o cálculo por linha que queria, com o custo de memória de uma medida. Só materialize numa coluna se aquele valor por linha também for usado como dimensão.

Fechando#

A diferença entre medida e coluna calculada não é um detalhe de sintaxe, é uma decisão de arquitetura. Coluna calculada é dado materializado, avaliado em contexto de linha, gravado no VertiPaq e pago em memória e refresh. Medida é cálculo sob demanda, avaliado em contexto de filtro, sem custo de armazenamento e recalculado a cada interação. A regra é simples: medida por padrão, coluna calculada só quando você precisa de um campo para filtrar, ordenar, relacionar ou segmentar.

Se o seu modelo de Power BI está pesado, lento no refresh ou cheio de colunas que ninguém sabe por que existem, esse costuma ser o sintoma de decisões de DAX tomadas no reflexo, não no critério. Fale com a gente e a gente ajuda a colocar seu modelo em ordem, do VertiPaq à última medida.