BI sin licencias: Metabase vs Redash vs Superset

Cada renovación anual de licencias de Business Intelligence duele un poco más. Power BI subió precios en 2025, Tableau se factura por usuario y por rol, y Looker directamente exige presupuesto de gran cuenta. Para una pyme o una startup que solo quiere ver sus métricas de negocio en un dashboard decente, pagar 10, 20 o 40 euros por usuario y mes por una herramienta que se usa dos veces por semana es difícil de justificar. La buena noticia: el ecosistema de BI open source ha madurado tanto que hoy es una alternativa seria, no un experimento.

Metabase, Redash y Apache Superset son las tres herramientas que concentran la mayoría de despliegues de BI open source en empresas. Las tres se conectan a tus bases de datos, las tres generan dashboards compartibles y las tres pueden autoalojarse sin pagar un euro en licencias. Pero se parecen menos de lo que sugiere cualquier comparativa rápida: una está pensada para que pregunte cualquiera, otra para equipos que viven en SQL y la tercera para organizaciones con un volumen de datos y de usuarios que ya justifica plataforma propia.

En Keliam llevamos años desplegando y manteniendo estas herramientas para clientes que quieren tomar decisiones basadas en datos sin un gran presupuesto. En esta guía comparamos las tres a fondo desde el punto de vista que nos toca: qué cuesta de verdad montarlas, operarlas y asegurarlas, qué equipo necesitas y cuál encaja según el perfil de tu empresa. Sin marketing: con requisitos de hardware, modelo de permisos y las limitaciones que descubrirás en el mes dos.

1. Por qué plantearse BI open source en 2026

El argumento del coste es el más visible, pero no es el único. Estas son las razones por las que cada vez más CTOs y responsables de IT evalúan alternativas open source antes de firmar con un proveedor comercial:

1.1 El coste por usuario penaliza justo lo que quieres conseguir

El objetivo de un proyecto de BI es que toda la organización mire los datos: comerciales, operaciones, atención al cliente, dirección. Con licencias por usuario, cada persona que añades al dashboard es un coste recurrente, así que las empresas acaban restringiendo el acceso a «los que lo necesitan de verdad» — exactamente lo contrario de una cultura de datos. Con una herramienta autoalojada, el usuario número 50 cuesta lo mismo que el número 5: nada. El coste pasa a ser fijo (infraestructura y mantenimiento) en lugar de lineal con la adopción.

1.2 Soberanía del dato y RGPD

Un BI en modo SaaS implica que tus ventas, márgenes y datos de clientes viajan a la nube del proveedor, con lo que eso supone en cláusulas de encargado de tratamiento, transferencias internacionales y dependencia. Autoalojando, los datos no salen de tu infraestructura: la herramienta se conecta a tus bases de datos desde tu propia red. Para empresas que trabajan con administración pública o manejan datos sensibles, este punto por sí solo decide la evaluación.

1.3 Madurez real del ecosistema

Metabase supera las 44.000 estrellas en GitHub, Superset las 68.000 y ambos tienen releases mensuales, documentación seria y comunidades activas. No hablamos de proyectos huérfanos: Superset nació en Airbnb y es proyecto top-level de la Apache Software Foundation; Metabase y Redash tienen empresas detrás que viven de sus versiones cloud. El riesgo de abandono, que era el miedo clásico con el open source, es hoy menor que el riesgo de que tu proveedor SaaS te suba la tarifa un 30%.

1.4 Cuándo NO es buena idea

Seamos claros: si nadie en tu empresa puede dedicar unas horas al mes a operar la herramienta (actualizaciones, backups, permisos) y tampoco quieres delegarlo en un partner, un SaaS comercial te dará menos disgustos. El open source no es gratis: es licencia cero a cambio de responsabilidad de operación. Sobre esa base, sigamos.

2. Metabase: BI para que pregunte cualquiera

