Conectar Power BI a bases de datos SQL

Para conectar Power BI a una base de datos SQL, abre Power BI Desktop, elige Obtener datos, selecciona el tipo de base de datos (SQL Server, PostgreSQL, MySQL, Azure SQL y otras), escribe el servidor y la base de datos, y marca las tablas o vistas en el Navegador. Las decisiones que de verdad importan vienen justo después: Import o DirectQuery, tablas o una consulta SQL propia, y cómo se actualizará el reporte cuando lo publiques. Esta guía te explica cada una.

Antes de conectarte: lo que necesitas

• Nombre del servidor (por ejemplo sql01.empresa.local o miservidor.database.windows.net) y, si hace falta, el puerto.
• Nombre de la base de datos y una cuenta con permiso de lectura. Pide al DBA un usuario de solo lectura o un esquema dedicado a reportes; un dashboard nunca debe usar una cuenta de administrador.
• El driver correcto. SQL Server y Azure SQL funcionan sin instalar nada. Otras bases (MySQL, Oracle, algunas fuentes ODBC) pueden pedir un conector o driver adicional. Revisa la documentación de conectores de Microsoft, porque los requisitos cambian entre versiones.
• Acceso de red. Si la base está detrás del firewall de la empresa, quizá necesites VPN en tu equipo y, más adelante, un gateway para el servicio de Power BI.

Paso a paso: conectar Power BI Desktop a SQL Server

1. Abre Power BI Desktop y haz clic en Inicio > Obtener datos > SQL Server.
2. Escribe el Servidor y, de forma opcional, la Base de datos.
3. Elige el modo de conectividad: Import o DirectQuery (lo vemos abajo).
4. Si quieres, abre Opciones avanzadas para pegar una instrucción SQL. Déjalo vacío si vas a elegir tablas.
5. Selecciona la autenticación: Windows, Base de datos (usuario SQL) o cuenta Microsoft (para Azure SQL con Microsoft Entra ID).
6. En el Navegador, marca las tablas o vistas y haz clic en Transformar datos (no en Cargar) para revisarlas primero en Power Query.
7. Quita las columnas que no uses, ajusta los tipos de datos y luego Cerrar y aplicar.

El proceso es casi igual para PostgreSQL, MySQL, Oracle, Snowflake y la mayoría de fuentes; solo cambian el nombre del conector y las opciones de autenticación.

Import vs DirectQuery: la decisión más importante

Import copia los datos dentro del modelo de Power BI, donde se comprimen y se consultan con el motor en memoria, que es muy rápido. DirectQuery deja los datos en la base y envía una consulta cada vez que alguien interactúa con un visual.

Para la mayoría de reportes de empresas pequeñas y medianas, Import es la opción por defecto. Usa DirectQuery cuando los datos deban estar casi en tiempo real o las tablas sean demasiado grandes. Power BI también permite modelos compuestos que combinan ambos modos, y en Microsoft Fabric existe Direct Lake para datos guardados en OneLake. Los límites de tamaño y las funciones disponibles dependen de tu licencia, así que revisa la documentación de Microsoft y nuestra guía de licencias de Power BI antes de decidir.

¿Tablas, vistas o una consulta SQL propia?

Hay tres maneras de traer los datos y cada una se comporta distinto.

Opción 1: elegir tablas o vistas (recomendada)

Al marcar objetos en el Navegador, Power Query genera el SQL por ti. Tus filtros, columnas eliminadas y agrupaciones se pueden plegar (query folding) hacia la base: la base hace el trabajo pesado y solo viajan a Power BI las filas necesarias.

Opción 2: pedir una vista en la base de datos

Si necesitas joins o reglas de negocio, lo más limpio es una vista. La lógica vive en un solo lugar, otras herramientas la pueden reutilizar y Power BI la trata como tabla, así que el plegado sigue funcionando. Nuestra guía de CTEs y subconsultas te enseña a escribir vistas fáciles de leer.

CREATE VIEW reporting.v_sales AS
SELECT s.sale_id,
       s.sale_date,
       s.customer_id,
       s.product_id,
       s.quantity,
       s.quantity * s.unit_price AS revenue
