Per-Query Pricing Costs More Than You Think at High Query Rates

Per-query pricing looks cheap because you're only charged for what you scan or compute, and nothing sits idle. That logic holds up fine at low volume. But the unit price is just one input. Billing minimums, scan multipliers, and burst patterns from automated queries are the other inputs, and they compound in ways that become visible only when the query count climbs into production territory.

At ten queries a day, none of this matters much. At ten thousand, it's most of your bill. The gap between those two states is what this piece works through: three mechanisms that turn a "pay for what you use" pitch into a bill nobody modeled ahead of time.

How 60-second billing minimums turn short queries into outsized charges

Snowflake and Amazon Redshift Serverless both bill compute in a floor of 60 seconds per activation. Run a query that takes two seconds, and the meter still reads sixty. Per-second billing kicks in only after that first minute passes. For Snowflake, the minimum resets every time a warehouse spins back up from idle. For Redshift Serverless, the 60-second floor applies to the warehouse's charge period rather than each individual query, but the effect on short, frequent workloads lands the same way.

Picture a dashboard that fires 20 queries on page load, each one finishing in about 3 seconds. Add it up and the actual computation is close to a minute of real work. But if those queries trigger separate warehouse activations, or arrive as bursts to a warehouse that keeps suspending and resuming, billed compute can stretch out toward 1,200 seconds. That's twenty minutes charged for one minute of work.

None of this is hidden. It's written into the pricing pages for both platforms. What's missing is the modeling. Nobody sits down before adoption and asks what a 60-second floor does at the query rate a real production system generates.

The math gets ugly fast at scale. Research from motherduck.com finds that an agent firing 10,000 short queries a day, each one running about 2 seconds, can end up paying a cost multiplier many times over under a 60-second minimum, depending on how the warehouse cycles and how queries cluster together over the day. In the worst-case scenario, that can represent up to a 30× cost multiplier over the actual compute performed, not a rounding error.

Teams notice the pain and often respond the wrong way: they bump every workload up to a bigger warehouse size, on the theory that fewer activations means fewer minimums. Sometimes that helps. Often it just adds a flat cost premium to workloads that never needed the extra horsepower in the first place. The engineering win of writing a fast, tight query, the thing every optimization guide tells you to chase, can quietly make your per-query economics worse under a minimum-billing regime. Shrinking your query time to 2 seconds instead of 45 doesn't save you money if the meter was never going to charge you for less than 60 anyway.

BigQuery's scan-based pricing and the cost of touching data you don't need

BigQuery's on-demand pricing charges $6.25 per TiB scanned. Run a full-table scan against a 10 TB table, and that single query costs $62.50, whether the result set that comes back is a thousand rows or ten.

Scale that pattern out. A team running 100 queries a day, each scanning 1 TiB, is paying $625 a day. Multiply by a month and that's $18,750. At that point the pricing model isn't just a cost, it's a constraint on curiosity: analysts start thinking twice before running an exploratory query, because every "let me just check something" costs real money.

The trap sits in the architecture, not the intent. BigQuery charges for what a query touches, not for what it returns or how useful the answer turns out to be. A query that scans 5 TB to return three rows costs the same as a query that scans 5 TB to return five million rows. Partitioning and clustering cut down how much data a query has to touch, and the savings can be substantial. But that only happens if someone invests in the schema work upfront. Skip that step, and every query inherits a scan-cost penalty that never goes away on its own.

Retrieval fees on object storage like Amazon S3 mirror this pattern. Teams budget for the cost of storing data by the gigabyte, but the per-request cost of pulling that data back out at query time raises real surprise spend in data-heavy applications. Storage alone runs 25 to 40% of total AWS bills in recent cloud spend reports. Retrieval costs stack on top of that base, and they don't show up on the invoice line most people check first.

What ClickHouse's compute-plus-storage model costs at each tier

ClickHouse Cloud splits its billing into two separate meters: storage and compute. Storage runs $25.30 per TB per month across every tier. Compute gets metered by the minute, in increments of 8 GiB of RAM.

The three tiers, with figures pulled straight from ClickHouse's own documentation for AWS us-east-1, tell a clear story about what you're actually paying for:

Basic costs $66.52 a month running 6 hours a day, or $186.27 a month running around the clock, on a single replica with 8 GiB RAM and 2 vCPUs, covering 500 GB of data plus 500 GB of backup. That's the entry point, and it comes with real limits: storage capped at 1 TB per service, single-zone only, and backup retention of just one day.

Scale starts at $499.38 a month. That price buys two or more replicas, multi-zone deployment, auto-scaling, separated compute for different workloads, private networking, and backup retention you can actually configure. The compute rate here runs $0.2985 per unit-hour.

