zzstoatzz.io
This repository has no description
1# read benchmark — 2026-06-12
2
3`scripts/bench-reads`: identical seeded workload (5 flows, 300 flow runs,
4~870 writes via the REST API, seed 1337), then 30 iterations per read
5pattern, sequential, same machine (macOS arm64 M3 Max). weir is a
6ReleaseFast-equivalent debug build? **no — debug build**; python 3.7.4 via
7`uv run`. pattern names mirror `profile_queries.py` in
8`prefectlabs/object-store-orchestration`.
9
10| pattern | weir p50/p95 | python+sqlite p50/p95 | python+postgres p50/p95 |
11|---|---|---|---|
12| seed write rate | 184–202/s | 160/s | 163/s |
13| point_lookup | **0.2 / 0.3** | 1.7 / 2.3 | 2.6 / 3.3 |
14| active_by_state | **1.0 / 1.2** | 4.4 / 5.5 | 4.7 / 5.2 |
15| completed_50 | 5.5 / 5.9 | 5.8 / 6.5 | 6.7 / 7.2 |
16| paginated (offset 100) | 5.5 / 5.6 | 6.0 / 7.5 | 6.8 / 7.0 |
17| count_completed | **0.2 / 0.3** | 1.3 / 1.8 | 2.1 / 2.7 |
18| flow_list | **0.4 / 0.5** | 3.4 / 4.2 | 4.5 / 4.9 |
19
20(milliseconds; python columns from separate runs against fresh stores.)
21
22## reading the table
23
24- **membership-set reads (point, count, active, list) are 4–11× faster**
25 than python against either database — they never leave process memory.
26 this is the cloud prototype's "redis answers the orchestration plane"
27 band, reproduced in miniature.
28- **bulk list reads are nearly tied** (5.5 vs 5.8–6.8 ms). ours loads all
29 candidates then sorts and slices (O(candidates)); sqlite/postgres push
30 LIMIT down. at 268 completed runs the costs coincide; at 10⁵ they won't.
31 the fix when it matters: a created-time zset so the slice happens before
32 the row loads.
33- **write rate: 184–202/s with the repo doing a signed commit + full CAR
34 rewrite on every mutation** — and it still edges out python's 160/s.
35 signing is not the bottleneck (~0.07ms); the CAR rewrite is, and it's the
36 known-naive part (block-level append is the designed fix).
37
38## reference points from the cloud prototype (not comparable, but orienting)
39
40their GKE simulation runs a p95/whale workspace (~440 writes/s continuous,
41millions of terminal rows) over networked GCS + redis:
42`active_by_state` 14ms, deployment reads 5ms, `completed_24h` 279ms,
43delta-merge-heavy task-run scans 869ms. different scale, different
44infrastructure, different question — theirs is "does the three-plane
45architecture hold at whale scale," ours is "does the atproto-canonical
46architecture cost anything at workspace scale." the answer so far: no —
47the appview makes reads competitive-to-faster, and the canonical layer
48taxes writes ~0 at this scale even with naive persistence.
49
50their open item — "we haven't run the same queries against the production
51Postgres" — is partially served here at small scale: python+postgres loses
52to python+sqlite on every pattern at n=300 (network hop dominates), which
53is itself a reminder that these comparisons only mean something within a
54scale class.
55
56## caveats
57
58- single machine, sequential requests, demo scale (300 runs), one run per
59 target. variance not characterized.
60- weir is a Debug build — its numbers would only improve.
61- python servers measured through uvicorn + pydantic validation; that's
62 the product surface, not the database. this benchmarks *architectures
63 end-to-end*, not storage engines.
64- no time-window patterns yet (`completed_1h`-style) — needs TID-range
65 scans or a time zset on our side.