Posts on Precomputing.com

Introduction

Fri, 25 Sep 2026 00:00:00 +0000

Answers ready before you ask: one small language keeps counts, percentiles, candles, invoices and log dashboards current in a SQLite file as the data arrives.

Precomputing is a project to make answers cheap. A short policy names the streams of events you have and the answers you want ready, and says how long each level of detail should live. From then on every event updates those answers the moment it arrives, so a question becomes a lookup, and old detail fades on the schedule you set.

How It Works

Fri, 25 Sep 2026 00:00:00 +0000

The idea. Decide the questions first. Keep their answers current as each event arrives, in one SQLite file, and let raw detail fade on a schedule while unusual events stay whole.

Before and After

Today a system that collects events usually keeps all of them and computes each answer when someone asks. A dashboard scans the last hour on every refresh. An invoice adds up a month of requests at the month’s end. Precomputing moves the work to the moment each event arrives:

The Policy Language

Fri, 25 Sep 2026 00:00:00 +0000

A policy is a short text file. It names the streams of events you have and the answers to keep ready, and says how long each level of detail survives.

The compiler turns it into plain SQLite, and the Engine runs it as it is. This post walks through a policy line by line, and shows what each line becomes in the file.

API Latency Case Study: A Million Requests Kept as Ready Answers Inside SQLite

Tue, 29 Sep 2026 00:00:00 +0000

A small web service that already keeps its data in SQLite wants the usual answers about its API: how many requests each endpoint gets, how long they take on average, and the p99. The simple way is a table with a row per request, scanned whenever someone looks. In the SQL demo the service keeps a compiled Precomputing policy in the same SQLite instead, and the answers stay current on every insert.

Market Data Case Study: Four Million Trades Turned Into Candles, Checked After a Pulled Plug

Mon, 28 Sep 2026 00:00:00 +0000

A stock chart is made of candles: for each minute, the first price, the highest, the lowest and the last, with the volume traded. A candle is a window summary, the same kind of summary Precomputing keeps for API latency, only in a field every investor knows. In the Engine demo a trading day of stock trades goes through the Engine, which keeps 1-second, 1-minute and 1-hour candles and a quote board ready in its SQLite file, and writes the file five times a second.

AI Usage Billing Case Study: A Month of Invoices That Match a Recount to the Billionth of a Dollar

Sun, 27 Sep 2026 00:00:00 +0000

An AI product that bills by the token has to count every request exactly once, even when the network does not cooperate. Clients retry, and a retry can arrive through a different gateway. A gateway that loses its link holds its reports and sends them hours later. A queue can stick at the end of the month, after the invoices are out. In the Meter demo the product’s gateways report every request to one meter, a compiled Precomputing policy inside SQLite, and the invoices are one SQL view over totals the meter keeps ready.

Web Shop Logs Case Study: A Dashboard Sent Upstream in 120 Times Fewer Bytes

Sat, 26 Sep 2026 00:00:00 +0000

A web shop sends its logs to a log platform so a dashboard can show requests, latency, errors, payments and revenue, and so someone can search the lines when things go wrong. The platform charges by the gigabyte ingested and by the million lines indexed, and many of those lines are never read. In the Logs demo a log reducer sits next to the shop’s services. It learns each kind of line as it arrives, keeps every line on site for 48 hours, and sends upstream only the answers the dashboard shows, the errors and anything new.

Inside the Engine: Same Answers, 12 to 17 Times Faster

Fri, 25 Sep 2026 00:00:00 +0000

The SQL runtime does all its work inside SQLite: every insert runs a trigger that updates every summary, sketch and answer the policy asks for. That is simple and it runs anywhere, but a trigger pays SQLite’s price for each small update. The Engine runs the same policy in Go, keeps the recent work in memory and writes what changed to the same SQLite file in one transaction at every checkpoint. Its answers are the same, to the last bit, and on Demo 2’s trades it is 12 to 17 times faster.

Next Applications: Eight Places Where Answers Kept Ready Could Fit

Fri, 25 Sep 2026 00:00:00 +0000

The four case studies share one pattern. The questions are known in advance and the events arrive as a stream, so the answers can be kept current as each event lands, while raw detail stays only as long as it is useful. API monitoring, market data, usage billing and logs came first because the demos cover them.

The pattern turns up in many more places. None of the eight below has been tested, and none runs Precomputing today. This post sets out what each would ask of the platform, and which parts already carry over from the demos. It is a map for choosing pilots, ideally together with the people who run these systems.

One File: The SQLite Layout Both Runtimes Write

Fri, 25 Sep 2026 00:00:00 +0000

A Precomputing file is an ordinary SQLite file. Any SQLite tool opens it, the same SQL works on it whichever runtime wrote it, and it carries its own policy, so a reader never has to guess what is inside. This post walks through the layout for one stream.

What Is in the File

For Demo 1’s stream, latency, with the key endpoint and the value ms: