Schema Compare in VS Code: Simplifying Fabric Warehouse Deployments
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.
Migrating from Azure Synapse Analytics to Microsoft Fabric Data Warehouse
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 placeFabric Connectivity Series Part #3 - Inbound SQL DW connections on Workspace Private Endpoints
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.An Overview of Lakehouses and Data Warehouses
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.Microsoft Fabric Data Warehouse
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.Fabric Connectivity Series Part #1 - Inbound SQL DW connections on Public Endpoints
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.
# Top 10 Anti-Patterns in Fabric Warehouse Production Code Part -2
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
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
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.
