How to read a database query plan (and stop the $400 surprise bill)

Modern cloud databases and analytics warehouses bill by data scanned and compute consumed, not by how complex your SQL looks or how small the final answer is.

A query that returns just five summary numbers can easily scan 100 gigabytes of historical data if written carelessly, while a query returning ten thousand rows can cost fractions of a cent if it is properly filtered.

This is how growth teams and marketing departments wake up to a $400 to $1,200 surprise bill at the end of the month on a dashboard that "only shows a few basic charts": an unoptimized query is silently scanning an entire warehouse every 15 minutes in the background.

Library vs filing cabinet

To understand why database bills explode, imagine asking a librarian: "What was our total revenue on Tuesday?" pennies per run, hundreds per month

If you write SELECT *, you force the database to pull down every single shelf in the library, even if your final chart only displays one number.

Four costly mistakes and fixes

1. SELECT * on Wide Marketing & Event Tables

Marketing datasets (like web event exports, CRM activity logs, and ad conversion tables) often have 50 to 100+ columns, including large nested JSON strings and user agent metadata.

-- ❌ EXPENSIVE: Scans all 80 columns in the table (50+ GB scanned)
SELECT * 
FROM analytics_events 
WHERE event_name = 'purchase';

-- ✅ CHEAP: Scans only the 3 columns needed (2 GB scanned — 96% cost reduction)
SELECT 
  event_date, 
  user_id, 
  order_value
FROM analytics_events
WHERE event_name = 'purchase';

2. Forgetting to Filter on the Partition Date

A partitioned table physically separates records into daily or monthly folders. When you filter by the partition date, the query engine skips 99% of historical data. When you forget the filter, it scans every record from the day the company was founded.

-- ❌ EXPENSIVE: Scans 3 years of company transaction history
SELECT SUM(order_total) 
FROM customer_orders;

-- ✅ CHEAP: Scans only yesterday's partition
SELECT SUM(order_total) 
FROM customer_orders
WHERE order_date = CURRENT_DATE() - 1;

3. The Function Wrapping Trap (Breaking Partition Pruning)

Applying SQL functions to a timestamp column can silently prevent the database engine from recognizing partitions:

-- ⚠️ RISKY: Function wrapping might bypass partition index on some engines
WHERE DATE(created_timestamp) = '2026-08-26'

-- ✅ SAFE: Use explicit date/timestamp boundary filters
WHERE created_timestamp >= '2026-08-26 00:00:00' 
  AND created_timestamp <  '2026-08-27 00:00:00'

4. Joining Before Aggregating (The Fan-Out Disaster)

Joining two raw, row-level tables (e.g. 5 million click events joined to 1 million orders on a shared timestamp) forces the database to perform massive in-memory data shuffles.

The Fix: Always aggregate both tables to the target grain (e.g. daily totals) first, then join the small aggregated summary tables:

-- ✅ CHEAP & FAST: Aggregate each side to daily totals, then join
WITH daily_ad_costs AS (
  SELECT 
    DATE(spend_date) AS day, 
    SUM(spend_amount) AS total_spend
  FROM ad_channel_spend
  WHERE spend_date >= '2026-08-01'
  GROUP BY 1
),

daily_sales AS (
  SELECT 
    DATE(order_created_at) AS day, 
    SUM(order_total) AS total_revenue
  FROM orders
  WHERE order_status = 'completed' 
    AND order_created_at >= '2026-08-01'
  GROUP BY 1
)

SELECT 
  s.day,
  c.total_spend,
  s.total_revenue,
  ROUND(s.total_revenue / NULLIF(c.total_spend, 0), 2) AS blended_roas
FROM daily_sales s
LEFT JOIN daily_ad_costs c USING (day)
ORDER BY s.day DESC;

Read a query plan in 60 seconds

When a query is slow or expensive, open its Execution Details / Query Plan tab in your database editor. Three numbers tell you almost everything:

Guardrails against runaway bills

One question before the FAQ. 30 seconds, no grading

Frequently Asked Questions

Why did my database query cost money if it returned 0 rows?

Cloud databases bill for the amount of data they had to inspect to confirm there were 0 matching rows. If you search for an obscure customer ID across a 500 GB table without an index or partition filter, the engine must scan all 500 GB to prove the ID does not exist.

What is the difference between partitioning and clustering?

• Partitioning divides tables into coarse segments (e.g., by day or month).
• Clustering sorts data inside each partition by specific columns (e.g., sorting events by user_id or campaign_id), allowing the engine to skip non-relevant blocks within a single day.

Summary

Controlling database costs does not require a degree in data engineering. By following three golden rules:

• Select only the specific columns you need (no SELECT *).
• Always filter by partition dates.
• Aggregate tables before joining.

You can run lightning-fast analytics across millions of marketing and CRM records while keeping your monthly database invoice under control.