Embedding de dashboards de Metabase en SaaS: los tres modos y el aislamiento multi-tenant

Construiste un producto SaaS y el cliente quiere ver sus propios números allí dentro — no en otra herramienta, detrás de otro login. Metabase resuelve esto con embedding, pero "embeber un dashboard" esconde tres modos bien diferentes y una pregunta que lo decide todo: cómo garantizar que cada cliente vea estrictamente sus datos.

Enviar al cliente a una herramienta separada cuesta contexto, login y adopción. Analytics embebido — dashboards dentro de tu propia interfaz, con tu marca — se vuelve parte del producto: el dato aparece donde ocurre la decisión. La cuestión nunca es si, es cómo — y el "cómo" en Metabase tiene tres formas.

• Static embedding (firmado) — un iframe con un token JWT firmado en el servidor. Los parámetros (ej.: el identificador del cliente) van bloqueados dentro del token; el usuario no interactúa ni los altera. Ideal para un panel fijo por cliente. Disponible en el open source.
• Interactive embedding — el Metabase completo embebido, con login vía SSO (JWT), donde el cliente explora y crea sus propias preguntas. Requiere Pro/Enterprise y combina con data sandboxing.
• SDK de analytics embebido (React) — componentes de Metabase dentro de tu aplicación, con control fino de layout y tema. Recurso Enterprise.

En un producto multi-tenant, el peor error posible es que un cliente vea los datos de otro. El aislamiento seguro depende del modo:

• Static embedding — el tenant va como parámetro bloqueado (locked) dentro del JWT firmado en tu backend. Como el token está firmado con un secreto del servidor, el cliente no tiene forma de falsificar otro identificador. Es el camino de aislamiento en el open source.
• Interactive embedding + data sandboxing — el filtro por fila se aplica automáticamente según el usuario del JWT, incluso si explora libremente. Es el aislamiento más fuerte para exploración abierta — y es Enterprise.
• OSS sin sandboxing — cuando necesitas exploración en el open source, la ruta es separar el dato por conexión/schema por tenant (la misma arquitectura de nuestro artículo de gobernanza en Metabase OSS).

• Pasar el tenant_id en un parámetro de URL editable — el cliente cambia el número y ve al vecino.
• Embeber sin firma (embed público) creyendo que "nadie va a adivinar la URL".
• Confiar en el front-end para filtrar — el filtro tiene que vivir en el token firmado o en la base de datos, nunca en el JavaScript.

Regla práctica: si el cliente solo necesita ver un panel por tenant, static embedding firmado lo resuelve — y corre en el open source. Si necesita explorar y crear preguntas con aislamiento por fila, es interactive embedding + data sandboxing (Enterprise). Si la exploración es necesaria pero el presupuesto es OSS, separa el dato por tenant en la arquitectura. El error es elegir por el brillo de la demo, no por el requisito real de aislamiento.