Metabase es la opción con menor fricción de adopción de las tres. Su editor visual de preguntas permite que un perfil de negocio — sin SQL — filtre, agrupe y grafique datos con unos clics. Esa es su gran baza y la razón por la que muchas pymes lo eligen.

2.1 Qué ofrece

• Query builder visual: «quiero ver pedidos, agrupados por mes, filtrados por provincia» se hace sin escribir una línea de SQL. El SQL nativo también está disponible para quien lo prefiera.
• Modelos y métricas: puedes definir modelos semánticos (qué es «ingreso neto», qué es «cliente activo») para que todo el mundo calcule igual las mismas cifras.
• Dashboards con filtros interactivos, alertas y suscripciones: envío programado de dashboards por email o Slack, alertas cuando una métrica cruza un umbral.
• Embedding: incrustar gráficos en aplicaciones propias o portales de cliente (con matices de licencia en la versión open source).
• Más de 20 conectores oficiales: MySQL, PostgreSQL, SQL Server, BigQuery, MongoDB, entre otros.

2.2 Despliegue y requisitos

Es un único JAR de Java o un contenedor Docker. Con 2 vCPU y 4 GB de RAM funciona con soltura para decenas de usuarios; la base de datos interna de la aplicación debe ser PostgreSQL en producción (el H2 embebido solo vale para probar). Actualizar es reemplazar el contenedor. De las tres, es la que menos conocimiento de sistemas exige.

2.3 Limitaciones

La edición open source (AGPL) no incluye permisos a nivel de fila ni por columna (sandboxing), SSO con SAML, ni embedding interactivo con marca blanca: eso queda en las ediciones de pago. Los permisos de la versión libre son por grupo, base de datos, esquema y colección — suficientes para la mayoría de pymes, cortos si necesitas que cada delegación vea solo sus datos con la misma tarjeta de dashboard. En visualización es correcto pero no espectacular: gráficos estándar bien resueltos, poca personalización avanzada.

3. Redash: SQL primero, para equipos técnicos

Redash toma el enfoque contrario: su unidad básica es la query SQL. Todo dashboard es una colección de consultas escritas a mano. Si tu equipo vive en SQL, esta franqueza se agradece; si esperas que marketing haga sus propios informes, ya no.

3.1 Qué ofrece

• Editor SQL potente con autocompletado de esquema, parámetros en las consultas (dropdowns, fechas) y resultados cacheados con refresco programado.
• Muchísimas fuentes de datos: más de 35, incluyendo APIs JSON, Google Sheets, Elasticsearch, Prometheus o ClickHouse — es notablemente bueno consultando fuentes «raras» que no son bases relacionales.
• Alertas sobre resultados de consultas con destino a email, Slack o webhooks.
• API REST completa: crear, ejecutar y extraer resultados de consultas programáticamente, útil para automatizaciones.

3.2 Despliegue y requisitos

Stack Python con varios servicios: aplicación web, workers de Celery para ejecutar consultas, Redis y PostgreSQL. El docker-compose oficial lo levanta todo, pero son más piezas que vigilar que el JAR único de Metabase. Con 2 vCPU y 4 GB de RAM va bien para un equipo pequeño.

3.3 El matiz importante: el estado del proyecto

Hay que decirlo claro: desde que Databricks adquirió la empresa en 2020, el desarrollo de la versión open source de Redash se ha ralentizado de forma notable. El proyecto sigue vivo, mantenido por la comunidad, y hay miles de instalaciones funcionando en producción — pero el ritmo de novedades no es comparable al de Metabase o Superset. Nuestra lectura: Redash sigue siendo una elección razonable como capa ligera de consultas SQL compartidas, sobre todo por su riqueza de conectores, pero para un proyecto nuevo de BI corporativo a cinco años vista, hoy pesa más apostar por uno de los otros dos.

4. Apache Superset: la plataforma para ir en serio

