Data Warehouse Community Blog articles

Schema Compare in VS Code: Simplifying Fabric Warehouse Deployments

techies — Mon, 14 Sep 2026 13:55:53 GMT

Deploying databases shouldn't feel uncertain. Synchronizing development and production schemas in Microsoft Fabric Warehouse can be challenging as database objects evolve. A frequent issue arises when the .sqlproj file isn't configured with the Fabric-specific schema provider (SqlDbFabricDatabaseSchemaProvider). Misconfiguration may lead Schema Compare to flag supported Fabric objects as unsupported. To avoid this issue, explicitly specify the schema provider in the .sqlproj XML if the GUI does not offer that option.

In this blog, let's take a quick look at how to get started.

Before using Schema Compare with Fabric Warehouse, make sure you have the following prerequisites.

You need access to an existing Warehouse item within a Microsoft Fabric workspace, with Contributor or higher permissions.
You also need Visual Studio Code installed on your workstation.
Next, install the .NET SDK, which is required to build and publish database projects.
Finally, install these two Visual Studio Code extensions:

SQL Database Projects
SQL Server (mssql)

Both extensions are available directly from the Visual Studio Code Marketplace.

After installing the extensions, open Visual Studio Code and select "Add Connection" to connect to Fabric Warehouse.

Enter the required server and authentication details, and complete the connection.

After connecting, access the Warehouse directly in Visual Studio Code.

Open Schema Compare

Now navigate to Database Projects in Visual Studio Code.

You should see your available database projects and connections. Right-click the database project or connection and select "Schema Compare."

Schema Compare gives you an object-level view of the differences between the source and target.

You can compare schemas between:

.dacpac files
Databases
SQL database projects

Comparison results outline actions to align target with source.

Instead of treating the database as a single deployment unit, you can review individual changes and decide what should happen next.

You can also selectively exclude actions from the comparison results when a particular change should not be deployed.

Schema Compare with Fabric Warehouse

Schema Compare's integration with Fabric Warehouse allows developers to identify differences in database objects before implementing changes.

Database Projects and Git

The database project becomes the artifact under review in the PR, not a raw DDL diff — schema changes get the same scrutiny as application code, and the deployment pipeline consumes a validated project state rather than an ad-hoc script.

Schema Compare exposes Fabric Warehouse DDL limitations before deployment, helping you proactively address issues and maintain greater control over the deployment process.

Fabric Connectivity Series Part #3 - Inbound SQL DW connections on Workspace Private Endpoints

FonsecaSergioMS — Tue, 26 May 2026 16:00:00 GMT

Design secure, private connectivity to Fabric SQL endpoints using workspace-level private links.
In this step-by-step guide, learn how to deploy the required resources, and validate end-to-end private connectivity for Data Warehouse workloads.

# Top 10 Anti-Patterns in Fabric Warehouse Production Code Part -2

ssrithar — Fri, 08 May 2026 13:31:20 GMT

You fixed the loops, batched the loads, and listed your columns explicitly. Good. But your Fabric Warehouse still has hidden cost leaks.

In Part 2, we tackle the six anti-patterns that don't show up until your tables are large and your team is shipping fast: scalar UDFs that silently dodge Fabric's inlining engine, MERGE statements that join on the wrong column (and why case-sensitivity makes it worse), small-file fragmentation from over-partitioned lakehouse shortcuts — and the OPTIMIZE + VACUUM + V-Order trio that fixes it — plus three CI/CD habits (missing column lists, hardcoded workspace GUIDs, and DROP-recreate cycles) that quietly erase your statistics, your permissions, and your Monday morning peace of mind.

Ten anti-patterns. Two posts. One rule: Fabric Warehouse is not SQL Server.

# Top 10 Anti-Patterns in Fabric Warehouse Production Code

ssrithar — Tue, 21 Apr 2026 13:51:16 GMT

