Problem statement / pain point (real-life scenario):
We are implementing CP4D's "Microsoft Azure Fabric Warehouse" connector for a multi-country banking client whose entire data platform is built natively on Microsoft Fabric — a single Fabric workspace holding both the source Lakehouse and the target Warehouse. To get high-performance writes (Load mode) into the Warehouse, the connector requires staging through an external Azure Blob Storage account; there is currently no supported way to write at scale without it.
For a customer that has deliberately standardized on Fabric and has no other use for Blob Storage, this forces them to introduce a resource that doesn't belong in their architecture just to satisfy the connector. In practice this has meant: provisioning a new storage account, setting up and approving a Private Endpoint and network rules for it, defining a separate identity/authentication path, and routing all of this through the customer's Architecture and Security review process — for a component whose only job is to move data between two services that already sit inside the same governed Fabric workspace. This has materially delayed our production go-live (on the order of 6+ weeks so far) and has consumed review cycles on the customer's side that they view as avoidable overhead, creating friction in the relationship.
Current workaround(s):
Proceeding with an external Blob Storage account as staging, with a Private Endpoint, Trusted Workspace Access / Resource Instance Rule, and Workspace Identity configured for Blob Storage Data Reader access, authenticated via a Service Principal and a CREDENTIAL clause on the Warehouse side.
This workaround is functional but adds an entire extra Azure resource, its own network/security configuration, and a round of customer architecture/security approval that would not otherwise be needed.
Proposed solution(s):
We validated directly (manual COPY INTO execution from the Fabric Warehouse SQL console) that Fabric Warehouse already supports COPY INTO reading from a OneLake Lakehouse Files location using native Fabric workspace permissions (Contributor role) — no CREDENTIAL clause, no Blob/SAS token, no storage firewall rules. This works today, manually, including when the Lakehouse and Warehouse are in the same workspace, which is exactly our customer's topology.
We propose adapting the Fabric Warehouse connector so that, when the source Lakehouse and target Warehouse are in the same (or an accessible) Fabric workspace, it can stage to a OneLake Lakehouse Files location and run COPY INTO from there, as a supported alternative to external Blob Storage.
Benefits / value:
Removes the need to provision, secure, and privately network a separate Blob Storage account solely for staging.
Unifies authentication: the same Service Principal already used for the Warehouse connection could also cover OneLake access, eliminating the current fallback to username/password authentication when Blob Storage isn't in place.
Shrinks the architecture/security review surface for customers, since no new external storage resource enters the picture — everything stays inside the already-governed Fabric workspace.
Simplifies private connectivity: OneLake and the Warehouse SQL endpoint can share a single workspace-level Private Endpoint instead of requiring a second one for Blob Storage.
Shortens implementation timelines for Fabric-native customers who have no other reason to hold a Blob Storage account.
Users impacted / frequency:
Any IBM Business Partner or customer using the CP4D Microsoft Fabric Warehouse connector in Load mode where the customer's data platform is Fabric-native (Lakehouse and Warehouse in the same tenant/workspace) is affected — this is a one-time architectural blocker per implementation, but it recurs on every new project using this connector pattern. In our case it affects one banking client's implementation across 6 countries, and has blocked production go-live for the entire engagement since the connector was first configured; we expect the same blocker to recur on any future Fabric-native client we onboard with this connector.
👌