make package compatible with Azure Synapse and Microsoft Fabric

[sdebruyn]

Overview

This adds compatibility for Azure Synapse and Microsoft Fabric.

The new version of the sqlserver adapter inherits from the fabric adapter. So in the macros, we can replace sqlserver__ with fabric__.

Changes

• Rename all sqlserver__ dispatch macros to fabric__ (sqlserver inherits from fabric, so dispatch finds these via the adapter type hierarchy)
• Add fabric__type_json() and fabric__type_array() returning varchar(max) — fixes [Bug]: Database Error ('22001', '[22001] [Microsoft][ODBC Driver 18 for SQL Server][SQL Server] String or binary data would be truncated. #521 (truncation errors from varchar(8000))
• Update all target.type conditionals to include "synapse" and "fabric" alongside "sqlserver"
• Add Fabric/Synapse type mappings in integration test helpers

Update type - breaking / non-breaking

• New features (non-breaking change)

What does this solve?

• Adds native compatibility for Microsoft Fabric and Azure Synapse adapters
• Fixes [Bug]: Database Error ('22001', '[22001] [Microsoft][ODBC Driver 18 for SQL Server][SQL Server] String or binary data would be truncated. #521 — JSON/array columns were created as varchar(8000) instead of varchar(max), causing truncation when uploading large payloads
• Addresses [Feature]: Want native Fabric compatibility #533 — native Fabric compatibility request

What databases have you tested with?

• Microsoft Fabric (Data Warehouse)

[Copilot]

Pull Request Overview

This PR extends dbt package compatibility to support Azure Synapse and Microsoft Fabric, which inherit from the SQL Server adapter. The changes replace SQL Server-specific conditional logic to include these new target types.

• Updates conditional logic throughout the codebase to include "synapse" and "fabric" alongside "sqlserver"
• Replaces SQL Server-specific macro implementations with Fabric equivalents
• Adds type mappings for the new database targets in configuration files

Reviewed Changes

Copilot reviewed 38 out of 38 changed files in this pull request and generated 12 comments.

Show a summary per file

File	Description
models/staging/*.sql	Updated target type conditionals to include synapse and fabric
models/sources/*.sql	Updated target type conditionals to include synapse and fabric
models/fct_*.sql	Updated target type conditionals to include synapse and fabric
models/dim_*.sql	Updated target type conditionals to include synapse and fabric
macros/upload_results/*.sql	Renamed sqlserver__ macros to fabric__ and updated conditionals
macros/upload_individual_datasets/*.sql	Renamed sqlserver__ macros to fabric__
macros/integration_tests/safe_cast.sql	Added type mappings for synapse and fabric
integration_test_project/seeds/seeds.yml	Updated column type conditional
dbt_project.yml	Updated persist_docs configuration conditionals

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[sdebruyn]

The copilot reviews are useless. The SQL Server adapter inherits from Fabric adapter.
@mtcarlone Could you take a look please? :)

[tkirschke]

Hi @sdebruyn ,

We have tried your Fabric Support branch in a project and noticed that the model_executions lack information regarding compile_started_at and query_completed_at - the corresponding columns are null.

It seems that the corresponding adapter variables are empty? These two values are set here and leverage the model.timing attribute.

Is this an adapter issue or something in your Fabric support?

Best regards
Tim

[sdebruyn]

Hi @tkirschke, thanks for testing this!

The compile_started_at and query_completed_at columns being null is not caused by this PR or the Fabric adapter. I've verified that the dbt-fabric adapter correctly produces compile and execute timing entries in model.timing — confirmed by checking NodeFinished events in test logs, which include both compile.started_at and execute.completed_at.

The timing data comes from dbt-core's task runner (BaseRunner.compile_and_execute()), not from the adapter, so it should work identically across all adapters.

Could you check:

1. Which version of dbt-core are you using?
2. Does your run_results.json contain timing entries for the affected models?
3. Are the affected models Python models or SQL models?

Also, if you're using Microsoft's dbt-fabric adapter, you might want to try my maintained fork instead — it has additional features and fixes: dbt-fabric-samdebruyn on PyPI / GitHub repo. The timing issue might be specific to the upstream adapter version you're using.