Cómo dimensionar la capacidad de Microsoft Fabric sin reventar el presupuesto
Qué consume realmente capacidad F, cómo identificar al culpable en su entorno y cuándo escalar, pausar o reorganizar workspaces.
La capacidad no es un servidor: es presupuesto por segundo
La primera confusión que vemos en proyectos de Fabric es tratar la capacidad como una máquina virtual. No lo es. Una SKU F es un pool de unidades de cómputo consumidas por operación — cada refresh de dataset, cada consulta DAX, cada notebook y cada pipeline retira unidades de ese pool.
La consecuencia práctica es que el cuello de botella rara vez aparece donde se espera. Un solo dataflow mal escrito ejecutándose cada hora puede costar más capacidad que cientos de usuarios abriendo informes. Antes de aumentar la SKU hay que saber quién consume.
Los tres consumidores que casi siempre explican la factura
En prácticamente todo entorno que auditamos, el consumo se concentra en tres lugares. Primero, refreshes completos de modelos grandes que podrían ser incrementales — reprocesar cinco años de historial cada madrugada es el desperdicio más común y el más fácil de corregir.
Segundo, transformación hecha en el lugar equivocado: Power Query resolviendo lo que debería resolverse en el lakehouse o el warehouse, repetido en cada carga. Tercero, informes con medidas DAX que recorren tablas de hechos completas en cada interacción, multiplicando el costo por la cantidad de accesos.
Corregidos esos tres puntos, es común que un entorno vuelva a caber en la SKU ya contratada — sin cambiar ninguna licencia.
Smoothing y throttling: el pico importa más que el promedio
Fabric distribuye el consumo a lo largo del tiempo (smoothing), lo que absorbe picos cortos. Pero cuando la deuda acumulada supera el límite comienza el throttling: las operaciones entran en fila y el usuario siente lentitud sin que nada esté técnicamente caído.
Por eso monitorear solo el promedio de utilización engaña. Lo que hay que observar es el patrón de pico — normalmente concentrado en la ventana de refresh — y la superposición entre cargas automáticas y horario de uso humano. Distribuir refreshes a lo largo del día muchas veces resuelve más que duplicar la capacidad.
Una ruta de decisión en cuatro pasos
Antes de tocar la SKU, siga este orden: (1) inventaríe el entorno y descubra qué existe, quién es responsable y qué nadie abre; (2) mida el consumo por ítem e identifique los cinco mayores; (3) optimice esos campeones de consumo — refresh incremental, transformación en la capa correcta, revisión de DAX; (4) solo entonces redimensione, con datos y no con impresiones.
Los entornos con pausas programadas (desarrollo y homologación fuera del horario comercial) y workspaces separados por criticidad mantienen un costo previsible durante el año. Ese acompañamiento continuo es exactamente lo que automatizamos en FabricBoard.
Leemos su entorno Fabric y mostramos los cinco mayores consumidores antes de cualquier propuesta.
Hablar con un consultor