ClickHouse for Microsoft Fabric: OneLake Read GA, Write Preview and Data Copying Caveats

The press release says a lot about "no copying" and "sub-second" speed. ClickHouse's own vendor attestation for the Fabric workload fills in more detail, and some of it complicates that message. Here is what's new, what's still in preview, and what Fabric admins should check before turning anything on.

The four milestones and their status​

Only the read path is GA. The Fabric workload and write-back are both previews. If you need a production SLA, plan around that.

The Fabric workload: speed, with a sync step​

ClickHouse says the workload is now in public preview through the Fabric workload hub, and it brings the ClickHouse query engine into the Fabric experience so data teams can accelerate OneLake queries to sub-second response times without leaving Fabric. The target use cases are highly concurrent agentic workloads, real-time interactive dashboards, and observability, which the company says now run at the latency users expect with no separate cluster to provision and no ETL pipeline to maintain.

The release gives no benchmark, dataset size, baseline or service-level commitment for "sub-second." Treat that phrase as a vendor claim until you've tested it on your own data.

Microsoft's Dipti Borkar, VP of Microsoft IQ and OneLake, said the workload gives joint customers more engine choices "without moving or copying data between platforms." ClickHouse's attestation document tells a more detailed story. It lists the workload as "ClickHouse (ClickHouse.ClickHouse.Cloud)", in public preview, with a release date of September 27, 2026. It also says that:

• Tables you choose to accelerate are copied into ClickHouse. OneLake stays the source of truth, but selected tables are copied or synced into a dedicated ClickHouse Cloud service running on Azure.
• Some metadata lives outside Fabric. Saved queries, service configuration and user references are stored in the ClickHouse Cloud control plane.
• Part of the service runs outside Azure. The attestation says the control plane has replicas in AWS and that customer data may pass through or be processed by it.
• Data is placed near your Fabric region, where possible. Services run in the ClickHouse Cloud Azure region matching your Fabric region if one exists. If not, the nearest supported region is used.

So "no copying" fits the direct-query read path, covered below. The accelerated workload works differently: it keeps a synced copy. Both designs are reasonable, since caching hot data in a columnar engine is how you get very low latency. But compliance teams should hear the accurate version before they sign off.

What the preview workload doesn't support yet​

The attestation also lists gaps that will matter to governance-minded admins:

• Purview sensitivity labels: not supported
• Data lineage and OneLake data hub: not supported
• ALM, CI/CD and item portability: not supported. Items can't be restored into other workspaces.
• Private Link: Azure Private Link can be set up from the ClickHouse Cloud console, but not through the Fabric workload
• Monitoring Hub: long-running copy jobs are monitored in the ClickHouse Cloud console, not Fabric's Monitoring Hub
• Cross-tenant B2B: not supported. Each Fabric workspace maps to one ClickHouse organization within the tenant.
• Language: English only

Several things are in place:

• Authentication: Microsoft Entra, with Conditional Access listed as working in full.
• OneLake access: on-behalf-of tokens during the trial, and a customer-provided service principal on paid plans.
• Trial: 30 days with credits, on the Scale tier, with idling enabled by default.
• Certifications claimed: SOC 2 Type II and ISO 27001.

Section summary: The workload makes it easy to add ClickHouse inside Fabric. The trade-off is a synced copy of the tables you accelerate, some metadata and processing outside Fabric, and a preview that doesn't yet include Purview labels, lineage or CI/CD.

OneLake read goes GA: the zero-copy path​

This is the most production-ready part of the announcement. ClickHouse reads OneLake Iceberg tables in place through Microsoft's standard APIs. Microsoft's documentation says the OneLake Table APIs work with clients that support the Iceberg REST Catalog or Unity Catalog standards. The prerequisites are:

• a Fabric tenant ID
• the workspace ID and data item ID
• the schema and table name
• an Entra user or service principal with read permission on the data item

This integration first appeared in November 2025. At that time ClickHouse said it would debut as a beta feature in ClickHouse 25.11 and arrive shortly after in ClickHouse Cloud. The beta-era ClickHouse documentation said the feature had to be enabled with SET allow_database_iceberg = 1, and asked for an Entra tenant ID, application (client) ID, client secret, a warehouse ID and a data item ID, with the warehouse ID being the workspace ID. The same documentation contained a useful warning: it recommended the Lakehouse ID as the data item ID, because in ClickHouse's testing a Warehouse ID didn't work.

GA may have changed whether that setting is still required. Check the current ClickHouse docs rather than assuming the beta steps still apply.

Practical checklist for the read path:

1. Register an Entra app, or use an existing service principal, with read access to the target lakehouse.
2. Grant the app permission for the Azure Storage token audience. Microsoft notes that the OneLake table endpoint uses the same audience as the OneLake filesystem endpoints.
3. Collect the tenant, workspace and lakehouse GUIDs. They appear in the OneLake URL or in your browser's address bar when the item is open in Fabric.
4. Make sure the tables are Iceberg, or set up Microsoft's automatic Delta-to-Iceberg conversion.
5. If queries fail, check the ID you used first. Lakehouse IDs worked in ClickHouse's testing and Warehouse IDs didn't.

OneLake write: a full read-transform-write loop, in preview​

ClickHouse says OneLake write support uses OneLake Table APIs with credential vending, and it is in public preview. The idea is to read from OneLake, aggregate at ClickHouse speed, and write the results back as governed Iceberg tables for Power BI, notebooks and other Fabric engines.

That fills a real gap. When we covered the original integration in late 2025, metadata write operations were still a roadmap item for OneLake Table APIs. The announcement doesn't cover write patterns, consistency guarantees, limits or setup steps, so this should stay out of critical pipelines until more documentation appears. The press release says "any Fabric engine" can read the output. Test that against your own security configuration before relying on it.

BYOC in Microsoft Marketplace: managed, inside your tenant​

BYOC runs ClickHouse Cloud inside the customer's own Azure tenant. According to ClickHouse:

• the customer keeps ownership of IAM policies, network controls and encryption settings
• ClickHouse handles provisioning, upgrades, monitoring and scaling
• data never leaves the customer's environment

It's aimed at organizations with data residency or sovereignty requirements. The release doesn't name specific jurisdictions or certifications, and it doesn't describe what telemetry or operator access flows back to ClickHouse.

The procurement angle may matter most to large enterprises. Because the offering is in Microsoft Marketplace, ClickHouse says purchases can go through existing Microsoft agreements and count toward Microsoft Azure Consumption Commitments (MACC). Confirm your own contract terms before assuming it qualifies.

Analysis: who gains, and what to watch​

For Microsoft, this fits the "many engines, one lake" strategy. Earlier, ClickHouse described how OneLake-cataloged data secured with OneLake Security can be accessed from Fabric, Azure AI Foundry and third-party engines like ClickHouse. Each new partner engine makes OneLake more central, even if the queries run elsewhere.

For ClickHouse, Fabric adds a distribution channel and puts its engine in front of Power BI-heavy organizations that might never have run their own cluster.

The main caution for readers is about wording. "No copying" is accurate for the GA read path. It isn't accurate for the accelerated workload, which syncs tables into a ClickHouse service and, according to the vendor's own attestation, involves a control plane with AWS replicas. Neither is a problem in itself, but data protection officers need to know which setup they're approving.

Bottom line:

• Read path (GA): the safe place to start.
• Fabric workload (preview): worth a 30-day trial for dashboard and observability latency tests, but it's missing Purview labels, lineage and CI/CD.
• Write path (preview): promising, but not ready for production pipelines.
• BYOC: most relevant to regulated shops that want a managed service and MACC credit.