Desarrollo de Dashboards en 2026: Custom vs Power BI

Construye un panel de visualización de datos a medida cuando el dashboard es una funcionalidad del producto, necesita push en tiempo real o debe servir a cientos de usuarios externos sin coste por asiento. Compra una herramienta de BI (Power BI, Looker, Metabase, Grafana) cuando la audiencia es interna, las preguntas cambian cada semana y los analistas necesitan explorar datos sin un deploy. La mayoría de las empresas necesitan ambos: una herramienta de BI para el análisis interno y una capa a medida solo donde el embedding, la latencia o el licenciamiento hacen que la herramienta de BI encaje mal.

Dashboard a medida vs Power BI, Looker, Metabase y Grafana

La pregunta correcta no es "cuál es la mejor herramienta", sino "quién mira esto, con qué frecuencia, cuán fresco debe estar y quién paga por usuario".

Criterio	Power BI	Looker	Metabase	Grafana	Dashboard a medida
Modelo de coste	Por usuario (Pro/Premium por usuario) o por capacidad; embedded requiere SKUs de capacidad	Por usuario más cuota de plataforma; precios enterprise	Open source self-hosted (gratis) o cloud por usuario	Open source self-hosted o cloud por uso	Coste de construcción + hosting + mantenimiento; sin coste por usuario
Embedding en tu producto	Sí, vía Embedded; requiere licencia de capacidad e iframe o SDK	Sí, embed SDK y signed URLs; fuerte para SaaS	Sí, iframe firmado; theming limitado	Sí, paneles por iframe; branding limitado en OSS	Nativo; control total de UX, tema e interacciones
Tiempo real	Streaming datasets y DirectQuery; aplican intervalos de refresco	Consulta bajo demanda; sin push	Consulta bajo demanda; polling con auto-refresh	El mejor de su clase para series temporales y métricas; paneles en vivo	Cualquier latencia que diseñes: SSE, WebSockets, polling
Personalización	Alta dentro del modelo de Power BI; custom visuals posibles	Alta vía LookML; UI restringida	Moderada; preguntas en SQL, visuales limitados	Alta para series temporales; débil para gráficos de negocio y tablas	Ilimitada, pero todo es responsabilidad tuya
Gobernanza de datos	Datasets, datos certificados, etiquetas de sensibilidad, integración con Purview	LookML es la capa semántica; versionado en git	Básica; modelos y permisos por colección	Mínima; la gobernanza vive en la fuente de datos	Solo lo que construyas; normalmente capa semántica más tests
Gestión de usuarios	Entra ID (Azure AD) nativo; RLS por rol	SSO, grupos, atributos de usuario controlan filtros de fila	Grupos, sandbox por grupo; SSO en planes de pago	Equipos, carpetas, SSO; RLS limitado	Tu proveedor de identidad; RLS aplicado en la capa de datos
Mejor encaje	Entornos Microsoft, reporting interno, finanzas	Equipos de datos con warehouse modelado, embedding en SaaS	Equipos pequeños, preguntas internas rápidas, presupuesto bajo	Infraestructura y telemetría de producto	Analítica para clientes, consolas de operaciones, vistas multi-tenant reguladas

Tres patrones se repiten:

• Solo reporting interno. Compra. Power BI si estás en Microsoft 365, Looker si ya modelas datos en un warehouse, Metabase si el presupuesto es ajustado. Un desarrollo a medida aquí es un pasivo de mantenimiento.
• Analítica dentro de un producto SaaS. Normalmente a medida, o Looker embedded si ya pagas Looker. Power BI Embedded funciona, pero el precio por capacidad y la identidad visual rara vez encajan con un producto.
• Consola de operaciones con datos en vivo. Grafana para infraestructura, a medida para operaciones de negocio (tableros de despacho, colas de fraude, planta de almacén). Las herramientas de BI no se diseñaron para actualizaciones por debajo del minuto y acciones del usuario en la misma pantalla.

La línea que separa los dos bandos: si los usuarios necesitan actuar desde la pantalla (aprobar, asignar, escalar), es una aplicación, no un informe. Constrúyela. Si los usuarios necesitan hacer preguntas nuevas, es análisis. Cómpralo.

