TL;DR: Una capacidad de Microsoft Fabric es un conjunto de cómputo medido en Capacity Units (CU), y el número del SKU es esa cantidad: una F64 son 64 CU. Cada operación (notebook, refresco, consulta) consume CU; Fabric usa smoothing para repartir el consumo en el tiempo y bursting para acelerar picos. El umbral clave es F64: a partir de ahí, los usuarios pueden consumir informes de Power BI sin licencia Pro individual. Si superas tu capacidad de forma sostenida, Fabric limita (throttling) las cargas. Puedes pausar la capacidad para dejar de pagar cómputo.
¿Qué es una capacidad en Microsoft Fabric?
Una capacidad es la unidad de cómputo y facturación de Fabric: un pool de recursos compartido por todas las cargas de un tenant (notebooks, pipelines, almacenes, modelos semánticos). Se vende en SKU que van de F2 a F2048, donde el número indica las Capacity Units (CU) disponibles. Una F64 ofrece 64 CU; una F2, solo 2.
A diferencia del antiguo Power BI Premium por capacidad, una capacidad de Fabric alimenta todas las experiencias de la plataforma con la misma bolsa de CU, no solo Power BI. Esto simplifica la compra pero obliga a pensar el consumo de forma global: un notebook Spark pesado y un refresco de modelo compiten por las mismas CU. La capacidad se asigna a uno o varios workspaces, y todo lo que ocurre en ellos descuenta de esa bolsa común.
¿Qué son las Capacity Units (CU) y cómo se consumen?
Las CU son la moneda de cómputo de Fabric: cada operación consume CU-segundos según su intensidad y duración. Un refresco de modelo, una consulta DAX, una ejecución de notebook o un Dataflow Gen2 descuentan CU mientras corren. No pagas por operación, sino por el tiempo que tu capacidad sostiene ese trabajo.
El consumo se divide en dos tipos con tratamiento distinto:
- Interactivo: consultas y acciones de usuario (abrir un informe, filtrar). Se evalúan en ventanas cortas.
- Background (en segundo plano): refrescos programados, notebooks, pipelines. Se reparten en una ventana de hasta 24 horas.
Esta distinción importa porque Fabric no te corta por un pico instantáneo: promedia. La pregunta más repetida en la comunidad —»¿cómo se calculan realmente las CU cuando ejecuto código?»— se responde así: cuentan los CU-segundos del motor que ejecuta la tarea, no el número de filas ni de usuarios. La herramienta para verlo es la Microsoft Fabric Capacity Metrics App, que desglosa qué workload consume qué.
Bursting y smoothing: por qué un pico no tumba tu capacidad
Smoothing y bursting son los dos mecanismos que evitan que un trabajo puntual sature tu SKU. El smoothing reparte el consumo de una operación a lo largo del tiempo (minutos para lo interactivo, hasta 24 h para lo background), de modo que un refresco intenso no se contabiliza todo en el mismo instante. El bursting permite que una tarea use temporalmente más CU de las que tu SKU tiene para terminar más rápido.
La duda clásica del foro —»si tengo una carga pesada de 4 a 6 de la mañana, ¿el bursting la hace más rápida?»— tiene respuesta afirmativa: sí, Fabric le presta capacidad extra para acelerarla. Pero esa capacidad prestada se devuelve mediante el smoothing en las horas siguientes. En la práctica:
- Bursting = velocidad ahora, a costa de consumo amortizado después.
- Smoothing = ese consumo se diluye en la ventana para que no dispare el throttling de golpe.
Mientras tu consumo promedio quepa en tu SKU, los picos son invisibles. El problema llega cuando el promedio, no el pico, supera tu capacidad de forma sostenida.
¿Qué pasa cuando «se exceden los límites de capacidad»?
Cuando tu consumo sostenido supera las CU de tu SKU, Fabric acumula una «deuda» de capacidad y aplica throttling: primero añade retardos a las operaciones interactivas, luego las rechaza, y en el extremo bloquea las cargas background. Es el origen del error «Fabric compute capacity exceeded its limits». No es un fallo: es la protección que evita que un tenant consuma sin límite.
Para evitarlo, el camino no siempre es subir de SKU. Opciones por orden de costo:
- Optimiza las cargas pesadas: filtra en origen, reduce refrescos innecesarios, agenda los notebooks fuera de hora pico.
- Distribuye en el tiempo: aprovecha que el background se promedia en 24 h y separa los trabajos grandes.
- Vigila con la Capacity Metrics App: identifica el workload que dispara el consumo antes de escalar.
- Sube de SKU solo si el consumo promedio real lo justifica.
El throttling depende del promedio, así que muchas veces reordenar cargas resuelve más que pagar una F superior.
El umbral F64: la licencia que cambia el costo
F64 es la frontera más importante de Fabric en términos de costo total: a partir de una capacidad F64 o superior, los usuarios finales pueden ver y consumir contenido de Power BI sin necesitar una licencia Power BI Pro individual. Por debajo de F64, cada usuario que abra un informe necesita su propia licencia Pro.
Esto cambia por completo el cálculo para organizaciones con muchos consumidores:
- Menos de F64 (F2–F32): pagas la capacidad más una licencia Pro por cada usuario que consume.
- F64 o más: pagas la capacidad y los consumidores entran gratis (solo los autores/desarrolladores siguen necesitando Pro).
Por eso la pregunta «¿cuántos usuarios pueden usar una F64?» no tiene un número fijo de licencias: el límite es de rendimiento (CU), no de asientos. Una F64 puede servir a cientos de lectores si el consumo cabe en sus 64 CU. Para una empresa con 200 lectores, saltar a F64 suele salir más barato que 200 licencias Pro.
Pausar la capacidad y modelos de precio
Puedes pausar una capacidad de Fabric para dejar de pagar cómputo cuando no la usas, y eso es exclusivo del modelo pago por uso (pay-as-you-go). Mientras está pausada no se factura cómputo, aunque el almacenamiento de OneLake se sigue cobrando aparte. Pausar también liquida cualquier deuda de capacidad pendiente del smoothing.
Hay dos modelos de compra con implicaciones distintas:
| Modelo | Ventaja | Limitación |
|---|---|---|
| Pago por uso (PAYG) | Pausas cuando quieres; pagas por hora | Tarifa por hora más alta |
| Reserva (1 año) | Descuento notable frente a PAYG | No puedes pausar para ahorrar; es un compromiso |
Una estrategia común es PAYG con auto-pausa programada fuera del horario laboral (por ejemplo, pausar de noche y fines de semana). Eso recorta el costo de cómputo sin migrar a reserva. Si tu uso es constante 24/7, la reserva anual suele ganar; si es intermitente, PAYG con pausas gana.
¿Qué SKU de Fabric elijo? (guía orientativa)
El SKU correcto depende de tu consumo promedio de CU y de si cruzas el umbral de licenciamiento F64, no del tamaño de tus datos. Esta tabla orienta el punto de partida; ajústalo midiendo con la Capacity Metrics App durante una prueba real.
| SKU | CU | Perfil típico | Licencia de consumidores |
|---|---|---|---|
| F2–F8 | 2–8 | Pruebas, equipos pequeños, desarrollo | Pro por usuario |
| F16–F32 | 16–32 | Departamento con cargas moderadas | Pro por usuario |
| F64 | 64 | Producción con muchos lectores | Incluida (sin Pro) |
| F128+ | 128+ | Empresa, alto volumen, varias áreas | Incluida (sin Pro) |
La recomendación práctica: si tienes pocos usuarios y cargas ligeras, empieza por una F pequeña en PAYG y mide. Si tienes muchos consumidores, calcula si F64 (con consumo gratis) ya sale más barato que sumar licencias Pro. Antes de decidir la arquitectura de datos que correrá sobre esa capacidad, conviene tener claro cuándo usar Lakehouse o Warehouse y cómo OneLake unifica el almacenamiento.
Errores y malentendidos comunes
La mayoría de sorpresas en la factura nacen de confundir CU con usuarios, de creer que pausar elimina todo el costo, o de subir de SKU cuando el problema era una carga mal agendada. Estos son los malentendidos más frecuentes:
| Malentendido | Realidad |
|---|---|
| «Una F64 admite 64 usuarios» | El número es CU de cómputo, no asientos; F64 sirve a cientos si el consumo cabe |
| «Si pauso, no pago nada» | El cómputo se detiene, pero el almacenamiento de OneLake se sigue facturando |
| «Un pico me tumba la capacidad» | El smoothing promedia; lo que importa es el consumo sostenido, no el pico |
| «Necesito subir de SKU para no tener throttling» | Muchas veces basta optimizar o reagendar las cargas pesadas |
| «Por debajo de F64 los lectores son gratis» | No: por debajo de F64 cada consumidor necesita licencia Pro |
Preguntas frecuentes
¿Cuántos usuarios soporta una capacidad F64? No hay un tope de usuarios fijo; el límite es de rendimiento (64 CU). Una F64 puede servir a cientos de lectores si su consumo combinado cabe en esas CU. Lo que F64 garantiza es que esos lectores no necesitan licencia Power BI Pro.
Si pauso la capacidad, ¿dejo de pagar? Dejas de pagar el cómputo, pero el almacenamiento de OneLake se factura aparte y sigue corriendo. Pausar también salda la deuda de capacidad acumulada por el smoothing.
¿Bursting hace más rápidas mis cargas? Sí: una tarea puede tomar prestada capacidad extra para terminar antes. Esa capacidad se devuelve después vía smoothing, así que acelera el pico a cambio de amortizar el consumo en las horas siguientes.
¿Conviene reserva anual o pago por uso? Si tu uso es constante todo el día, la reserva (con su descuento) suele ganar. Si es intermitente y puedes pausar de noche y fines de semana, el pago por uso con auto-pausa sale más barato.
Conclusión
Entender las capacidades de Microsoft Fabric se reduce a tres ideas: el SKU es la cantidad de CU, el consumo sostenido (no el pico) es lo que dispara el throttling gracias a smoothing y bursting, y F64 es el umbral donde los consumidores dejan de necesitar licencia Pro. Empieza pequeño en pago por uso, mide con la Capacity Metrics App y escala solo cuando el promedio real lo justifique.
Este artículo cierra la serie sobre Microsoft Fabric: para el panorama completo revisa Lakehouse vs Warehouse y la guía de decisión oficial de Microsoft Learn sobre capacidades.
Deja una respuesta