From Synapse Serverless to Microsoft Fabric:
Solving the Deletion Vector Problem
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.
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.
- 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
- 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
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.
Exposing ADLS Gen2 Delta Tables via Fabric SQL Analytics Endpoint
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.
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:
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).
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.
Configure RBAC on the Storage Account
The Workspace Identity of your Lakehouse needs the correct role on the storage account:
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.
Connect in SSMS
In the Fabric workspace → find the SQL analytics endpoint item → ... → Copy SQL connection string. Open SSMS 19.1+:
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.
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
| Requirement | Detail |
|---|---|
| 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.
