Skip to content
inetGeek

Methodology

How the data on this site is sourced, what makes us leave a value out, and the conditions a page has to meet before it is published.

01.

Where the numbers come from

Every factual value on this site was read from a page published by the provider it describes — their documentation, pricing page or knowledge base. Nothing is written from memory, and nothing is taken from a search result summary, a forum post or another comparison site.

Each value is stored with the URL it came from, the sentence it came from quoted verbatim, the date it was read, and how authoritative the source is. You can see all four by expanding "Sources" beside any figure. If a value has no source, it cannot be added — the build rejects it.

02.

When we leave a cell empty

A blank is not an oversight. It means we looked and the provider does not publish that figure, or publishes it somewhere we could not treat as evidence. We would rather show a gap than a number we cannot stand behind.

Specific cases where we record nothing: when a page states a figure only after JavaScript runs and the number is missing from what we can read; when two fetches of the same page disagree; when the only statement is on a page about a different product; and when two official sources contradict each other.

That last one is real. One host's marketing page advertises unlimited bandwidth while its own fair-use policy says it does not offer unlimited bandwidth. We publish neither figure.

Sourcing coverage — hosting938 of 2296 cells · 41%
Which criteria each provider publishes, by criterion group
ProviderPricingMetered ratesLimitsExecutionDeploymentInfrastructureDataStorageObservabilityInferenceEmailAuthQueuesGPUCachingVectorCI/CDSecretsCDNPipelinesStreamingMessagingOn-callSupportCompliancen
Alibaba Cloud31
AWS Amplify23
Azure Container Apps11
Civo27
Cloudflare Pages25
Cloudflare Workers9
Cloudways23
Contabo21
Deno Deploy8
DigitalOcean38
DigitalOcean App Platform12
DreamHost20
Fly.io26
Flywheel18
Google Cloud25
Google Cloud Run23
Heroku23
Hetzner27
Hostinger28
Hostinger VPS23
IONOS VPS21
Kamatera29
Kinsta26
Koyeb8
Leaseweb24
Linode (Akamai Cloud)25
netcup18
Netlify32
Nhost12
Oracle Cloud28
OVHcloud21
Pressable19
RackNerd16
Railway31
Render32
SiteGround23
UpCloud30
Vercel33
Vultr23
WP Engine25
Zeabur21

sourced from the provider's own documentationnot published, or not published in a form we could cite

Every filled cell is a value read from that provider's own page and stored with its source. Empty cells are the honest state of the data — providers with thorough documentation fill most of a row, marketing-led hosts far less.
Sourcing coverage — databases310 of 546 cells · 57%
Which criteria each provider publishes, by criterion group
ProviderPricingMetered ratesLimitsExecutionDeploymentInfrastructureDataStorageObservabilityInferenceEmailAuthQueuesGPUCachingVectorCI/CDSecretsCDNPipelinesStreamingMessagingOn-callSupportCompliancen
Aiven21
Amazon Aurora29
Amazon RDS27
Crunchy Bridge12
Firebase22
Neo4j13
Neon27
Nile17
PlanetScale21
Prisma Postgres15
ScaleGrid29
Supabase25
TigerData28
Turso24

sourced from the provider's own documentationnot published, or not published in a form we could cite

Every filled cell is a value read from that provider's own page and stored with its source. Empty cells are the honest state of the data — providers with thorough documentation fill most of a row, marketing-led hosts far less.
Sourcing coverage — object storage118 of 216 cells · 55%
Which criteria each provider publishes, by criterion group
ProviderPricingMetered ratesLimitsExecutionDeploymentInfrastructureDataStorageObservabilityInferenceEmailAuthQueuesGPUCachingVectorCI/CDSecretsCDNPipelinesStreamingMessagingOn-callSupportCompliancen
Amazon S317
Azure Blob Storage15
Backblaze B217
Bunny Storage9
Cloudflare R211
IDrive e210
Storj14
Tigris10
Wasabi15

sourced from the provider's own documentationnot published, or not published in a form we could cite

