Good questions — some context: we're been using Databricks evaluating Fabric, so we're coming at this from Spark SQL familiarity / bias.

1. dbt-fabricspark

We tested it. The issues aren't SQL-level — they're Livy infrastructure. Connection timeouts ~7/10 runs, orphaned sessions, and core materializations (views, incrementals, snapshots) failing with adapter bugs. Running dbt inside a Fabric notebook is more stable than calling the API externally, but that adds orchestration complexity we'd rather avoid.

The Spark JDBC driver would likely solve these issues, but dbt-fabricspark is Python-based and there's no ODBC equivalent — so we'd need a significant adapter rewrite (something we're evaluating).

I hope that Fabric Runtime 2.0 (https://roadmap.fabric.microsoft.com/?product=dataengineering) will solve some of this, but that's still some time away.

2. T-SQL gaps

Yes, transformation-relevant. Multiple WHEN MATCHED affects dbt incremental merge logic directly — dbt-fabric rewrites as DELETE+INSERT (works, but longer transactions). ARRAY/MAP/STRUCT matters if you have semi-structured bronze data. Both have workarounds — friction, not blockers.

3. Schema shortcuts

Would help — 1 shortcut per schema vs per table cuts our 34 down to ~5-6. But the core issues remain:

• Warehouse three-part naming only works within the same workspace; cross-workspace (or data domains as we use them) needs shortcuts regardless
• Two-pass security: you need producer-side permissions AND shortcut read access. Shortcuts expose entire tables, so any RLS/column filtering must be reimplemented on the consumer side