With Microsoft Fabric Warehouse , many teams carried over habits from dedicated SQL pools, Synapse serverless, or on-premises SQL Server. Most of those habits still work — but a handful of them quietly erode performance on Fabric's Delta Parquet + MPP engine, and they only reveal themselves once your tables cross a few hundred million rows or your capacity starts throttling. What looks like a "Fabric is slow" problem is, more often than not, a code problem inherited from an older architecture.

Over the last several months I've reviewed a number of production Fabric Warehouses across industries, and the same anti-patterns keep showing up. In this first post of a two-part series, I'll walk through the four that cost teams the most Capacity Units and the most debugging time, show the fix for each, and — most importantly — explain why the fix matters specifically in Fabric, not just as a generic SQL best practice. Part 2 will cover the remaining six.

Partition & Column Pruning in Azure Fabric Warehouse

Rakesh_Sharma1 — Tue, 24 Mar 2026 13:58:36 GMT

If you’re bringing Parquet data into Microsoft Fabric, you don’t have to sacrifice query performance. Fabric’s SQL engine (built on the same technology as Azure Synapse serverless SQL pools) automatically applies partition pruning and column pruning when querying Parquet files. These optimization features allow Fabric to skip over irrelevant partitions and unneeded columns – dramatically reducing the amount of data scanned and accelerating your queries. In this article, we’ll explore how partition and column pruning work in Fabric, with examples and best practices to help you make the most of these features for lightning-fast analytics on your data lake.

Designing Dimensions Right: Identity Columns in Fabric Warehouse Explained

AparnaRamakris — Mon, 29 Dec 2025 15:18:07 GMT

Why IDENTITY Column feature is Important to a Data Warehouse

Automating SQL Permissions Deployment in Microsoft Fabric Data Warehouse

LorenzoBonati — Tue, 02 Dec 2025 17:00:00 GMT

Fabric Deployment Pipelines and Git integration currently don’t transfer SQL object-level permissions when moving a Warehouse from Dev to Prod. After seeing this come up in some customer cases, I put together two small scripts that help you identify permissions in your Dev environment and export them so you can reapply them in Prod. Sharing them here so others can benefit as well.

How to delete an orphaned Fabric SQL Analytics Endpoint

LorenzoBonati — Mon, 01 Dec 2025 14:30:17 GMT

A simple Fabric Notebook script that helps you delete an orphaned SQL Analytics Endpoint when it remains in the workspace after removing a Lakehouse.

Migrating from Azure Synapse Analytics to Microsoft Fabric Data Warehouse

Shubham_rai955 — Tue, 18 Nov 2025 15:24:40 GMT

Migrating from Synapse to Fabric? It is easier than it looks.

I just walked through the full migration using the built in assistant in Microsoft Fabric, and the way the AI steps in to fix problem scripts honestly surprised me.

Here is the real flow:
→ Upload the DACPAC
→ Auto convert the supported objects
→ Fix the incompatible ones with Copilot guiding you
→ Copy your data with simple wizards
→ Reroute every connection in one place

Simplifying Multi-Company Data Consolidation with Medallion Architecture in Microsoft Fabric

Royel — Tue, 04 Nov 2025 15:03:51 GMT

Managing data across multiple subsidiaries can feel like juggling different systems, formats, and rules all while leadership demands one unified view. In this blog, I’ll show you how Microsoft Fabric’s Medallion Architecture (Bronze–Silver–Gold) turns that chaos into clarity.

Learn how to standardize, consolidate, and scale your multi-company data effortlessly using Fabric Lakehouse and Warehouse from raw ingestion to business-ready insights.

💡If your organization is struggling to unify data across multiple entities, this guide will show you a proven architectural blueprint that actually works.

Microsoft Fabric Data Warehouse

Ilgar_Zarbali — Wed, 02 Jul 2025 15:41:17 GMT

Microsoft Fabric Data Warehouse (Azure Synapse)
Microsoft Fabric introduces a new era in data management, and at its core lies a transformative capability—the Data Warehouse, also known as Azure Synapse within Fabric. While it builds on familiar concepts from traditional BI systems, Fabric’s Data Warehouse breaks new ground by offering a truly open, scalable, and fully integrated analytical environment.

