100%

About

This app runs the workload of a customer support desk run by agents: hundreds of customer accounts, each with a team of agents and people watching live queries of its tickets.

Each block is one customer org, and each box in it is one live query. The same queries sit in the same places in every block. Rindle keeps every result up to date as the data changes, without re-running the query.
Four agents per org watch those queries and do nothing until one changes:
Each block's tables sit at its left and its agents under it. A write runs into the tables, from outside for a customer or from an agent, and a line runs out of them to every query the write moved. A query an agent watches tells it, the agent's outline runs while it thinks, and then it writes back in.
The agents add and remove queries themselves: Triage registers a watch on each ticket it takes, which appears in grey at the bottom of the block, and the Responder drops it when the customer says it's fixed.
The sliders at the bottomunder Workload, at the bottom, set the desk: how many orgs, how many queries each can have open, how often each writes. They are shared, so every viewer sees the same settings.
Zoom in to read the tickets change. Zoom further in for each query's code, and ⚡ to write in as a customer yourself.
HoverTap any number at the top to see what it measures.

New live query — for everyone on this board

project

Connecting…

The Fleet Board· walkthrough

The server model

Re-run it, or keep it?

A server that keeps live queries fresh has two choices. It can re-run every query on a timer. Or it can keep each result and apply every write to it as a change. This board holds thousands of an issue tracker's live queries on one rindled, and prices both.

01 polling pays per query, per interval 02 IVM pays per write 03 which costs less depends on both

01 · the workloadshared/app-def.ts · trimmed

const issueList = defineQuery("issue-list", projectArg,
  ({ project }) =>
    q.issue
      .where(and(
        fieldCondition("project", eq(project)),
        open(),
      ))
      .orderBy("updated", "desc")
      .limit(12)
      .sub("owner", rels.issueAssignee, person)
      .sub("latest", rels.issueComments,
           newestComments(2)),
);

01 / The workload

An issue tracker's open tabs.

Every card on the board is one live query that someone in a tracker has open: a project's open issues, a kanban board, a backlog, one issue's thread, a status dashboard, a saved search. There are 320 projects, 51,823 issues and 11 query shapes.

The connected users and queries / user sliders hold up to 20,000 of them at once, all on one rindled. Every viewer of this page shares that roster, so a second viewer adds subscriptions but no new pipelines.

02 · keep it freshtwo ways

// Polling: re-run every query on a timer.
setInterval(() => {
  for (const q of roster) {
    // read the whole query again
    const rows = db.all(q.sql);
    if (changed(q, rows)) send(q, rows);
  }
}, interval);

// IVM: read each query once,
// then apply each write to it.
for (const q of roster) q.materialize();
// each commit → a delta for each query
// that it changes

02 / Two ways to keep it fresh

Polling pays for reads. IVM pays for writes.

A poller re-runs every query on every interval, whether anything changed or not. Its cost is the rows each query reads, times the number of queries, times the polls per second. The write rate does not change it.

An incremental engine runs each query once. After that, it pushes each committed row through only the queries that row can change. Its cost follows the write rate. The size of a query matters much less, because a write moves a few rows of a result, not all of it.

03 / Where each wins

A map of the trade.

The chart puts the two costs on one map. Two of its axes are controls on the board: writes per second is users × writes / user / min, and the polling interval is the equiv qps stat, which you click for 100 ms, 1 s or 5 s. The third axis, how many rows each poll reads, is the bands.

Live queries

Point at the map to see how large a query must be before IVM costs less there.

Query size

Dashed box

The range measured on Fly. Everything outside it is extrapolated.

Assumes

Maintaining a query costs the same per write however large it is. That is close for a window a write moves one row of. It is not true of every shape.

Not counted

04 / Read the board

What polling would ask for.

Equiv QPS @1s is the query rate a database would have to serve to keep every card on the board fresh by polling: live queries divided by the interval. Its hover says how many of those polls would find anything, from what the board has seen change.

Turn writes / user / min up. rindled's cores rise and the query rate does not.
Turn connected users or queries / user up. Every new query is another poll on every interval.
Click the stat. A longer interval divides the rate, and makes every view that much staler.
Initial puts the board back where it starts, as it does on its own after five minutes with nobody watching. Realistic is a busy hour at a mid-size tracker. Stress pins every slider to its ceiling, every write aimed at a watched query.

These queries are light: indexed lookups under a limit, about a hundred rows read per poll. The board sits on the chart's 1× line, where polling does best.

05 · what is measuredand what is not

rindled: Its own process CPU, sampled live on its machine.
Polling: On the board, a query rate: live queries over the interval. On the map, modelled from per-query costs measured on the same machine type, checked against a real poll loop within ~15%.
The map: Fly performance-4x, September 2026. Rows read are SQLite scan statistics over the poller's SQL.

05 / Keep it honest

The poller gets its best case.

On the map, the poller is warm, memory-mapped SQLite with prepared statements, good indexes and hand-written SQL, in the same process as its data: no network, no connection, and one poll per query however many clients watch it. It is charged for committing the same writes rindled commits. Neither side is charged for sending results to viewers.

Polling is not run live, because a second SQLite would share rindled's CPU and spoil its number.

The trade

Polling pays for every query, every interval. IVM pays for every write.

CPU is not the only difference. A maintained view changes when the write lands, not at the next poll, and every view moves together.