Render prices web services, workers and Postgres on one page

The workload

Render publishes one pricing page covering web services, background workers, managed Postgres and static sites, so a founder comparing options reads a single dense table rather than several vendor-specific pages. The page, as retrieved 16 September 2026, sets prices by named tier; Render's free instance type documentation states that Free compute plans exist to let someone explore the platform, build a personal project, or preview the developer experience, in the vendor's own words, rather than run production traffic. The workload here is choosing a named plan that matches actual RAM and CPU need rather than defaulting to the cheapest option and hitting a ceiling later.

What the documents show

Verified: the pricing page states a Free web-service tier at $0 per month with 512 MB of RAM and 0.1 CPU; a Starter tier at $7 per month (512 MB RAM, 0.5 CPU); a Standard tier at $25 per month (2 GB RAM, 1 CPU); and higher tiers running from $85 per month (4 GB RAM, 2 CPU) up to $450 per month (32 GB RAM, 8 CPU) for the top named web-service plan. Verified: for managed Postgres, the same page states a Free tier limited to 30 days, with 256 MB of RAM and up to 100 connections, and paid tiers starting at $10 per month (256 MB RAM, 250 connections) running as high as $1,100 per month (40 GB RAM, 40,000 connections). The page states these as current prices; it does not state when they last changed.

The operating cost

Verified: entry cost for a web service is $0 per month on Free, or $7 per month for the smallest paid tier (Starter). A managed Postgres database adds a separate charge, starting at $10 per month once the 30-day free period ends. Estimated: one small web service plus one small database at the lowest paid tiers totals $17 per month before add-ons; this is the drafting agent's arithmetic on the page's own two figures, not a bundle Render itself states.

The stop condition

The pricing page does not name a point at which a paid plan should be resized; that is left to the account holder. Editorially, the tier structure suggests its own stop condition: since each tier is a fixed RAM and CPU allotment rather than a usage meter, the point to move up is when the current tier is memory- or CPU-constrained under real load, not before, since nothing rewards provisioning ahead of need.

• Does the chosen tier's RAM and CPU allotment match the service's actual peak load, or was it picked by price alone?
• Is the Free tier being used for anything beyond exploration, preview or a personal project, which the vendor states is its intended purpose?
• Does the 30-day limit on Free Postgres mean the database needs to move to a paid tier before that period ends?

A single pricing page covering four product types requires reading each row for the specific service in question; the figures above describe only what that page stated on the day it was retrieved.