This article offers a high-level overview of Microsoft Fabric Data Warehouse, providing foundational insights for professionals ready to embrace modern data architecture.

An Overview of Lakehouses and Data Warehouses

Ilgar_Zarbali — Thu, 10 Apr 2025 16:00:00 GMT

Unlocking the Future of Data: Lakehouses vs. Data Warehouses
In today’s data-driven world, choosing the right architecture is crucial for turning information into insight. Are traditional data warehouses still the gold standard, or are modern lakehouses rewriting the rules? Dive into our latest article as we explore how these two powerful approaches stack up — and discover which one could transform your data strategy.

Fabric Connectivity Series Part #2 - Inbound SQL DW connections on Private Endpoints - Step by Step

FonsecaSergioMS — Thu, 03 Apr 2025 18:52:52 GMT

Content

This is a sequence for a series of connectivity posts

Fabric Connectivity Series Part #1 - Inbound SQL DW connections on Public Endpoints

Introduction

You can use private links to provide secure access for data traffic in Fabric. Azure Private Link and Azure Networking private endpoints are used to send data traffic privately using Microsoft's backbone network infrastructure instead of going across the internet.

Using private endpoints with Fabric provides the following benefits:

Restrict traffic from the internet to Fabric and route it through the Microsoft backbone network.
Ensure only authorized client machines can access Fabric.
Comply with regulatory and compliance requirements that mandate private access to your data and analytics services.

Scope of this post

How to create Fabric Private Endpoint (Step-By-Step)
How to configure VM, using hosts file to be able to connect private to Fabric DW

Not on scope of this post

Main focus is DW / SQL Endpoint private connections. Others endpoint will not be covered here
Will dedicated other post just for
- DNS name resolution
- Routing / NSG / Firewall

Before you go forward, I suggest you read carefully this documentation on explanation, considerations and limitations ( Private links for secure access to Fabric)

I created image below to be more visual on how Private Endpoint works

Some important thing you will notice

Public internet clients going directly to Fabric FQDN resolving to public IP will fail

Personal computer going directly to internet,
Or a corp machine

Power BI Service (Running from cloud). Even though part of your tenant. The machine that act as client is not part of YOUR network.

You will need OnPrem Data Gateway or VNET Data gateway to be able to access it private

Access from other Azure VNETs need to be enabled using Azure VNET peering or VPN between azure networks. Lot's of customers use Hub-Spoke architecture
Client inside same VNET usually allowed by defaut, but good to double check

Important security note:
A private endpoint is a single directional technology that lets clients initiate connections to a given service but doesn't allow the service to initiate a connection into the customer network.

You will need OnPrem Data Gateway or VNET Data gateway to be able to access it private

Setup

Will follow steps documented at Set up and use private links

Step 1 - Setup Private Endpoint on Fabric