Arquitectura de datos detrás de un dashboard de negocio

El front-end es el diez por ciento visible. Todo dashboard fiable, a medida o comprado, se apoya en las mismas cinco capas.

1. Sistemas de origen

ERP, CRM, facturación, base de datos del producto, streams de eventos, hojas de cálculo. Inventaríalos con propietario, cadencia de refresco y método de acceso (API, réplica, CDC, exportación de archivos). Nunca consultes bases de datos OLTP de producción directamente desde un dashboard: una sola consulta de informe sin índice puede bloquear la tabla de checkout.

2. Ingesta: ETL o ELT

En 2026 el estándar es ELT: aterriza los datos en bruto en un warehouse o lakehouse (BigQuery, Snowflake, Redshift, Databricks, o Postgres/ClickHouse para volúmenes menores) y transforma con SQL bajo control de versiones (dbt o SQLMesh). Usa ETL solo cuando los datos deben enmascararse antes de aterrizar, algo habitual bajo el RGPD cuando el warehouse está en una jurisdicción distinta a la del origen.

3. Capa modelada

Hechos y dimensiones, o una tabla ancha por dominio. El objetivo es un esquema al que una consulta de dashboard llegue con uno o dos joins, no las cincuenta tablas del sistema de origen. Mantén los datos en bruto inmutables y reconstruibles, para que un bug en una transformación sea una reejecución, no un incidente.

4. Capa semántica

La capa que dice "ingresos = sum(invoice_total) where status = 'paid'" exactamente una vez. Opciones: LookML (Looker), datasets de Power BI, dbt metrics vía MetricFlow, Cube, o un módulo de métricas escrito a mano en tu API. Un dashboard a medida sin capa semántica produce tres cifras de ingresos en tres pantallas en seis meses.

5. Agregación y frescura

Decide por métrica: ¿cuán antigua puede ser? Escríbelo.

Tipo de métrica	Frescura típica	Mecanismo
Cierre financiero, P&L	Diaria	Batch nocturno, tabla preagregada
Pipeline de ventas	Horaria	Modelo incremental cada hora
Uso del producto	5–15 minutos	Ingesta por streaming, agregación en micro-batch
Cola de operaciones, fraude	Segundos	Stream de eventos, push al cliente

Muestra la frescura en pantalla ("Datos a las 07:00 CET"); un usuario que no ve una marca de tiempo asume que el dato es en vivo.

Reglas de selección de gráficos que sobreviven a la revisión

La mayoría de los dashboards fallan por tener veinte gráficos en una pantalla sin que nadie sepa cuál importa. Reglas que aguantan:

1. Una pregunta por gráfico. Si el título no puede escribirse como pregunta ("¿Está subiendo el churn en DACH?"), el gráfico es decoración.
2. Tendencia: línea. Tiempo en el eje x, de una a cuatro series. Más de cuatro se convierte en una cuadrícula de small multiples.
3. Comparación entre categorías: barra horizontal, ordenada por valor, no alfabéticamente. Las etiquetas siguen legibles en móvil.
4. Parte de un todo: barra apilada o barra al 100%. Los gráficos de tarta fallan en cuanto hay más de tres porciones o los valores son cercanos. Un donut con una cifra grande en el centro es aceptable para una sola proporción.
5. Distribución: histograma o box plot. Las medias ocultan la forma.
6. Relación: dispersión, con línea de tendencia solo cuando es estadísticamente significativa.
7. KPI único: cifra, variación respecto al periodo anterior, sparkline. Es la tarjeta que los directivos realmente leen.
8. Las tablas también son gráficos. Para conciliación y operaciones, una tabla ordenable con formato condicional supera a cualquier visualización.
9. El color codifica significado, no decoración. Un color de acento para "esta serie", uno para "alerta", grises para todo lo demás. Usa una paleta apta para daltónicos y cumple el contraste WCAG.
10. Nunca truncar el eje y en un gráfico de barras. En uno de líneas, truncar está permitido si se indica.
11. Above the fold: como máximo de cinco a siete tarjetas. Todo lo demás es drill-down.

