Desenvolvimento de Dashboards em 2026: Custom vs Power BI

Construa um dashboard custom quando o dashboard é uma funcionalidade do produto, precisa de push em tempo real ou tem que atender centenas de usuários externos sem cobrança por assento. Compre uma ferramenta de BI (Power BI, Looker, Metabase, Grafana) quando a audiência é interna, as perguntas mudam toda semana e os analistas precisam explorar dados sem deploy. A maioria das empresas precisa dos dois: uma ferramenta de BI para análise interna e uma camada custom só onde embedding, latência ou licenciamento tornam a ferramenta de BI uma escolha ruim.

Dashboard custom vs Power BI, Looker, Metabase e Grafana

A pergunta certa não é "qual ferramenta é a melhor", e sim "quem olha isto, com que frequência, quão atualizado precisa estar e quem paga por usuário".

Critério	Power BI	Looker	Metabase	Grafana	Dashboard custom
Modelo de custo	Por usuário (Pro/Premium por usuário) ou por capacidade; embedded exige SKUs de capacidade	Por usuário mais taxa de plataforma; preço enterprise	Open source self-hosted (grátis) ou cloud por usuário	Open source self-hosted ou cloud por uso	Custo de construção + hospedagem + manutenção; sem cobrança por usuário
Embedding no seu produto	Sim, via Embedded; exige licença de capacidade e iframe ou SDK	Sim, embed SDK e signed URLs; forte para SaaS	Sim, iframe assinado; theming limitado	Sim, painéis por iframe; branding limitado no OSS	Nativo; controle total de UX, tema e interações
Tempo real	Streaming datasets e DirectQuery; intervalos de refresh se aplicam	Consulta sob demanda; sem push	Consulta sob demanda; polling com auto-refresh	O melhor da categoria para séries temporais e métricas; painéis ao vivo	Qualquer latência que você projetar: SSE, WebSockets, polling
Personalização	Alta dentro do modelo do Power BI; custom visuals possíveis	Alta via LookML; UI restrita	Moderada; perguntas em SQL, visuais limitados	Alta para séries temporais; fraca para gráficos de negócio e tabelas	Ilimitada, mas tudo é responsabilidade sua
Governança de dados	Datasets, dados certificados, rótulos de sensibilidade, integração com Purview	LookML é a camada semântica; versionado em git	Básica; modelos e permissões por coleção	Mínima; a governança fica na fonte de dados	Só o que você construir; em geral camada semântica mais testes
Gestão de usuários	Entra ID (Azure AD) nativo; RLS por papel	SSO, grupos, atributos de usuário controlam filtros de linha	Grupos, sandbox por grupo; SSO nos planos pagos	Times, pastas, SSO; RLS limitado	Seu provedor de identidade; RLS aplicado na camada de dados
Melhor encaixe	Ambientes Microsoft, relatórios internos, finanças	Times de dados com warehouse modelado, embedding em SaaS	Times pequenos, perguntas internas rápidas, orçamento baixo	Infraestrutura e telemetria de produto	Analytics para clientes, consoles de operação, visões multi-tenant reguladas

Três padrões aparecem repetidamente:

• Só relatórios internos. Compre. Power BI se você está no Microsoft 365, Looker se já modela dados em um warehouse, Metabase se o orçamento é apertado. Um build custom aqui é passivo de manutenção.
• Analytics dentro de um produto SaaS. Em geral custom, ou Looker embedded se você já paga pelo Looker. Power BI Embedded funciona, mas o preço por capacidade e a identidade visual raramente combinam com um produto.
• Console de operações com dados ao vivo. Grafana para infraestrutura, custom para operações de negócio (quadros de despacho, filas de fraude, chão de armazém). As ferramentas de BI não foram desenhadas para atualizações abaixo de um minuto e ações do usuário na mesma tela.

A linha que separa os dois campos: se os usuários precisam agir a partir da tela (aprovar, atribuir, escalar), é uma aplicação, não um relatório. Construa. Se os usuários precisam fazer perguntas novas, é análise. Compre.