Every filled cell is a value read from that provider's own page and stored with its source. Empty cells are the honest state of the data — providers with thorough documentation fill most of a row, marketing-led hosts far less.
Sourcing coverage — observability195 of 270 cells · 72%
Which criteria each provider publishes, by criterion group
ProviderPricingMetered ratesLimitsExecutionDeploymentInfrastructureDataStorageObservabilityInferenceEmailAuthQueuesGPUCachingVectorCI/CDSecretsCDNPipelinesStreamingMessagingOn-callSupportCompliancen
Axiom25
Better Stack22
Datadog22
Elastic Cloud24
GlitchTip20
Grafana Cloud22
OpenObserve24
Sentry17
SigNoz19

sourced from the provider's own documentationnot published, or not published in a form we could cite

Every filled cell is a value read from that provider's own page and stored with its source. Empty cells are the honest state of the data — providers with thorough documentation fill most of a row, marketing-led hosts far less.
Sourcing coverage — LLM APIs206 of 300 cells · 69%
Which criteria each provider publishes, by criterion group
ProviderPricingMetered ratesLimitsExecutionDeploymentInfrastructureDataStorageObservabilityInferenceEmailAuthQueuesGPUCachingVectorCI/CDSecretsCDNPipelinesStreamingMessagingOn-callSupportCompliancen
Anthropic22
Baseten26
DeepInfra23
DeepSeek11
Fireworks AI24
Google Gemini API18
Novita AI22
OpenAI20
Together AI22
xAI18

sourced from the provider's own documentationnot published, or not published in a form we could cite

Every filled cell is a value read from that provider's own page and stored with its source. Empty cells are the honest state of the data — providers with thorough documentation fill most of a row, marketing-led hosts far less.
Sourcing coverage — transactional email119 of 253 cells · 47%
Which criteria each provider publishes, by criterion group
ProviderPricingMetered ratesLimitsExecutionDeploymentInfrastructureDataStorageObservabilityInferenceEmailAuthQueuesGPUCachingVectorCI/CDSecretsCDNPipelinesStreamingMessagingOn-callSupportCompliancen
AhaSend13
Amazon SES14
Brevo8
Cloudflare Email Service8
EmailLabs5
MailerSend10
Mailgun14
Mailjet7
Postmark13
Resend16
SMTP2GO11

sourced from the provider's own documentationnot published, or not published in a form we could cite

Every filled cell is a value read from that provider's own page and stored with its source. Empty cells are the honest state of the data — providers with thorough documentation fill most of a row, marketing-led hosts far less.
Sourcing coverage — auth149 of 240 cells · 62%
Which criteria each provider publishes, by criterion group
ProviderPricingMetered ratesLimitsExecutionDeploymentInfrastructureDataStorageObservabilityInferenceEmailAuthQueuesGPUCachingVectorCI/CDSecretsCDNPipelinesStreamingMessagingOn-callSupportCompliancen
Auth024
Better Auth15
Clerk20
Kinde18
Nhost12
Stytch22
SuperTokens15
WorkOS23

sourced from the provider's own documentationnot published, or not published in a form we could cite

Every filled cell is a value read from that provider's own page and stored with its source. Empty cells are the honest state of the data — providers with thorough documentation fill most of a row, marketing-led hosts far less.
Sourcing coverage — queues and background jobs169 of 290 cells · 58%
Which criteria each provider publishes, by criterion group
ProviderPricingMetered ratesLimitsExecutionDeploymentInfrastructureDataStorageObservabilityInferenceEmailAuthQueuesGPUCachingVectorCI/CDSecretsCDNPipelinesStreamingMessagingOn-callSupportCompliancen
Amazon SQS21
Azure Queue Storage14
Cloudflare Queues11
Google Cloud Pub/Sub13
Hatchet20
Inngest21
Temporal25
Trigger.dev18
Upstash QStash9
Zeplo17

sourced from the provider's own documentationnot published, or not published in a form we could cite

