Database Engine2026Active

ivm

SQL views that stay correct by applying only what changed.

An embeddable Incremental View Maintenance engine. Declare a SQL view once, mutate the base tables, and the view stays correct by applying only the deltas, never recomputing. It implements the DBSP model, where every row carries a signed weight (insert +1, delete −1), so what streaming databases run as a separate service becomes an importable library.

livelast push CI passing ·

~/ivm

Project Telemetry

Updates / sec

37K

p99 latency

43 µs

vs recompute

≈3,600×

Oracle tests

570

Run it in your browser

A pocket version of the engine. Change the base table and the view is patched by that one row's ±1 weight, then checked against a full recompute.

SELECT region, COUNT(*), SUM(amount), MIN(amount) FROM sales GROUP BY region

sales · base table · 6 rows
idregionamountdelete
1north42
2south25
3east12
4north18
5south40
6east33
view · maintained from deltas
regioncountsummin
east24512
north26018
south26525

Insert or delete a row. Each change is one signed delta, applied to one group.

How it works

~/ivm/architecture · step 1/4

01

base-table mutations

02

Z-set deltas (±1)

03

operator graph

04

join / aggregate state

05

view deltas

06

oracle check

01Incremental projection, filter, INNER/LEFT/RIGHT/FULL joins and GROUP BY with COUNT/SUM/AVG/MIN/MAX.
02Handles the retractions that break naive versions: recovering the next MIN/MAX after the current one is deleted, and flipping outer-join rows between matched and NULL-padded.
03A wrong aggregate still looks like a valid number, so an independent recompute oracle shares no code with the incremental path. 570 tests assert incremental == oracle after every delta.
0437,000 single-row updates/sec at p50 21 µs / p99 43 µs on a 50K-row base: ≈3,600× faster than recompute, still ≈33× when 2% of the base changes.

Project Info

DomainDatabases
RoleAuthor
Year2026
StatusActive

Tech Stack

PythonSQLSQLiteDBSPpytestGitHub Actions