Arquitetura de dados por trás de um dashboard de negócios

O front-end é os dez por cento visíveis. Todo dashboard confiável, custom ou comprado, se apoia nas mesmas cinco camadas.

1. Sistemas de origem

ERP, CRM, faturamento, banco do produto, streams de eventos, planilhas. Inventarie todos com dono, cadência de atualização e método de acesso (API, réplica, CDC, exportação de arquivo). Nunca consulte bancos OLTP de produção diretamente de um dashboard: uma única consulta de relatório sem índice pode travar a tabela de checkout.

2. Ingestão: ETL ou ELT

Em 2026 o padrão é ELT: aterrisse os dados brutos em um warehouse ou lakehouse (BigQuery, Snowflake, Redshift, Databricks, ou Postgres/ClickHouse para volumes menores) e transforme com SQL versionado (dbt ou SQLMesh). Use ETL só quando os dados precisam ser mascarados antes de aterrissar, o que é comum sob o GDPR quando o warehouse está em jurisdição diferente da origem.

3. Camada modelada

Fatos e dimensões, ou uma tabela larga por domínio. O objetivo é um schema que uma consulta de dashboard alcance com um ou dois joins, não as cinquenta tabelas do sistema de origem. Mantenha os dados brutos imutáveis e reconstruíveis, para que um bug numa transformação seja uma reexecução, não um incidente.

4. Camada semântica

A camada que diz "receita = sum(invoice_total) where status = 'paid'" exatamente uma vez. Opções: LookML (Looker), datasets do Power BI, dbt metrics via MetricFlow, Cube, ou um módulo de métricas escrito à mão na sua API. Um dashboard custom sem camada semântica produz três números de receita em três telas em seis meses.

5. Agregação e atualidade

Decida por métrica: quão antiga ela pode ser? Escreva isso.

Tipo de métrica	Atualidade típica	Mecanismo
Fechamento financeiro, DRE	Diária	Batch noturno, tabela pré-agregada
Pipeline de vendas	Horária	Modelo incremental a cada hora
Uso do produto	5–15 minutos	Ingestão por streaming, agregação em micro-batch
Fila de operações, fraude	Segundos	Stream de eventos, push para o cliente

Mostre a atualidade na tela ("Dados de 07:00 BRT"); usuário que não vê timestamp assume que o dado é ao vivo.

Regras de escolha de gráficos que sobrevivem à revisão

A maioria dos dashboards falha por ter vinte gráficos numa tela sem ninguém conseguir dizer qual importa. Regras que se sustentam:

1. Uma pergunta por gráfico. Se o título não pode ser escrito como pergunta ("O churn está subindo no Sul?"), o gráfico é decoração.
2. Tendência: linha. Tempo no eixo x, de uma a quatro séries. Mais de quatro vira um grid de small multiples.
3. Comparação entre categorias: barra horizontal, ordenada por valor, não alfabeticamente. Os rótulos continuam legíveis no celular.
4. Parte de um todo: barra empilhada ou barra 100%. Gráficos de pizza falham assim que há mais de três fatias ou os valores são próximos. Donut com um número grande no centro é aceitável para uma única proporção.
5. Distribuição: histograma ou box plot. Médias escondem a forma.
6. Relação: dispersão, com linha de tendência só quando for estatisticamente significativa.
7. KPI único: número, variação em relação ao período anterior, sparkline. É o tile que executivos realmente leem.
8. Tabelas também são gráficos. Para conciliação e operações, uma tabela ordenável com formatação condicional supera qualquer visualização.
9. Cor codifica significado, não decoração. Uma cor de destaque para "esta série", uma para "alerta", cinzas para todo o resto. Use uma paleta segura para daltônicos e cumpra o contraste WCAG.
10. Nunca trunque o eixo y em gráfico de barras. Em gráfico de linha, truncar é permitido se estiver sinalizado.
11. Acima da dobra: no máximo cinco a sete tiles. Todo o resto é drill-down.

