potluckdb performance evidence

Checked and measured 30 September 2026. Homepage numbers use release 0.1.0-rc.df3809a06183, published 23 September. These are observed results, not service-level guarantees.

What the page measures

Bulk ingestion and the controlled prefetch comparison are secondary evidence. They are expandable on the homepage rather than competing headline metrics. Provider read/write timings describe local operations in each configuration, not network access to that provider.

Published SDK performance run

Source: release assets (private source reviewed; not publicly accessible). The six performance-*.json files and performance-execution.json were retrieved with authenticated GitHub access. Full unchanged result objects are in ../assets/release-bcf64a5756bb23c9/story-evidence.json; chart values are in benchmark-data.csv.

Environment: Linux, EC2 c7i.2xlarge, us-east-1, Python 3.14.7, installed bundled native SDK. Full profile: 20,000 seeded rows, 256-byte payloads, 1,000-row insertion batches, 400 single-operation samples, and one 100-row steady-state push.

The expandable charts show every configuration. They are not a cloud-provider leaderboard: local durability, scheduling and run variance contribute to these results. The directory configuration has no network. The S3 write p99 is 1.698 ms; the homepage rounds to two decimal places.

The S3 100-row push submitted 97,331 bytes, with 5 object PUTs, 1 coordination update, 0 GETs and 0 LISTs. It measures publication, not another device receiving, adopting and rendering the change. Delta illustrations show a concept, not a measured ratio of unchanged to changed pages.

The published small-table aggregation was 1.581 ms with SQLite, 31.813 ms for the first DuckDB call and 1.569 ms warm with DuckDB. It does not establish a meaningful DuckDB speed advantage; the homepage instead identifies the separate million-row experiment below.

Browser core size

The official browser tarball's SHA-256 was checked against its published checksum. potluckdb_runtime_interface_wasm.wasm contains 2,615,633 raw bytes. Node.js 24's Brotli compressor produced:

791,966 bytes is approximately 792 decimal kB, or 773 KiB. This excludes JavaScript glue, workers, storage adapters, application code and the optional DuckDB engine. First usable screen time also depends on transfer, compilation, storage initialization and application work; it was not measured here. See raw sizing result and measurement script (retained in the source workspace).

Local DuckDB comparison

Same release, official Windows Python SDK and analytics wheel with published SHA-256 checksums verified. Windows 11 build 26200, AMD64 Family 25 Model 97 Stepping 2, Python 3.12.14. Native SDK, local filesystem, no cloud access. One million rows of integer data, grouped into 100 results.

SELECT region, count(*), sum(amount * units), min(amount), max(amount)
FROM events
GROUP BY region
ORDER BY region;

Engine order alternated between warm trials. Every result was compared for equality. The measured ratio is 5.241×, displayed as 5.2×. This is a workload-specific, single-machine comparison; other queries and data distributions can favor either engine. The seed uses one recursive-CTE INSERT and must not be reported as the published per-row ingestion benchmark. Native results are not browser results.

Controlled prefetch experiment

The actual released native SDK used a local in-memory object adapter with an artificial 20 ms delay per successful object GET. Four fresh read-only snapshots were opened and fully scanned in each mode; ordering alternated. Dataset: 4,096 rows, each with a highly compressible 1,024-character payload. Both modes used a remote read-concurrency limit of 32. The total includes opening the snapshot and its full scan, not just a scan after an uncounted warm-up.

The comparison is 4.878× in this controlled workload, not an S3 or R2 latency claim. Prefetch requests more objects and bytes; its benefit depends on access patterns, latency and budgets. Count and payload-length totals were checked for every run. No zero-cost or universal-speedup claim is made.

The complete samples for both local experiments are in ../assets/release-bcf64a5756bb23c9/local-experiments.json. The reproduction script (retained in the source workspace) expects the official Python SDK and analytics wheels extracted together into a story-sdk directory beside it. It runs through normal SDK trial/license initialization, creates a fresh local data directory and makes no cloud requests. Do not bypass trial or entitlement checks. The sizing script expects work/story-core.wasm, extracted from the verified browser tarball, when run from the workspace root.

Metric selection and historical context

Earlier local sessions were recovered, including the August prototype browser-WAL experiment: about 2.9–3.0 ms median and 3.8–4.1 ms p95 for a warm two-statement transaction, and later separate measurements of actual UI and real-R2 propagation. Those results belong to an older prototype and are not used as current potluckdb claims.

The old prototype's scheduling observations are not a current limitation. Current source reviewed at 3018fe73de07232b15157e2c43577832a8a10fa7 includes cooperative sync operations and the regression test test_A3_A4_A13_blocked_bucket_work_does_not_occupy_the_local_lane. This source review is not a fresh browser latency benchmark.

The next product-level benchmark worth running is focused: click-to-visible-save p50/p95/p99 during active sync, with correctness checked, followed by commit-to-visible-on-peer latency. Record cold and warm starts separately, and include bytes/requests for catch-up. Neither an isolated SDK call nor a push duration substitutes for those measurements. The homepage does not invent numbers for these currently unmeasured user journeys.