Most statements are far narrower than the table they run against. Strata reads the query, works out which layer of your data can answer it, and sends it there — the slice built for that filter instead of the whole thing. Less scanned, faster back, and nothing in your SQL has to change to get it.
Four inputs, one formula, no quoted multiplier. See the maths ↓
You pay for the data you read and the compute you burn. Read less of both and that part of the bill moves with it.
The narrowed layer is usually the one already prepared for that filter, so the answer arrives with far less work done to find it.
Your statements, tools and habits stay as they are. Point them at Strata and the routing happens underneath.
A saving quoted from someone else's data is worth nothing to you, and it stops being true the moment anything underneath it changes. So the whole calculation is set out below, in full, and the terms you set are the ones only you know — how much of your traffic this can help, how narrow your filters really are, and what your scans cost today.
The scanning part of the bill — not your whole infrastructure bill.
Start here by looking at what your dashboards and jobs actually filter on.
Lower means narrower filters and a bigger saving. An evenly split key gives a small number; a skewed one gives a large one.
Kept below 100% on purpose. Raise it once you have measured your own traffic.
You write the query you were going to write. The only difference is how much of the table has to be touched to answer it.
Every row fetched, filtered after the fact.
Only what can match, read where it already sits.
That 35% is the number from the calculator above, not a claim about your data. Move the slider and it moves. What a filter reads depends entirely on how evenly the key at hand splits your table — and on a skewed key, the honest answer is that the saving is small.
A narrower read does less work, moves less data, and finishes sooner — and the layer that answers is typically the one prepared for that exact filter, sitting closer to where the query runs than the original source is. Both effects land on the same number: the time between asking and having an answer.
It shows up most on the queries that were quietly expensive. A filtered count over a large table is normally the worst offender — it reads everything to count a subset of it — and it is exactly the shape that routing helps most. Unlike the cost, no honest general figure can be put on the time: it depends on your engine, your storage and the distance between them. It is the one number worth measuring rather than modelling, and measuring it is a single command away.
Strata works out from the query itself which layers could answer it, including which key a filter is really testing. Only real identifiers count — a name inside a string is data, not a filter.
The narrowest layer that can answer goes first, with the broader ones behind it as a safety net. Nothing is probed or trialled — the order follows from the query and how the table is registered.
The first layer that answers ends the run. Your result comes back, the timing is recorded, and the layer that produced it is named — so a slow-looking query has an explanation rather than a shrug.
This is the part that decides whether a saving is ever realised. A tool that needs every query rewritten, or a new way of naming tables, saves nothing — it just moves the cost onto whoever has to remember the rules.
That is the whole list. One thing, set once at the connection — not per query, not per table, and not per person.
The statement is untouched, because the routing does not live in the statement. It is a property of the data and the registration around it — so it applies to every query anyone runs, including the ones written after you set it up, and including the ones written by people who have never heard of it.
Routing that happens invisibly is indistinguishable from routing that is not happening, and the formula above is only worth anything if the numbers going into it are real. So every run reports the layer that answered and how long it took, and the same statement can be run against every layer in turn and compared. That turns each term in the calculation into something you measured on your own data.
Every attempt is recorded, including the ones that failed and the ones fallen back from — which is how you find the query that has been reading far more than it needed to, long after the fact.
The choice comes from reading the statement, not from a setting someone has to remember to add — or to remove again when the data changes.
If the narrowest layer cannot be read, the next one answers and the failed attempt is reported rather than hidden, so a fallback never looks like a clean result.
Any layer can be timed on your own query, so "is this faster?" resolves to a measurement on your data rather than a claim from a page.
Each run is logged with the statement as asked for and the statement as executed, so the difference between the two is visible and searchable.
Naming the source, the export or a slice all resolve to the same table, so nobody has to remember which spelling points at which layer.
It reads the same table registration the rest of the platform already maintains, so anything already described there is immediately usable here.
Four terms, one multiplication, and nothing you cannot measure for yourself. If the figure is small, that is a real answer too.