Negative Bytes Scanned: Why a 149 GB Query Reports -1.5 GB

A telemetry row that reports -1.5 GB scanned for a query that read about 149 GB is not measuring anything; it is a 32-bit integer that ran out of room. According to the tldr.tech data roundup, unloading Snowflake QUERY_HISTORY to Parquet can corrupt values when large numbers are written as INT32, and casting the nine affected columns before export prevents overflow, bad joins, and incorrect analysis ^[1].

The arithmetic is unglamorous. A signed 32-bit integer stops at 2,147,483,647 ^[4]. A 149 GB scan is 159,987,531,776 bytes, roughly 74 and a half times that ceiling ^[5]. What survives truncation is the true value modulo 4,294,967,296, shifted back into signed range, so any remainder above 2^31-1 reads as a negative number ^[6].

That produces the constraint operators should internalise: an overflowed byte count can never sit further than about 2.1 GB from zero, no matter how much the query actually read ^[7]. The magnitude carries no information about scale. Sums over the column are noise, ordering by it is meaningless, and the same truncation breaks joins that use those values ^[1].

As for why INT32 gets chosen, Snowflake's own unload documentation says that by default it optimizes columns in unloaded Parquet files to the smallest precision that accepts all the values, and that setting ENABLE_UNLOAD_PHYSICAL_TYPE_OPTIMIZATION to FALSE produces an output schema determined by the logical column types instead ^[2]. So there are two levers: explicit casts on the nine columns ^[1], or pin the schema and stop the optimizer guessing ^[2].

None of this touches the invoice. Snowflake charges credits based on how many warehouses run, how long, and at what size, billed per second with a one-minute minimum ^[8]. Bytes scanned is a diagnostic, not a billing unit. What corrupts is everything built on top: chargeback models that attribute cost through object tags and query tags ^[9], and the ranking of which queries to fix first.