n8n SQL Server Guide: Connect, Query and Schedule Syncs

To connect n8n to SQL Server, add the built-in Microsoft SQL node, create a Microsoft SQL credential with the server name, database, user, password and port (1433 by default), and choose whether to use TLS. The node can execute any SQL query and insert, update or delete rows, so it covers everything from a one-off lookup to a scheduled sync that keeps a SQL Server table in step with another system.

Checked October 2026 against the n8n docs for the Microsoft SQL node and Microsoft SQL credentials, n8n's security advisory GHSA-5qpp-pqww-h7fp, and Microsoft Learn pages linked below. The SQL and workflows here are templates to adapt.

Forum threads about this connector are mostly old and mostly about the same three things: TLS errors that will not go away, queries that break on a stray apostrophe, and syncs that insert duplicates. This guide covers each with current fixes. For the broader picture of databases in n8n, see our n8n database automation guide (and our n8n MongoDB guide if you also work with document databases), and for ready-made workflows, the n8n templates library is the hub for this series.

What does the n8n MSSQL node do?

The Microsoft SQL node, often searched as the n8n MSSQL node, has four operations per the n8n docs (checked October 2026):

• Execute an SQL query. Any T-SQL you write: SELECT, MERGE, stored procedure calls, multi-statement batches.
• Insert rows in database. Maps incoming item fields to table columns.
• Update rows in database. Updates rows matched on a key column.
• Delete rows in database.

The node can also be used as a tool by an AI agent. Be careful with that: an agent that can run arbitrary SQL with a write-capable login can do anything that login can. Give agent-facing credentials a read-only database user.

How do you set up the n8n Microsoft SQL credential?

The credential asks for more than most database connectors. What each field means, from the n8n credential docs:

n8n tests the credential when you save it. If the test fails, the error usually lands in one of two groups: a timeout (the network path) or a TLS or certificate error (the handshake). Timeouts first: Microsoft's default network protocol configuration page shows TCP/IP disabled on new Developer and SQL Server Express installs, so enable it in SQL Server Configuration Manager, restart the service, and open the port in any firewall between n8n and the server.

Fixing n8n SQL Server TLS and encryption errors

Most stubborn n8n SQL Server connection problems are about the certificate, not the password. Microsoft documents that SQL Server always encrypts the login packets, and that if no suitable certificate is configured, it generates a self-signed certificate at startup that no client trusts by default. Turn on Use TLS in n8n against a default install and the handshake fails for exactly that reason.

About Ignore SSL Issues: it is the n8n equivalent of the Trust Server Certificate setting in Microsoft's drivers. Microsoft's guidance on encrypting connections is that trusting a certificate without validation still encrypts the traffic but does not stop a device in the middle from intercepting it, and that self-signed certificates should not be relied on in production or on servers connected to the internet. Use it for a private-network test, then fix the certificate.

For old servers, Microsoft's TLS 1.2 support article (checked October 2026) says SQL Server 2016, 2017, 2019 and 2022 support TLS 1.2 natively, while 2008, 2008 R2, 2012 and 2014 need specific updates. For Azure SQL Database, Microsoft's database security checklist states that connections require TLS 1.2 or higher, so Use TLS must be on, and the server firewall must allow the address n8n connects from. n8n Cloud publishes its outbound IP addresses, but notes that many instances share them, so an IP rule alone does not prove a request came from you.

How do you write parameterized queries in the n8n SQL Server node?

The obvious way to put a value into a query is an expression in the query text, like WHERE email = '{{ $json.email }}'. Do not do this with any input you do not control. In September 2026 n8n published an advisory rated High: version 1 of the Microsoft SQL node substituted expression values straight into the SQL text with no parameterisation, so a workflow that put webhook or HTTP input into the Query field could let an outside caller run arbitrary SQL with the credential's privileges. The fix shipped in n8n 2.42.1 and 2.41.4.

The advisory's guidance for workflows that keep using the node: upgrade the node to type version 1.1 or later by removing and re-adding it, then move dynamic values into the Query Parameters option and reference them as positional parameters.