Every filled cell is a value read from that provider's own page and stored with its source. Empty cells are the honest state of the data — providers with thorough documentation fill most of a row, marketing-led hosts far less.
Sourcing coverage — GPU compute267 of 442 cells · 60%
Which criteria each provider publishes, by criterion group
ProviderPricingMetered ratesLimitsExecutionDeploymentInfrastructureDataStorageObservabilityInferenceEmailAuthQueuesGPUCachingVectorCI/CDSecretsCDNPipelinesStreamingMessagingOn-callSupportCompliancen
Baseten26
CoreWeave18
Crusoe Cloud23
DeepInfra23
Fireworks AI24
Hyperstack20
Lambda19
Nebius AI Cloud19
Novita AI22
Paperspace20
RunPod20
TensorDock13
Vast.ai20

sourced from the provider's own documentationnot published, or not published in a form we could cite

Every filled cell is a value read from that provider's own page and stored with its source. Empty cells are the honest state of the data — providers with thorough documentation fill most of a row, marketing-led hosts far less.
03.

Why some values say "limited"

Capability columns take one of three values. "Supported" means the provider documents the capability without material qualification. "Not supported" means a provider page explicitly states the absence — we never infer it from silence. "Limited" means the capability exists but is constrained, and the quoted excerpt says how.

"Limited" carries most of the useful information. Docker on a self-managed VM is not the same product as a managed Docker deploy. Autoscaling that requires a paid plan is not the same as autoscaling. Scheduled jobs on a fuzzy hourly cycle are not cron. Flattening those into a tick would lose the thing you are trying to find out.

04.

Facts and opinions are stored differently

A sourced fact has a URL. A recommendation does not, because it is a judgment, and giving it a citation would dress opinion up as evidence.

Recommendations are stored separately, carry the name of whoever wrote them, and are marked approved or not. An unapproved recommendation blocks the page from being indexed. Where you see "Choose X if…", a person wrote and signed off on that wording.

05.

How we compute a lean

Some comparisons show a bar or a chart indicating which side a criterion favors. That lean is inetGeek's own read, computed from the same sourced values already on the page — never a separate claim, never something a provider stated. It is calculated by exactly six fixed rules: a ratio between two documented magnitudes (more storage, more memory, a lower price); a straight comparison when both sides are a plain yes/no, flipped for the one criterion where yes is the worse answer (a required credit card); a comparison of documented support levels (supported beats limited beats not supported); a published vocabulary for a handful of prose criteria — what happens past a cap, what happens when idle — where two providers in the same class are recorded as matching, and different classes lean only if the vocabulary declares an order, which none does today; on trust criteria only, a documented commitment against a sourced statement that none is published on the plan you can buy; and a documented criterion against a vendor page that was read for it, on a stated date, and does not mention it. That sixth rule is the only one that leans on a one-sided row, and it never applies to a cell nobody has read — the page says "Not stated on the vendor's page (checked <date>) — corrections welcome", and a vendor whose page says more than we found can send a link. It applies only to compliance criteria, where a security page that never mentions SOC 2 is evidence and a pricing page that never says when a free plan ends is not. In the iScore the same observed absence counts low — between limited and none — once per pillar however many things the page is quiet about, and never at more than a quarter of the weight of what the vendor itself documented there. Nothing else produces a lean.

101 of the 128 criteria this site tracks can produce a lean today, given the data currently on file. The rest cannot, and that is deliberate rather than a gap more sourcing would close. A criterion stays lean-ineligible when there is no side a reasonable reader would agree is simply better — which billing structure suits you depends on your own usage, and PostgreSQL is not an improvement on MySQL — or when providers document the same concept in ways too different to reduce to one number without inventing a choice the source never made. Forcing a bar onto either would be exactly the fabricated precision this site refuses everywhere else.

Where a lean is possible but the data on file does not yet support it — a figure exists on one side but not the other, or the concept is sound but no provider has stated it in a comparable form — the criterion is left to show its sourced values with no bar, the same as any other undocumented cell. One exception is deliberate: on a trust criterion, a provider whose own page says it publishes no commitment on the plan you can buy is not undocumented, and that sourced absence is what the fifth rule compares. A future source can close a real gap; no amount of sourcing will make a genuine trade-off into a right answer.

06.

iScore — one number, with its width

