Skip to content
sqlite-predict

sqlite-predict

Forecasting, anomaly detection, and prediction as SQL primitives. Runs wherever SQLite already does.
Get startedView on GitHub

Prediction as a SQL primitive

Section titled “Prediction as a SQL primitive”

forecast(), detect_anomalies(), and predict() become functions you call over your own rows: forecast and detect_anomalies are aggregates that compose with WHERE, joins, and GROUP BY; predict is a scalar that composes with row-level SELECT, WHERE, and joins, so ORMs and query builders work unchanged. The core is one small C99 file with no dependencies, so it runs in your app, on a phone, in the browser, or in the per-database state an AI agent keeps.

-- forecast a metric 24 steps ahead: plain SQL supplies the rows
SELECT forecast(ts, value, 24) FROM readings;


-- GROUP BY splits the series. WHERE, joins, and bound parameters
-- compose, so ORMs and query builders work unchanged.
SELECT city, forecast(ts, value, 24) FROM readings GROUP BY city;


-- and when a stronger model is too heavy to call per query:
-- distill it once into a few-KB native student that lives in your
-- database, then serve the student in microseconds
SELECT model_id FROM distill_forecast('SELECT * FROM windows',
  '{"context":96,"horizon":24,"student_id":"traffic-v1"}');
SELECT forecast(ts, value, 24, '{"model":"traffic-v1"}') FROM readings;

Install anywhere

pip install sqlite-predict · npm install sqlite-predict · cargo add sqlite-predict

Zero dependencies

Pure C99. No ONNX runtime, no GPU, no network at serve time.

Distill once, serve forever

Compress your own model, or a foundation model you are licensed to distill, into a few-KB student that lives in your database and snapshots, forks, and syncs with it. See Distillation.

Measured, reproducible numbers

~0.89 MASE distilled forecasting, SOTA-level anomaly detection, calibrated intervals. See Benchmarks.

The pipeline, the meter, or a SQL function

Section titled “The pipeline, the meter, or a SQL function”

Every way to predict on tables makes you pick one: build the pipeline, pay the meter, or call a function where the data already lives.

Why SELECT forecast(…)

A SQL function at your data. Zero-shot in seconds; distill a teacher once and serve its student in microseconds, forever. No pipeline, no endpoint, no meter.

  • FIRST PREDICTIONSECONDS
  • TRAININGNONE, OR ONCE IN SECONDS
  • SERVINGIN-PROCESS, MICROSECONDS
  • DATA LEAVES THE DBNEVER
  • COST AT VOLUMEFLAT, NEAR ZERO

Why not an ML pipeline?

Great algorithms. The cost is the pipeline around them: export, features, container, deploy.

  • FIRST PREDICTIONMONTHS
  • TRAININGPER DATASET, YOUR CLUSTER
  • SERVINGYOUR INFRA, MS
  • DATA LEAVES THE DBTO THE PIPELINE
  • COST AT VOLUMEYOUR CLUSTER

Why not AutoML?

Automates the fit. Keeps the pipeline, the infrastructure, and the wait before a first answer.

  • FIRST PREDICTIONWEEKS
  • TRAININGPER DATASET, MANAGED
  • SERVINGDEPLOYED ENDPOINT
  • DATA LEAVES THE DBUSUALLY, TO A CLOUD
  • COST AT VOLUMEYOUR CLUSTER

Why not a prediction API?

Seconds to a first answer, and the frontier lives here. But your rows ride along on every metered call.

  • FIRST PREDICTIONSECONDS
  • TRAININGHIDDEN IN EVERY CALL
  • SERVINGNETWORK ROUND-TRIP
  • DATA LEAVES THE DBEVERY CALL
  • COST AT VOLUMELINEAR, THEIR INVOICE

The honest asterisk: a frontier model called zero-shot is still the accuracy ceiling. The benchmarks measure the gap; a distilled student typically gives up about half a point of accuracy against its teacher.