La base de datos SQL en Microsoft Fabric es una base transaccional dentro del ecosistema Fabric que guarda estados, objetivos, aprobaciones y otros datos que tus usuarios necesitan escribir. Power BI y el modelo semántico son excelentes para leer y explicar métricas, pero no están hechos para modificar datos. SQL Database aporta esa capa operativa, con permisos y auditoría, y devuelve la información al análisis mediante Direct Lake o el SQL analytics endpoint.
Por qué un modelo analítico no alcanza cuando hay que escribir
La mayoría de las arquitecturas de datos nacen para leer. Consolidas tus fuentes en una única verdad, construyes el modelo semántico como contrato de las métricas y consumes todo desde Power BI, Excel o un agente de IA. Ese flujo funciona muy bien mientras solo consultas.
El problema aparece cuando el negocio necesita actuar sobre los datos: fijar un objetivo por equipo, aprobar una previsión, clasificar manualmente un registro o dejar una nota ejecutiva. Nada de eso vive en la fuente operativa original y el modelo semántico no está diseñado para recibir escrituras. Necesitas una capa preparada para operar.
Acadevor lo resume como un principio de arquitectura: la lectura analítica y la escritura operativa son responsabilidades distintas. Mezclarlas ensucia el modelo y rompe el gobierno de las métricas.
Qué es exactamente la base de datos SQL en Fabric
SQL Database en Fabric es una base de datos transaccional que vive dentro de Fabric, junto al resto de tus elementos (lakehouse, modelo semántico, informes). Su rol en la arquitectura es el : guardar estados, objetivos y aprobaciones con permisos y auditoría, sin exponer tokens de escritura en la interfaz.
Demo gratuita
Mira cómo construir tu sistema de datos e IA
Un recorrido práctico de principio a fin para unificar fuentes dispersas en un modelo semántico que alimenta Excel, Power BI, Copilot y tus agentes.
A diferencia de una tabla analítica pensada para consultas masivas, una base transaccional está optimizada para escrituras controladas, integridad y trazabilidad. Cada cambio queda registrado y se puede auditar. Cuidar los permisos, los esquemas y los índices desde el primer día marca la diferencia, y para eso conviene apoyarse en las buenas prácticas para la base de datos SQL en Fabric.
Lo importante es entender su lugar en el ciclo completo:
Lectura analítica: la experiencia consulta medidas y dimensiones del modelo semántico. Los cálculos oficiales no se duplican en la interfaz.
Lógica de negocio: User Data Functions aloja código Python sin servidor, reutilizable, y lo expone a Fabric o a aplicaciones externas mediante endpoints autenticados.
Almacenamiento operativo: SQL Database (o Cosmos DB) guarda estados, objetivos y aprobaciones.
Retorno analítico: una vez guardado, el dato vuelve a quedar disponible para Power BI, Excel o agentes a través de Direct Lake, del SQL analytics endpoint, de un refresco programado o de una API.
Para qué sirve: los casos que resuelve
La base de datos SQL en Fabric cubre todo lo que el usuario necesita escribir sobre datos gobernados, sin salirse del ecosistema. Los patrones más frecuentes:
Objetivos por métrica, equipo, escenario, período y moneda. El caso clásico de planificación y seguimiento.
Clasificaciones manuales que no nacen en la fuente operativa, como marcar un cliente estratégico o etiquetar una excepción.
Notas ejecutivas, responsables, estados y comentarios de seguimiento que acompañan a las cifras.
Reglas compartidas que se actualizan una vez y se invocan desde varios canales.
La clave: la escritura pasa por una capa validada, no por un formulario que expone credenciales. Una User Data Function o un backend seguro recibe la acción, la valida y la escribe.
Cómo elegir la ruta de implementación correcta
No toda escritura necesita la misma solución. El conocimiento de Fabric describe cuatro rutas para implementar acciones sobre datos gobernados, cada una con su límite documentado.
Ruta
Cuándo encaja
Límite que se documenta
Fabric App y Data API
Tu empresa quiere una aplicación Fabric propia donde el usuario pueda tanto consultar como editar los datos
Disponibilidad vigente según la documentación oficial, más la región, el método de autenticación, el esquema de permisos y quién responde por la interfaz
User Data Functions
La misma regla debe invocarse desde Pipelines, Notebooks, Activator, Power BI o una app por REST
Identidad, conexiones, idempotencia, errores, registros y librerías del entorno de Python
Flujo transaccional y analítico
Un informe de Power BI necesita ejecutar una acción acotada y escribir mediante una función sobre SQL Database o Cosmos DB
Estado de disponibilidad según la documentación oficial. Se validan región, tenant, latencia, auditoría y una alternativa para producción
Backend externo
Hace falta un inicio de sesión propio, operaciones transaccionales complejas o conectar con sistemas ajenos a Fabric
Definición del contrato de la API, gestión de secretos, monitoreo, control de autorización y su sincronía con la capa de análisis
Un detalle que conviene no saltarse: el estado de disponibilidad de estas capacidades cambia con el tiempo, así que revísalo en la documentación oficial antes de decidir. Antes de llevarlas a producción se valida la región, el tenant, la latencia y la auditoría, y se define una alternativa por si alguna pieza aún no encaja con los requisitos del caso.
Un patrón concreto: objetivos y Scorecards
El ejemplo más útil para dimensionar todo esto es una tabla de objetivos. Debe guardar la métrica, el equipo, el escenario, el tipo de período, el período, el valor, la moneda, el estado, el responsable y la auditoría. Una clave lógica evita duplicados por período y escenario.
El flujo queda así:
El usuario define o ajusta un objetivo desde una experiencia (un informe, una app).
Una User Data Function o un backend seguro valida la acción y la escribe en SQL Database.
Si también se sincroniza un Scorecard, las llamadas a Power BI REST se ejecutan fuera del navegador y se prueban como una integración independiente.
Los datos escritos vuelven al análisis por Direct Lake o el SQL analytics endpoint. Direct Lake solo si el modelo y las fuentes fueron diseñados para ese modo.
Así el objetivo escrito por dirección aparece junto a las métricas reales, todos ven los mismos números y la reunión se dedica a decidir, no a discutir cifras.
Dónde encaja en tu arquitectura de datos
La base de datos SQL en Fabric no reemplaza al modelo semántico ni al lakehouse. Los complementa. El modelo semántico sigue siendo el contrato de las métricas; la arquitectura medallion (Bronze, Silver, Gold) sigue ordenando el flujo de datos. SQL Database aporta la pieza que faltaba: un lugar gobernado para lo que el negocio escribe.
Pensarlo como capas separadas evita el error más común, meter lógica de escritura dentro del modelo analítico y terminar con métricas poco confiables. Criterio antes que herramienta: primero decides qué necesita escribir tu negocio, después eliges la ruta.
Cómo aterrizar la decisión
Si diriges los datos de tu empresa y no tienes claro dónde deberían vivir los objetivos, las aprobaciones o las clasificaciones manuales, esa decisión es de arquitectura, no de herramienta. La forma más rápida de aterrizarla es ver el ciclo completo funcionando, desde la escritura gobernada hasta el retorno al análisis, con un caso real sobre la mesa. Mira la demo gratuita y evalúa cómo encajaría esta capa en tu propia arquitectura.
Preguntas relacionadas
¿Qué es la base de datos SQL en Microsoft Fabric?
Es una base de datos transaccional dentro del ecosistema Fabric que funciona como capa de almacenamiento operativo. Guarda estados, objetivos y aprobaciones con permisos y auditoría, y devuelve esos datos al análisis mediante Direct Lake o el SQL analytics endpoint.
¿Por qué no basta con Power BI y el modelo semántico?
Power BI y el modelo semántico son excelentes para leer, explicar y gobernar métricas, pero no están diseñados para escribir. Cuando el flujo necesita objetivos, clasificaciones, notas o aprobaciones manuales, la escritura debe vivir en una capa preparada para operar, como SQL Database.
¿Cómo regresan al análisis los datos que se escriben?
Los datos escritos vuelven a Power BI, Excel o agentes mediante Direct Lake, el SQL analytics endpoint, una actualización o una API. Direct Lake solo se usa si el modelo y las fuentes fueron diseñados para ese modo.
¿Quién valida y ejecuta la escritura de forma segura?
Una User Data Function o un backend seguro recibe la acción, la valida y la escribe. Así no se exponen tokens de escritura en la interfaz. Si además se sincroniza un Scorecard, las llamadas a Power BI REST se ejecutan fuera del navegador y se prueban como integración independiente.
¿La base de datos SQL en Fabric está lista para producción?
El estado de disponibilidad de las capacidades relacionadas conviene verificarlo en la documentación oficial. Antes de llevarlas a producción se validan región, tenant, latencia y auditoría, y se documenta una alternativa por si el caso no admite depender de una vista previa.
