Microsoft & Snowflake’s Commitment to Apache Ossie
If you haven't already, check out FabCon and SQLCon 2026 in Barcelona: Building the data foundation for Microsoft Copilot and Agents for a complete look at all of our FabCon Europe announcements across Fabric and Microsoft Databases. Advancing an open, interoperable semantic foundation for AI-powered analytics Today, Microsoft is pleased to affirm our commitment to Apache Ossie (incubating), a community-led effort to establish a vendor-neutral standard for exchanging semantic metadata across analytics, AI, and BI platforms. This has been a close collaboration with Snowflake, who helped found Ossie. We have heard loud and clear that customers want to enable platform-agnostic agentic experiences. Shared semantic context must be defined once and reused across platforms, enabling agentic consumption at scale, maximizing the reach of AI-powered analytics, and empowering users to leverage the best agent for the job. Power BI semantic models are key enablers of AI-powered analysis, providing humans and AI agents with governed semantic context to answer data questions quickly and confidently. Power BI semantic models have more than 38 million monthly active users and are adopted by 94% of Fortune 500 companies. Microsoft was also recognized as a Leader and Outperformer in the GigaOm’s radar for semantic layers & metric stores in 2025. We’re now bringing this wealth of experience to Apache Ossie, and we are excited to work with Snowflake and other partners to help make the project successful. Why Apache Ossie matters Until now, semantic definitions were often recreated across platforms, introducing complexity, inconsistency, and management overhead. Apache Ossie addresses this with a common specification that tools can read and write. Its goal is straightforward but consequential: define a semantic layer once and make it portable across the data and AI ecosystem, while preserving semantic meaning and governance for agentic consumption. Collaboration with Snowflake Snowflake and Microsoft serve many of the same customers, but customers don't want to choose between ecosystems. They want their data and analytics investments to work together. That makes interoperability between, for example, Snowflake Semantic Views and Power BI semantic models a shared responsibility. This layers on top of the integration work we have already done with Snowflake for writing Iceberg tables from Snowflake to OneLake, Mirrored Databases from Snowflake, using Iceberg tables with OneLake, Catalog Integration for OneLake, Power Query Snowflake connector and much more. As discussed in the Snowflake blog post and the message below from Carl Perry, VP of Analytics at Snowflake, our collaboration is currently focused on using Apache Ossie as a vehicle for cross-platform semantic-layer conversion without moving or duplicating the underlying data. Looking ahead, we’re committed to advancing the open standard by building on our deep expertise in semantic modeling by, including helping establish DAX as an Ossie-recognized query language. We also plan to help advance Ossie support for ontologies so customers can extend the business logic in semantic models beyond agentic analysis and into platform-agnostic operational intelligence. Ultimately our goal is simple: enable customers to define once, and reuse anywhere. Today, we are highlighting the following new integration scenario: converting an Ossie document into both a Snowflake Semantic View and a Power BI semantic model. This enables customers to define shared semantic context once, then reuse it across Snowflake and Fabric while retaining the agentic experiences and capabilities of each platform. Refer to Apache Ossie Microsoft Converter for more information. Building together We look forward to working with the Apache community, Snowflake, and others across the industry to create a more open and connected future for AI-powered analytics, delivering more choice and flexibility for customers. Get involved: Visit the Apache Ossie project website and repository to explore the specification and community contribution channels. Share your thoughts and feedback with us. Apache Ossie is undergoing incubation at the Apache Software Foundation. Incubation indicates that the project is working toward the governance, infrastructure, and community practices expected of established Apache projects.
Databricks ADBC connector for Power BI and Microsoft Fabric (Generally Available)
This release is part of the broader ODBC-to-ADBC transition for Power Query connectors described in the Transition from ODBC to ADBC drivers in Power BI and Microsoft Fabric documentation. What’s new Existing connections in your semantic models, dataflows, and paginated reports continue to work unchanged — the migration path is currently opt-in per connection, per workspace, or per tenant. Highlights: Improved security - ADBC drivers incorporate security enhancements, such as memory safety and garbage collection. No changes to existing behavior - This transition moves away from the embedded ODBC drivers that ship with Power BI. It does not change behavior for the ODBC connector when you use a separately installed ODBC driver. Efficient large dataset support - ADBC provides a set of standard interfaces for interacting with Arrow data, which is especially efficient at fetching large datasets with minimal overhead and no serialization or copying. Supported authentication - Databricks ADBC supports OAuth (user), OAuth (M2M / Client Credentials), and Microsoft Entra ID. Connectors covered by this release Connector Previous driver New driver (GA) Databricks Simba Spark ODBC Databricks ADBC Azure Databricks Simba Spark ODBC Databricks ADBC How to try it You can test the ADBC driver now. We suggest you start soon to help ensure the eventual deprecation of ODBC and migration to ADBC runs smoothly. There are three ways to begin validating ADBC, ordered by how much control you want. 1. Opt in per connection using Implementation="2.0" The fastest way to compare ADBC and ODBC for a specific report or dataset. Add the Implementation="2.0" option to the source step in your Power Query expression: Source = Databricks.Catalogs("adb-1234567890.1.azuredatabricks.net", "/sql/1.0/warehouses/<warehouse-id>", [Implementation="2.0"]) Refresh the dataset and compare row counts, column types, and totals against your production baseline. If you want to force a side-by-side comparison against ODBC, use Implementation="1.0" . 2. Override the default for a validation workspace If you want to validate several reports together, a workspace admin can turn ADBC on for a single workspace while the rest of the tenant continues to use the legacy driver. Publish the reports you want to test into that workspace and run your normal refresh schedule. 3. Enable ADBC by default at the tenant level When you’re confident with the results, the tenant admin can enable Users can connect to data sources by using Apache Arrow database connectivity (ADBC) in the Admin portal. New connections across the tenant will use the ADBC driver by default, and Desktop and the service stay aligned on the same driver. What to expect during validation The ADBC driver is designed as a compatibility-preserving replacement for the Simba Spark ODBC driver. Validate your key reports in Desktop before enabling ADBC at the tenant level and report any regressions to [email protected]. Explore Transition from ODBC to ADBC drivers in Power BI and Microsoft Fabric for more information. What’s next The Power BI service will move from ODBC to ADBC through the first quarter of 2027. We recommend that you start validating today, so the tenant-level move is a non-event when it lands. We’d love your feedback Try the new Databricks ADBC driver. If anything looks different from what you'd expect — a refresh that fails, a total that changed, a performance regression — send the tenant ID, connector, M expression, and what you observed to [email protected]. Get started this week: Read the Databricks connector documentation. Install the latest Power BI Desktop. Pick one production report on Databricks and add Implementation="2.0" to its source step. Compare row counts, column data types, and key totals against your production baseline. Report anything unexpected to [email protected].Modern Power BI architecture choices for reporting on Azure Databricks: A performance benchmark for Power BI storage modes
Many enterprise Power BI semantic models use Azure Databricks as a data source. When building these models, developers and architects face an early and consequential decision: which storage mode to use. Cost, security, and ease of development and tuning all factor in — but report performance is probably the most important of them, because reports that are slow to load are one of the most common causes of end-user dissatisfaction. In practice, that decision is often made on intuition rather than evidence. To help change that, we've published a new white paper, Modern Power BI Architecture Choices for Reporting on Azure Databricks, benchmarking four ways of serving the same Delta tables to a Power BI report: Direct Lake on OneLake — over Delta tables in a Fabric lakehouse or warehouse Direct Lake on mirrored Unity Catalog tables — shortcuts, no copy DirectQuery — on a Databricks SQL warehouse Composite Model on Databricks — DirectQuery combined with Import-mode aggregations Figure: The four Power BI storage modes benchmarked to evaluate their impact on report performance and scalability. What the results suggest: there's no universal winner — but there are clear patterns. Direct Lake on OneLake performed well across the widest range of situations in this benchmark. It's highly competitive at smaller and mid-size volumes, and for the typical Power BI workload — where reports are used repeatedly throughout the day — it delivers interactive performance without extra modeling effort. At the top end of the volume curve, the picture shifts. With billions of rows, a Composite Model with aggregations was the fastest and most consistent pattern, staying sub-100ms on queries the aggregation tables can resolve. The caveat is equally clear: that advantage doesn't extend to queries that fall through to the underlying DirectQuery source, so the payoff depends on how well your aggregations match real user behavior. These are just the headline findings — the detailed results vary considerably by data volume, cache state, filter scenario, and query type. We'd encourage you to read the white paper for the full picture before deciding on a pattern. One thing worth noting up front: this is a point-in-time comparison as of June/July 2026, and both platforms are moving quickly. It also measures the end-user query experience within Power BI, rather than raw database execution speed. Treat it as a guide for running your own testing, on your own data. Explore the white paper for a full walkthrough of through each pattern in detail — the test setup, what was measured, and how results break down by data volume, cache state, and query type. Visit the Power BI download center to access the paper and other related resources.Direct Lake Calculated Columns (Preview)
Calculated columns are now available in preview for Direct Lake on OneLake semantic models. This has been one of the most requested capabilities since Direct Lake launched and closes a long-standing gap with Import and DirectQuery storage modes. You can define calculated columns directly in your semantic model using DAX in web modeling and Power BI Desktop, without changing the table storage mode or modifying data upstream. The problem this solves Direct Lake combines Import-like performance with near real-time data freshness by querying Delta tables in OneLake and loading data into memory as needed. But until now, if your model needed a derived column, you had only two options: push the logic upstream into the data source or move the table to a different storage mode. Calculated columns close that gap – you can now define columns directly in the semantic model using DAX without leaving Direct Lake. What you can build Common use cases include: Derived values, such as an age calculated from a birth date. Concatenating fields, such as city and region into a single field for slicers. Formatted dates like Month-Year for grouping in visuals. Multilingual reports using data translations with USERCULTURE(). Personalized content based on functions like USERPRINCIPALNAME(). Examples 1. Age = DATEDIFF( DimCustomer[BirthDate], TODAY(), YEAR ) 2. Customer Location = DimCustomer[CityName] & ", " & DimCustomer[ContinentName] 3. Month Name = FORMAT( DimDate[FirstOfMonth], "mmmm", USERCULTURE() ) The first two return the same value for every user unless security context differs. The third adapts to the language of the person viewing the report – see Month Name. Calculated columns now have a new Expression Context property. Direct Lake calculated columns support User Context expression context only. With User Context: The expression is evaluated when a user queries the model. Evaluation respects row-level security (RLS) and object-level security (OLS). Expressions that do not reference user-aware DAX expressions or secured columns typically return the same value for every user. Considerations: Cannot be used in relationships. Direct Lake calculated columns are evaluated at query time and do not materialize. Because of this, they cannot be used as relationship keys. Build relationship keys in the Delta table when needed. Do not observe filter context. Calculated columns return a fixed value for each row and do not respond to report filters or slicers. Use a measure when the result must change based on report interactions. Unlike standard calculated columns, Direct Lake calculated columns are evaluated in the current user's security context. This means calculations automatically respect RLS and OLS. Security behavior across expression contexts The security difference is easiest to see with a column that references a protected value. Consider a model where OLS hides DimCustomer[Education] from a "NoEducationOLS" role, and a calculated column derived from it: Is Graduate = IF( DimCustomer[Education] = "Graduate Degree", "Yes", "No" ) The result depends on the expression context: Import - Standard Import - User Context Direct Lake - User Context Observes OLS No Yes Yes Result for a restricted user "Yes" or "No", derived from the hidden value Column not available Column not available With Standard, a restricted user still sees the derived answer and the protection is effectively bypassed. With User Context in both Import and Direct Lake, the reference to the secured column is evaluated within the user's security context, so the restricted user does not see the derived column. The sensitive value is never exposed. Import – Standard Expression Context Import – User Context Expression Context Getting Started Calculated columns for Direct Lake are available in preview. Open a Direct Lake on OneLake semantic model in the web or Desktop, create a calculated column, and begin modeling directly in DAX. To learn more, see the Create calculated columns in Power BI Desktop documentation.Bringing Power BI Insights to Every Copilot User
The future of Power BI and Copilot starts by meeting users where they already work. We’re bringing trusted Power BI answers into Microsoft 365 Copilot first, so people can ask questions of governed business data in the flow of work — then carrying that richer, more conversational experience back into the Power BI service itself.
Workspace outbound access protection for Power BI reports (Preview)
Workspace outbound access protection (OAP) is a workspace-level control in Microsoft Fabric that lets you constrain where the data inside a workspace can flow. With this preview, OAP support now extends to Power BI reports. The good news for report authors and admins: there's nothing new to configure on the report itself. Protection comes from a single, well-defined rule that the workspace enforces automatically as soon as you turn OAP on.Migrating from embedded ODBC drivers to ADBC in Power BI and Fabric
If you use connectors like Databricks, Snowflake, or BigQuery in Power BI or Fabric, there’s an important change coming. Microsoft is moving from embedded ODBC drivers to ADBC, which affects how connections are established and managed. This post explains what’s changing, who’s impacted, and the steps you can take now to prepare.Building in the Agentic Era with Power BI and Fabric
Microsoft Build 2026 marks a major shift in how developers build data experiences with AI agents. Today we're announcing two capabilities that bring agentic analytics to the forefront: Agent Skills for Power BI, which let developers prompt an AI agent to build and refine semantic models and reports, and Fabric Apps for Semantic Models, which enable AI agents to build and deploy Fabric-native web apps on semantic models. Both capabilities will accelerate the time it takes to go from raw data to a polished analytics solution with just natural language prompts.
