Thursday, 18 June 2026

Microsoft Fabric Migration Series - Chapter 1

Microsoft Fabric Migration Series

From Synapse Serverless to Microsoft Fabric:
Solving the Deletion Vector Problem

Data Technet Principal Architect June 2026 Azure Synapse · Microsoft Fabric · Delta Lake
SSMS — Synapse Serverless SQL Pool
SELECT TOP 100 * FROM transactions_tbl;
 
Msg 19726, Level 16, State 2, Line 2
Feature 'Deletion Vectors' is not supported for table
'datasource_124485ee-6864-4f64/transactions_tbl'.
Msg 16513, Level 16, State 0, Line 2
Error reading external metadata.
 
Completion time: 2026-06-18T09:14:22.8410531+00:00

That error above is what our analysts and support team woke up to one morning. Not a permissions issue. Not a network problem. The tables were simply gone — inaccessible from SSMS, which is the primary tool our support team and analysts use for day-to-day data investigation and ad-hoc querying.

SSMS access to our Delta Lake tables is not a nice-to-have. It is the mechanism that allows our analysts and support teams to run their own queries, validate data, investigate incidents, and answer business questions — without raising a ticket and waiting for an engineer to spin up a notebook, run the query, and send back results. When that access broke, every data question became an engineering task. The support team was blocked. Analysts were blocked. The entire self-service data capability we had built over months collapsed overnight.

The root cause was a Synapse Spark pool runtime upgrade to Spark 3.5. A long-term migration to Microsoft Fabric was already on the roadmap — but that is a months-long process. We needed a quick win that restored SSMS access now, without waiting for a full platform migration. This post explains what broke, why it broke, and the exact steps we used to restore analyst and support team access within a day using Microsoft Fabric's SQL Analytics Endpoint as a drop-in replacement for Synapse Serverless SQL.




The Upgrade That Broke Everything

For a long time, Deletion Vectors were not a concern for Synapse Serverless SQL users. Synapse Spark pools running on Spark 3.3 (Delta Lake 2.2) or Spark 3.4 (Delta Lake 2.4) could not produce them — the feature simply did not exist in those Delta versions.

That changed when Microsoft released Azure Synapse Runtime for Apache Spark 3.5 (GA, August 2025), which ships with Delta Lake 3.2. Deletion Vectors are a Delta Lake 2.0+ feature, and Delta Lake 3.2 enables them by default on tables that receive DELETE or UPDATE operations.

The upgrade pressure was real. Synapse Spark 3.3 reached end of support in March 2025. Spark 3.4 follows in March 2026. Teams upgrading their Spark pools to remain on a supported runtime found that their Spark jobs began silently producing Delta tables with Deletion Vectors — without any deliberate action on their part.

Runtime
Delta Lake
EOL
Deletion Vectors
Spark 3.3
2.2
Mar 2025
Not possible
Spark 3.4
2.4
Mar 2026
Not possible
Spark 3.5 ← upgrade target
3.2
Current
Produced by default
Fabric Runtime 1.3
3.x (Kernel)
Read correctly
The key insight: The Synapse environment that produces the data (Spark pool, Runtime 3.5, Delta Lake 3.2) and the Synapse environment that queries it (Serverless SQL Pool, Delta Reader 1.0) are two completely separate engines that have diverged. The Spark pool writes modern Delta 3.x tables. The Serverless SQL Pool cannot read them. There is no configuration fix — it is an architectural incompatibility.

Why Synapse Serverless Cannot Handle Deletion Vectors

Synapse Serverless SQL uses the Delta Reader 1.0 protocol — the legacy standalone Delta reader. It understands the basics of the Delta format but has not been updated to support modern Delta Lake features introduced in the Delta 2.x and 3.x protocol.

✕  Synapse Serverless SQL
  • Delta Reader 1.0 (legacy protocol)
  • Deletion Vectors — hard error
  • Liquid Clustering — not supported
  • V2 Checkpoints — not supported
  • Column Mapping — limited support
  • Silently returns deleted rows on older DV tables