Go to Fabric (https://app.fabric.microsoft.com)
Config > Admin Portal
On Tenant Setting you will find Azure Private Link

Do not block public internet access before PE is completely set and tested

Step 2 - Setup Private Link Service (PLS) for PowerBI on Azure Portal

You need to start from Create a Resource > Custom deployment
Select Build you own template in the editor
Use template below

<resource-name> is the name you choose for the Fabric resource. (Name for resource to be created. Ex: FabricPLS)
<tenant-object-id>. See How to find your Microsoft Entra tenant ID.

{
  "$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {},
  "resources": [
      {
          "type":"Microsoft.PowerBI/privateLinkServicesForPowerBI",
          "apiVersion": "2020-06-01",
          "name" : "<resource-name>",
          "location": "global",
          "properties" :
          {
               "tenantId": "<tenant-object-id>"
          }
      }
  ]
}

Save the template
Select Resource Group and Region and create resource

Step 3 - Create Private Endpoint (PE)

Create new resource > Private Endpoint
Select Name like FabricPE and region

Select Resource Type and Resource (PLS created on Step 2)

Select what network and subnet will be placed this Private endpoint
Keep default (Yes) to integrate names with Private DNS Zones. This will be needed for automatic name resolution (Will be explained later)

Finish deployment

Step 4 - Name resolution

DNS is a complex topic and I can dedicate another post for more details on that

If you access you Fabric Private Endpoint > DNS configuration you will find 2 entries that you need. On my scenario

IP (10.0.2.7) assigned to "mwc-global.pbidedicated.windows.net" this represents your FQDN xxxx-xxxx.datawarehouse.fabric.microsoft.com
IP (10.0.2.9) assigned to "xxxx.pbidedicated.windows.net" this it the TDS (redirected connection)

If you test name resolution from any public network, name still resolvable to public IP

nslookup xxxx-xxxxx.datawarehouse.fabric.microsoft.com

So you or network team / DNS team need to get this resolved to private, where we have some options

Hosts File: Workaround on client machine with fixed entry on Hosts File (Good for quick test)
Azure DNS
Custom DNS

For simplification:
- Using Host file for this test. I'm ignoring whatever DNS answer and forcing name resolution

See below some tests done on my test VM

1 - NSLookup only check DNS request. It IGNORE hosts file entry
2 - We can see DNS Server used 10.0.0.4
3 - Public IP DNS see 20.150.161.150
4 - Test-NetConnection try to make real connection
5 - Remote address is different (HOSTs file entry)
6 - Hosts File
7 - Forcing IPs to specific FQDN and redirect name

Step 5 - Testing Connection

Testing using SSMS + Wireshark monitoring client hello packages with filter below

tls.handshake.extensions_server_name contains "fabric" or tls.handshake.extensions_server_name contains "pbi"

We can see from network trace the 2 connections to Fabric went all private

Step 6 - Next steps

⚠️ At this point we only used HOSTs file solution. Only fix TSQL connection, you need to make sure all endpoints are resolving to private
Will be shared on next posts for the series

How to setup Azure DNS / Custom DNS with Conditional Forwarder
How to create routes, and check NSGs

Fabric Connectivity Series Part #1 - Inbound SQL DW connections on Public Endpoints

FonsecaSergioMS — Fri, 22 May 2026 22:17:40 GMT

In today’s data-driven world, seamless connectivity to your data warehouse is critical for ensuring smooth operations and uninterrupted analytics workflows. Microsoft Fabric Data Warehouse (DW) offers robust connectivity options, but like any system, connectivity issues can arise. This guide will help you understand the common challenges and provide actionable steps to troubleshoot connectivity issues with Fabric DW.

Securing Your Microsoft Fabric Data Warehouse: A Comprehensive Guide

indirabandari — Mon, 16 Dec 2024 17:00:00 GMT

Microsoft Fabric offers a robust security framework to safeguard sensitive data in today's data-driven landscape. This blog post explores key security considerations and best practices for securing your Fabric data warehouse. By understanding network security, identity and access management, data security, monitoring and logging, and implementing strong security measures, organizations can effectively mitigate risks and protect their valuable data assets.

Open Mirroring in Fabric: Mirror Any Data?

AndyDDC — Tue, 03 Dec 2024 16:29:02 GMT

At Ignite November '24, Open Mirroring was announced. Up until this release, mirroring data into Fabric for downstream processing and analytics had been focused on a handful of core data technologies such as Azure SQL Database. Open Mirroring now increases the possibily of any data source being mirrored into Fabric. In this article we'll go through the steps necessary to create an Open Mirroring database and then work through how data can be inserted, updated, and deleted.

The Importance of New Case-Insensitive Collation in Fabric Warehouse

AndyDDC — Tue, 19 Nov 2024 01:19:53 GMT

The Fabric Warehouse service, launched in summer 2023, simplifies end-to-end data and analytics solutions. This T-SQL based platform provides SQL developers with a dedicated Data Warehousing environment featuring auto-scale and fault-tolerance capabilities. It uses the Parquet file format and Delta Lake, which offer new possibilities in Data Warehousing. This blog post will discuss the new case insensitive collation feature.

AI in Fabric Data Warehousing

desertislesql — Mon, 18 Nov 2024 15:16:51 GMT

Now you can use a Fabric Data Warehouse as the source for a chatbot without having to code.