Connecting Power BI to SQL Databases

To connect Power BI to a SQL database, open Power BI Desktop, choose Get data, pick your database type (SQL Server, PostgreSQL, MySQL, Azure SQL and others), enter the server and database name, and select tables or views in the Navigator. The decisions that really matter come right after: Import or DirectQuery, tables or a custom SQL query, and how the report will refresh once it is published. This guide walks through each choice.

Before you connect: what you need

• Server name (for example sql01.company.local or myserver.database.windows.net) and, if required, a port.
• Database name and an account with read permission. Ask your DBA for a read-only login or a dedicated reporting schema; a dashboard should never use an admin account.
• The right driver. SQL Server and Azure SQL work out of the box. Some other databases (MySQL, Oracle, certain ODBC sources) may require you to install a connector or driver first. Check Microsoft's connector documentation for your source, since requirements change between versions.
• Network access. If the database is behind a corporate firewall, you may need VPN access from your machine and, later, a gateway for the Power BI Service.

Step by step: connecting Power BI Desktop to SQL Server

1. Open Power BI Desktop and click Home > Get data > SQL Server.
2. Type the Server and, optionally, the Database.
3. Choose the Data connectivity mode: Import or DirectQuery (explained below).
4. Optionally expand Advanced options to paste a SQL statement. Leave it empty if you plan to pick tables.
5. Pick the authentication method: Windows, Database (SQL login) or Microsoft account (for Azure SQL with Microsoft Entra ID).
6. In the Navigator, check the tables or views you need and click Transform Data (not Load) so you can review them in Power Query first.
7. Remove columns you don't need, set data types, then Close & Apply.

The flow is almost identical for PostgreSQL, MySQL, Oracle, Snowflake and most other sources; only the connector name and authentication options change.

Import vs DirectQuery: the most important decision

Import copies the data into the Power BI model, where it is compressed and queried by the fast in-memory engine. DirectQuery leaves the data in the database and sends a query every time someone interacts with a visual.

For most small and mid-size business reports, Import is the right default. Choose DirectQuery when data must be close to real time or the tables are too large to import. Power BI also supports composite models that mix both modes, and in Microsoft Fabric there is Direct Lake for data stored in OneLake. Model size limits and feature availability depend on your license, so check Microsoft's documentation and our Power BI licensing guide before committing.

Tables, views or a custom SQL query?

You have three ways to bring data in, and they behave differently.

Option 1: Select tables or views (recommended)

Picking objects in the Navigator lets Power Query generate the SQL for you. Your filters, column removals and grouping steps can be folded back to the database, meaning the database does the heavy work and only the needed rows travel to Power BI.

Option 2: Ask for a database view

If you need joins or business logic, the cleanest approach is a view in the database. The logic lives in one place, other tools can reuse it, and Power BI treats it like a table, so folding still works. Our guide to CTEs and subqueries shows how to write readable view logic.

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;

Option 3: Paste a native SQL query

The SQL statement box under Advanced options is quick, but Power Query generally can't fold later steps on top of a native query, so every refresh may pull more data than needed. For SQL Server sources, an advanced pattern is to use Value.NativeQuery with folding enabled in the M code:

let
    Source = Sql.Database("sql01.company.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

Folding support with this option depends on the connector, so treat it as a technique to test, not a guarantee. If M is new to you, see our Power Query M introduction.

Refreshing after you publish

Connecting in Desktop is only half the job. Once you publish to the Power BI Service, the service needs its own way to reach the database.

• Cloud databases (Azure SQL, Snowflake, BigQuery and similar) can usually be refreshed directly from the service, as long as credentials are set in the semantic model settings and the firewall allows it.
• On-premises databases need the on-premises data gateway, a small Windows service installed on a machine that can reach the database. You register it, add the data source, and then configure scheduled refresh.
• Large tables benefit from incremental refresh, which only reloads recent partitions. It relies on the RangeStart and RangeEnd parameters and works best when the date filter folds to the source.

The number of scheduled refreshes per day and some gateway features depend on your license and capacity, so confirm the current limits on Microsoft's official pages.

Performance and security best practices

• Bring only what you need. Remove unused columns and filter old history at the source. Fewer columns help compression more than fewer rows.
• Model as a star schema. Import fact and dimension tables separately and relate them in Power BI rather than importing one giant flattened query. See star schema in Power BI.
• Use a reporting schema. Views in a schema like reporting decouple your dashboard from changes to the raw tables.
• Index for DirectQuery. In DirectQuery mode, every visual becomes SQL, so the DBA may need indexes on join and filter columns.
• Least privilege. Use a read-only account limited to the reporting views. Never embed admin credentials in a shared file.
• Privacy levels. When combining a SQL source with files or web data, Power Query privacy levels can block folding or merges. Set them deliberately rather than turning them off globally.

Troubleshooting common errors

• "A network-related or instance-specific error occurred": the server name, port or firewall is wrong, or you are off the VPN.
• "Login failed for user": wrong authentication type. Clear old credentials in File > Options and settings > Data source settings and try again.
• Certificate or encryption errors: newer drivers encrypt by default. Ask your DBA to install a trusted certificate rather than disabling encryption.
• Refresh works in Desktop but fails in the Service: missing gateway, gateway data source not mapped, or credentials not entered in the semantic model settings.

Next steps

1. Connect to one table in Import mode and practice checking query folding.
2. Ask for (or create) a reporting view and rebuild the same query on top of it.
3. Publish to the Service and set up a scheduled refresh, with a gateway if your database is on-premises.

Watch: video lessons

▶

▶

Frequently asked questions