✓  Fabric SQL Analytics Endpoint
  • Delta Kernel 3.x (full protocol)
  • Deletion Vectors — correctly applied
  • Liquid Clustering — supported
  • V2 Checkpoints — supported
  • Column Mapping — supported
  • Correct rows returned, no data integrity risk
Silent data correctness risk: On tables where Deletion Vectors exist but the Delta log protocol requirement is not yet enforced, Synapse Serverless does not error — it silently returns logically deleted rows. The hard error only surfaces once the table protocol version is explicitly bumped. Before that point, your analysts may be querying stale, deleted data without any warning.

How Deletion Vectors Work in the Delta Log

Fabric reads the _delta_log, finds the deletion vector reference, loads the .dvd bitmap, and applies it as a row mask — returning only live rows. Synapse Serverless reads the Parquet files directly and ignores deletion_vectors/ entirely.


⚡ Quick Win

Restore SSMS Access in Under a Day — No Data Migration Required

The steps below do not require moving any data out of ADLS Gen2. Your Delta tables stay exactly where they are. Fabric reads them in place via a Shortcut — the same pattern as a Synapse external table, but with a fully modern Delta protocol reader underneath. This is the fastest path to restoring analyst and support team self-service access while the longer-term Fabric migration continues in the background.


Exposing ADLS Gen2 Delta Tables via Fabric SQL Analytics Endpoint

01

Create a Fabric Lakehouse

In your Microsoft Fabric workspace (assigned to an F2 or higher F-capacity): New item → Lakehouse. Name it to match your environment, e.g. enterprise_lakehouse.

Capacity delegated setting: After provisioning any new F capacity, go to Admin Portal → Capacity Settings → select the capacity → Delegate tenant settings → Users can create Fabric items → enable explicitly. This setting does not always inherit from the tenant-level switch and will prevent Lakehouse creation if missed.
02

Create an ADLS Gen2 Shortcut Under Tables

In the Lakehouse → Tables section → right-click → New shortcut → select Azure Data Lake Storage Gen2 (not Azure Blob Storage). Enter the DFS endpoint URL:

https://enterprisedatalake.dfs.core.windows.net

Select Workspace Identity as the authentication method, then navigate to your container and select the individual Delta table folders (each showing the Delta Table icon in the picker).

HNS endpoint matters: If your storage account has Hierarchical Namespace (HNS) enabled — standard for ADLS Gen2 — you must use dfs.core.windows.net. Using the blob.core.windows.net endpoint causes silent failures on Delta log traversal, producing a misleading "invalid credentials" error even when auth is correctly configured.
Tables/ not Files/: The shortcut must be created under the Tables section, not Files. Shortcuts created under Files are visible in the Lakehouse explorer but will not appear in SSMS or the SQL Analytics Endpoint. This is the single most common mistake in this setup.
03

Configure RBAC on the Storage Account

The Workspace Identity of your Lakehouse needs the correct role on the storage account:

-- Azure Portal: Storage Account → Access Control (IAM) → Add role assignment Role: Storage Blob Data Contributor Assign access to: Managed identity Member: Your Fabric Workspace Identity -- NOT Blob Contributor — that is a management plane role and -- does not grant read access to blob data.
Propagation delay: Azure RBAC assignments can take 5–10 minutes to propagate. If you receive 403 errors immediately after assigning the role, wait and retry before investigating further.
04

Wait for Schema Sync

Fabric automatically reads each _delta_log and infers the schema for the SQL Analytics Endpoint. With 20+ tables, allow 10–15 minutes for the sync to complete. Tables appear progressively — do not refresh repeatedly or navigate away, the sync is a background server-side process.

05

Connect in SSMS

In the Fabric workspace → find the SQL analytics endpoint item → ... → Copy SQL connection string. Open SSMS 19.1+:

Server: <guid>.datawarehouse.fabric.microsoft.com Authentication: Azure Active Directory - Universal with MFA Database: enterprise_lakehouse
SSMS version requirement: SSMS 19.1 or later is required. Older versions do not support Fabric SQL endpoint authentication.
06

