Azure SQL Database

Azure SQL Database is Microsoft's fully managed relational database service. It runs the same engine as Microsoft SQL Server, so Weld connects to it over the same protocol and supports the same sync modes — the differences are all in networking and authentication, which is what this guide covers.

Features

🔧 Setup Guide

Step 1 - Choose an authentication method

Weld supports two ways to authenticate. Pick whichever matches how your organisation manages access to Azure SQL.

Connections are always encrypted. Weld requires TLS and validates the certificate Azure presents, so there is nothing to configure for encryption and no option to disable it.

Option A - SQL authentication

In the Weld app, add a new Azure SQL Database connection and select SQL authentication, then fill in:

• Server — your server's fully qualified name, for example your-server.database.windows.net
• Port — 1433
• Database — the name of the database you want to sync from
• User and Password — a SQL login with read access to the tables you want to sync

We recommend creating a dedicated read-only login for Weld rather than reusing an administrator account:

-- Run in the master database of your logical server
CREATE LOGIN weld_reader WITH PASSWORD = '<a-strong-password>';

-- Run in the database you want to sync
CREATE USER weld_reader FOR LOGIN weld_reader;
ALTER ROLE db_datareader ADD MEMBER weld_reader;

Option B - Microsoft Entra ID (service principal)

Use this when your server has Microsoft Entra-only authentication enabled, or when your organisation's policy is to avoid SQL logins.

1. Create an app registration in your Microsoft Entra tenant.

In the Azure portal, go to Microsoft Entra ID → App registrations → New registration. Give it a recognisable name such as weld-elt, and leave it as a single-tenant registration. From the overview page, note the Directory (tenant) ID and the Application (client) ID.

Then go to Certificates & secrets → New client secret and copy the secret value immediately — Azure only shows it once.

2. Create a database user for the app registration.

Connect to your database as a Microsoft Entra administrator and run the following, replacing weld-elt with your app registration's display name:

CREATE USER [weld-elt] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [weld-elt];

If you want Weld to read only specific tables rather than the whole database, grant SELECT on those tables instead of adding the user to db_datareader.

3. Enter the credentials in Weld.

Add a new Azure SQL Database connection, select Microsoft Entra ID (service principal), and fill in the server, port and database as above, plus:

• Directory (tenant) ID
• Application (client) ID
• Client secret

Step 2 - Data To Sync

1. Select the tables you wish to include in the sync.
   You can view the schema, remove columns or hash sensitive information.
2. Update Sync mode:
   By default the connector runs full syncs. To reduce sync time and the load on your database we recommend setting up syncs to run incrementally.

We currently support both Merge and Append mode for incremental syncs.

Merge

To have your table running incrementally using the merge configuration you need a table primary key and a cursor timestamp (updated_at is preferred).

When a sync is run, Weld will select only the new or changed rows since the last update.

Append

If a row updated_at timestamp is not available on the table then another option is to run an incremental sync using append mode. Append mode uses a cursor to keep track of how far the sync got on the last run. It will use that cursor to append new entries at the end of the table on the next run.

Append is not widely used as it does not capture updates in the previous rows.

Full Sync at Midnight

A limitation of both Merge and Append modes is that they do not capture deleted rows. If you expect rows to be deleted often from your tables then you can set a table to run a full sync at midnight which will remove those deleted rows.

Step 3 - Configure Sync

1. Select how often you would like the data to sync.
2. Provide a unique destination table name.

Weld will take over from here and commence syncing data from your Azure SQL database.

Things worth knowing

Serverless databases that auto-pause

If your database uses the serverless compute tier, it pauses after a period of inactivity and takes up to a minute to resume when something connects. Weld waits for the resume and retries automatically, so a paused database is not an error and does not lock your connection — the first sync after an idle period simply takes longer than usual.

Read replicas

With high throughput systems, running a high frequency sync against a production database can put unnecessary load onto the running services. If you are on a service tier that offers read replicas, pointing Weld at a replica keeps sync traffic off your primary.

Private endpoints and restricted networks

If your server has public access disabled and is reachable only over a private endpoint, Weld cannot connect to it directly. In that case use the Connect through an SSH Tunnel option on the connection form and point it at a bastion host that can reach the database.

System views in the table list

Azure SQL exposes a small number of its own views, such as sys.database_firewall_rules, alongside your tables. You can safely ignore these when selecting tables to sync.

Troubleshooting

"Login failed for user" when using SQL authentication. Check that the login exists and has a database user in the database you are connecting to. On Azure SQL, a login created in master does not automatically have access to other databases — you need the CREATE USER step shown above. If your server has Microsoft Entra-only authentication enabled, SQL logins are rejected outright and you need Option B.

"Security token could not be authenticated or authorized", or an error containing AADSTS. The service principal credentials were rejected by Microsoft Entra. The most common cause by far is an expired client secret — check the expiry date on your app registration under Certificates & secrets. Also confirm the tenant ID and client ID match the app registration exactly.

The connection saves but no tables appear. The database user exists but has no read permissions. Confirm it is a member of db_datareader, or has SELECT granted on the tables you expect to see.

Connection attempts time out. Almost always the server firewall. Confirm all three Weld IP addresses are allowed under Networking → Public access, and that public access has not been disabled entirely.