---
title: "Dashboards en tiempo real con Metabase 2026"
description: "Cómo construir dashboards en tiempo real con Metabase en 2026: refresh automático, datos en streaming, caching, performance y arquitectura recomendada."
slug: "como-construir-dashboards-en-tiempo-real-con-metabase"
url: "https://catalizadora.ai/blog/como-construir-dashboards-en-tiempo-real-con-metabase"
cluster: "datos-sistemas/construir-dashboards-tiempo"
author: "Pablo Estrada"
published_at: "2026-05-11T12:00:00+00:00"
updated_at: "2026-06-19T19:59:51.42746+00:00"
read_minutes: "5"
lang: "es"
---
# Dashboards en tiempo real con Metabase 2026

> Cómo construir dashboards en tiempo real con Metabase en 2026: refresh automático, datos en streaming, caching, performance y arquitectura recomendada.

Para construir dashboards en tiempo real con Metabase en 2026 la regla es: **auto-refresh entre 5 y 60 segundos, cache global de 60 segundos, vistas materializadas Gold con refresh programado, y read replica de tu base para que las queries no peguen al primary**. Metabase no es streaming nativo, pero con esa combinación cubrís el 90 por ciento de casos operativos pyme. Para sub-segundo verdadero o cuando la lógica de negocio requiere KPIs en código con guardrails, vas a dashboard a medida.

## ¿Qué entendemos por dashboards en tiempo real?

"Tiempo real" en el mundo de dashboards es ambiguo. Tres niveles realistas:

1. **Near real-time (1 a 60 segundos)**: data se actualiza cada minuto. Metabase con auto-refresh lo cubre. Cubre operaciones, ventas, pedidos abiertos.
2. **Real-time (sub-segundo, push)**: data llega por WebSocket o Server-Sent Events. Metabase no lo soporta nativo. Necesitás dashboard custom.
3. **Batch refresh (5 minutos a 1 hora)**: data se actualiza periódica. Cualquier BI lo soporta sin estrés. Cubre reportería ejecutiva, KPIs estratégicos.

Para una pyme con operación normal, el 90 por ciento de paneles caben en near real-time. Sub-segundo es necesario para trading, telemetría IoT crítica, monitoreo de SRE. No para una distribuidora o una escuela.

## Configuración paso a paso de Metabase para tiempo real

### Paso 1: vistas materializadas en Gold

En tu Postgres o data lake, creá vistas materializadas para los KPIs que va a consumir Metabase:

```sql
CREATE MATERIALIZED VIEW gold.sales_today AS
SELECT 
  store_id,
  COUNT(*) AS orders,
  SUM(amount) AS revenue,
  AVG(amount) AS avg_ticket
FROM silver.sales
WHERE sale_date = CURRENT_DATE
GROUP BY 1;

CREATE INDEX ON gold.sales_today (store_id);

-- Refresh programado cada 1 minuto
SELECT cron.schedule('refresh-sales-today', '* * * * *', $$
  REFRESH MATERIALIZED VIEW CONCURRENTLY gold.sales_today;
$$);
```

`CONCURRENTLY` permite que la materialized view se refresque sin bloquear lecturas. `pg_cron` lo orquesta cada minuto.

### Paso 2: cache en Metabase con TTL razonable

En Admin Settings > Caching activá cache global con TTL configurable:

- **Minimum query duration**: 1 segundo (queries más cortas no se cachean, no vale la pena).
- **Cache TTL multiplier**: 10x el tiempo de la query. Una query de 2 segundos se cachea 20 segundos.
- **Max cache entry age**: 60 segundos para dashboards operativos, 300 segundos para ejecutivos.

Con cache 60 segundos y auto-refresh del dashboard cada 60 segundos, el primer cliente que abre paga la query, los siguientes 59 segundos consumen cache.

### Paso 3: auto-refresh del dashboard

En cada dashboard Metabase, click en el ícono de reloj > Auto-refresh > seleccioná intervalo (1 min, 5 min, 10 min, 15 min, 30 min, 60 min, o custom).

Para operaciones recomendado 1 minuto. Para reportería ejecutiva 5 minutos. Para vista estratégica 15 minutos.

### Paso 4: read replica para queries pesadas

Si tu volumen es serio (más de 100 GB con queries de varios segundos), creá una read replica de tu Postgres dedicada para Metabase. En Supabase Pro, AWS RDS, o Postgres self-hosted, las read replicas son nativas.

Metabase apunta a la replica; tu app operativa al primary. Cero contención.

## Arquitectura recomendada para pyme LATAM

```
Sistemas fuente (ERP, CRM, POS, Shopify)
  └─ Ingesta a Bronze (Supabase / S3 / BigQuery)
       └─ dbt transforma a Silver
            └─ Materialized views a Gold (refresh cada 1 a 5 min via pg_cron)
                 ├─ Read replica de gold para Metabase
                 │    └─ Metabase con cache 60s + auto-refresh dashboard 60s
                 └─ Read replica para queries ad-hoc del equipo de datos
```