Superset es la más ambiciosa de las tres: una plataforma de exploración y visualización de datos de nivel empresarial, con la gobernanza y la escalabilidad como prioridades. Es lo más cercano en open source a un Tableau o un Power BI en capacidades — y también lo más exigente de operar.

4.1 Qué ofrece

• Más de 40 tipos de visualización, incluyendo mapas, sunburst, sankey y gráficos avanzados que Metabase no tiene, más un motor de dashboards muy flexible (tabs, filtros cruzados, drill-down).
• Capa semántica: datasets con métricas y dimensiones definidas centralizadamente, sobre los que los usuarios exploran sin escribir SQL (y SQL Lab para los que sí lo escriben).
• Permisos finos de verdad: roles granulares y row-level security incluidos en la versión open source — lo que en Metabase es de pago, aquí es gratis.
• SSO empresarial: integración con OAuth, LDAP u OpenID Connect vía Flask AppBuilder, también sin pasar por caja.
• Escala: cachés con Redis, ejecución asíncrona de consultas con Celery, y compatibilidad con prácticamente cualquier base SQL vía SQLAlchemy, incluidos motores analíticos como ClickHouse, Druid o Trino.

4.2 Despliegue y requisitos

Aquí está el peaje: Superset es una aplicación Python con metadata database (PostgreSQL), Redis, workers Celery y beat scheduler. El despliegue serio se hace con Docker Compose o Helm en Kubernetes, y conviene reservar 4 vCPU y 8 GB de RAM como punto de partida. Las actualizaciones requieren migraciones de esquema y leerse las release notes. No es un proyecto de viernes por la tarde: es una plataforma que merece un responsable.

4.3 Limitaciones

La curva de aprendizaje es real, tanto para administradores como para usuarios de negocio: la interfaz es más densa que la de Metabase y la configuración inicial (roles, datasets, cachés) lleva días, no horas. No hay aplicación móvil ni un sistema de suscripciones por email tan redondo como el de Metabase (los informes programados existen, pero configurarlos es más áspero).

5. Comparativa directa: la tabla que importa

Criterio	Metabase	Redash	Superset
Usuario tipo	Negocio sin SQL	Analistas SQL	Analistas + negocio con formación
Sin saber SQL	Excelente	No viable	Posible con datasets preparados
Visualizaciones	Estándar, correctas	Básicas	Las más ricas (40+)
Row-level security gratis	No (de pago)	No	Sí
SSO (SAML/OAuth) gratis	Solo Google/LDAP	Parcial	Sí (OAuth/LDAP/OIDC)
Complejidad de operación	Baja	Media	Alta
Hardware inicial	2 vCPU / 4 GB	2 vCPU / 4 GB	4 vCPU / 8 GB
Ritmo de desarrollo	Muy activo	Ralentizado	Muy activo (Apache)
Licencia	AGPL v3	BSD-2	Apache 2.0

Una nota sobre licencias, porque en BI tiene consecuencias prácticas: la AGPL de Metabase obliga a liberar el código de modificaciones si ofreces la herramienta modificada como servicio, y su edición open source no permite ocultar el logo ni hacer marca blanca del embedding. Apache 2.0 (Superset) y BSD (Redash) son permisivas y no plantean estos problemas. Si tu plan incluye incrustar dashboards en un producto que vendes, revisa este punto con calma antes de elegir.

6. Arquitectura de referencia: dónde encaja el BI en tu stack

Un error habitual es conectar la herramienta de BI directamente contra la base de datos de producción de tu ecommerce o tu ERP. Funciona el primer mes; después, la consulta pesada de un dashboard compite con las transacciones de tus clientes y acabas con la web lenta a las 10 de la mañana. La arquitectura sana separa capas:

