What a question to your data actually costs
Asking became cheap and frequent at the same time — and frequency dominates the bill. We measured where scan actually goes, and the result inverts most people's intuition.
Once the data lives together and a connector exists, asking stops being a project and becomes a habit. That is the point — and it is also the origin of a bill nobody had before.
Every question is a query, and every query reads bytes. The cost is not in the language model: it is in the volume scanned to answer.
Where scan actually goes
We measured this on our own platform, split by what originated the query. The result runs against intuition:
| Origin | Executions | Volume scanned |
|---|---|---|
| AI connector | 2,265 | 143.6 GB |
| Internal media panel | not applicable | 102.7 GB |
| Application (product screens) | 142 | the remainder |
The first two accounted for 96% of all scan. The important reading is not that AI is expensive per question — each of its queries is small. It is that it asks sixteen times more often.
When cost per question falls, the number of questions rises faster than the price drops. The bill is dominated by frequency, not size.
The four costs nobody anticipates
- 01The exploratory question. Before answering, the AI looks at what exists: lists tables, counts rows, checks distinct values. Small, numerous queries that add up.
- 02The dashboard that refreshes itself. Twenty queries updating hourly run close to five hundred times a day, weekends included.
- 03The live filter. A report with interactive filtering usually re-runs every unit on each change of slice — twenty queries per click.
- 04The query with no window. With no date filter, the question scans the entire history. It is the most common way a simple question gets expensive.
The locks that work
None of them requires limiting who can ask, which would mean giving up the gain.
- A mandatory default window. Every query is born with a date slice, and widening it is an explicit choice.
- A concurrency ceiling per project. On one night we measured, a single project scanned 1.47 TB and over a hundred queries were blocked by the ceiling — which did exactly its job.
- Recompute only what has been viewed. A dashboard nobody opened does not need to be fresh.
- Materialise what repeats. A question asked every day should become a prepared table, not a fresh query.
- Measure by actor and origin, not just the total. Without that breakdown, you know you spent and not where.
The measurement mistake that ruins the decision
A methodological warning is worth adding. It is common to measure cost by summing daily consumption and presenting the total. That works for flow — queries executed, events ingested — and does not work for level.
Storage is a level: summing the size of the base every day counts the same object thirty times a month. It is an easy mistake to make, and it inflates perceived cost on exactly the line that grows least.
What this means in practice
The conclusion is not to slow down the questions. It is that a data layer with AI has to be born with query governance: default window, ceiling, a cache with the right key, and measurement by origin.
Without it, the first month is wonderful and the second arrives with an invoice nobody can explain — and the typical reaction is to switch off access, which throws away the gain along with the cost.
In CrazyLeads every query passes through an admission control with a per-plan ceiling, consumption is recorded by channel, origin and actor, and reports recompute only what someone has viewed since the last computation.