Esta arquitectura te da: data fresca cada 1 a 5 minutos visible en Metabase, sin saturar la base operacional, escalable hasta varios TB, costo moderado (Supabase Pro 25 USD al mes más read replica desde 50 USD al mes).

## El caso real: 11 secciones de 21 segundos cold a 2 ms warm

En una escuela cliente nuestra rediseñamos un dashboard CEO de 11 secciones colapsables. No estaba en Metabase puro, sino en Flask con HTML/Jinja inline (filosofía similar, control total). Tenía cold load de 21 segundos: demasiado lento para uso ejecutivo.

Aplicamos:

- Cache de 60 segundos en memoria de HTML compilado.
- Paralelización de HubSpot API con ThreadPoolExecutor.
- Sparklines SVG inline (no librería externa, render instantáneo).
- KPI deltas semana-vs-semana visibles en cada card.
- TOC sticky con scrollspy.
- Sección de atribución multi-canal con 7 de 7 inscritos trazables.

Resultado: cold load 21 segundos a warm load 2 milisegundos. Mejora 10,000x. Auditoría 0 fails críticos. Eso es el techo de performance cuando vas a dashboard a medida.

## ¿Cuándo Metabase no es suficiente?

Metabase deja de servir cuando necesitás:

1. **Sub-segundo push real-time**: trading, IoT crítico, telemetría SRE. Acá vas a Grafana o dashboard custom con WebSockets.
2. **KPIs en código con guardrails**: cuando la lógica de negocio requiere TypeScript o JavaScript que calcula KPI exacto, y la IA sólo genera narrativa sobre datos verificados. Cero hallucinations en métricas.
3. **Branding pixel-perfect**: cuando el dashboard es producto cliente-facing y necesita la marca del cliente exacta.
4. **Multi-tenant complejo**: cuando cada cliente ve su dashboard con permisos granulares por rol y región. Metabase tiene RLS pero la curva de configuración es alta.

En esos casos, dashboard a medida. Una distribuidora cliente nuestra entregó reportería avanzada con 28 KPIs hardcoded en JavaScript, IA sólo para narrativa contextual, browser-side compute, audit trail inmutable con SHA-256.

## Próximos pasos

Si tu data ya está limpia en Postgres o data lake y tu lógica es estándar, Metabase con cache y auto-refresh te entrega tiempo real operativo en 2 a 4 semanas. Si tu lógica requiere KPIs en código o branding cliente-facing, agendá una llamada de 30 minutos sobre tu operación.

- [MAGIA Core](https://catalizadora.ai/magia/core) si querés data lake unificado más dashboards por rol en 12 semanas, código a tu nombre.
- [MAGIA Forge](https://catalizadora.ai/magia/forge) si tu reportería requiere motor de IA con guardrails y KPIs trazables a código.

Sin retainers, sin licencias atadas, código a tu nombre.
## Preguntas frecuentes

### ¿Metabase soporta dashboards en tiempo real real?

Metabase no es streaming nativo, pero soporta auto-refresh de dashboards cada 1 segundo, 1 minuto, 5 minutos o personalizado. Para tiempo real verdadero (sub-segundo, push-driven) necesitas dashboard custom con WebSockets. Metabase con refresh de 5 a 60 segundos cubre el 90 por ciento de casos pyme.

### ¿Cómo evito que Metabase tumbe mi base con refresh agresivo?

Tres tácticas: vistas materializadas en gold con refresh programado (no on-demand), cache de Metabase con TTL de 60 segundos, y read replica de tu base para que las queries de Metabase no peguen al primary. Sin esas tres, refresh agresivo en producción mata tu Postgres.

### ¿Cuál es el patrón recomendado para dashboards de operaciones?

Para operaciones (ventas en vivo, pedidos abiertos, capacidad operativa) usá vistas materializadas Gold con refresh cada 1 a 5 minutos, Metabase con cache 60 segundos y auto-refresh de panel cada 60 segundos. Suficiente para decisiones operativas, sin saturar la base.

### ¿Cómo configuro cache en Metabase?

En Admin Settings > Caching activás cache global con TTL configurable. Recomendado: cache mínimo 60 segundos, máximo 3600 segundos. Para dashboards ejecutivos con data estable, cache 5 minutos. Para operaciones, 60 segundos. Para data rara vez consultada, cache 1 hora.

### ¿Cuándo Metabase no es suficiente y necesito dashboard a medida?

Cuando necesitás push real-time sub-segundo, lógica de negocio compleja con KPIs en código contra hallucinations, branding pixel-perfect del cliente, o velocidad warm load sub-100 ms. Una escuela cliente nuestra rediseñó su dashboard de 21 segundos cold a 2 milisegundos warm con cache en memoria.


---

Source: https://catalizadora.ai/blog/como-construir-dashboards-en-tiempo-real-con-metabase
Author: Pablo Estrada — AI Catalyst, LLC (catalizadora.ai)