Hierarquia de layout: KPIs no topo, tendências no meio, tabelas de detalhe embaixo. Filtros em uma barra no topo, aplicados globalmente, sempre visíveis.

Performance: pré-agregação, cache e tempo real

Um dashboard que leva oito segundos para carregar não é usado, por mais correto que seja.

Pré-agregue na escrita, não na leitura

Não varra cem milhões de eventos toda vez que alguém abre a página de vendas. Materialize rollups diários e horários por combinação de dimensões que aparece na tela. Uma tabela de rollup com alguns milhões de linhas responde à maioria dos dashboards de negócio em dezenas de milissegundos. Warehouses oferecem materialized views; no Postgres, um REFRESH MATERIALIZED VIEW CONCURRENTLY agendado ou uma tabela de rollup incremental resolve.

Cache na camada certa

Três caches, três tempos de vida:

• Cache de consulta (Redis ou o result cache do próprio warehouse) com chave pelo texto da consulta mais o contexto de segurança do usuário. O TTL é igual à política de atualidade da métrica, então uma métrica diária fica em cache por horas e uma horária por minutos.
• Cache de resposta da API com ETag ou Cache-Control: private, max-age, para que um reload não reexecute nada.
• Cache no cliente (TanStack Query, SWR), para que trocar de aba e voltar seja instantâneo, com revalidação em segundo plano.

Nunca compartilhe cache entre usuários quando há row-level security em jogo; uma chave de cache sem o ID do tenant é um vazamento de dados. O guia de estratégias de cache se aprofunda em invalidação e chaveamento.

// A chave de cache precisa incluir tudo que altera o conjunto de resultados
const key = `dash:v3:${metricId}:${tenantId}:${roleHash}:${dateRange}:${filtersHash}`;

Tempo real só onde compensa

Polling a cada trinta segundos serve para a maioria das telas "ao vivo" e não custa nada para construir. Quando as atualizações precisam chegar em segundos, faça push: Server-Sent Events para streams unidirecionais do servidor para o cliente (a maioria dos dashboards), WebSockets quando o cliente também envia mensagens frequentes ou você precisa de frames binários. Os trade-offs estão em WebSockets vs Server-Sent Events. Em qualquer caso, envie deltas, não o dataset inteiro, e limite os re-renders no cliente para que uma rajada de mil eventos não repinte um gráfico mil vezes.

Orçamento de front-end

Faça lazy-load dos gráficos abaixo da dobra, virtualize tabelas longas e renderize séries grandes com canvas (ECharts, uPlot) em vez de SVG. Dez mil nós SVG travam um laptop intermediário.

Controle de acesso e row-level security

Três camadas:

Autenticação. SSO pelo seu provedor de identidade com OIDC ou SAML; tokens de vida curta; nada de contas compartilhadas de "visualizador de dashboard". Veja autenticação moderna com OAuth 2.0 e JWT.

Autorização no nível da tela. Papéis decidem quais dashboards e quais tiles ficam visíveis. Mantenha isso grosseiro: "financeiro", "gerente-de-vendas", "cliente".

Row-level security na camada de dados. É aqui que os times erram, filtrando na UI ou na query string. Aplique onde as consultas rodam:

-- Postgres: a política vale para toda consulta, inclusive as que você esqueceu
ALTER TABLE sales_daily ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON sales_daily
  USING (tenant_id = current_setting('app.tenant_id')::uuid);

A API define app.tenant_id a partir do token verificado antes de rodar qualquer consulta. Warehouses oferecem equivalentes (row access policies no Snowflake, row-level access no BigQuery, papéis de RLS no Power BI, user attributes no Looker). Para regras em nível de coluna (salário visível só para o RH), mascare na camada semântica, não no gráfico.

Registre toda consulta com usuário, tenant, filtros e contagem de linhas: é a sua trilha de auditoria para o GDPR.

Dashboards mobile

A maioria dos executivos abre dashboards no celular entre reuniões. Projete para isso explicitamente:

