Sizing and capacity

These are measurements from our own staging configuration and our benchmark corpus, not a guarantee. Your numbers will differ. They are published because “ask sales” is not an acceptable answer to a capacity question, and a measured number with its provenance stated is more useful than a range invented to be safe.

The shape of the load

One binary, one Postgres. Reviews are the load, and reviews are bursty: a busy morning is many pull requests in a few minutes, then quiet. Capacity planning here is about the burst, not the daily total.

Compute

Modest. The gate is a parser and a rule set over the changed files of one pull request — not a build, not a container, no cloud calls. The performance budgets in the build are:

• webhook to comment: p95 under 60 seconds
• scan: under 2 minutes per 500 resources

Both are tests, so a change that makes reviews slower than that fails CI. On our benchmark corpus of 40 real repositories, garboard gate ran in under 1 second per repository, with the slowest at 0.83 seconds on a 111-file tree.

Scanning is heavier than gating, and it is occasional — a repository is scanned to derive conventions, not on every pull request.

Postgres

The database holds facts, not code archives: conventions, evidence, findings, review history, receipts and episodes.

Growth comes from three places, and only one of them is unbounded by default:

Receipts and the audit log are the two to watch on a long-lived install. Neither is large per row; both are permanent unless you set a retention window.

Vector dimension drives episode storage. The offline hash embedder is smaller than a hosted model’s native width — see operations before changing it, because switching backends on an existing database needs a column migration.

Token spend, on bring-your-own-key plans

The deterministic gate uses no tokens at all. Parsing, conventions, findings, evidence and blocking are free of any model.

Tokens are spent on exactly two things:

• Prose — the sentence explaining a finding. Small, and only on pull requests that produce findings. A repository that is mostly clean spends almost nothing.
• Fixes — only when someone clicks Fix. This is the variable cost, and it is driven by human clicks rather than by pull request volume.

So the spend scales with findings you act on, not with pull requests reviewed. A team with a clean estate pays for very little.

If you set no key at all, the gate is unaffected and the cost is zero. That is not a degraded mode — it is invariant 5.