Microsoft Fabric Accelerates Python UDFs and Complex Data Types
trending_up Trend: python-udfs

Microsoft Fabric Accelerates Python UDFs and Complex Data Types

calendar_month June 28, 2026

Summary

Microsoft has announced major performance improvements for Python User Defined Functions (UDFs) and complex data types within the Native Execution Engine (NEE) in Microsoft Fabric. These optimization measures eliminate critical serialization and processing bottlenecks, allowing developers to execute custom Python code on Spark clusters with significantly faster runtime performance. By running operations natively in the columnar engine, existing pipelines can achieve 2x to 5x speedups without any code changes.

What happened?

In the latest updates to Microsoft Fabric, the Native Execution Engine has been enhanced with optimized execution paths for Python/Scala UDFs and complex, nested data structures (such as arrays, maps, and structs):

  • Reduced Serialization Overhead: The engine minimizes serialization roundtrips between the JVM and Python worker processes, keeping data in the columnar format longer.
  • Native Columnar Processing: Operations on complex types like explode, map access, and struct field extraction are now executed natively in the columnar engine, preventing fallbacks to slower row-based processing.
  • Code-Free Benefits: Existing Spark notebooks and jobs automatically benefit from these optimizations once the NEE is enabled in the workspace settings.

Why it matters

Historically, data teams running Apache Spark faced a difficult trade-off between developer productivity and execution efficiency. Python UDFs incurred severe performance penalties due to JVM-to-Python context switching, leading teams to either rewrite logic in SQL/Scala or flatten nested schemas at ingestion time. With these optimizations, engineers can leverage the flexibility and library ecosystem of Python without sacrificing performance. This results in faster ETL pipelines, lower cluster compute times, and reduced operational costs.

Evidence

The speedups have been validated by internal benchmarks from Microsoft as well as positive community feedback from Fabric MVPs:

  • Vectorized Python/Scala UDFs: Show performance gains of up to 5.76× faster execution.
  • Complex UDFs: Run 1.08× to 2.5× faster, depending on the logic complexity.
  • End-to-End TPC-DS Workloads: Experience up to 2.35× faster execution for queries with complex data types.
  • Community Validation: MVPs like Gilbert Que and Reza Rad have highlighted these engine-level enhancements as key enablers for modern, Python-heavy lakehouse architectures.

Analysis

The performance enhancements in Fabric point to a broader architectural shift. Modern analytics workloads are expanding beyond simple SQL queries to incorporate AI, real-time decision-making, and semi-structured formats. A performance engine that only optimizes SQL is no longer sufficient. Fabric’s Native Execution Engine bridges the gap by applying native vectorization to Python workflows and nested schemas. By keeping data in its native columnar format throughout execution, the engine successfully removes CPU and memory bottlenecks.

Practical Takeaways

  • Enable NEE: Go to Workspace Settings > Data Engineering/Science > Spark Settings > Environment. Enable the Native Execution Engine under the Compute settings of your default environment.
  • Use Vectorized UDFs: Where possible, use vectorized UDFs (Pandas UDFs) as they yield the highest performance gains under the Native Execution Engine.
  • Keep Data Nested: Avoid premature flattening of complex data structures (arrays, structs, maps) during ingestion, as the NEE can now process them natively and efficiently.

Open Questions

  • To what extent will highly custom Python libraries used inside UDFs impact the realized performance gains of the Native Execution Engine?
  • Will future iterations expand NEE support to other compute workloads outside of Apache Spark in Fabric?

Sources

  1. Microsoft Fabric Updates Blog: Improve performance for Python UDFs and complex data types
  2. Gilbert Que Twitter Post
  3. Reza Rad LinkedIn Post
  4. AzureCharts Update Entry