Estimate what a query costs to run on a pay-per-scan engine like BigQuery or Athena: price is driven by the bytes scanned, not query runtime.
GB
$
TB
Results
Calculated
Cost per query
—
Data scanned x price/TB
Data scanned per month
—
Queries/day x 30
Billable data
—
After free tier
Estimated monthly cost
—
Billable data x price/TB
Add this calculator to your website
How SQL query cost is calculated
Serverless SQL engines such as Google BigQuery (on-demand tier), Amazon Athena, and Trino/Presto-based lakehouses bill by how much data a query reads, not by how long the query takes to run. This calculator uses that same bytes-scanned pricing model: it multiplies the data scanned by one query by the price charged per terabyte (TB) scanned, then projects that per-query cost across your daily query volume to estimate a monthly bill.
The formula
Cost per query = (data scanned per query in GB ÷ 1000) × price per TB scanned. Monthly data scanned = data scanned per query × queries per day × 30. Many pay-per-scan engines also include a monthly free allowance — BigQuery's on-demand tier, for example, includes 1 TiB free per month — which is subtracted from the monthly total before the remaining, billable data is multiplied by the price per TB.
Understanding the inputs
Data scanned per query is the number of gigabytes the engine reads from storage to answer the query; check your engine's query details or execution panel, or run a dry run/EXPLAIN, to find this value. Price per TB scanned is your engine's on-demand rate — check your provider's current pricing page, since these rates change over time. Queries per day is your typical query volume, and free tier is any monthly data allowance included before billing starts.
Interpreting the results
The highlighted cards show the cost of a single query and the projected monthly bill after your free tier is applied. The supporting cards show the raw monthly data volume and the billable portion once the free tier is subtracted, which is useful for seeing how much of your usage is actually free.
Frequently Asked Questions
How is SQL query cost actually billed?
Serverless, pay-per-scan engines such as Google BigQuery (on-demand tier), Amazon Athena, and Trino/Presto-based lakehouses charge per byte or per terabyte of data scanned by the query, not per second of compute time. Reading less data, through column pruning, partitioning, and selective filters, lowers the bill directly.
How can I reduce the data a query scans?
Select only the columns you need instead of SELECT *, filter on partitioned or clustered columns so the engine can skip irrelevant data before reading it, and avoid full table scans when a WHERE clause on a partition key can prune most of the table first.
Why do some warehouses charge differently from BigQuery or Athena?
Engines like Snowflake, Redshift, and Databricks typically bill for compute time on a running warehouse or cluster (per second or per credit-hour), so cost depends on query duration and warehouse size rather than bytes scanned. This calculator models the bytes-scanned approach used by BigQuery on-demand and Athena; for compute-time billing, multiply warehouse-hours by the hourly rate instead.
What does the free tier input represent?
Many pay-per-scan engines include a monthly data allowance before billing starts, for example BigQuery's on-demand tier includes 1 TiB of scanning free each month. Set this field to 0 if your engine or plan has no free allowance.
Practical Guide for SQL Query Cost Calculator
SQL Query Cost Calculator is most useful when the inputs reflect the situation you are actually planning around, not a best-case estimate. Treat the result as a decision aid: it gives you a structured way to compare assumptions, spot outliers, and decide what to verify next. For Other work, the most important review lens is baseline behavior, time cost, throughput, constraints, friction, and the decision threshold you care about.
Start with a baseline run using values you can defend. Then change one assumption at a time and watch which output moves the most. If one input dominates the result, spend your verification time there first. If several inputs have similar influence, use a conservative scenario and an optimistic scenario to create a practical range instead of relying on a single exact number.
Before acting on the result, compare the result with recent real-world data instead of ideal targets or one-off examples. This is especially important when the calculator supports a purchase, project plan, performance target, or operational decision. The calculator can make the math consistent, but the quality of the conclusion still depends on current data, clear units, and assumptions that match your real constraints.
When the output looks surprising, slow down and inspect each input in order. A small change in one high-leverage field can move the final number more than several low-leverage fields combined. For SQL Query Cost Calculator, that means you should first confirm the value with the greatest scale, then confirm the value with the greatest uncertainty, then rerun the calculator with conservative and optimistic assumptions. This sequence turns the calculator from a single answer into a practical decision range.
Review Checklist
Confirm every input uses the unit and time period requested by the calculator.
Run a low, expected, and high scenario so the answer has a useful range.
Check whether rounding or a missing decimal place changes the decision.
Update the calculation after each meaningful workflow, schedule, cost, or usage change.