1. Fuentes: la base de datos transaccional de tu tienda o aplicación, el ERP/CRM, hojas de cálculo, APIs de terceros (Google Ads, pasarelas de pago).
2. Capa analítica: en el caso más simple, una réplica de lectura de MySQL/PostgreSQL. En cuanto cruzas fuentes, un pequeño warehouse (PostgreSQL dedicado o ClickHouse si el volumen aprieta) alimentado por procesos ETL — aquí es donde herramientas como n8n o scripts programados hacen el trabajo de conectar tu ERP y CRM a un dashboard sin castigar producción.
3. Visualización: Metabase, Redash o Superset leyendo solo de la capa analítica, con un usuario de base de datos de solo lectura y acceso restringido por red.

Este esquema además simplifica el RGPD: puedes seudonimizar o excluir columnas sensibles en el proceso de carga, de modo que el BI nunca vea datos personales que no necesita. Y si el día de mañana cambias de herramienta de visualización, la capa analítica — donde está el trabajo de verdad — se queda.

7. Seguridad: lo que no puedes descuidar al autoalojar

Autoalojar significa que la seguridad es tuya. Un Metabase o un Superset expuesto a internet con la configuración por defecto es un regalo: da acceso de lectura a todos tus datos de negocio. Lo mínimo exigible:

• Nunca expuesto directamente: detrás de un reverse proxy con TLS, y si el acceso es solo interno, detrás de VPN o con allowlist de IPs. Estas herramientas no están pensadas para aguantar internet hostil.
• Usuarios de BD de solo lectura y limitados a los esquemas necesarios. La herramienta de BI jamás debe poder escribir en tus datos.
• Autenticación seria: contraseñas fuertes, 2FA donde esté disponible, SSO corporativo si tienes directorio. Revisar y retirar cuentas de exempleados — el clásico.
• Actualizaciones al día: las tres publican parches de seguridad con regularidad. Superset, por ejemplo, ha corregido CVEs importantes en los últimos años que siguen explotándose en instalaciones abandonadas.
• Backups del metadata: las consultas, dashboards y permisos viven en la base de datos interna de la aplicación. Perderla es perder meses de trabajo de tu equipo.
• Logs y trazabilidad: quién consulta qué, especialmente si hay datos personales de por medio y tienes que responder ante una auditoría.

Si tu organización ya trabaja con marcos como ISO 27001 o el ENS, el BI autoalojado entra en el alcance como un activo más: inventario, análisis de riesgos y controles de acceso aplican igual que a cualquier sistema con datos de negocio.

8. Coste real: «gratis» con matices

Hagamos las cuentas que el departamento financiero va a pedir. Para un despliegue tipo de 25 usuarios activos:

8.1 Lo que cuesta el open source autoalojado

• Infraestructura: un VPS o instancia cloud de 2-4 vCPU y 4-8 GB de RAM, entre 20 y 80 €/mes según proveedor y si añades réplica analítica.
• Puesta en marcha: despliegue, conexión de fuentes, modelo de permisos y primeros dashboards: entre 2 y 10 jornadas de trabajo según complejidad, una vez.
• Operación: actualizaciones, backups, gestión de usuarios y soporte interno: de 2 a 8 horas al mes en régimen estable, internas o de un partner con contrato de mantenimiento.

8.2 La comparación honesta

Esos mismos 25 usuarios en un BI comercial tipo cuestan entre 250 y 900 €/mes en licencias, todos los meses, para siempre, y subiendo con cada renovación. El open source autoalojado suele quedar en 50-150 €/mes de coste recurrente equivalente una vez amortizada la puesta en marcha. El punto de equilibrio típico llega entre el mes 6 y el 12 — y a partir de ahí, cada usuario nuevo amplía la diferencia. Con 100 usuarios, la comparación deja de ser una decisión y pasa a ser una obviedad.

¿Cuándo no salen las cuentas? Con 3-5 usuarios y necesidades simples, la versión cloud de pago de estas mismas herramientas (Metabase Cloud parte de unos 85 $/mes) o incluso un plan básico de Power BI puede ser más barato que operar nada. El open source gana con la escala.