FROM dbo.sales AS s
WHERE s.is_cancelled = 0;

Opción 3: pegar una consulta SQL nativa

El cuadro de instrucción SQL en Opciones avanzadas es rápido, pero por lo general Power Query no puede plegar los pasos siguientes sobre una consulta nativa, así que cada actualización puede traer más datos de los necesarios. Con SQL Server, una técnica avanzada es usar Value.NativeQuery con el plegado habilitado en el código M:

let
    Source = Sql.Database("sql01.empresa.local", "SalesDB"),
    Sales = Value.NativeQuery(
        Source,
        "SELECT sale_id, sale_date, customer_id, revenue FROM reporting.v_sales",
        null,
        [EnableFolding = true]
    ),
    Recent = Table.SelectRows(Sales, each [sale_date] >= #date(2026, 1, 1))
in
    Recent

El soporte de plegado con esta opción depende del conector, así que pruébalo en tu caso. Si M es nuevo para ti, mira nuestra introducción al lenguaje M.

Actualizar después de publicar

Conectarte en Desktop es solo la mitad del trabajo. Al publicar en el servicio de Power BI, el servicio necesita su propia forma de llegar a la base.

• Bases en la nube (Azure SQL, Snowflake, BigQuery y similares) normalmente se actualizan directo desde el servicio, siempre que pongas las credenciales en la configuración del modelo semántico y el firewall lo permita.
• Bases locales necesitan el gateway de datos local (on-premises data gateway), un servicio de Windows instalado en un equipo que vea la base. Lo registras, agregas el origen de datos y configuras la actualización programada.
• Tablas grandes se benefician de la actualización incremental, que solo recarga las particiones recientes. Usa los parámetros RangeStart y RangeEnd y funciona mejor cuando el filtro de fecha se pliega a la fuente.

La cantidad de actualizaciones diarias y algunas funciones del gateway dependen de tu licencia y capacidad; confirma los límites vigentes en las páginas oficiales de Microsoft.

Buenas prácticas de rendimiento y seguridad

• Trae solo lo necesario. Quita columnas que no uses y filtra el historial viejo en la fuente. Menos columnas ayudan más a la compresión que menos filas.
• Modela en esquema estrella. Importa por separado las tablas de hechos y dimensiones y relaciónalas en Power BI, en vez de una consulta gigante aplanada. Mira esquema estrella en Power BI.
• Usa un esquema de reportes. Las vistas en un esquema como reporting protegen tu dashboard de cambios en las tablas originales.
• Índices para DirectQuery. En DirectQuery cada visual se convierte en SQL, así que el DBA quizá deba crear índices en las columnas de join y filtro.
• Mínimo privilegio. Usa una cuenta de solo lectura limitada a las vistas de reportes. Nunca guardes credenciales de administrador en un archivo compartido.
• Niveles de privacidad. Al combinar SQL con archivos o datos web, los niveles de privacidad de Power Query pueden bloquear el plegado o las combinaciones. Configúralos a conciencia en vez de desactivarlos para todo.

Solución de errores comunes

• "A network-related or instance-specific error occurred": el servidor, el puerto o el firewall están mal, o no estás conectado a la VPN.
• "Login failed for user": tipo de autenticación incorrecto. Borra las credenciales viejas en Archivo > Opciones y configuración > Configuración de origen de datos y vuelve a intentar.
• Errores de certificado o cifrado: los drivers recientes cifran por defecto. Pide al DBA un certificado de confianza en lugar de desactivar el cifrado.
• Actualiza en Desktop pero falla en el servicio: falta el gateway, el origen no está asignado en el gateway o no pusiste las credenciales en el modelo semántico.

Próximos pasos

1. Conéctate a una tabla en modo Import y practica revisar el plegado de consultas.
2. Pide (o crea) una vista de reportes y reconstruye la misma consulta sobre ella.
3. Publica en el servicio y programa la actualización, con gateway si tu base es local.

Mira: lecciones en video

▶

▶

Preguntas frecuentes