Jerarquía de layout: KPIs arriba, tendencias en medio, tablas de detalle abajo. Filtros en una barra superior, aplicados globalmente, siempre visibles.

Rendimiento: preagregación, caché y tiempo real

Un dashboard que tarda ocho segundos en cargar no se usa, por muy correcto que sea.

Preagrega en escritura, no en lectura

No recorras cien millones de eventos cada vez que alguien abre la página de ventas. Materializa rollups diarios y horarios por cada combinación de dimensiones que aparece en pantalla. Una tabla de rollup de unos pocos millones de filas responde a la mayoría de dashboards de negocio en decenas de milisegundos. Los warehouses ofrecen vistas materializadas; en Postgres, un REFRESH MATERIALIZED VIEW CONCURRENTLY programado o una tabla de rollup incremental hacen el trabajo.

Caché en la capa correcta

Tres cachés, tres tiempos de vida:

• Caché de consulta (Redis o el result cache del propio warehouse) con clave por el texto de la consulta más el contexto de seguridad del usuario. El TTL es igual a la política de frescura de la métrica, así que una métrica diaria se cachea durante horas y una horaria durante minutos.
• Caché de respuesta de la API con ETag o Cache-Control: private, max-age, para que una recarga no vuelva a ejecutar nada.
• Caché en el cliente (TanStack Query, SWR), para que cambiar de pestaña y volver sea instantáneo, con revalidación en segundo plano.

Nunca compartas caché entre usuarios cuando hay row-level security en juego; una clave de caché sin el ID del tenant es una fuga de datos. La guía de estrategias de caché profundiza en invalidación y claves.

// La clave de caché debe incluir todo lo que cambia el conjunto de resultados
const key = `dash:v3:${metricId}:${tenantId}:${roleHash}:${dateRange}:${filtersHash}`;

Tiempo real solo donde compensa

Un polling cada treinta segundos vale para la mayoría de pantallas "en vivo" y no cuesta nada construirlo. Cuando las actualizaciones deben llegar en segundos, haz push: Server-Sent Events para streams unidireccionales del servidor al cliente (la mayoría de dashboards), WebSockets cuando el cliente también envía mensajes frecuentes o necesitas frames binarios. Los trade-offs están en WebSockets vs Server-Sent Events. En cualquier caso, envía deltas, no el dataset completo, y limita los re-renders en el cliente para que una ráfaga de mil eventos no repinte un gráfico mil veces.

Presupuesto de front-end

Carga en diferido los gráficos below the fold, virtualiza las tablas largas y renderiza series grandes con canvas (ECharts, uPlot) en lugar de SVG. Diez mil nodos SVG congelan un portátil de gama media.

Control de acceso y row-level security

Tres capas:

Autenticación. SSO a través de tu proveedor de identidad con OIDC o SAML; tokens de vida corta; nada de cuentas compartidas de "visor de dashboard". Consulta autenticación moderna con OAuth 2.0 y JWT.

Autorización a nivel de pantalla. Los roles deciden qué dashboards y qué tarjetas son visibles. Mantenlo grueso: "finanzas", "responsable-de-ventas", "cliente".

Row-level security en la capa de datos. Aquí es donde los equipos se equivocan, filtrando en la UI o en la query string. Aplícalo donde se ejecutan las consultas:

-- Postgres: la política aplica a toda consulta, incluidas las que olvidaste
ALTER TABLE sales_daily ENABLE ROW LEVEL SECURITY;

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

La API fija app.tenant_id a partir del token verificado antes de ejecutar cualquier consulta. Los warehouses ofrecen equivalentes (row access policies en Snowflake, row-level access en BigQuery, roles de RLS en Power BI, user attributes en Looker). Para reglas a nivel de columna (salario visible solo para RR. HH.), enmascara en la capa semántica, no en el gráfico.

Registra cada consulta con usuario, tenant, filtros y número de filas: es tu pista de auditoría para el RGPD.

Dashboards móviles

La mayoría de los directivos abren dashboards en el móvil entre reuniones. Diseña para ello explícitamente:

