The Rollup Nothing Ever Filled
There is a table in this database for storing a daily value of a named metric. Nothing has ever written to it. Every number on every dashboard is therefore computed from live data at the moment you look — which is both the right answer and an expensive one.
Every reporting system eventually faces one decision, and almost every one of them makes it by accident: do you compute the number when somebody asks, or do you compute it once and store it?
The table that was going to store it
Three columns: a date, the name of a metric, and a value. That is the whole shape of a daily rollup, and it is the right shape.
Nothing writes to it. No scheduled command, no job, no service, no controller. It has a migration and a model class and it has never held a row.
So the decision was made by default: everything is computed live.
What computing live gets you
Correctness, and it is not a small thing. A stored figure is a claim about the past that stops being checked. If a transaction is corrected, a stored rollup is wrong until somebody rebuilds it, and nothing about the screen says so.
A live figure cannot drift from its source, because it has no independent existence. Every backdated correction, every reversal, every late invoice is reflected the next time anybody looks.
Computed live — what happens here
- Always agrees with the underlying data
- Backdated corrections appear immediately
- No rebuild job to fail silently
- Cost grows with data volume
- No history of what the number was
Stored daily — the table nobody filled
- Fast, and constant cost
- A frozen figure that can go stale
- Needs a rebuild path and somebody to run it
- Cheap to trend over two years
- Records what you believed on the day
A live number cannot lie about the present and cannot tell you anything about the past. A stored one is the exact opposite, and most people want both without noticing they are different features.
The two things you give up
The first is speed at scale, and it arrives gradually. A dashboard that is instant on two years of data is not instant on ten, and nothing about the design changes on the day it stops being instant — the query is the same query, over more rows.
The second is more interesting: you cannot know what a number used to be.
If somebody asks why the margin figure in March's board pack does not match the same figure computed today, a live system cannot answer. Both numbers are correct against the data as it stood when they were produced, and the data changed. Without a rollup, there is no record of what you believed in March.
That is not a hypothetical for anybody who has ever had a board pack questioned. It is the single most common reporting argument there is, and it is unanswerable by construction here.
What to do about it today
-
Keep the pack you actually published
The exported file is your only record of what the number was. Filing it is the whole of your historical reporting, and it takes a folder and a convention.
-
Date every figure you quote
Not the period — the date it was produced. "Margin for March, as at 4 April" is a defensible sentence; "margin for March" is one that will be contradicted eventually.
-
Expect dashboards to slow before they break
A live computation degrades gradually. If a screen that was instant now takes several seconds, that is the signal, and it arrives long before anything fails.
-
Do not reconcile two live reports run on different days
They will differ, and the difference is not an error in either one. This is the argument that consumes an afternoon and produces nothing.
Two, and the table for the first one already exists
The schema was designed and never wired, which makes this unusually well-defined — the decision it encodes was already made once by somebody.
A nightly rollup, with a rebuild path
A scheduled job writing the day's value for each named metric into the table that is already there. The rebuild path is not optional and is the half that gets forgotten: a stored figure with no way to recompute it becomes permanently wrong the first time anybody backdates a transaction.
As-at reporting on the stored series
What did this number look like on that date, answered from the rollup rather than from a re-query. This is what makes the first item worth building — it turns "why does March disagree" from an argument into a lookup.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. If your dashboards have started to feel slow, that is the signal to raise this.
Talk to us about reporting performanceWhat AWRA OpsHub does today
- Live computation of dashboard and report figures against current data, so nothing can drift from its source.
- Report runs recorded, so who ran what and when is answerable.
- Exports in several formats, which are in practice the only historical record of what a figure was.
- Shared cost and consumption definitions across reports, so two live reports agree with each other when run together.
What it does not do
- Any stored daily metric. The rollup table exists and has never been written to.
- Any as-at view of what a metric was on a past date.
- Any caching or materialisation of dashboard figures.
- Any warning that a report is slow because of data volume.
- A rebuild or backfill path, since there is nothing stored to rebuild.
Not ours, by choice
- Computing live is the correct default and we would not change it wholesale. The gap is the absence of a stored series alongside it, not the presence of live computation.
- This is the ninth surface found in this codebase that exists as structure with nothing wired to it. The pattern is published separately; what is specific here is that the missing wiring encodes a real architectural choice.
- Nothing here is market-specific. The Indian Ocean hub carries this because small multi-entity groups there run long comparison series across years, which is exactly what a live-only system cannot reconstruct.
Four questions about how a number is produced
Is this computed now or stored?
A good answer sounds like
A direct answer.
What it actually means
It decides whether the number can go stale and whether history exists. Ours is computed now, always.
What did this number say last quarter?
A good answer sounds like
A lookup.
What it actually means
If the answer is "run it for last quarter", that is a re-query and it will not match what you published.
If a stored figure is wrong, how is it rebuilt?
A good answer sounds like
A named command.
What it actually means
A stored metric with no rebuild is worse than a live one. Ask before you prefer stored.
What happens to this dashboard at ten times the data?
A good answer sounds like
An honest answer.
What it actually means
Live computation degrades gradually and nobody notices the day it stops being fast.
Our position
Live computation is the right default and we are keeping it. File every pack you publish, date every figure you quote by the day it was produced, and never reconcile two live reports run a week apart. If you need to answer what a number was rather than what it is, that is a build — and the table it would write to has been sitting there unused since it was created.
File the pack, date the figure
Two habits, no software, and between them they answer the question a live reporting system structurally cannot.
Talk about reporting historyFrequently asked questions
Does this mean my dashboards will get slow?
Eventually, gradually, and in proportion to how much data you accumulate. It is a well-understood trade rather than a defect, and the signal is a screen that used to be instant taking a few seconds.
Can I reproduce a report exactly as it ran last month?
Only from the export you kept. Re-running it against today's data produces today's answer for last month's period, which is a different thing and will differ wherever anything was corrected.
Why is the table still there if nothing uses it?
The same reason as the other inert surfaces in this product: deleting it is a decision rather than a cleanup, and it is the schema a rollup would use. What was missing was a record that it is unwired, and now there is one.
