Azure SQL

Replicate into Azure SQL Database or Hyperscale, set up the target identity, and write into Always Encrypted columns.

SQL Flow applies changes to Azure SQL Database, including Hyperscale, with the same transactional, exactly-once writes as the SQL Server target. This page covers what differs on Azure: authentication, transport security, serverless databases and resource limits.

Requirements

Permissions

The target user needs the same permissions as on SQL Server. Membership in db_owner covers all of them. For a Microsoft Entra identity, create the user from the external provider. Replace <user_name>, and repeat the last statement for each schema that holds target tables:

CREATE USER [<user_name>] FROM EXTERNAL PROVIDER;
GRANT CREATE SCHEMA, CREATE TABLE, CREATE TYPE TO [<user_name>];
GRANT VIEW DEFINITION TO [<user_name>];
GRANT SELECT, INSERT, UPDATE, DELETE, ALTER ON SCHEMA::[dbo] TO [<user_name>];

To use adaptive resource governance, also grant VIEW DATABASE STATE.

What SQL Flow creates on the target

The objects are the same as on SQL Server: your tables, only when you select Prepare target schema or a create action, and the bookkeeping schema, sqlflow by default, created at the first start. These objects use storage and count against the database's size limit.

Options

The Target step offers the same fields as SQL Server, except Encryption:

The Authentication methods for Azure SQL are SQL login, Microsoft Entra managed identity, Microsoft Entra workload identity, Microsoft Entra service principal (with a client secret or a certificate), Microsoft Entra integrated and Microsoft Entra password. See Authentication methods. For unattended agents, use a managed identity or a service principal.

Serverless databases

A serverless database pauses when idle and resumes on the first connection, which can take longer than the default 15-second connect timeout. Set mssqlConnectResiliency=true with the CLI's --opt to connect with a 60-second timeout and 3 retries 10 seconds apart. During an Azure failover, a tier change or a resume, apply also retries its connection for up to 120 seconds. If that runs out, the pipeline faults without skipping anything, and a restart continues from its last committed position.

Adaptive resource governance

Set applyAdaptiveResourceGovernance=true with the CLI to have apply shrink its batches and parallelism when the database's log write rate nears its limit. It is off by default, and needs VIEW DATABASE STATE; without it, apply doesn't adapt but is otherwise unaffected.

Always Encrypted targets

Azure SQL targets support Always Encrypted columns exactly as SQL Server targets do: alwaysEncrypted=encrypt to encrypt plaintext into the target's encrypted columns, or alwaysEncrypted=ciphertext to copy ciphertext from a DirectLog source.

On Azure, keep the column master key in Azure Key Vault and let the agent reach it with a managed identity or a workload identity that has the key permissions get, unwrapKey and verify:

sqlflow connection edit <connection_name> \
  --opt alwaysEncrypted=encrypt \
  --opt alwaysEncryptedKeyStore=azurekeyvault \
  --opt alwaysEncryptedKeyVaultCredential=managedidentity \
  --opt alwaysEncryptedKeyVaultClientId=<client_id>

Omit alwaysEncryptedKeyVaultClientId for a system-assigned identity. For a workload identity, set alwaysEncryptedKeyVaultCredential=workloadidentity with alwaysEncryptedKeyVaultTenantId, alwaysEncryptedKeyVaultClientId and alwaysEncryptedKeyVaultTokenFile. Untick Collapse row versions (faster): encrypted columns need ordered, row-by-row apply.

Limitations

• Keys. A target table without a primary key or unique key that matches the source key is refused at the start. rowversion, timestamp, hierarchyid, sql_variant, xml, json, geography, geometry, vector and unbounded columns can't be part of a created key.
• Types. CLR user-defined types are refused. sql_variant is supported outside the key from a DirectLog or Reconstruction source, and needs ordered apply (untick Collapse row versions (faster)); see Data type mapping.
• Existing tables. Missing columns aren't added to an existing table.
• Read-only routing. mssqlApplicationIntent=readonly is refused, because a readable secondary can't take writes.

See also

• SQL Server target
• SQL database in Fabric target
• Database credentials and secret references
• On-premises SQL Server → Azure SQL over a WAN with relay agents