Enterprise ranges from $2,669 to $9,714 a month for high-memory, large-storage setups, at a compute rate of $0.3903 per unit-hour. This tier adds SAML and SSO, HIPAA and PCI compliance, customer-managed encryption keys, and a dedicated support engineer.

Notice the jump from Basic to Scale: roughly 7.5x, from $66 to $499. That's not a rate hike. The per-unit compute prices barely move, $0.2181 versus $0.2985 per unit-hour. What's driving the jump is redundancy and configuration: multiple replicas, multiple zones, real backup policy. You're paying for resilience, not for a markup on the same resource.

There's no permanent free tier, just a 30-day trial with $300 in credit. And a few costs sit outside the headline numbers. Public internet egress runs $0.1152 per GB; inter-region egress runs $0.0312 per GB. Managed ingestion through ClickPipes costs $0.04 per GB ingested plus $0.20 an hour per compute unit, billed on top of base compute. Auto-scaling, if left unmonitored without budget alerts, can produce a bill nobody expected. And backups eat into storage costs, which matters more on Basic, where retention is capped at a single day.

Running the same engine self-hosted, under its Apache 2.0 license, costs somewhere between $2,435 and $30,720 a month in raw infrastructure, depending on data volume and how much high availability the team needs, plus another 10 to 20% in engineering time to keep it running. The managed tiers only make sense financially when the premium buys back operational work that would otherwise land on an engineer's calendar.

The cost crossover point: when per-query pricing overtakes fixed compute

Put the two models side by side on the same workload. Scanning 100 TiB a day on BigQuery runs $18,750 a month. A March 2026 analysis from oneuptime.com finds that the equivalent workload run on self-hosted infrastructure, three c5.2xlarge instances, costs approximately $734.40 a month.

That gap exists, but the crossover point isn't just "big data equals fixed compute wins." Two thresholds mark where fixed-compute pricing starts to pay off: data volume above 2 TB uncompressed, or concurrency above 50 simultaneous users. Below those lines, a team is often paying for analytical horsepower it doesn't need yet, and per-query pricing may genuinely be the cheaper, simpler choice.

Compression plays a quiet role here too. Columnar storage engines routinely shrink 10 TB of raw data down to a fraction of that footprint on disk. At $25.30 per TB, every percentage point of compression ratio directly widens the cost gap against a scan-priced system that bills against the uncompressed logical size of the data touched.

At the low end, a 16 GiB cloud VM running self-hosted analytics costs somewhat less than the Basic managed tier, minus the 1 TB storage cap and with full control over configuration. The premium that Scale charges, $499.38 a month, buys multi-zone failover, auto-scaling, and freedom from babysitting a cluster, not raw compute power.

For a realistic mid-size workload, say 2 TB of compressed data with dashboards running 8 hours a day and 100 GB of monthly egress, the fixed-compute tier costs a few hundred to well over a thousand dollars a month. Compare that to a scan-priced platform running into the hundreds to low thousands of dollars a month, or a per-second-billed warehouse running a comparable but somewhat higher range. The ranges overlap. That overlap is the point: at this scale, the pricing model matters less than the workload's shape.

What doesn't change under fixed compute is the sensitivity to how many questions get asked. A team that doubles its query volume on a fixed-compute plan pays the same bill. Ask twice as many questions, or 20 times as many, and the invoice doesn't move. Per-query pricing runs in the opposite direction: every additional question is additional cost, with no ceiling built in.

How AI agents expose the worst case of per-query billing

Agents don't query like people do. A human analyst runs a query, reads the result, thinks for thirty seconds, and runs another. An agent runs dozens in parallel, in rapid succession, often exploratory, often short. That profile, short and frequent, is exactly the pattern that triggers billing minimums at their worst.

The scale here isn't hypothetical anymore. Uber's QueryGPT handles more than 1.2 million interactive queries a month. A 2026 arxiv.org paper reports that OpenAI's internal data agent works across 70,000 datasets totaling 600 petabytes. These are production numbers at organizations building agent infrastructure right now, not edge cases from a lab. They're production numbers at organizations building agent infrastructure right now. TiDB reports that 90% of new daily TiDB Cloud clusters get created by AI agents rather than by humans clicking through a console, which says something about how fast provisioning itself has shifted hands.

Run the billing-minimum math from earlier at this scale, and the exposure gets serious. The same motherduck.com analysis cited earlier finds that ten thousand short queries a day, each around 2 seconds, can carry a cost multiplier many times over under a 60-second billing floor. That's the identical mechanism from a human-driven dashboard, just running at agent-scale volume, continuously, without the idle gaps a human workday naturally builds in.

Agent-generated data adds a second wrinkle. Telemetry from agents tends to arrive as schemaless JSON with a shape that shifts from one run to the next. Any database that demands a rigid schema before it'll accept data forces an ETL step in front of every query, and that step adds both latency and cost before the actual analysis even starts.

