Azure SQL Database as a source for your data warehouse and Power BI
Native Azure SQL connection
An Azure SQL Database already lives in the cloud, so Yres reads it with the standard Azure Data Factory cloud runtime; there is no runtime to install in your own network. You provide the server name (ending in database.windows.net), the database name and a SQL login with read access, and you allow access from Azure in the firewall of the SQL server. A copy activity in Data Factory fetches the tables and loads them, with history, into the data warehouse in your own Azure tenant, where Power BI connects.
At a glance
- Connection
- Direct connection; Azure Data Factory copies the tables into the data warehouse
- Server name and port
- The full server name in the form xxx.database.windows.net; the port is always 1433
- Sign-in
- SQL authentication: a SQL login with user name and password
- Integration runtime
- The cloud runtime is enough. A self-hosted integration runtime is only needed when the database is shielded by a private network or firewall
- Firewall
- Allow the Azure Data Factory IP range, or switch on "Allow Azure services and resources to access this server" on the SQL server
- Incremental loading
- Yes, on one or two change columns of the same data type
- Credentials
- Yres does not keep them itself: the connection is held as a single secret in your own Azure Key Vault, where Data Factory reads it
What you arrange yourself
- 1Open your SQL database in the Azure Portal and copy the server name and database name from the Overview screen.
- 2Create a separate SQL login with read-only access to that database.
- 3Open the SQL server firewall for Azure Data Factory: through the IP range, or with the option "Allow Azure services and resources to access this server".
- 4Add a source of type Azure SQL Database in Yres, fill in the five fields, refresh the metadata and pick your tables.
When you need this — and when you don't
A standalone connector is enough if…
If everything you want to report on already sits in one Azure SQL Database and its tables are already fit for reporting, Power BI can connect to it directly and a data warehouse adds little.
Yres adds value if…
Yres earns its place when the Azure SQL Database is the production database of an application: that often keeps only the current state. Yres records every change, tracks which rows have disappeared and puts the data next to your other sources, without reports querying the application database itself.
Frequently asked questions: Azure SQL
Do I need an integration runtime for Azure SQL Database?
Not one of your own. Azure SQL Database is reachable from the cloud, so the standard Azure Data Factory cloud runtime is enough. Only when the database is shielded by a private network or firewall and cannot be reached directly do you need a self-hosted integration runtime.
What do I have to set in the Azure SQL server firewall?
One of two things: allow the Azure Data Factory IP range, or switch on the server option "Allow Azure services and resources to access this server". Without either, the cloud runtime cannot reach the database.
Can Yres sign in with a Microsoft Entra account?
For this source Yres uses SQL authentication. So you create a SQL login with a password, preferably a separate account that is only allowed to read.
What happens in the data warehouse when a row is deleted in the source database?
That depends on the load type you choose per table. With FULL and DELTA the row stays marked as current. With IMAGE, a full snapshot, Yres closes every row that is no longer delivered; the row is kept as history.
Full technical description in the knowledge base →·Last reviewed:
Data warehouse automation that runs in your own Azure
Built for organisations on Azure and Power BI. Yres connects your sources, keeps the history and promotes changes in a controlled way, without manual work.