Methodology

What is being compared

Each listed price belongs to one purchasable plan. A scenario supplies the workload kind, vCPU and RAM per instance, total persistent storage, monthly internet egress, instance count, billable hours, region, public IPv4 need, load-balancer need, and seat count. The default scenario is one always-on container instance with 2 vCPU, 4 GB RAM, no persistent storage, 100 GB monthly egress, any region, public IPv4, no load balancer, and one seat.

Eligibility is checked before price. The workload kind must match the plan boundary, the plan must serve the selected region, and its published vCPU and RAM must meet or exceed the request. An unknown resource allocation fails closed when the scenario asks for that resource. The main table keeps the cheapest complete qualifying plan from each vendor and leaves the rest of that vendor's qualifying ladder on its provider page.

This is a price dataset, not a deployment compatibility database. It knows what a provider charges and performs a narrow boundary check for container, static, or database workloads. It does not know runtime support, deploy method, persistent-disk behavior, background-worker support, cron, WebSockets, private networking, or CPU performance. Captured orderability can remove an unavailable plan from ranking, while uncaptured orderability remains visibly unknown. That is why the first row is called the lowest complete infrastructure bill, never the winner.

How every bill line is calculated

The scenario bill is the rounded sum of every applicable line below. Charges are in US dollars per month. A line is omitted when the scenario does not request it and the plan does not require it. If a mandatory rate is missing, the total stays unknown and cannot rank.

• Compute for an always-on monthly plan = monthly plan price x instance count. The monthly rate is used when run time is 730 hours or more.
• Compute for a plan with an hourly rate = hourly price x monthly run time x instance count.
• Compute for a monthly plan used less than 730 hours = monthly plan price x instance count. Stopping early does not prorate a monthly subscription.
• Platform fee = the mandatory monthly account fee once, not once per instance.
• Additional seats = seats above the included count x the monthly price for each extra seat.
• Additional storage = requested persistent storage above the included amount x the monthly price for each extra GB.
• Transfer overage = internet transfer above the included allowance x the price for each billable GB. The included allowance is applied once to the scenario, not once per instance.
• When the provider does not charge transfer by the GB, the transfer line has zero cost only while the request stays inside a known published limit. An unknown limit blocks the total. Above a limit, a throttle, soft limit, or hard stop changes the workload and blocks ranking rather than becoming free transfer.
• Managed Postgres = a linked managed-database plan and price when the scenario requests it. The current compute plans have no such linkage, so the stateful preset returns an explicit unknown database line and no ranked compute-only total.
• Public IPv4 = the published monthly IPv4 charge when the scenario needs IPv4 and the plan says it is not included.
• Kubernetes control plane = the published control-plane charge for every Kubernetes plan. Zero cost is accepted only when the provider states that the control plane is free.
• Load balancer = the monthly price of one load balancer when the scenario requests it.
• Mandatory support = the required monthly support charge when the provider makes it compulsory.
• Complete total = round to cents after summing all applicable known lines. A sum of known lines is shown for diagnosis when another line is unknown, but it is not a total and does not rank.
• Promotional renewal total = complete first-term total - first-term compute + monthly renewal price x instance count. It is shown separately from the first-term bill.

The four price states

Price state controls whether a plan is allowed into the price order. A complete bill must also have no unknown mandatory line. Passing one test does not bypass the other.

• Published: the vendor prints the plan price. It may rank after every applicable bill line is known.
• Derived: every input is public and the plan includes a human-checkable formula and its inputs. It may rank after every applicable bill line is known.
• Scenario required: the cost depends on usage, requests, seats, credits, or another input the visitor has not supplied. It never ranks. The row names the missing input and asks for it.
• Quote: no public source exposes a reproducible total. It never ranks. The row points to the vendor's quote path and names what is missing.
• Ranked rows are sorted by complete scenario total from low to high. Scenario-required, quote, and incomplete rows sit below every ranked row in stable vendor order, never between priced rows.

Where prices come from

Each price cites the provider pricing, product, documentation, or terms page where the fact is printed. A provider homepage is not sufficient evidence for a price. The source link is the page to check, and the checked date says when that page was read.

A non-USD price keeps the source amount, source currency, exchange rate, exchange-rate source, and exchange-rate date. A calculated price keeps its formula and named inputs. Promotional plans show the renewal monthly price, and commitment plans show the commitment length when it is known.

What happens when something is unknown

An unknown is never treated as free. If compute, storage overage, transfer overage, IPv4, Kubernetes control plane, or a requested load balancer lacks a required rate, the total stays unknown. The bill shows the sum of known lines for diagnosis, marks the row incomplete, and removes it from ranking.

Unknown eligibility is stricter. A plan with no published vCPU or RAM is excluded when the scenario requests that resource. A plan with no confirmed regions is excluded from a specific-region scenario. Every exclusion carries a reason.

An unknown included-transfer allowance is never converted to zero. It blocks a positive-transfer total because the calculator cannot prove the request is inside a usable allowance. Published throttles, soft limits, and hard stops also block any scenario that exceeds the stated limit.

What the dates mean

The source-checked time belongs to one plan and says when its cited page was read. A separate availability time says when stock or orderability was checked. The date the facts were combined does not make an older provider check newer.

The current source checks run from 2026-07-25 at 15:00 UTC through 2026-07-26 at 11:43 UTC. The public health file reports the earliest represented source check and confirms that all 996 retained facts loaded.

What is not in the headline

The bill does not currently add taxes, optional support, negotiated discounts, migration cost, exit work, backups, team labor, inter-region transfer, request charges that lack visitor inputs, storage IOPS, or regional capacity risk. A requested managed Postgres component is material: because compute-to-database linkage is not available, it is an explicit unknown line that prevents a compute-only total from ranking.

Team cost is off by default because it is not a provider charge and the site has no defensible universal salary or operations-hours assumption. A review of eleven tools found that AWS Pricing Calculator, Google Cloud Pricing Calculator, Azure Pricing Calculator, Judoscale, LearnKube, Infracost, S3Compare, CostStorage, and LearnAWS estimate configured provider charges, while Vantage and CloudZero analyze actual provider spend. None adds the buyer's labor to the default provider bill. Team economics belong in a separate opt-in calculation with a rate and hours entered by the buyer, and they must not reorder the infrastructure table.

How corrections are handled

Corrections to a source fact, formula, price state, region, or plan mapping are dated and flow into a newly assembled set. The provider, product family and plan identity are kept together, so a correction changes the intended offer rather than every plan from that provider.

A historical receipt should retain its scenario, provider source, and checked date. If a recalculation disagrees with a displayed number, the displayed number is wrong and should be reported with the page URL, scenario, and provider source.