<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Can the 5% deletion-vector threshold used by OPTIMIZE be configured? in Data Engineering</title>
    <link>https://community.databricks.com/t5/data-engineering/can-the-5-deletion-vector-threshold-used-by-optimize-be/m-p/169424#M56098</link>
    <description>&lt;P&gt;Hello everyone, we have a compliance requirement to guarantee that deleted records are physically removed from the underlying Parquet files.&lt;/P&gt;&lt;P&gt;Our current flow is:&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;&lt;P&gt;DELETE&amp;nbsp; creates deletion vectors (DVs)&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;OPTIMIZE&amp;nbsp; may rewrite files and materialize the deletions&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;VACUUM&amp;nbsp; removes obsolete files&lt;/P&gt;&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;From Delta Lake, OPTIMIZE only considers files for DV-driven rewriting when the deleted-row ratio exceeds optimize.maxDeletedRowsRatio, which defaults to 5%:&lt;/P&gt;&lt;P&gt;&lt;A href="https://github.com/delta-io/delta/pull/1578" target="_blank" rel="noopener"&gt;https://github.com/delta-io/delta/pull/1578&lt;/A&gt;&lt;/P&gt;&lt;P&gt;This means files with a small number of deleted rows may keep those rows physically present even after OPTIMIZE.&lt;/P&gt;&lt;P&gt;We can guarantee physical removal with:&lt;/P&gt;&lt;PRE&gt;REORG TABLE &amp;lt;table&amp;gt; APPLY (PURGE);&lt;/PRE&gt;&lt;P&gt;followed by VACUUM, but running REORG ... APPLY(PURGE) after every deletion request is expensive.&lt;/P&gt;&lt;P&gt;Is there a supported Databricks configuration to lower the OPTIMIZE DV threshold, ideally to 0, so that any file with a DV is rewritten? We are on AWS&lt;/P&gt;&lt;P&gt;If not, is there a recommended way to guarantee physical deletion for compliance without running REORG TABLE ... APPLY(PURGE) after every deletion?&lt;/P&gt;</description>
    <pubDate>Tue, 22 Sep 2026 11:48:39 GMT</pubDate>
    <dc:creator>dario66952</dc:creator>
    <dc:date>2026-09-22T11:48:39Z</dc:date>
    <item>
      <title>Can the 5% deletion-vector threshold used by OPTIMIZE be configured?</title>
      <link>https://community.databricks.com/t5/data-engineering/can-the-5-deletion-vector-threshold-used-by-optimize-be/m-p/169424#M56098</link>
      <description>&lt;P&gt;Hello everyone, we have a compliance requirement to guarantee that deleted records are physically removed from the underlying Parquet files.&lt;/P&gt;&lt;P&gt;Our current flow is:&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;&lt;P&gt;DELETE&amp;nbsp; creates deletion vectors (DVs)&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;OPTIMIZE&amp;nbsp; may rewrite files and materialize the deletions&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;VACUUM&amp;nbsp; removes obsolete files&lt;/P&gt;&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;From Delta Lake, OPTIMIZE only considers files for DV-driven rewriting when the deleted-row ratio exceeds optimize.maxDeletedRowsRatio, which defaults to 5%:&lt;/P&gt;&lt;P&gt;&lt;A href="https://github.com/delta-io/delta/pull/1578" target="_blank" rel="noopener"&gt;https://github.com/delta-io/delta/pull/1578&lt;/A&gt;&lt;/P&gt;&lt;P&gt;This means files with a small number of deleted rows may keep those rows physically present even after OPTIMIZE.&lt;/P&gt;&lt;P&gt;We can guarantee physical removal with:&lt;/P&gt;&lt;PRE&gt;REORG TABLE &amp;lt;table&amp;gt; APPLY (PURGE);&lt;/PRE&gt;&lt;P&gt;followed by VACUUM, but running REORG ... APPLY(PURGE) after every deletion request is expensive.&lt;/P&gt;&lt;P&gt;Is there a supported Databricks configuration to lower the OPTIMIZE DV threshold, ideally to 0, so that any file with a DV is rewritten? We are on AWS&lt;/P&gt;&lt;P&gt;If not, is there a recommended way to guarantee physical deletion for compliance without running REORG TABLE ... APPLY(PURGE) after every deletion?&lt;/P&gt;</description>
      <pubDate>Tue, 22 Sep 2026 11:48:39 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/can-the-5-deletion-vector-threshold-used-by-optimize-be/m-p/169424#M56098</guid>
      <dc:creator>dario66952</dc:creator>
      <dc:date>2026-09-22T11:48:39Z</dc:date>
    </item>
    <item>
      <title>Re: Can the 5% deletion-vector threshold used by OPTIMIZE be configured?</title>
      <link>https://community.databricks.com/t5/data-engineering/can-the-5-deletion-vector-threshold-used-by-optimize-be/m-p/169465#M56104</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;Short version: I couldn't find that knob anywhere in the Databricks docs. maxDeletedRowsRatio is an OSS Delta conf, and Databricks doesn't document it, so even if it's accepted on a given runtime you'd be relying on undocumented behavior for a compliance control. I wouldn't.&lt;/P&gt;&lt;P&gt;More to the point, the docs are explicit that OPTIMIZE is not the tool for this: "File compaction events don't have strict guarantees for resolving changes recorded in deletion vectors" and "Some changes recorded in deletion vectors might not be physically applied if target data files are not candidates for file compaction." The GDPR page says the same in one line: for tables with DVs, after deleting records "you must also run REORG TABLE ... APPLY (PURGE) to permanently delete underlying records."&lt;BR /&gt;&lt;A href="https://docs.databricks.com/aws/en/tables/features/deletion-vectors" target="_blank"&gt;https://docs.databricks.com/aws/en/tables/features/deletion-vectors&lt;/A&gt;&lt;BR /&gt;&lt;A href="https://docs.databricks.com/aws/en/ldp/gdpr" target="_blank"&gt;https://docs.databricks.com/aws/en/ldp/gdpr&lt;/A&gt;&lt;/P&gt;&lt;P&gt;The good news is REORG is cheaper than it sounds. Per the docs, "APPLY (PURGE) only rewrites files that contain soft-deleted data", it's idempotent, and you can scope it with a WHERE on partition columns. Two things make it cheaper still: set spark.databricks.delta.reorg.purgeMode to rows so it only looks at files with soft-deleted rows instead of scanning every footer, and don't run it per delete request. Batch the requests into a control table, run the DELETE/MERGE once a day, then one REORG APPLY (PURGE) and one VACUUM with the retention threshold set to the purge completion time. That's the flow the docs describe, and a daily SLA for physical erasure is what most DPOs accept.&lt;BR /&gt;&lt;A href="https://docs.databricks.com/aws/en/sql/language-manual/delta-reorg-table" target="_blank"&gt;https://docs.databricks.com/aws/en/sql/language-manual/delta-reorg-table&lt;/A&gt;&lt;/P&gt;&lt;P&gt;If the table is small or delete-heavy and you really want physical removal on every DELETE, the other option is to not use deletion vectors on that table at all (delta.enableDeletionVectors = false). Then DELETE rewrites the files itself and you're back to VACUUM only. You give up the write performance DVs bring, which is exactly the trade-off.&lt;/P&gt;&lt;P&gt;One caveat on OPTIMIZE FULL (DBR 16+): it "Rewrites all data files in the table", so it would clear DVs as a side effect, but it's a full rewrite and the docs never position it for this. REORG is the documented path.&lt;/P&gt;</description>
      <pubDate>Tue, 22 Sep 2026 16:05:07 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/can-the-5-deletion-vector-threshold-used-by-optimize-be/m-p/169465#M56104</guid>
      <dc:creator>ThomazNeto</dc:creator>
      <dc:date>2026-09-22T16:05:07Z</dc:date>
    </item>
  </channel>
</rss>

