Fly.io vs Render in 2026: Real Pricing, Free Tiers, and the Postgres Trap Nobody Mentions

"Fly.io vs Render" searches usually start with a sticker-price question and end up somewhere else entirely once the free tier runs out or the first Postgres crash happens at 2am. This brief compares what each platform actually charges today, what "free" really covers, and - the part most comparison posts skip - what happens to your database when something goes wrong. We pulled the numbers below directly from each vendor's own documentation the same day this page was updated, not from a screenshot that might be a year stale.

Use this page when you're about to run a real trial, not when you're browsing. The safest decision starts with one real workload, one budget ceiling, and a clear answer to "who's on the hook if the database falls over at 2am." If you can't answer that last one yet, the pricing table below won't save you from a bad choice - it'll just help you make it with better numbers.

The five-minute verdict

If you only read one paragraph: Fly.io wins when you need Machines running in specific regions close to your users and you're willing to either operate Postgres yourself or pay separately for a managed database product. Render wins when you want one bill, one dashboard, and a database that's actually someone else's problem to keep alive - plus a free tier generous enough to prototype on before you spend anything. Neither platform is "wrong" for a given team; they're solving slightly different problems, and the database question below is where that difference shows up hardest.

What compute actually costs today

Fly.io bills Machines per second against named CPU/RAM presets, and the exact rate depends on region. Render bills web services as flat monthly instance tiers. Here's what each looks like at the low end, verified 2026-07-12:

* Render's own marketing pricing page (render.com/pricing) loads its plan grid through client-side JavaScript. A direct text fetch of that page on 2026-07-12 returned navigation and footer content only - zero dollar figures rendered into the static HTML we could read. The RAM/CPU specs above are confirmed directly from Render's own compute-plans documentation, which does render as plain text. The dollar amounts are corroborated by three independent third-party pricing trackers referencing Render's current plan grid as of 2026-07-12, not confirmed by our own direct fetch of the official page. Check the live number at render.com/pricing before you commit a budget, since that JS-rendered page is the only place the current headline rate is authoritative.

Fly also layers on RAM beyond a preset at about $5 per 30 days per additional GB, plus separate line items for stopped-Machine storage ($0.15/GB per 30 days), provisioned volumes ($0.15/GB/month), and a dedicated IPv4 address ($2/mo) if you want one. Render folds persistent disk into a flat $0.25/GB/month rate, but a dedicated/static outbound IP is its own paid add-on (Pro workspace plan or higher, billed monthly per IP set) rather than something included free on paid plans. Neither approach is inherently cheaper - Fly's itemized model rewards precise capacity planning, Render's bundled model rewards not having to think about it, and Fly's $2/mo dedicated IPv4 is the simpler of the two IP options.

The database question most comparisons skip

This is the part that actually changes a production decision, and it's asymmetric between the two platforms in a way the marketing pages don't make obvious.

Render Postgres is genuinely managed, billed in the same relationship as your web service. Storage runs $0.30/GB/month, and Render's own cost-guide article walks through a real example: "an always-on Starter web service plus a Basic-256mb Postgres instance on a Hobby workspace typically ran about $13/month." There's also a free Postgres tier - 1GB of storage - but it expires after 30 days, so it's a trial, not a production option.

Fly.io splits "Postgres" into two genuinely different products, and confusing them is the mistake this section exists to prevent. The self-managed option (fly postgres create) runs on your own Machines at normal compute pricing, and Fly's own documentation is blunt about what that means: "This is not a managed database. If Postgres crashes because it ran out of memory or disk space, you'll need to do a little work to get it back." The same page states plainly: "We are not able to provide support or guidance for unmanaged Postgres." Backups, upgrades, monitoring, and failover are entirely on you.

If you want an actually-managed database on Fly, that's Fly Managed Postgres (MPG) - a separate product with its own pricing: Basic at $38/mo (Shared-2x CPU, 1GB RAM), Starter at $72/mo (2GB RAM), up through Launch at $282/mo (8GB RAM) and Scale at $962/mo (32GB RAM), plus $0.28/GB/month for provisioned storage beyond the plan. Fly's docs list MPG as including automatic backups and recovery, high availability with automatic failover, performance monitoring and metrics, resource scaling, 24/7 support and incident response, and encryption of data at rest and in transit - the things the unmanaged option explicitly does not cover.

The practical takeaway: if a "Fly vs Render" comparison you've read elsewhere treats their databases as roughly equivalent line items, it skipped this distinction. Render's managed Postgres is closer in spirit to Fly's MPG than to Fly's unmanaged option - compare those two against each other, and compare the unmanaged option's near-zero compute cost against the very real operational burden it comes with.

Free tiers, compared honestly

