Cuánto cuesta Microsoft Fabric en 2026
Capacidades F, Power BI, almacenamiento, reservas, consumo y criterios para calcular el coste real.
Microsoft Fabric no tiene un único precio por usuario. El coste depende de la capacidad de cómputo contratada, las licencias Power BI necesarias, el almacenamiento en OneLake, la región, el modelo de compra y el consumo de cada carga. Una estimación correcta debe incluir ingeniería, warehouse, Power BI, tiempo real, ciencia de datos, Copilot y operación.
Capacity Units
Power BI
OneLake
Reserva
El precio de Fabric es el resultado de varias capas
La capacidad F representa el cómputo compartido. A ese importe pueden sumarse licencias Power BI, almacenamiento, conectividad, servicios Azure, soporte, implementación y operación.
Microsoft Fabric se compra principalmente mediante capacidades F de Azure. Cada SKU aporta un número determinado de Capacity Units. Estas unidades son consumidas por consultas, pipelines, notebooks, warehouses, modelos Power BI, eventos, agentes y otras operaciones.
La capacidad puede adquirirse bajo pago por uso o mediante una reserva que reduce el coste cuando existe un consumo estable. El precio varía según la región, la moneda, el acuerdo comercial y el modelo de contratación.
El punto más importante es que una capacidad pequeña no siempre es barata y una capacidad grande no siempre es cara. El coste real depende del uso. Una F8 saturada puede generar lentitud y throttling; una F64 infrautilizada puede suponer una inversión innecesaria.
Cómputo Fabric
Capacidad F compartida por las distintas experiencias y medida en Capacity Units.
Licencias de usuario
Power BI Pro, PPU o licencias gratuitas según el tamaño de la capacidad y el modo de consumo.
Almacenamiento y operación
OneLake, movimiento de datos, servicios adicionales, administración y soporte.
Las seis partidas que determinan el coste real
Una estimación incompleta suele calcular solo la capacidad. Esto oculta licencias, almacenamiento, integración, operación y crecimiento.
Capacidad F
Cómputo principal para ejecutar las cargas de Microsoft Fabric.
Licencias Power BI
Coste por usuario según creación, compartición y visualización de contenido.
OneLake
Almacenamiento utilizado por lakehouses, warehouses, modelos y réplicas.
Conectividad
Gateways, redes privadas, integración, transferencia y servicios Azure relacionados.
Implementación
Arquitectura, migración, modelado, desarrollo, seguridad y adopción.
Operación
Monitorización, FinOps, soporte, gobierno, formación y evolución continua.
De F2 a F2048: la capacidad crece por escalones
Cada SKU incorpora un número equivalente de Capacity Units. El tamaño no debe elegirse por número de empleados, sino por cargas, concurrencia, ventanas de ejecución y experiencia esperada.
| SKU | Capacity Units | Uso orientativo | Precaución |
|---|---|---|---|
| F2 | 2 CU | Pruebas, desarrollo o cargas muy limitadas. | Puede saturarse rápidamente con procesos simultáneos. |
| F4 | 4 CU | Pilotos controlados y pequeños equipos. | No asumir que soportará producción empresarial. |
| F8 | 8 CU | Primeros productos de datos y BI controlado. | Vigilar procesos de fondo y picos interactivos. |
| F16 | 16 CU | Plataformas departamentales con varias cargas. | La concurrencia puede exigir separación. |
| F32 | 32 CU | Entornos empresariales medios. | Los visores Power BI siguen necesitando licencia. |
| F64 | 64 CU | Plataforma empresarial y consumo Power BI amplio. | Debe justificarse con volumen, licencias y uso. |
| F128+ | 128 CU o más | Grandes plataformas, múltiples dominios y alta concurrencia. | Puede convenir distribuir cargas entre capacidades. |
Importante: estos usos son orientativos. Dos organizaciones con el mismo número de usuarios pueden necesitar capacidades muy distintas según sus procesos, modelos y concurrencia.
Flexibilidad para probar, ajustar y detener la capacidad
Las capacidades F compradas en Azure pueden facturarse por uso, con un mínimo de un minuto. Esto permite escalar, reducir, pausar y reanudar según el escenario.
Sin compromiso largo
Adecuado para pilotos, desarrollo, validaciones y cargas estacionales.
Pausa y reanudación
La capacidad puede pausarse para detener el coste de cómputo cuando no se utiliza.
Escalado bajo demanda
Permite subir o bajar de SKU sin rediseñar toda la plataforma.
Coste variable
La flexibilidad suele tener un precio unitario mayor que una reserva.
Riesgo operativo
Pausar una capacidad detiene los workloads y afecta a los usuarios.
Uso recomendado
Empezar midiendo y reservar solo cuando exista un patrón estable.
Cuándo tiene sentido comprometer capacidad
Las reservas de Microsoft Fabric permiten reducir el coste de cómputo cuando la organización puede comprometerse con una cantidad estable de Capacity Units.
Escenario adecuado
- La plataforma ya funciona en producción.
- El consumo base es estable y medido.
- Existe presupuesto anual comprometido.
- La organización no prevé reducir drásticamente la carga.
Escenario inadecuado
- El proyecto aún está en prueba.
- No se ha instalado Capacity Metrics.
- El tamaño se ha elegido por intuición.
- Existen picos muy estacionales o impredecibles.
La reserva debe cubrir el consumo base previsible. Los picos pueden gestionarse con capacidad adicional, escalado o rediseño de cargas. Reservar el máximo observado suele ser una mala decisión financiera.
La capacidad no elimina siempre el coste por usuario
La relación entre Fabric y Power BI es una de las áreas que más errores produce al calcular el presupuesto.
Capacidades inferiores a F64
Los usuarios que visualizan contenido Power BI compartido necesitan normalmente Pro o PPU.
F64 o superior
Los usuarios con licencia gratuita y rol de visor pueden consumir contenido Power BI alojado en la capacidad.
Creadores de contenido
Los autores que publican y comparten Power BI necesitan Pro o PPU según el escenario.
PPU
Premium Per User habilita capacidades premium por usuario, pero no sustituye todos los casos de capacidad Fabric.
Elementos no Power BI
El acceso a otros elementos Fabric sigue reglas diferentes y debe revisarse por rol y licencia.
Cálculo económico
A veces una F64 puede competir con muchas licencias Pro; otras veces una F32 más Pro resulta más eficiente.
El almacenamiento se factura por separado
La capacidad paga el proceso, pero el almacenamiento de datos en OneLake se mide y factura independientemente.
Lakehouses
Archivos y tablas Delta almacenados para ingeniería y ciencia de datos.
Warehouses
Datos gestionados por Fabric Warehouse sobre OneLake.
Mirroring
Las réplicas desde Snowflake, Databricks, bases de datos y otras fuentes ocupan almacenamiento.
Modelos y copias
Duplicaciones, snapshots y versiones pueden aumentar el volumen.
Retención
Históricos, logs y eventos necesitan políticas explícitas de conservación.
Optimización
Shortcuts y mirroring selectivo pueden evitar copias innecesarias.
Qué tareas gastan Capacity Units
Cada experiencia consume capacidad de forma distinta. Dos procesos con la misma duración pueden generar consumos muy diferentes.
Power BI
Consultas, actualizaciones, modelos semánticos, Direct Lake y operaciones interactivas.
Data Factory
Copias, pipelines, Dataflows Gen2 y movimientos entre sistemas.
Spark
Notebooks, trabajos, sesiones, transformaciones y ciencia de datos.
Warehouse
Consultas SQL, cargas, mantenimiento y operaciones sobre tablas.
Tiempo real
Ingesta, procesamiento de eventos, KQL, dashboards y activaciones.
Copilot y agentes
Consultas, indexación, respuestas y operaciones de IA disponibles en Fabric.
Qué ocurre cuando se consume más capacidad de la contratada
Fabric puede suavizar parte del consumo, pero una sobrecarga prolongada termina degradando la experiencia, retrasando operaciones o rechazando solicitudes.
Smoothing
Parte del consumo puede distribuirse en el tiempo para absorber variaciones temporales.
Acumulación
Los procesos de fondo e interactivos pueden acumular consumo pendiente.
Throttling
Las operaciones pueden retrasarse o rechazarse para proteger la capacidad.
No todo throttling exige comprar una SKU mayor. También puede resolverse escalonando procesos, optimizando modelos, separando capacidades o eliminando cargas ineficientes.
Cómo cambia el presupuesto según el uso
Los ejemplos no sustituyen una prueba de capacidad, pero permiten entender por qué no existe una tarifa única por empresa.
Un producto de datos
- F2, F4 o F8 bajo pago por uso.
- Pocos usuarios creadores.
- Volumen limitado.
- Capacidad pausada fuera de uso.
- Objetivo: medir consumo real.
Varios dominios y Power BI
- F16 o F32 como hipótesis inicial.
- Licencias Pro para los consumidores.
- Ingeniería, warehouse y BI.
- Monitorización diaria.
- Posible reserva tras estabilización.
Consumo amplio y múltiples cargas
- F64 o capacidades distribuidas.
- Usuarios gratuitos como visores.
- Múltiples dominios y horarios.
- Separación de cargas críticas.
- FinOps y gobierno formal.
Lo que no aparece en la tarifa de capacidad
El coste tecnológico es solo una parte del presupuesto. Una plataforma sin gobierno puede gastar más y aportar menos aunque la SKU sea pequeña.
Migración de datos
Inventario, limpieza, transformación, reconciliación y retirada de sistemas.
Modelado semántico
Medidas, relaciones, seguridad y definiciones empresariales reutilizables.
Integración
Conectores, gateways, APIs, redes privadas y tratamiento de errores.
Gobierno
Catálogo, permisos, linaje, dominios, calidad y responsables del dato.
Adopción
Formación, soporte, diseño de casos de uso y cambio de procesos.
Operación
Monitorización, incidencias, optimización, actualizaciones y evolución.
Cómo reducir el coste sin limitar el valor
La mayor oportunidad suele estar en la arquitectura y la operación, no en negociar unos céntimos por Capacity Unit.
Medir antes de reservar
Utilizar pago por uso y Capacity Metrics para conocer el consumo real.
Escalonar procesos
Evitar que actualizaciones, notebooks y pipelines compitan en la misma ventana.
Optimizar Power BI
Reducir modelos, consultas, cardinalidad y actualizaciones innecesarias.
Separar cargas
Asignar workspaces críticos a capacidades distintas cuando el aislamiento aporte valor.
Pausar desarrollo
Detener capacidades de pruebas y entornos temporales fuera del horario necesario.
Revisar almacenamiento
Eliminar réplicas, históricos y copias que no tengan una finalidad definida.
Seis pasos para calcular una capacidad defendible
El tamaño debe basarse en una combinación de medición técnica, previsión de negocio y margen operativo.
1. Inventariar
Fuentes, usuarios, modelos, informes, pipelines, notebooks y eventos.
2. Clasificar
Separar cargas interactivas, de fondo, críticas, estacionales y experimentales.
3. Probar
Ejecutar un piloto sobre una capacidad de pago por uso.
4. Medir
Utilizar Capacity Metrics para detectar consumo, picos y throttling.
5. Optimizar
Corregir diseños ineficientes antes de escalar la SKU.
6. Contratar
Elegir pago por uso, reserva o combinación según el patrón estable.
Un presupuesto útil debe explicar qué valor compra
Ayesa combina capacidades en Microsoft Fabric, Power BI, Azure, Dynamics 365, Business Central, Power Platform, seguridad e inteligencia artificial.
Esto permite dimensionar Fabric a partir de procesos y decisiones de negocio, no como una infraestructura aislada. El objetivo es pagar por una plataforma que conecte dato, analítica, automatización y agentes.
Una estimación completa debería incluir
Dudas habituales sobre el precio de Microsoft Fabric
Los importes concretos cambian por región, acuerdo y fecha. La estructura de costes debe revisarse antes de contratar.
¿Microsoft Fabric se paga por usuario?
El cómputo principal se paga mediante una capacidad F. Sin embargo, pueden ser necesarias licencias Power BI por usuario según el tamaño de la capacidad y la forma de consumir contenido.
¿Qué es una Capacity Unit?
Es una unidad que representa potencia de proceso disponible para ejecutar consultas, trabajos, pipelines y otras tareas de Fabric.
¿Cuál es la capacidad mínima?
Las capacidades F comienzan en F2. Que exista una F2 no significa que sea adecuada para cualquier producción.
¿Qué diferencia hay entre F32 y F64?
F64 duplica las Capacity Units de F32 y permite que usuarios con licencia gratuita y rol de visor consuman contenido Power BI alojado en la capacidad.
¿Se puede pausar Microsoft Fabric?
Las capacidades F de Azure pueden pausarse y reanudarse. Al pausar se detiene el cómputo, pero el almacenamiento continúa generando coste.
¿Qué es el throttling?
Es la limitación aplicada cuando la capacidad acumula un consumo superior al contratado. Puede retrasar o rechazar operaciones.
¿Una reserva siempre compensa?
No. Compensa cuando existe un consumo base estable. Para pilotos o cargas variables, el pago por uso puede ser más adecuado.
¿OneLake está incluido en la capacidad?
El proceso utiliza la capacidad, pero el almacenamiento en OneLake se factura separadamente.
¿Copilot consume capacidad?
Las funcionalidades de Copilot y agentes disponibles en Fabric consumen recursos y pueden tener requisitos de SKU y licencia específicos.
¿Cómo puedo saber qué SKU necesito?
La forma más fiable es desplegar un piloto, ejecutar cargas reales, instalar Capacity Metrics y analizar consumo, picos y throttling.
Completa la decisión sobre Microsoft Fabric
¿Cuánto costaría Microsoft Fabric en tu organización?
Ayesa analiza cargas, usuarios, Power BI, almacenamiento, integración y crecimiento para calcular un escenario realista y evitar tanto la saturación como el sobredimensionamiento.
Calcula el coste de Fabric con datos reales
Cuéntanos qué fuentes, usuarios, informes, pipelines, notebooks, eventos y casos de IA formarían parte de la plataforma.
Te ayudaremos a definir una capacidad inicial, un modelo de licencias y una hoja de ruta de crecimiento defendible.
Documentación de referencia
Consulta la documentación oficial de precios de Microsoft Fabric, licencias de Fabric, funcionalidades por SKU, Capacity Metrics, throttling y reservas de capacidad. Los precios concretos deben verificarse para la región, moneda y acuerdo comercial aplicables.