Precomputing: Keeps Dashboard Answers Ready in a SQLite File as the Data Arrives
Most dashboards ask the same few questions all day long: requests per endpoint, month-to-date usage for one customer, error rates by status code. The usual setup recounts raw rows from scratch on every refresh, or ships every row to a hosted analytics service that bills by the gigabyte. A dashboard that needs to answer quickly on demand either waits for a database query to finish, or pays for a service that stores everything.
Precomputing does the counting once, as the data comes in. You write a short policy that names the answers you want: the dimensions, the retention times, the granularity. Then you say how long each level of detail should live. Precomputing compiles that policy to plain SQLite triggers, so every INSERT keeps those answers current, and reading one answer is a single lookup. Old detail fades on your schedule; unusual events are kept whole.
The nice part for app developers is that it’s still just SQLite. Any SQLite tool opens the file and sees the answers as plain views with no separate system running beside them. The performance of triggers hits a wall, and when it does, you can swap in a Go engine that runs the same policy and writes the same file, byte for byte. Your dashboard sees no difference.
The same language drives a usage meter for billing, where a retried request counts once and a closed month stays closed. It powers a log reducer that keeps every line on your machine and sends upstream only what a dashboard needs. An AI agent can ask the precomputed file for answers over MCP, instead of reading raw rows and doing the math itself.
For app teams that run their own infrastructure, precomputing saves the step of shipping data somewhere else to get answers. You keep the data, define what you want to know, and the system maintains those answers as new data arrives. The tradeoff is obvious: you can’t explore the data freely after precomputation, only ask the questions you defined. But for dashboards, that’s exactly what you want. You know what your users need to see, and every answer is fast.
The architecture is clean for teams that care about that. Triggers keep the policy close to the data; a Go engine can run the same policy with more horsepower if needed. Either way, the underlying SQLite file is just a file, portable and queryable with any tool. You’re not locked into a service or a platform.
Precomputing is version 0.1, checked hard on simulated data and not yet deployed to anyone’s production traffic. The platform page covers the full picture. The Policy Language walks through a policy line by line, showing how to name answers and set retention rules. The SQL demo puts three hours of simulated API traffic through a compiled policy in SQLite’s WebAssembly build, right in your browser, so you can see what the answers look like and how they update as traffic flows in.
For anyone running a dashboard on a machine they control, or using SQLite on the backend, precomputing trades a one-time policy for the ability to answer dashboard questions at machine speed without running a separate service. The answers stay fresh as data arrives, stale data drops automatically, and your dashboard gets what it asks for instantly.