Render's free tier is real and usable: 750 instance hours per workspace per month (enough for one always-on small service, or several part-time ones), with services spinning down after 15 minutes of no inbound traffic and taking about a minute to spin back up on the next request. Free Postgres and free Key Value instances exist too, but both are trial-grade - the database expires after 30 days, and Key Value is in-memory only with no disk persistence.

Fly.io's current pricing documentation doesn't list a comparable free compute allowance. The smallest paid Machine (Shared-cpu-1x, 256MB) runs about $2.02/month in Amsterdam, and billing starts immediately - there's no always-free tier to prototype against before that. Fly does give small free allowances in adjacent areas (the first 10GB of volume snapshots per month, the first 10 single-hostname SSL certificates), but none of that substitutes for a genuinely free compute tier.

For a weekend project or an evaluation you're not ready to pay for yet, that difference alone can decide the platform before pricing tiers even enter the conversation.

Bandwidth: the line item nobody budgets for

Fly.io prices outbound data transfer by region, which rewards knowing where your users actually are and punishes guessing wrong:

Render charges a flat $0.15/GB worldwide, confirmed directly from Render's own cost-guide article. Fly's tiered rates run from $0.02/GB in North America and Europe up to $0.12/GB in Africa and India, with lower cross-region rates for traffic that stays inside Fly's network. If most of your traffic is North American or European, Fly's bandwidth is meaningfully cheaper than Render's flat rate. If a meaningful share of your users are in regions Fly prices at $0.12/GB, that advantage shrinks or reverses - run your actual traffic split through both rate cards before assuming either platform wins on bandwidth.

Who should actually pick what

Pick Fly.io if: you need Machines running in specific regions close to your users (Fly's regional footprint is the platform's core differentiator), and you've already decided how you'll handle the database - either by budgeting for Managed Postgres or by genuinely committing to operate Postgres yourself, backups and all. Fly rewards teams with real infrastructure opinions and punishes teams who assume "it just works" the way a fully managed platform would.

Pick Render if: you want one bill, one dashboard, and a database that's Render's problem to keep running, not yours. The 750 free hours make it the lower-risk choice for prototyping, and the itemized cost example in Render's own docs ($13/month for a small always-on service plus database) is a real number you can budget against without guessing at a per-second rate.

Look elsewhere if: you're choosing based on lowest possible sticker price alone. Fly's per-second Machine pricing and Render's flat instance tiers are both reasonable for a real production workload - the platform that actually saves you money is the one whose operational model matches how much database and infrastructure work your team wants to own, and that number rarely shows up on a pricing page.

Honest tradeoffs nobody puts in the demo

Fly's tradeoff: granular, itemized pricing rewards precise capacity planning and punishes anyone who doesn't do it. The unmanaged Postgres option is genuinely inexpensive - and genuinely means you are the on-call database engineer, per Fly's own documentation, not implied by omission.

Render's tradeoff: the bundled, managed model costs more per raw compute unit for teams that would happily self-manage a database to save money, and the marketing pricing page's client-side rendering makes it harder to do the kind of quick screenshot-and-compare research that Fly's plain-text docs pages allow.

How to actually run this evaluation

Don't decide from a pricing page alone - run the shortlist against one real, currently-painful workload:

1. Pick the actual workload - the service and database size you'll really run, not a toy example sized to make one platform look better.
2. Price both platforms against that exact spec, including the database. If you'd need Fly Managed Postgres to match Render's managed database, price MPG - not Fly's unmanaged option - as the honest comparison.
3. Time-box a real deploy on your top choice using the free tier or a short trial, and note the first limit you actually hit (free-hour cap, bandwidth region surprise, a Postgres crash you have to fix yourself).
4. Price the switch cost, not just the monthly delta - migrating a database and re-pointing DNS costs real hours even when the destination platform is objectively cheaper.
5. Write down who owns the database before you commit. This is the question the sticker price can't answer, and it's the one that actually predicts your 2am experience six months from now.

The bottom line

"Fly.io vs Render" is really two separate questions wearing one search query: where do you need compute to run, and who do you want operating your database. Answer those before comparing the per-second and per-month numbers, because the platform that wins on sticker price is not always the one that wins on the 2am question.

Prices and specs verified directly against fly.io/docs/about/pricing, fly.io/docs/mpg, fly.io/docs/postgres, render.com/docs/compute-plans, render.com/docs/free, and render.com's cost-guide article on 2026-07-12.

Keep reading

• Railway vs Render in 2026 — if Render's on your shortlist, this is the other head-to-head worth reading before you commit.
• Fly.io review — a deeper look at Fly's platform beyond pricing, including the regional-deploy workflow this brief only touches on.
• Render alternatives — the wider shortlist if neither Fly nor Render's operating model fits your team.
• Vercel alternatives for backend-heavy apps — if your workload is frontend-first rather than a full backend service, this comparison covers different ground entirely.