Each provider page carries an iScore: the provider against every peer in its category, 0 to 100, with an 80% interval beside it. It is computed from the same sourced facts the page shows, by rules written down in one file, and nothing in it is set by hand per provider. Numbers are scored on a log scale against the category median; yes, limited and no count 100, 50 and 0; a fact past its staleness window or read from a third-party source counts for less; a criterion every peer answers the same way counts for a quarter of one that separates them.

The width is the honest part. A provider with few documented facts is pulled toward the middle of its category rather than scored on what little is known, and its band is wide. A rank is a finding only where the posterior puts a provider above the next one at 90% or better; everywhere else it is an ordering, and it is printed with a ≈ to say so. Six pillars make up the number — price, capacity, capabilities, trust, evidence and adoption — and the weights differ by category: a payment processor is chosen on trust and fee, an LLM API on price and context window. Those weights are our read of what decides the purchase, disclosed on the iScore page, not a fact.

The score changes whenever the data does. Add a provider and the category median moves; re-source a fact and its freshness weight resets; publish a limit as a number instead of a sentence and it starts to count. That is also the route to a better score, and the iScore page lists exactly which published facts move each pillar.

How iScore is computed, and what moves it →

07.

What has to be true before a page publishes

A comparison needs at least six criteria sourced for the pair, at least three where the two genuinely differ, a relevance score showing the providers plausibly substitute for each other, no fact older than 120 days, and approved recommendations on both sides.

A provider page needs at least four sourced facts. A stack page needs at least three providers that document that stack.

Pages that fail are still built, but marked so search engines skip them, and they say on the page which requirement they missed. A URL existing is not a reason to publish it.

08.

What we deliberately do not do

No score without its rules and its width. "8.4 out of 10" on its own implies a measurement nobody performed. iScore exists because readers asked for one number, and it is allowed on one condition: every rule is published, every criterion names the fact it was read from, and the interval is printed beside it. Where two providers differ we still show both values and say which criteria separate them; the number is a summary of that, never a substitute.

No star ratings or review markup. Structured data is used only where it genuinely describes the page.

No ranking by commission. There are currently no affiliate relationships on this site, and if that changes, paid links will be marked and disclosed rather than folded into an ordering you cannot see.

09.

Freshness, and where this is weakest

Every value carries the date it was read, shown as the "Updated" stamp on each page. Pricing moves fastest; a fact older than 120 days blocks a comparison from publishing until it is re-checked.

The honest limitation: this site currently documents what providers publish about themselves. That is verifiable and it is not the same as independent measurement. Nothing here is a benchmark we ran. Where a provider publishes nothing, we have nothing — which is why a handful of cells stay empty rather than being filled in with something plausible.

10.

Corrections

If a figure here is wrong or has changed, tell us and we will re-check it against the source and update the date. The quoted excerpt beside each value exists precisely so an error is easy to demonstrate.

Every claim this site makes about a vendor's silence — a page we read on a stated date that did not mention a criterion — and every change we have made to a published fact is listed on the ledger at /ledger/, generated from the data. A vendor whose page says more than we found can send the link; the row is replaced, not argued with.

What this site currently holds

Counted from the data at build time, not typed into the page. A claim about our own coverage is held to the same rule as a claim about a provider: if it can drift out of sync with reality, it is wrong to write it as a literal.

Coverage

233
providersacross 41 categories
453
comparisonspublished, gate passed
128
criteriadefined in the comparison table

Evidence

3,546
sourced facts15.2 per provider on average
297
source domainsfirst-party, cited per figure
737
comparable figurescarry a unit, so they can be ranked

What we cannot stand behind

14
facts we cannot re-readthe vendor blocks or challenges our checker

Every figure carries the date it was read. The oldest in the corpus was verified on 5 September 2026, the newest on 17 October 2026. Anything that ages past its field's limit stops being published rather than quietly staying on the page.

When these numbers change, hear about it. Sources are re-checked monthly; a repricing goes out as a short note.

Confirm by email; unsubscribe from any issue. Your address goes to Kit and nowhere else — what we do with it.

Every page here is sourced and dated.