Serverless SQL billed per scan: estimate and control it

Rohit Athaide · 2026年11月3日 公開

Some SQL services have no servers to size. You send a query, they read the data it needs, and you are billed by how much data was read. It is simple to start and easy to overspend, because the cost of a query is invisible until you run it.

Who bills this way

• Amazon Athena bills per amount of data scanned.
• Google BigQuery on-demand bills per amount of data processed by a query. BigQuery also offers capacity pricing, billed on reserved compute, as an alternative.
• Azure Synapse serverless SQL pool bills per amount of data processed.

Each has its own rules about what counts, minimum amounts per query and how compression and file format affect the measure. Read the vendor page for the current terms.

Oracle has no service that bills this way, and our data platform estimate marks that line as not offered with the reason. See data lake cost basics.

The formula

monthly query cost = (data scanned per query) x (queries per month) x (price per unit scanned)

The hard part is the first term. It is not the size of your table. It is what the engine has to read to answer the query.

What determines the amount scanned

• File format. A columnar format such as Parquet lets the engine read only the columns a query uses. A row format such as CSV or JSON forces it to read everything.
• Compression. Compressed files are smaller on disk. Depending on the vendor, the measure may count compressed bytes or uncompressed ones.
• Partitioning. If data is split by date and the query filters by date, the engine skips the rest. See partitioning and Parquet.
• Selecting columns. SELECT * reads every column. Naming the columns reads fewer.
• Filters that cannot prune. A filter on a function of a column may force a full scan.

A worked structure without prices

Suppose a table holds a year of events and a dashboard query reads one day of three columns. In CSV with no partitioning it reads the whole year of every column. In partitioned Parquet it reads one day of three columns. The ratio between those two can be hundreds to one. The dashboard runs, say, every five minutes: that is a few hundred runs a day, so a small difference per query multiplies quickly.

Run the numbers with the price from the vendor’s page, or use the data platform estimator, which asks for scan size and query count directly.

Controls

1. Use the vendor’s query cost preview where it exists. Some show the bytes a query will read before you run it.
2. Set per-query or per-day limits on bytes processed.
3. Put a budget alert on the service. See budgets and cost alerts.
4. Materialize heavy dashboards into smaller summary tables, and point the dashboard at those.
5. Cache results where the tool allows it.
6. Review the most expensive queries each month. A handful usually cause most of the bill.

When per-scan is wrong for you

If many people run heavy queries all day, a capacity-based or warehouse option can be cheaper and more predictable. The choice depends on volume. The glossary explains the billing terms used on this page.