Methodology
- How facts get onto this site, what each one is worth, and how the ranking arithmetic works.
- If any of it is wrong, that is a bug, so file it.
- Categories
- 12
- Tools tracked
- 156
- Confidence levels
- 5
- Last verified
- 2026-07-30
How a fact gets here
- A comparison starts as a field registry: the dimensions that actually separate the tools in a category, defined as data.
- Facts are gathered one cell at a time from primary sources only: vendor docs, pricing and status pages, changelogs, licences, repos and regulator registers.
- Aggregators and vendor blogs about rivals are not primary sources, so they are not used as ones.
Every published cell carries four things
The valueThe fact itself, typed to the field it fills.
The sourceThe exact URL it came from. No source, no publish.
Verified dateWhen a human last checked it against that source.
ConfidenceOne of five levels, so a guess never reads as a measurement.
The confidence ladder
- Not all facts are equally solid, so they are not shown as though they were.
- Five levels, applied per cell, carried through the tables, the JSON API and the markdown twins.
- The default for an unannotated fact is inferred, not vendor-claimed.
| Level | What it means | How much to trust it |
|---|---|---|
| measured Measured by toolweight | We ran the test ourselves, on a stated date, with a published method. | Highest. Reproducible, and the only class where we are the primary source. |
| vendor-claimed Vendor-claimed | Straight off the vendor's docs, pricing or status page, with the URL recorded. | High for prices and limits. Treat performance claims as marketing until measured. |
| community Community-reported | Reported in issue threads, changelogs, forums or public incident write-ups. | Moderate. Usually right about behaviour, often wrong about scope. |
| inferred Inferred | A judgement call, or read off adjacent facts like an error message or a pricing tier. | Low. Cited so you can check the reasoning, not so you can rely on the number. |
| unknown Unknown | We do not know, and the cell says so instead of guessing. | None, deliberately. Counted against the page's freshness score. |
Verification cadence
- Each category declares how long a cell stays believable before someone re-checks it.
- Cadence is not a promise everything is fresh, it is the line past which we call a cell stale in public.
- The build fails any cell older than three times its cadence.
- Current cadences: 14d, 30d, 7d.
| Category | Re-verify every |
|---|---|
| Sandbox providers | 30d |
| Coding agents | 14d |
| LLM APIs | 7d |
| Browser APIs | 30d |
| S3-compatible storage | 30d |
| Vercel alternatives | 30d |
| Convex alternatives | 30d |
| Email APIs | 30d |
| Database engines | 30d |
| Domain registrars | 30d |
| Domain APIs | 30d |
| AU SMS APIs | 30d |
- The sources page lists every cell that has slipped past its cadence, alongside every unknown.
- Site-wide, the newest verification anywhere is 2026-07-30.
- That derived date drives dateModified and sitemap lastmod, so it cannot be gamed by touching a file.
How the weighting engine scores
- A score is a weighted mean of normalised field values.
- Three steps, each boring on purpose.
1. NormaliseEvery field maps to 0-1 in the good direction, scaled against the values present in that category's roster.
2. Drop blanksA null, an unknown, or a zero-weight field contributes nothing. It is skipped, not scored as a loss.
3. Weighted meanSurviving fields contribute value x weight, divided by the weights that survived. Scaled to 0-100.
| Field type | How it scores |
|---|---|
| Number, duration, bytes, currency, range | Min-max scaled across the roster, flipped when lower is better. A clamp caps outliers. |
| Tristate | yes = 1 · partial = 0.6 · no = 0 |
| Boolean | 1 or 0, inverted where less is better. |
| Enum | Ranked by the field's rank map, then min-max scaled across those ranks. |
| Multi-value, region list, languages | Scored on breadth against the widest member of the roster. |
| Text, markdown, URL, date, tier table | No ranking signal. Not scored. |
- An unknown is excluded, never scored as a zero.
- Punishing a tool for a fact we have not researched would be our problem billed to them.
- Each row reports coverage, so a 91 on 40% coverage never quietly beats an 88 on 100%.
- Normalisation is relative to the roster, so scores are only meaningful within a category and shift when a tool is added.
- Weights are yours, so there is no single best tool, only the best under a stated set of priorities visible in the URL.
- Some categories, like SQLite vs PostgreSQL vs MySQL, ship a decision matrix instead of a score.
What toolweight will not do
| Never | Why |
|---|---|
| No user accounts | Nothing to log in to, and no email collected to read a table. |
| No reviews or star ratings | Gameable within a month of launch, and a five-star average never answered which tool to use. |
| No affiliate links | Every outbound vendor link is a plain link. No tracking, no commission. |
| No sponsored placement | Roster membership is editorial. Ordering is alphabetical, or by weights you set. |
| No auto-generated /vs/ pages | A comparison exists only if someone wrote it. Asking for one that does not returns a 404. |
| No vendor-influenced placement | Vendors correct facts through the same public tracker as everyone else. |
Corrections
- Wrong data is worse than missing data, so corrections come before new categories.
- Each one is a public issue, each change a commit against a published number.
- Vendors correcting their own facts go through the same queue as everyone, and no faster.