<?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 How to force Databricks Serverless to process 1 TB (40 Billion Rows) in 14 Minutes in Community Articles</title>
    <link>https://community.databricks.com/t5/community-articles/how-to-force-databricks-serverless-to-process-1-tb-40-billion/m-p/169114#M1577</link>
    <description>&lt;P&gt;Databricks Serverless is incredible for abstracting infrastructure, but because it scales based on the volume of pending tasks, relying on default configurations for massive data ingestion can leave performance on the table.&lt;/P&gt;&lt;P&gt;I recently ran an experiment to ingest 91 massive Parquet files (6–8 GB each) totaling 1.04 TB. Using standard 128MB partitions, this only generates a few thousand tasks—not enough to trigger the Serverless engine’s maximum horizontal scale-out.&lt;/P&gt;&lt;P&gt;Here is the one-line configuration hack to change that: &lt;FONT color="#999999"&gt;spark.conf.set("spark.sql.files.maxPartitionBytes", "33554432")&lt;/FONT&gt;&lt;/P&gt;&lt;P&gt;By dropping the max partition size to 32MB, we force Spark to aggressively split those massive files into roughly &lt;STRONG&gt;23,000 micro-tasks&lt;/STRONG&gt;. When the Serverless auto-scaler detects a queue that large, it instantly provisions a massive fleet of Photon-enabled workers, pushing read throughput over 1.2 GB/s.&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;The Results &amp;amp; The "Gotcha"&lt;/STRONG&gt; While the engine chewed through 40.1 billion rows in just 14 minutes and 5 seconds, it actually read 3x more rows than it wrote (13.3 billion).&lt;/P&gt;&lt;P&gt;Why? &lt;STRONG&gt;Cluster-on-write&lt;/STRONG&gt;.&lt;/P&gt;&lt;P&gt;Because the target Delta table was created with &lt;FONT color="#999999"&gt;CLUSTER BY (sales_date, warehouse_name),&lt;/FONT&gt; the Serverless engine had to perform a massive in-memory shuffle of all 40 billion rows before writing. Crunching a 1 TB shuffle in 14 minutes with zero infrastructure management is a huge win for Serverless compute, but it technically missed my sub-10-minute SLA for this pipeline.&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;The Architecture Fix for Maximum Speed:&lt;/STRONG&gt; If you need absolute maximum raw I/O throughput:&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;&lt;P&gt;&lt;STRONG&gt;Decouple the clustering:&lt;/STRONG&gt; Create the initial Delta table &lt;I&gt;without&lt;/I&gt; clustering keys.&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;&lt;STRONG&gt;Ingest raw:&lt;/STRONG&gt; Execute the write phase as a pure, map-only I/O operation (no shuffle). With the 32MB partition trick, this 1 TB load drops into single-digit minutes.&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;&lt;STRONG&gt;Defer the heavy lifting:&lt;/STRONG&gt; Run ALTER TABLE ... CLUSTER BY after the write. Serverless Predictive Optimization will seamlessly sort the underlying files asynchronously in the background.&lt;/P&gt;&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;Check my LinkedIn post:&amp;nbsp;&lt;A href="https://lnkd.in/p/e3xUqq5b" target="_blank" rel="noopener"&gt;https://lnkd.in/p/e3xUqq5b&lt;/A&gt;&lt;/P&gt;&lt;P&gt;Has anyone else been experimenting with partition sizing to manipulate Serverless auto-scaling? Let me know your findings below. &lt;span class="lia-unicode-emoji" title=":backhand_index_pointing_down:"&gt;👇&lt;/span&gt;&lt;/P&gt;&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="Stress Test.png" style="width: 400px;"&gt;&lt;img src="https://community.databricks.com/t5/image/serverpage/image-id/31290iC0862017A4B9F80F/image-size/medium?v=v2&amp;amp;px=400" role="button" title="Stress Test.png" alt="Stress Test.png" /&gt;&lt;/span&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;#Databricks #DataEngineering #ApacheSpark #Serverless #BigData #PerformanceTuning #DeltaLake&lt;/P&gt;&lt;P&gt; &lt;/P&gt;</description>
    <pubDate>Fri, 18 Sep 2026 17:17:12 GMT</pubDate>
    <dc:creator>ShamenParis</dc:creator>
    <dc:date>2026-09-18T17:17:12Z</dc:date>
    <item>
      <title>How to force Databricks Serverless to process 1 TB (40 Billion Rows) in 14 Minutes</title>
      <link>https://community.databricks.com/t5/community-articles/how-to-force-databricks-serverless-to-process-1-tb-40-billion/m-p/169114#M1577</link>
      <description>&lt;P&gt;Databricks Serverless is incredible for abstracting infrastructure, but because it scales based on the volume of pending tasks, relying on default configurations for massive data ingestion can leave performance on the table.&lt;/P&gt;&lt;P&gt;I recently ran an experiment to ingest 91 massive Parquet files (6–8 GB each) totaling 1.04 TB. Using standard 128MB partitions, this only generates a few thousand tasks—not enough to trigger the Serverless engine’s maximum horizontal scale-out.&lt;/P&gt;&lt;P&gt;Here is the one-line configuration hack to change that: &lt;FONT color="#999999"&gt;spark.conf.set("spark.sql.files.maxPartitionBytes", "33554432")&lt;/FONT&gt;&lt;/P&gt;&lt;P&gt;By dropping the max partition size to 32MB, we force Spark to aggressively split those massive files into roughly &lt;STRONG&gt;23,000 micro-tasks&lt;/STRONG&gt;. When the Serverless auto-scaler detects a queue that large, it instantly provisions a massive fleet of Photon-enabled workers, pushing read throughput over 1.2 GB/s.&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;The Results &amp;amp; The "Gotcha"&lt;/STRONG&gt; While the engine chewed through 40.1 billion rows in just 14 minutes and 5 seconds, it actually read 3x more rows than it wrote (13.3 billion).&lt;/P&gt;&lt;P&gt;Why? &lt;STRONG&gt;Cluster-on-write&lt;/STRONG&gt;.&lt;/P&gt;&lt;P&gt;Because the target Delta table was created with &lt;FONT color="#999999"&gt;CLUSTER BY (sales_date, warehouse_name),&lt;/FONT&gt; the Serverless engine had to perform a massive in-memory shuffle of all 40 billion rows before writing. Crunching a 1 TB shuffle in 14 minutes with zero infrastructure management is a huge win for Serverless compute, but it technically missed my sub-10-minute SLA for this pipeline.&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;The Architecture Fix for Maximum Speed:&lt;/STRONG&gt; If you need absolute maximum raw I/O throughput:&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;&lt;P&gt;&lt;STRONG&gt;Decouple the clustering:&lt;/STRONG&gt; Create the initial Delta table &lt;I&gt;without&lt;/I&gt; clustering keys.&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;&lt;STRONG&gt;Ingest raw:&lt;/STRONG&gt; Execute the write phase as a pure, map-only I/O operation (no shuffle). With the 32MB partition trick, this 1 TB load drops into single-digit minutes.&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;&lt;STRONG&gt;Defer the heavy lifting:&lt;/STRONG&gt; Run ALTER TABLE ... CLUSTER BY after the write. Serverless Predictive Optimization will seamlessly sort the underlying files asynchronously in the background.&lt;/P&gt;&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;Check my LinkedIn post:&amp;nbsp;&lt;A href="https://lnkd.in/p/e3xUqq5b" target="_blank" rel="noopener"&gt;https://lnkd.in/p/e3xUqq5b&lt;/A&gt;&lt;/P&gt;&lt;P&gt;Has anyone else been experimenting with partition sizing to manipulate Serverless auto-scaling? Let me know your findings below. &lt;span class="lia-unicode-emoji" title=":backhand_index_pointing_down:"&gt;👇&lt;/span&gt;&lt;/P&gt;&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="Stress Test.png" style="width: 400px;"&gt;&lt;img src="https://community.databricks.com/t5/image/serverpage/image-id/31290iC0862017A4B9F80F/image-size/medium?v=v2&amp;amp;px=400" role="button" title="Stress Test.png" alt="Stress Test.png" /&gt;&lt;/span&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;#Databricks #DataEngineering #ApacheSpark #Serverless #BigData #PerformanceTuning #DeltaLake&lt;/P&gt;&lt;P&gt; &lt;/P&gt;</description>
      <pubDate>Fri, 18 Sep 2026 17:17:12 GMT</pubDate>
      <guid>https://community.databricks.com/t5/community-articles/how-to-force-databricks-serverless-to-process-1-tb-40-billion/m-p/169114#M1577</guid>
      <dc:creator>ShamenParis</dc:creator>
      <dc:date>2026-09-18T17:17:12Z</dc:date>
    </item>
  </channel>
</rss>