The shape of infrastructure built for this kind of load looks different from a system built for human analysts. It needs isolated, read-only compute sitting over shared data, because agents shouldn't have write access to production. It needs full logging of every query for auditability, since nobody's reviewing each one by hand. And it needs a compute pricing model that doesn't punish curiosity, since an agent asking a thousand small questions is doing its job, not wasting resources. Per-query pricing runs against all three of those needs at once. Sandboxed branches that let an agent poke at real data without ever touching the production copy, paired with tooling that gives agents a way to introspect schema and validate a pipeline before running against it, are the engineering answer that's emerged to handle agent access at this scale.

ClickHouse internals that make fixed-compute pricing work: MergeTree, schema design, and columnar compression

Fixed-compute pricing only works economically if the engine underneath can actually deliver fast queries without a per-scan cost. That's where the MergeTree engine does its work. Writes land in an append-only fashion, a sparse primary index tracks one entry per granule of up to 8,192 rows, and background merge processes consolidate data over time. Partition pruning lets a query skip entire chunks of data it doesn't need. The result is fast ingest and fast reads at the same time, without billing tied to how much gets scanned.

Schema design is arguably the single biggest lever on cost here. Choosing the right sorting key physically groups the rows a query needs next to each other on disk, so a range scan skips past irrelevant data without ever reading it. That sorted layout also compresses better, since neighboring values tend to look alike, and similar values compress harder than random ones.

Data type choice adds up too. Using a narrow type like UInt8 instead of Int64 for a low-cardinality numeric column cuts storage per row substantially. LowCardinality(String) applies dictionary encoding to string columns that only take on a small set of repeated values, shrinking their footprint the same way.

Columnar storage itself produces this advantage: it determines how much data a query touches. A query that reads two columns out of a hundred-column table only touches those two columns' worth of data. A row-oriented system, or a scan-priced platform charging by total bytes touched, pays for the other ninety-eight columns anyway. That's a difference in physical I/O that turns directly into a cost difference under scan-based pricing.

Materialized views built on the AggregatingMergeTree engine push this further: they pre-aggregateompute aggregations during the background merge process itself, so a query pattern that runs thousands of times a day gets answered from pre-aggregated data instead of recomputing from scratch every time. Cost shifts from query time to ingest time, which is a much cheaper place for it to live when the same question gets asked repeatedly.

Pushing partition counts into the thousands spikes metadata overhead on the coordination layer (ClickHouse Keeper) and slows down part management. Monthly partitioning is the safer default for most workloads, rather than partitioning by day or by some finer-grained key that seems appealing at first glance.

And as of ClickHouse 25.8, approximate nearest-neighbor vector search support means embedding vectors can live in the same table as the analytical data they describe. That removes the need for a separate vector database, and with it, a whole extra layer of per-query cost for agentic retrieval workloads that would otherwise have to query two systems instead of one.

Modeling your actual cost before committing to a pricing model

Total cost of ownership has to get calculated against the actual distribution of query durations a workload produces, not against its average load. Billing minimums vanish in an average-load model. They show up in full force the moment you look at the tail, the thousands of two-second queries that each get rounded up to a sixty-second charge.

Four variables decide which pricing model actually wins for a given team, and none of them can be answered from a vendor's pricing page alone.

Query duration distribution matters first. What share of queries finish in under 10 seconds versus running long? Short queries are the ones that suffer worst under a minimum-billing floor, so a workload dominated by them needs to weigh that risk directly.

Query volume over time matters just as much. Are queries clustered into business hours with long idle stretches overnight, or do they run continuously? Per-minute billing that drops to zero on idle time is efficient for the bursty pattern a human workday produces. Agents tend to erase those idle gaps entirely, running around the clock, which changes the math.

Data volume and scan patterns come next. A team running tightly filtered queries against a well-partitioned schema gets rewarded by scan-based pricing. A team running frequent full-table scans gets punished by it, regardless of how many or how few queries it runs in a day.

Agentic share of query traffic rounds out the list. Even a modest layer of agent-driven queries shifts the whole distribution toward the short end and multiplies the total query count, and both of those movements amplify the cost of per-query billing at the same time.

The two crossover thresholds mentioned earlier, 2 TB of uncompressed data or 50 concurrent users, are a starting point for this calculation, not a rule that applies uniformly to every team. A team sitting below either threshold should still check its actual query volume before assuming per-query pricing comes out cheaper. Schema investment remains the strongest lever available to teams staying on a scan-priced platform: partitioning and clustering can cut the data scanned per query by a meaningful fraction, and that reduction applies to every query run afterward, not just the first one.

The practical step, before signing any annual contract, is running a benchmark against a workload's own real query distribution rather than a vendor's reference numbers. Any platform unwilling to support that kind of test on an identical workload is one whose cost claims deserve a second look before they end up on next year's budget.