By the numbers
What trckable weighs and how fast it is, how each number was measured, and what the numbers do not claim.
Lightweight is the product, so here are the measurements, how each one was taken, and what it does not claim.
Measured by CI, on every change
These are measured on x86-64 Linux by CI for every commit to the product, and this page is rebuilt from those measurements: the numbers below are CI's, for commit c794f7f on 30 Sep 2026. Sizes are gzip level 9 (zlib, the same bytes on any machine).
| Measured | What it is |
|---|---|
| 2,045 B | tracker (/js/t.js), minified and gzipped, incl. goals, outbound links and checkout-link attribution. CI fails above 2,048 B |
| 1,596 B | the same tracker with every optional feature off — what a site that only counts visits downloads |
| 3,382 B | every module a site can turn on at once, including Core Web Vitals (225 B), form submissions (114 B) and trckable's own cookie bar (1,026 B). Settings → Modules prices each one before you turn it on |
| 2,264 B | added to a React app by trckable/react, gzipped. CI fails above 2,560 B |
| 29.7 MB | the Docker image, compressed (docker save | gzip -1). CI fails above 30 MB |
| 55 MB | the container's memory (docker stats), settled 10 s after its first event: the highest reading across CI's last five runs, since the file cache moves it by a few MB from run to run. CI fails above 64 MB |
| 127 KB | dashboard first load (JS + CSS, gzipped), no chart library. CI fails above 130 KB |
| 0 of 40,000 | events lost or counted twice when CI kills the server mid-load (20,000 with kill -9, 20,000 with a graceful restart) |
| 7 × 28 | payment scenarios (trials, upgrades, partial refunds, refund-before-payment, disputes, test mode; all 5 providers), each replayed in 28 orders: identical money every time |
| 6 × 3 | real-browser tests in Chromium, Firefox and WebKit: exact counts, lost-response retries counted once, offline delivery, cookieless mode storing nothing, checkout links carrying the visitor |
| 0 | axe-core (WCAG 2.1 AA) violations on the dashboard's main screens, in both themes and all three browsers, against 30 days of demo data |
Measured by hand
Measured once on 23 Sep 2026, on an Apple-silicon Mac (Go 1.27, DuckDB 1.5.5),
with synthetic data from bench/demoseed and bench/querybench. Not yet in CI,
so treat them as a snapshot, not a guarantee.
| Measured | What it is |
|---|---|
| 44 B | disk per event, averaged over 9.25M synthetic events (DuckDB compresses columns; one event on its own is larger). A 5 GB volume holds ~115M events |
| ≤ 115 ms | p95 of every Core dashboard query at 9.25M events, on one DuckDB thread |
| 68–196 ms | one complete 30-day dashboard report (KPIs, chart, 11 breakdowns, per-day scrubber data) at 9.25M events on 2 DuckDB threads, small site to big site; repeat views are cached |
| 163 ms | a 30-day report with revenue attribution, comparison and per-day data on the 120-day demo site (300k events, 2,600 payments) |
What these numbers are not:
- Query times are on a fast desktop core; a small cloud vCPU may be 1.5–2× slower.
- The crash and query tests use synthetic traffic. Payment fixtures follow each provider's documented payloads (2026-09); live sandbox runs against each provider are still to do.
- RAM grows under heavy query load (DuckDB is capped at 256 MB by default).
- Longer ranges on very large sites take longer (a 90-day report on the biggest synthetic site: 555 ms).
Reproduce: pnpm --filter @trckable/tracker size, go run ./bench/crashtest -signal kill|term, go run ./bench/querybench, go run ./bench/demoseed, go test ./internal/ledger, cd e2e && npx playwright test --repeat-each 3.
DataFast alternative, self-hosted and open source
trckable vs DataFast: the same revenue-attribution idea (which channel brought paying customers), open source and self-hostable, with a smaller script. Sourced facts, and where DataFast is better.
Changelog
Every trckable release, newest first. The current version is 0.5.5.