Metabase frente a Superset: permisos, costo y límite
Comparativa técnica para elegir BI self-hosted: permisos, consultas, PostgreSQL, costo mensual, prueba de salida y riesgos antes de producción.
Un tablero barato puede salir caro cuando todos ven la misma consulta. Metabase v0.62.2 y Apache Superset 6.1.0 cubren BI self-hosted desde lugares distintos: uno acelera preguntas operativas, el otro da más control a equipos de datos. Para pymes con PostgreSQL, ventas, stock o cobranza, la decisión debe mirar permisos, base de metadatos, consultas, respaldo y salida antes del primer gráfico.
Dónde aparece la decisión real
La cifra que ordena la comparación viene de GitHub: Metabase tenía 47.821 estrellas y Superset 73.451 al 23 de junio de 2026. Metabase publicó v0.62.2 el 17 de junio; Superset publicó 6.1.0 el 13 de mayo. Los dos proyectos están vivos, así que el desempate no pasa por popularidad. El tablero sin dueño es el punto de falla. La documentación de Metabase dice que los permisos se asignan a grupos y cubren datos, colecciones, aplicación, filas y columnas. Superset documenta roles provistos, permisos granulares y acceso por base o dataset, con Admin como rol plenamente confiable. El puente técnico vuelve a Stack Overflow 2025: PostgreSQL aparece con 55,6 % entre entornos de base usados, una señal útil para pymes que ya guardan datos estructurados ahí.
Cómo funciona por dentro
El flujo empieza con la conexión a datos. PostgreSQL guarda ventas, facturas, stock, usuarios o auditoría. Metabase o Superset reciben credenciales de sólo lectura, consultan tablas o vistas y guardan su propia configuración en una base de metadatos. Esa base guarda usuarios, tableros, consultas, permisos y preferencias. El segundo paso define permisos. En Metabase, administración crea grupos por área y decide qué tablas, colecciones y acciones puede usar cada grupo. En Superset, sistemas trabaja con roles, datasets, bases y permisos de SQL Lab. La regla operativa es simple: ventas consulta ventas, gerencia consulta tablero consolidado, sistemas administra conexión y auditoría revisa cambios. El tercer paso crea consultas. Metabase permite preguntas guiadas y SQL para usuarios con permiso. Superset trabaja con datasets, charts, dashboards y SQL Lab para perfiles más técnicos. El cuarto paso publica: un tablero queda en una colección o espacio con lectura controlada. El quinto paso alerta fallas: consulta lenta, conexión caída, credencial vencida o tablero sin dueño. El sexto paso prueba salida. Se exporta definición de consultas, se copia la base de metadatos y se restaura en otro servidor. Si el tablero se ve, pero las credenciales apuntan a producción con permisos amplios, la prueba todavía está incompleta.
Qué se instala o configura primero
La pila inicial usa PostgreSQL 17, vistas de sólo lectura, Metabase v0.62.2 o Superset 6.1.0, proxy HTTPS, backup diario, logs y una cuenta administrativa separada. Con dólar oficial vendedor de $ 1.481,79, un servidor de USD 20 a USD 60 por mes equivale a $ 29.636 a $ 88.907 mensuales. Una implementación de USD 700 a USD 1.500 queda entre $ 1,04 y $ 2,22 millones. Incluye conexión a una base, cinco vistas, dos tableros, matriz de permisos, respaldo y restauración. No incluye limpieza de datos viejos ni gobierno completo de definiciones comerciales. UMSA suele empezar con una pregunta estrecha: cobranza vencida por cliente, stock por depósito o tickets por estado. El primer entregable verificable es abrir el tablero con tres usuarios y ver tres permisos distintos. También conviene guardar un catálogo mínimo de métricas: nombre, fórmula, tabla origen, responsable y fecha de revisión. Ese archivo evita que una consulta vieja siga viva porque nadie se anima a tocarla. El catálogo vive junto al repositorio de vistas, no en una captura del tablero. El objeto concreto aparece en una bodega chica: un monitor con cuatro pestañas abiertas no dice quién cambió la consulta. El tablero elegido debe dejar escrito dueño, fecha, filtro, origen de dato y contacto técnico. Metabase encaja cuando el equipo necesita preguntas frecuentes, colecciones y permisos comprensibles para áreas no técnicas. Superset encaja cuando hay más SQL, datasets curados y necesidad de separar roles técnicos. La selección termina cuando un usuario sin permiso intenta abrir una consulta sensible y el sistema rechaza la acción.
Dónde se rompe y cómo probarlo
El primer riesgo es conectar con usuario dueño de la base. La señal aparece cuando el BI puede escribir o borrar. La prueba crea una credencial de sólo lectura, intenta una operación de escritura y documenta el rechazo. El segundo riesgo es duplicar definiciones. La señal aparece cuando ventas y administración calculan margen con columnas distintas. La prueba crea una vista canónica en PostgreSQL y obliga a los dos tableros a leerla. El tercer riesgo es publicar por enlace abierto. La señal aparece cuando un tablero interno carga sin sesión. La prueba abre el enlace desde navegador limpio, usuario sin grupo y red externa. El cuarto riesgo es respaldar sólo la base de negocio. La prueba restaura metadatos, tableros, consultas, usuarios y permisos en otro servidor. Un BI sirve cuando cada número muestra origen, dueño y permiso.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.