9. Cuál elegir según tu caso

9.1 Elige Metabase si…

Eres una pyme o startup, quieres resultados la primera semana y la mayoría de quienes consultarán datos no saben SQL. Es el punto de entrada con mejor relación esfuerzo/valor y la que menos operación exige. Encaja de maravilla como primer BI sobre un ecommerce: conectas la réplica de la tienda y en una tarde tienes los KPIs de tu ecommerce en un dashboard que dirección consulta desde el móvil.

9.2 Elige Redash si…

Tu equipo es técnico, vive en SQL, y necesitas consultar fuentes heterogéneas (APIs, Elasticsearch, Prometheus) desde un mismo sitio con alertas simples. Asume su ritmo de desarrollo lento como parte del trato. Para equipos de ingeniería que quieren compartir consultas operativas, sigue cumpliendo con nota.

9.3 Elige Superset si…

Tienes volumen de datos serio, muchos usuarios, necesidad de permisos finos (cada departamento o cliente ve solo lo suyo) y capacidad técnica para operar la plataforma — propia o externalizada. Es la única de las tres que compite de tú a tú con las suites comerciales en capacidades de gobierno y visualización, y su licencia Apache no te ata las manos.

9.4 El camino que solemos recomendar

En la mayoría de pymes: empezar con Metabase sobre una réplica analítica bien montada. Si en un año se queda corto en permisos o visualización, migrar la capa de visualización a Superset es asumible, porque el trabajo estructural — la capa de datos, los ETL, las métricas definidas — se conserva. Lo que no recomendamos es elegir herramienta antes de ordenar los datos: un Superset sobre datos caóticos da dashboards caóticos con mejor aspecto. Como contamos al comparar dashboards a medida frente a Power BI y Metabase, la herramienta es el 30% del proyecto; el otro 70% es modelar bien el dato. Y si tu fuente principal es un ERP como Odoo, esa ordenación previa es aún más determinante.

Conclusión

El BI open source ha dejado de ser la opción de los que no pueden pagar licencias para convertirse en la opción de los que han hecho números. Metabase democratiza el acceso al dato con una operación mínima; Superset ofrece plataforma de nivel empresarial con permisos y SSO que otros cobran aparte; Redash mantiene su nicho como capa SQL ligera para equipos técnicos. Las tres son software serio, en producción en miles de empresas.

La decisión no es tanto «¿cuál es mejor?» como «¿quién va a usarla, sobre qué datos y quién la va a operar?». Respondidas esas tres preguntas, la elección casi se hace sola — y el dinero de las licencias se queda en proyectos que muevan el negocio.

Preguntas frecuentes

¿Puedo migrar después de Metabase a Superset sin perder el trabajo?

Los dashboards y preguntas no se migran automáticamente entre herramientas: habrá que rehacerlos. Lo que se conserva íntegro es la capa de datos (réplica, warehouse, ETL, definiciones de métricas), que es donde reside la mayor parte del esfuerzo. Por eso insistimos en invertir ahí primero.

¿Estas herramientas sirven para dashboards en tiempo real?

Las tres refrescan consultas bajo demanda o programadas (cada pocos minutos), suficiente para el 95% de casos de negocio. Para tiempo real estricto (segundos), necesitarás motores analíticos tipo ClickHouse detrás — Superset es la que mejor se integra con ellos.

¿Qué pasa con el soporte si algo se rompe?

No hay teléfono al que llamar incluido en la licencia: el soporte es la comunidad, la documentación o un partner. Muchas empresas cubren esto con un contrato de mantenimiento que incluya la plataforma de BI junto al resto de sus sistemas.

¿Metabase, Redash y Superset funcionan con MySQL y PostgreSQL?

Sí, las tres soportan ambos de forma nativa y excelente. Superset, vía SQLAlchemy, es la que más motores cubre en total, incluyendo warehouses cloud y motores analíticos columnar.