Methodology

Every comparison starts with a field registry — a list of the dimensions that actually distinguish the tools in that category, defined as data rather than code. A field declares its label, its type, its unit, which direction is better, a default weight, and a help string that states precisely how the fact is defined. "Cold start" is meaningless on its own; "time from API call to executable environment, p50, warm pool empty" is a claim you can check.

Facts are then gathered per tool, one cell at a time, from primary sources: vendor documentation, published pricing pages, status pages, changelogs, licences, public repositories, regulator registers. Aggregators, review sites and vendor blog posts about their competitors are not primary sources and are not used as ones.

Every cell that reaches the site carries four things: the value, the URL it came from, the date it was last verified, and a confidence level. A cell missing its source fails the build rather than being published. That constraint is the reason the tables are slower to fill than a scraped competitor's, and it is the entire point.

Not all facts are equally solid, so they are not presented as though they were. Five levels, applied per cell, shown in the expanded row and carried through the JSON API and the markdown twins.

The default for an unannotated fact is inferred, not vendor-claimed — the honest default, and an incentive to annotate. A page's freshness score is the mean confidence rank across its cells, so a table full of guesses scores badly and says so on the page rather than in a footnote.

Each category declares a verifyCadence: how long a cell in that category stays believable before someone has to look again. Current cadences on this site: 14d, 30d, 7d. LLM pricing moves weekly, so that category is 7d. Coding agents churn monthly, so 14d. Object storage pricing is comparatively glacial, so 30d or 90d is honest.

Cadence is not a promise that everything is fresh — it is the threshold past which we call a cell stale in public. The sources page lists every cell that has slipped past its category's cadence, alongside every cell marked unknown. Nobody else ships that view, because it is the one that makes you look bad.

The build enforces the outer bound: a cell verified longer ago than three times its category's cadence fails validation outright. Data can be out of date here. It cannot be silently out of date.

Site-wide, the newest verification anywhere in the dataset is 2026-07-23, and that is the date used for dateModified and sitemap lastmod. It is derived, not typed, so it cannot be gamed by touching a file.

A score is a weighted mean of normalised field values. Three steps, and each one is boring on purpose.

1. Normalise each field to 0–1, in the good direction. Numbers, durations, byte sizes, currencies and ranges are min–max scaled against the values actually present in that category's roster, then flipped when higherIsBetter is false — so the cheapest egress price and the fastest cold start both land at 1. A field can declare a clamp so one outlier does not flatten everything else into the same corner. Tristates score yes = 1, partial = 0.6, no = 0. Booleans score 1 or 0, inverted where less is better. Enums use the field's declared rank map, min–max scaled across the ranks it defines. Multi-value fields — region lists, SDK languages — score on breadth relative to the widest member of the roster. Text, markdown, URLs, dates and tier tables carry no ranking signal and normalise to nothing at all.

2. Drop everything without a signal. A cell that is null, or explicitly unknown, or an enum option the field never ranked, returns no value. Fields with a weight of zero are skipped before any of this happens.

3. Take the weighted mean over what is left. Each surviving field contributes normalised × weight, and the divisor is the sum of the weights of the fields that survived — not the sum of all weights. An unknown is excluded from the calculation, never counted as a zero. Scoring a missing fact as a failure would punish tools for being under-researched by us, which is our problem and not theirs. The result is scaled to 0–100 and rounded to one decimal place.

Alongside the score, each row reports coverage: how many of the weighted fields actually had a usable value, over how many were considered. A tool scoring 91 on 40 % coverage is not beating a tool scoring 88 on 100 % coverage, and the table shows you both numbers so you can see that for yourself.

Two consequences worth stating plainly. Because normalisation is relative to the roster, scores are only meaningful within a category, and they move when a tool is added or removed. And because weights are yours to set, there is no such thing as "the best" tool here — only the best one under a stated set of priorities, with the priorities visible in the URL.

Some categories have no score column at all. Comparing SQLite, PostgreSQL and MySQL on a single number would be a lie about what those things are, so that page ships a decision matrix instead.

• No user accounts. There is nothing to log in to, nothing to sign up for, and no reason to collect an email address to read a table.
• No reviews or star ratings. Vendor-gameable within a month of launch, and a five-star average has never once answered "which of these should I use". If community signal ever ships, it will be "used in production by" attestations from verified accounts, not votes.
• No affiliate links. Not disclosed ones, not rel="sponsored" ones, not "we may earn a commission" ones. Outbound links to vendors are plain links.
• No sponsored placements or paid inclusion. Roster membership is editorial. Ordering is either alphabetical, or by a score whose weights you can see and change.
• No auto-generated pairwise pages. A /vs/ URL exists only if someone wrote the analysis. Asking for one that does not exist returns a 404, not a synthesised table.
• No vendor-influenced placement. Vendors are welcome to correct facts about themselves through the same public issue tracker as everyone else. That is the whole of the relationship.

Wrong data is worse than missing data, so corrections take priority over new categories. Every correction is a public issue against the repository, every change is a commit, and material changes to a published number show up in the changelog. If you are a vendor and we have got you wrong, say so — it will be fixed with the same weight as any other report, and no faster.