Performance

Measured reads, writes, live streams, and revalidation at 100,000, 300,000, and 1,000,000 objects of one type, on a 4-core machine. No tuning; the numbers describe this machine and this setup, nothing more.

Measured on 2026-10-25. Everything measured goes through the HTTP API.

In short

• Lookups by id, link traversals, and linked filters use indexes and stay in single-digit milliseconds at every size.
• Filters and sorts on properties scan the type’s objects. There are no property indexes yet. Filters that find their first page early stay cheap; those that must look at every object, such as starts_with or order_by on a property, grow with the type.
• Writes do not depend on the size: about 800 object creations, 750 links, or 650 actions per second with 8 clients on these 4 cores, and less with 32, as the clients contend for the cores and the 20 pooled connections. Actions refuse a concurrent change to an object they read with 409 version_conflict by design; with random targets among this many objects, none occurred.
• A type’s validation summary counts every object of the type, so a schema change that changes the rules takes longer to answer as the type grows, without reading any object’s data.
• Revalidation after a rules change rechecks about 3,500 objects per second at every size: a million objects in under 5 minutes.
• Catching up a live stream ran at 40,000 to 48,000 events per second, the first event within 20 ms, at every size.

Revalidation

After a rules change, a background job rechecks every object of the type. Measured on the same machine and setup, from the rules change to the job’s last type.validation event, with every object valid:

The job walks the type once, in batches found from a cursor. Its progress events count the whole type, so it sends them at most once a second, and less often on large types: after each one it waits nine times as long as that count took.

In the first run, before this was fixed, revalidation was quadratic: after each batch of 200 objects the job recounted the whole type for its progress event, and its query for the next batch scanned past every object already checked (301 ms per batch at a million objects, against 1.8 ms from a cursor). Its rate fell from 521 objects/s at 120,000 objects to 217 at 320,000 and 79 at 1,000,000, where 30 minutes covered 14% of the type. The per-size results below keep those numbers.

Machine

The server, Postgres, and the benchmark client share these cores, and HTTP goes over loopback TCP.

Setup

One organization with two object types: asset (name, a status enum, priority an integer 1-5, cost a double, site_code) and site (code, a region enum). Each asset has a many_to_one link to one of a hundredth as many sites, and the writes add many_to_many links between assets. The bulk of each size is inserted directly into Postgres in the form the API stores, then ANALYZEd. Each size’s revalidation rechecks every object, the bulk ones included.

• Reads come from one sequential client, an agent with view_objects and an API token, so row level security and the object access policy apply: 200 calls each after a warm-up, or as many as fit in a minute (n below). Their parameters are spread over the bulk objects.
• Writes come from the owner, with a session token. Each client sends its next request when the last one answers; each run lasts 10 seconds.

Results

100,000 assets

Before the runs: 100000 assets, 1000 sites, 100000 links, 4 events; database 147 MiB. Bulk top-up took 7.5 s.

Reads, one client, as an agent with view_objects (ms):

Writes as the owner, 10 s per run:

Live-stream catch-up: a new stream with a cursor from before the writes received their 70719 events in 1.75 s (40328 events/s; first after 11 ms).

Revalidation (before the fix): a rules change (max on cost) answered in 316 ms; the maintenance job then rechecked all 120384 assets, every one valid, in 231 s (521 objects/s).

300,000 assets

Before the runs: 300000 assets, 3000 sites, 298901 links, 71326 events; database 519 MiB. Bulk top-up took 16.1 s.

Reads, one client, as an agent with view_objects (ms):

Writes as the owner, 10 s per run:

Live-stream catch-up: a new stream with a cursor from before the writes received their 64220 events in 1.35 s (47669 events/s; first after 16 ms).

Revalidation (before the fix): a rules change (max on cost) answered in 994 ms; the maintenance job then rechecked all 319394 assets, every one valid, in 1471 s (217 objects/s).

1,000,000 assets

Before the runs: 1000000 assets, 10000 sites, 995739 links, 137144 events; database 1672 MiB. Bulk top-up took 55.3 s.

Reads, one client, as an agent with view_objects (ms):

Writes as the owner, 10 s per run:

Live-stream catch-up: a new stream with a cursor from before the writes received their 67112 events in 1.39 s (48326 events/s; first after 12 ms).

Revalidation (before the fix): a rules change (max on cost) answered in 2480 ms; the maintenance job had rechecked 142600 of 1021024 assets when the run stopped waiting, after 1805 s (79 objects/s).