Three claims, in the order they matter to whoever signs it off. What it takes off the
bill, what it takes off the clock, and — the part that decides whether either
happens — how much work it puts on your team to get.
01 Where the saving comes from
Almost every platform prices a query on what it had to read: bytes scanned, files
opened, warehouse seconds. That number is set by how much of the table a statement
touches — and most statements touch far more than they need.
1
The filter does the narrowing
A statement that matches a fraction of a table does not need to read the rest. This is the dominant effect, and it is where nearly all of the saving sits.most of it
2
The data is already split that way
The layer that answers is organised by the key the filter tests, so the narrow read is a contiguous slice rather than a scan that discards what it finds.structural
3
Nothing new is stored to get it
No copies, no materialised duplicates, no second version going stale. The saving is not traded against a new storage bill.no cost
Working out yours
The saving is a product of four things: what scanning costs you now, how much of your
traffic filters on something the data is split by, how narrow those filters really
are, and how much of the reduction survives contact with reality. The first is on
your bill. The second you can estimate from your busiest dashboards. The third is the
one that decides everything, and only your data can answer it.
The saving holds when a key splits your data reasonably evenly in front of the
filter. It shrinks when the key is skewed and one value covers most of the rows,
because then the slice is most of the table. Both cases exist in real data,
often in the same schema. Which one you are in is worth measuring rather than
assuming, and measuring it is the first thing to do.
02 Why the answer arrives sooner
Latency follows volume: less to read is less work to do before there is something to
return. On top of that, the layer that answers is usually held nearer to where the
query runs than the original source is, so the bytes that are read travel a shorter
distance. The two effects compound, and both land on the same number — time to
answer.
It helps the worst queries most. A filtered count over a large table used to read everything to count a subset of it. That is the shape routing helps most, and usually the one someone has already complained about.
It helps the ones nobody wrote on purpose. A dashboard that refreshes every minute and filters on one column is the same query hundreds of times an hour. Routing applies to each of them without anyone changing the dashboard.
Latency is the one to measure, not model. Unlike cost, no general figure survives the differences between engines, storage and distances. Two numbers are needed: the same statement against the whole table, and against the narrow layer. Both are one command away.
So the page does not quote a speed-up. It gives you the means to produce your own —
and reports the layer that answered, with its timing, on every run in the meantime.
03 The whole change, itemised
A saving that requires rewriting queries is not a saving; it is a project. So this is
the complete list of what the adoption involves, and there is exactly one item on it.
what changes
Where the statements are sent.
Set once, at the connection. Not per query, not per table, not per person, and not
again next quarter.
what does not
The SQL, exactly as written.
The names you already use.
Dashboards, notebooks, scheduled jobs.
The shape of what comes back.
Anything to keep in step by hand.
Any new thing to learn before the first query runs.
before
SELECT region, count(*) AS orders
FROM your_table
WHERE key = 'value'
GROUP BY 1;
-- points at the table itself
after
SELECT region, count(*) AS orders
FROM your_table
WHERE key = 'value'
GROUP BY 1;
-- points at Strata instead
That is the entire migration. The statement text is byte-identical, because the
routing is not expressed in the statement — it is a property of how the data is
arranged and described. Which means it also applies to queries written later, by
people who have never heard of it, on tools nobody thought to update.
why the effort matters as much as the saving
Anything that asks people to remember a rule is really asking them not to forget it.
A hint added to one query is missed in the next thousand; a convention documented in
a wiki drifts the moment the wiki does. Putting the decision in the routing layer
instead means it is made correctly the first time, by everyone, including whoever
joins next year.
04 What it does not do
Worth as much as what it does, since it is what you will be asked about.
✕
It does not move or copy your data
There is no materialisation to keep fresh and no duplicate to fall out of date. It reads what is already there, from where it already is.
✕
It does not change what your query returns
The rows and columns coming back are the ones the statement asks for. It changes where they were read from, not what they are.
✕
It does not rescue a wrongly written query
A filter that cannot match anything still matches nothing, and a query that genuinely needs every row still reads every row. Routing narrows reads; it does not fix the question.
✕
It does not guarantee a saving
On a skewed key, or traffic that is already narrow, the honest answer is that there is little to win. It reports which case you are in rather than promising otherwise.
✕
It does not ask you to trust it
Every run names the layer that answered, with its timing, and the alternatives can be timed on the same statement. The audit trail shows both what was asked for and what ran.
05 The things you are about to ask
Do we have to change our queries?
No. You keep writing against the names you already use. There is no hint syntax, no annotated view to remember, and no wrapper to put around your SQL.
What does it do to the cluster?
It sends a statement somewhere narrower and returns what came back. It does not create tables, does not move data, and does not change how anything is registered or stored.
What if it picks the wrong layer?
You will see it: the layer that answered is reported on every run, with its timing, and every alternative can be timed on the same statement. A wrong choice shows up as a number, not as a mystery.
How do we know the saving is real before committing?
Put your own numbers into the calculation on the home page, then measure two runs — the same statement against the whole table and against the narrow layer. If the difference is small, that tells you something worth knowing before anyone signs anything.
What does it depend on?
The table registration the platform already maintains. Anything described there is immediately usable, and nothing needs describing twice or kept in step by hand.
See it on a table of your own.Run a statement, watch which layer answers, and time the alternatives.