• Móvil es un layout distinto, no uno encogido. Apila las tarjetas de KPI una por fila; mantén un gráfico por altura de pantalla; deja las tablas detrás de un toque.
• Objetivos táctiles de al menos 44 px, sin tooltips solo por hover; toca para mostrar valores.
• Barras horizontales, no verticales, para que las etiquetas de categoría tengan espacio.
• Menos series. Dos líneas en un móvil, no seis.
• Lectura offline. Una PWA que muestra el último estado descargado con su marca de tiempo supera a un spinner en el tren.
• Notificaciones push para alertas con deep link a la vista filtrada; aquí es donde lo a medida supera a cualquier herramienta de BI.

Checklist de proyecto de dashboard

Cada "no" es un riesgo que hay que poner en precio.

• Cada dashboard tiene un propietario con nombre y una decisión escrita a la que da soporte.
• Cada métrica tiene una única definición en una capa semántica, con test.
• La frescura por métrica está documentada y se muestra en pantalla.
• Los sistemas de origen se leen mediante réplicas, CDC o exportaciones, nunca OLTP de producción.
• Las consultas pesadas van a tablas preagregadas; hay objetivo de p95 de carga de página (dos segundos es un listón habitual).
• Las claves de caché incluyen tenant y rol; los TTL coinciden con la política de frescura.
• Row-level security se aplica en la base de datos o la capa semántica y está cubierto por un test automatizado que intenta leer filas de otro tenant.
• SSO en marcha; sin cuentas compartidas.
• Los tipos de gráfico siguen las reglas de selección; nada above the fold más allá de siete tarjetas.
• El layout móvil está diseñado, no derivado.
• Existe log de auditoría de consultas, retenido según tu política de RGPD.

Plantilla de requisitos

Una petición que no puede responder a esto no está lista para estimar.

1. Audiencia. Quién, cuántos, interna o externa, en qué dispositivos.
2. Decisiones. Las tres decisiones que este dashboard debería cambiar, en una frase cada una.
3. Métricas. Nombre, fórmula, origen, propietario, requisito de frescura, tolerancia aceptable.
4. Dimensiones y filtros. Qué desgloses (tiempo, región, producto, cliente) y qué filtros deben ser globales.
5. Acciones. ¿Pueden los usuarios hacer algo desde la pantalla (aprobar, asignar, comentar)? Si sí, es una aplicación; acótala como tal.
6. Seguridad. Roles, reglas de fila (tenant, región, equipo), máscaras de columna, necesidades de auditoría.
7. Latencia. Objetivo de carga de página y latencia de actualización por pantalla (diaria, horaria, minutos, segundos).
8. Volumen. Filas por tabla de hechos hoy y dentro de dos años; usuarios concurrentes en pico.
9. Embedding y marca. Standalone, dentro de un producto, white-label, restricciones de tema.
10. Exportación y entrega. CSV, PDF, correo programado, acceso por API para sistemas downstream.
11. Alertas. Umbrales, canales (correo, push, Slack, Teams), quién los configura.
12. Herramientas existentes. Licencias de BI ya pagadas, proveedor de identidad, warehouse, plataforma de eventos.
13. No objetivos. Qué queda explícitamente fuera del alcance de la versión uno.
14. Medida de éxito. Cómo sabrás en 90 días si funcionó (adopción, latencia de decisión, informes retirados).

Recomendación

Por defecto, una herramienta de BI para el análisis interno: Power BI en un entorno Microsoft, Looker sobre un warehouse modelado, Metabase cuando presupuesto y alcance son pequeños, Grafana para telemetría. Construye un dashboard a medida cuando está orientado al cliente, embebido en tu producto, necesita actualizaciones push en segundos o requiere acciones en la misma pantalla. En ambos casos, invierte primero en las partes invisibles: la capa semántica, la preagregación, la política de frescura y el row-level security. Esas deciden si las cifras son fiables; los gráficos solo deciden si se leen. En Arvucore solemos recomendar mantener la herramienta de BI para exploración y construir a medida solo las dos o tres pantallas donde la herramienta falla visiblemente, y expandir desde ahí.