Grant Read Access to Analysts and Support Teams

The SQL Analytics Endpoint is read-only by design — no INSERT, UPDATE, DELETE, or CREATE TABLE is possible through the endpoint. Schema-level SELECT grants are therefore the maximum permission available, with no risk of accidental data modification from an SSMS session.

-- Grant read access on all tables to a specific user GRANT SELECT ON SCHEMA::dbo TO [analyst@domain.com]; -- Or manage a team via a role CREATE ROLE db_analysts; GRANT SELECT ON SCHEMA::dbo TO db_analysts; ALTER ROLE db_analysts ADD MEMBER [analyst1@domain.com]; ALTER ROLE db_analysts ADD MEMBER [support1@domain.com];

Is the Data Live?

Yes. The shortcut is a live pointer to the ADLS Gen2 path. Every query reads the latest committed state of the Delta table directly from source. Deletion Vectors are applied at query time — rows deleted by a Spark 3.5 job will not appear in Fabric query results. No data is copied to OneLake. Storage costs do not increase.

Change in ADLS Gen2 Visible in Fabric SQL Endpoint
New rows inserted✓ Immediately
Rows updated✓ Immediately
Rows deleted (via Deletion Vectors)✓ Immediately — DVs applied correctly
New columns added✓ After schema sync refresh
New Delta table added to folder⚠ Requires new shortcut

Prerequisites Checklist

RequirementDetail
F2+ Fabric capacity Workspace must be assigned to an F or P capacity. PPU workspace mode is not sufficient for Fabric item creation.
Capacity delegated setting Admin Portal → Capacity Settings → Delegate tenant settings → "Users can create Fabric items" — must be explicitly enabled per capacity.
DFS endpoint (HNS) Use dfs.core.windows.net — not blob.core.windows.net — for HNS-enabled storage accounts.
Storage Blob Data Contributor Data plane role on the storage account. Not to be confused with Blob Contributor (management plane only).
Network access Storage account networking must allow Microsoft.Fabric/workspaces as a resource instance, or be set to "Enable from all networks".
Shortcut under Tables/ Not Files/. Shortcuts under Files are not exposed via the SQL Analytics Endpoint.
SSMS 19.1+ Older versions do not support Fabric SQL endpoint AAD authentication.

Synapse Serverless vs Fabric SQL Analytics Endpoint

Capability Synapse Serverless SQL Fabric SQL Analytics Endpoint
Delta protocol Reader 1.0 (legacy) Delta Kernel 3.x
Synapse Spark 3.5 output ✕ Protocol mismatch ✓ Same Delta generation
Deletion Vectors ✕ Hard error ✓ Fully supported
Liquid Clustering
V2 Checkpoints
SSMS connectivity
Data correctness on DV tables ✕ Silent corruption risk ✓ Correct
Data copy required No No
Setup time Under a day

A Quick Win on the Road to Fabric

SSMS access to Delta Lake tables is not a luxury — it is the self-service data layer that keeps analysts and support teams independent. When that access breaks, every data question becomes a notebook ticket to an engineer. The business slows down, the engineering team gets buried in ad-hoc queries, and trust in the data platform erodes.

The Deletion Vectors error in Synapse Serverless is not a configuration issue and it is not caused by a wrong setting in your Spark pool. It is a direct consequence of upgrading to Synapse Spark 3.5 (Delta Lake 3.2) — a necessary upgrade given that Spark 3.3 reached end of support in March 2025 and Spark 3.4 follows in March 2026. The two Synapse engines — Spark pools and Serverless SQL — have diverged at the protocol level. There is no patch coming.

Microsoft Fabric's SQL Analytics Endpoint restored our analyst and support team SSMS access within a day, with no data migration, no change to the ADLS Gen2 storage structure, and no disruption to existing Spark pipelines. The Fabric migration continues on its longer-term timeline. The business is unblocked today.

For teams running modern Delta Lake workloads written by Synapse Spark 3.5, this is not a workaround. It is the correct long-term architecture.

No comments:

Post a Comment