-- Query
SELECT id, email, plan
FROM dbo.Customers
WHERE email = $1 AND plan = $2;

-- Query Parameters (option), as an expression returning an array
{{ [ $json.email, $json.plan ] }}

The parameters are bound to a prepared statement instead of being pasted into the SQL, so an apostrophe in a name is just an apostrophe. Pass an array when a value might contain a comma; the field also accepts a comma-separated string, which would split such a value. Existing nodes do not upgrade themselves, so audit older workflows: open each Microsoft SQL node that runs a query and check whether its query text contains {{ }} expressions fed by outside data.

The upsert pattern for scheduled n8n SQL Server syncs

A scheduled extract-sync copies changed records from a source (a CRM, a billing API, another database) into a SQL Server table on a timer. Two things make it reliable: a watermark so each run only fetches what changed, and an upsert so re-running a batch never creates duplicates.

Step 1: a control table for the watermark

CREATE TABLE dbo.SyncState (
  sync_name  NVARCHAR(100) PRIMARY KEY,
  last_sync  DATETIME2 NOT NULL
);

Each run starts by reading last_sync for its sync name and asks the source for records changed after it. Only after the upsert succeeds does it write the new time. If a run fails halfway, the next run fetches the same window again, which is safe because the write is an upsert.

Step 2: one MERGE per batch

Sending one query per item is slow and noisy. Instead, use an Aggregate node to collect the items into one list, then run a single Microsoft SQL query that receives the whole batch as one JSON parameter and unpacks it with OPENJSON:

MERGE dbo.Customers WITH (HOLDLOCK) AS target
USING (
  SELECT * FROM OPENJSON($1)
  WITH (
    external_id NVARCHAR(64)  '$.id',
    email       NVARCHAR(320) '$.email',
    full_name   NVARCHAR(200) '$.name',
    updated_at  DATETIME2     '$.updated_at'
  )
) AS source
ON target.external_id = source.external_id
WHEN MATCHED AND source.updated_at > target.updated_at THEN
  UPDATE SET email = source.email,
             full_name = source.full_name,
             updated_at = source.updated_at
WHEN NOT MATCHED BY TARGET THEN
  INSERT (external_id, email, full_name, updated_at)
  VALUES (source.external_id, source.email, source.full_name, source.updated_at);

Pass the batch as the only query parameter, wrapped in an array so its commas are not treated as separators, for example {{ [ JSON.stringify($json.data) ] }} when the Aggregate node writes the list to a field named data. Details that matter, each from Microsoft's documentation:

• OPENJSON needs compatibility level 130 or higher. Below that, SQL Server cannot find the function. Check sys.databases if the query fails with an unknown function error.
• MERGE must end with a semicolon. Without it SQL Server raises error 10713.
• MERGE is not race-free by default. A Microsoft engineering post archived on Microsoft Learn explains that two sessions inserting the same key can collide, and recommends a SERIALIZABLE (HOLDLOCK) hint. The template uses HOLDLOCK for that reason.
• Only newer data wins. The source.updated_at > target.updated_at condition stops an older replayed batch overwriting newer rows.

For the timer itself, the Schedule Trigger accepts intervals or cron expressions; our n8n cron expression guide lists the common schedules and the timezone setting that catches people out. If the source pushes events instead of waiting to be asked, replace the Schedule Trigger with a Webhook node as described in our n8n webhook guide, and keep the same MERGE.

If you want to turn data pipelines like this into the backend of a product, our AI SaaS Builder program covers databases, auth, payments and automation end to end.

Common n8n SQL Server mistakes

• Ignoring SSL issues in production. It hides a certificate problem instead of fixing it.
• Expressions in the query text. Use Query Parameters on node version 1.1 or later.
• Per-item queries. Batch with Aggregate and one MERGE.
• Moving the watermark first. Move it only after the write succeeds.
• No alert on failure. A silent failed sync means stale reports. Attach an error workflow; see our n8n error handling guide.

n8n SQL Server FAQ