• Mobile é um layout diferente, não um layout encolhido. Empilhe os tiles de KPI um por linha; mantenha um gráfico por altura de tela; coloque tabelas atrás de um toque.
• Alvos de toque de pelo menos 44 px, sem tooltips só por hover; toque para mostrar valores.
• Barras horizontais, não verticais, para que os rótulos de categoria tenham espaço.
• Menos séries. Duas linhas no celular, não seis.
• Leitura offline. Um PWA que mostra o último estado carregado com o timestamp supera um spinner no trem.
• Notificações push para alertas com deep link para a visão filtrada; é aqui que o custom supera qualquer ferramenta de BI.

Checklist de projeto de dashboard

Cada "não" é um risco a precificar.

• Cada dashboard tem um dono nomeado e uma decisão escrita que ele apoia.
• Cada métrica tem uma definição única em uma camada semântica, com teste.
• A atualidade por métrica está documentada e visível na tela.
• Os sistemas de origem são lidos por réplicas, CDC ou exportações, nunca OLTP de produção.
• As consultas pesadas batem em tabelas pré-agregadas; a meta de p95 de carregamento está definida (dois segundos é uma régua comum).
• As chaves de cache incluem tenant e papel; os TTLs seguem a política de atualidade.
• Row-level security é aplicado no banco ou na camada semântica e coberto por um teste automatizado que tenta ler linhas de outro tenant.
• SSO implantado; sem contas compartilhadas.
• Os tipos de gráfico seguem as regras de escolha; nada acima da dobra além de sete tiles.
• O layout mobile é projetado, não derivado.
• Existe log de auditoria de consultas, retido conforme sua política de GDPR.

Template de requisitos

Um pedido que não consegue responder a isto não está pronto para estimativa.

1. Audiência. Quem, quantos, interno ou externo, em quais dispositivos.
2. Decisões. As três decisões que este dashboard deve mudar, em uma frase cada.
3. Métricas. Nome, fórmula, origem, dono, requisito de atualidade, tolerância aceitável.
4. Dimensões e filtros. Quais quebras (tempo, região, produto, cliente) e quais filtros precisam ser globais.
5. Ações. Os usuários podem fazer algo a partir da tela (aprovar, atribuir, comentar)? Se sim, é uma aplicação; escope como tal.
6. Segurança. Papéis, regras de linha (tenant, região, time), máscaras de coluna, necessidades de auditoria.
7. Latência. Meta de carregamento e latência de atualização por tela (diária, horária, minutos, segundos).
8. Volume. Linhas por tabela de fatos hoje e em dois anos; usuários simultâneos no pico.
9. Embedding e marca. Standalone, dentro de um produto, white-label, restrições de tema.
10. Exportação e entrega. CSV, PDF, e-mail agendado, acesso por API para sistemas downstream.
11. Alertas. Limiares, canais (e-mail, push, Slack, Teams), quem os configura.
12. Ferramentas existentes. Licenças de BI já pagas, provedor de identidade, warehouse, plataforma de eventos.
13. Não objetivos. O que está explicitamente fora do escopo da versão um.
14. Medida de sucesso. Como você saberá em 90 dias se funcionou (adoção, latência de decisão, relatórios aposentados).

Recomendação

Por padrão, use uma ferramenta de BI para análise interna: Power BI em ambiente Microsoft, Looker sobre um warehouse modelado, Metabase quando orçamento e escopo são pequenos, Grafana para telemetria. Construa um dashboard custom quando ele é voltado ao cliente, embarcado no seu produto, precisa de atualizações push em segundos ou exige ações na mesma tela. Nos dois casos, invista primeiro nas partes invisíveis: camada semântica, pré-agregação, política de atualidade e row-level security. Elas decidem se os números são confiáveis; os gráficos só decidem se são lidos. Na Arvucore, costumamos recomendar manter a ferramenta de BI para exploração e construir custom só as duas ou três telas onde a ferramenta falha visivelmente, e expandir a partir daí.