V-Order in Microsoft Fabric – what is that?

Microsoft has modified the default configuration of V-Order in Microsoft Fabric lakehouses. Per the official Microsoft documentation (updated March 1, 2026), V-Order is disabled by default in newly created workspaces (spark.sql.parquet.vorder.default = false). This change, aligned with the writeHeavy Spark resource profile assigned to workspaces created after approximately April 2025 (following FabCon), prioritizes write performance for ingestion, transformation, and update-heavy data engineering pipelines.

V-Order is an advanced write-time optimization applied to Parquet files. It restructures the internal organization of data blocks through specialized sorting, dictionary optimization, row-group alignment, and tailored compression algorithms. This technique, built on Microsoft’s Verti-Scan engine technology, significantly accelerates analytical read operations in Power BI (especially Direct Lake mode), SQL analytics endpoints, and Spark workloads, while preserving full compatibility with the open Parquet standard.

V-Order comes with many benefits:

Better Compression V-Order uses smart methods to shrink file sizes. Files are often much smaller than regular Parquet files. This saves storage space.
Smarter Data Arrangement It reorganizes data inside files (for example, by sorting and grouping rows wisely). This helps the system read only the needed parts quickly and skip unnecessary data.
Faster Queries and Analysis Reading data uses much less input/output (I/O), memory, and CPU power. Queries run noticeably faster-especially for reports and interactive analysis.
Works with Standard Parquet Files created with V-Order can still be read by any tool that supports Parquet. However, they perform best inside Microsoft Fabric.
Easy Integration in Fabric V-Order works automatically in many parts of Fabric, such as Lakehouse tables, Warehouse storage, and data pipelines. No extra setup is usually needed.

The primary trade-off is an average write overhead of approximately 15%, accompanied by higher capacity unit (CU) consumption. Disabling V-Order by default reduces this overhead, accelerating writes at the expense of read efficiency in read-heavy scenarios.

To verify the V-Order status in a Fabric notebook:

Session-level check: spark.conf.get("spark.sql.parquet.vorder.default")

Table-level check:SHOW TBLPROPERTIES your_schema.your_table;

Absence of “delta.parquet.vorder.enabled” = “true” indicates V-Order is disabled. Enable V-Order selectively for read-optimized tables. For a new table:

CREATE TABLE your_schema.your_table 
( -- columns ) 
USING DELTA TBLPROPERTIES ("delta.parquet.vorder.enabled" = "true");

For an existing table:

ALTER TABLE your_schema.your_table 
SET TBLPROPERTIES ("delta.parquet.vorder.enabled" = "true");

You can also enable it for the current session (affecting subsequent writes):

spark.conf.set("spark.sql.parquet.vorder.default", "true")

If you have table that was created in the past you can apply retroactively to existing files by running OPTIMIZE command:

OPTIMIZE your_schema.your_table VORDER;

Typically enable V-Order on gold-layer tables or those supporting Power BI Direct Lake reports with infrequent modifications, where read acceleration provides significant value.

But as you may think there are scenarios where V-Order may not be beneficial. V-Order introduces write overhead, rendering it less advantageous for write-intensive workloads involving frequent ingestion, transformations, or updates, where minimizing write latency is essential and reads occur infrequently.I would also say that you should not enable it on staging tables in ingestion pipelines that are regularly truncated, dropped, recreated, or read only once or twice before downstream processing, the added ingestion duration frequently outweighs read improvements.

From some time in Fabric Warehouse environments, V-Order is enabled by default. If you notice degraded performance then disable it for write-heavy staging use cases using simple ALTER DATABASE command:

ALTER DATABASE CURRENT SET VORDER = OFF;

This command applies to all new Parquet files generated by the warehouse engine. The action is irreversible! V-Order cannot be re-enabled afterward. Thoroughly evaluate the impact on read performance (e.g., analytical queries or Direct Lake scenarios) prior to execution. For optimal workload separation, dedicate a warehouse or lakehouse layer to staging and ingestion (with V-Order disabled where supported) while preserving V-Order in a distinct read-optimized environment for analytics and reporting. This approach aligns configuration with workload characteristics, balancing write efficiency and read performance.

You can test it on your own but if you would like to see test from someone else I recommend Andy Cutler’s article:

Performance Analysis of V-Ordering in Fabric Warehouse: On or Off?

You can find there very interesting results, especially those that shows that V-Orders sometimes give you worse performance 🙂

For comprehensive syntax, Fabric runtime notes (e.g., deprecated settings in runtime 1.3+), resource profile details, and further guidance, consult the Microsoft documentation:

I hope you find it useful and remember that not all the features fit all the scenarios!