All BigQuery cost anti-patterns

ORDER BY without LIMIT on a large result

A top-level sort with no LIMIT forces the whole result through a single worker. It is the most common cause of "resources exceeded".

What it is

Producing a globally ordered output means the final sort cannot be distributed. With a LIMIT, BigQuery only needs the top N per worker. Without one, everything has to pass through one place.

Why it costs money

  • Slot time, not bytes, is what this wastes — which makes it an Editions cost problem rather than an on-demand one.
  • A query that fails still bills for the bytes it read before failing.
  • The sort is very often pointless: the consumer is a dashboard or an export that re-sorts anyway.

Worked example

Expensive
SELECT * FROM `analytics.events` ORDER BY event_timestamp
Cheaper
SELECT * FROM `analytics.events` ORDER BY event_timestamp DESC LIMIT 1000
The arithmetic. Bytes billed are identical. The difference is a query that completes in seconds versus one that consumes hundreds of slot-hours and may fail outright.

How to fix it

  1. 1Add a LIMIT whenever a top-level ORDER BY is genuinely needed.
  2. 2Drop the ORDER BY when writing to a destination table — order is not preserved on write, so sorting first achieves nothing.
  3. 3For ordering within groups, ROW_NUMBER() OVER (PARTITION BY …) distributes properly.
The analyzer detects this one. Paste your query into the BigQuery Query Cost Analyzer and it will point at the exact line.

Fixing one query is satisfying. Fixing the pattern is the win.

Finitizer finds every instance of this across your BigQuery job history, ranks them by what they actually cost, and keeps checking after you have fixed them.