Live Demo: SQL

Three hours of API traffic for a small web service run through a compiled Precomputing policy, inside SQLite, right here in your browser. The same requests are kept two ways: every request in a plain table, and the answers in the precomputed file. Watch one grow with traffic and the other with time, then check that the answers stayed right.

Simulated traffic, real SQLite. The requests come from a fixed script. The policy is compiled by the real compiler, and the SQL runs in SQLite’s own WebAssembly build.

How to Run It

1. Press Play. Requests start arriving at five endpoints, about 100 a second. Three simulated hours pass in about a minute on a recent computer.
2. Make trouble. Add a slow request, or start an outage on any endpoint, and watch the p99 chart and the log.
3. Review the results. The run finishes at full speed. Every answer is set next to the exact value computed from every request.
4. Ask the file. Run a ready-made SQL question or write your own, then download the file.

On a wide screen the demo can use the whole window: open it full screen.

The Controls

The Scenario

A small web service on 28 September 2026, from 09:00 to 12:00 UTC. Its five endpoints have their own usual latency: /api/search about 30 ms, /api/login 45 ms, /api/cart 80 ms, /api/checkout 120 ms and /api/report 250 ms, each spread the way real latencies spread. Along the way the script plants 300 slow requests, and at 10:30 /api/checkout runs six times slower for two minutes.

The Policy

stream latency {
  key   endpoint text
  value ms real

  raw     keep 5m                        # recent requests stay whole for five minutes
  rollup  10s keep 24h                   # then 10-second summaries for a day
  rollup  1m  keep 30d  quantiles ms     # 1-minute summaries with p99 for a month
  rollup  1h  keep 1y   quantiles ms     # hourly summaries for a year

  samples 3 per 1m                       # three whole requests kept from every minute
  anomalies ms log z > 4 keep 20 per 1m  # unusually slow or fast requests kept whole
}

precompute requests = count(latency) by endpoint
precompute avg_ms   = avg(latency.ms) by endpoint
precompute p99_ms   = p99(latency.ms) by endpoint

The compiler turns these lines into 147 lines of SQL: the tables, one view per answer and one trigger that does the work on every insert. The demo ships that SQL precompiled and loads the compiler only when you press Compile.

What the Numbers Mean

• Raw table, every request kept: the same requests in a plain SQLite table, as an application would keep them without Precomputing. It is there to compare with, and to check the answers against.
• Precomputed file: everything the policy keeps. Whole requests for the last five minutes, window summaries at 10 seconds, 1 minute and 1 hour, quantile sketches, three samples a minute, the unusual requests and the ready answers.
• Smaller: the raw table’s size divided by the file’s. Both are SQLite pages in use.
• p99 difference: how far the p99 read from the sketches is from the exact p99 computed from every request. The policy promises 1%.
• Unusual requests kept whole: requests far from their endpoint’s usual latency, kept with their z-score. A storm keeps at most 20 a minute per endpoint, and every unusual request is still counted in its window.

Things to Try

1. Let one run finish untouched. Press Play and wait, or press Review the results at once. The run ends with 1,080,198 requests, a 4.5 MB file against 35.2 MB of raw rows, and every p99 within 0.65%.
2. Turn the traffic up. At 200 requests a second the raw table doubles. The precomputed file grows much less, because a summary costs the same whether its minute held 10 requests or 10,000.
3. Start an outage and watch the baseline. The anomaly baseline ignores unusual requests, so an outage stays unusual while it lasts. Look for the red band on the p99 chart, and for the requests kept whole in Unusual requests at the end.
4. Add slow requests. Each one should appear among the requests kept whole. The results say how many of yours were kept.
5. Ask the file. Try “p99 per hour”, which reads the 1-minute sketches of each hour, or “Bytes per table” to see where the space goes.
6. Change the policy. In Try the compiler, change keep 5m to keep 1h or add precompute max_ms = max(latency.ms) by endpoint, and compile.

If It Does Not Start

The demo works in any current Chrome, Edge, Firefox or Safari, on a computer or a phone, with JavaScript switched on. It needs WebAssembly, which all of them support. SQLite comes with the page, 1.5 MB (577 KB compressed), and runs inside it. If the demo says it could not start, try another browser, or allow scripts on this page if an extension blocks them.

In testing no check has failed. If one ever does, the results say so in red, and the project would be glad to hear about it through the contact page.

What Is Real Here

Real:

• SQLite 3.53.4, SQLite’s own WebAssembly build, unchanged.
• The compiled SQL, from the real compiler, the same SQL the command line prints for this policy.
• Both files, byte for byte, and every check against the raw table.

Simulated:

• The web service and its requests. They follow a fixed script, so a run left alone ends with the numbers on the Platform page.
• Time: three hours pass in about a minute on a recent computer.

The API latency case study follows a run from start to finish.