Render vs Netlify

Short answer

Once your Netlify app needs a backend that outlives a request, move it to Render. Pairing the platforms is a valid middle step, and staying on Netlify works only while every piece of server logic fits Netlify's function limits. You have three reasonable paths:

• Move everything to Render means running the static site, backend services and database on one platform. It fits when you want one bill and private networking between your backend services and database.
• Pair the platforms means keeping the frontend, Forms and Identity on Netlify and running APIs, workers, scheduled jobs and the database on Render. It works as a middle step when you value Netlify's frontend features and need a long-running backend.
• Stay on Netlify means keeping everything where it is. It fits only while every piece of server logic finishes inside Netlify's fixed function execution limits.

Render's backend services run far longer: Web service responses can take up to 100 minutes. Cron jobs run for up to 12 hours. Background workers run continuously. Web services support WebSockets on every workspace plan. Private networking connects your services to managed Postgres. Render also hosts your static frontend, so the whole app runs on one platform with one bill.

Documentation and prices checked: Render between 2026-09-11 and 2026-10-23, Netlify between 2026-09-14 and 2026-10-23.

Where Netlify Functions hit limits

Netlify offers three kinds of serverless functions, plus Edge Functions:

• Synchronous functions handle request and response work such as API endpoints and server-side rendering.
• Background functions run for up to 15 minutes and don't need to finish before a visitor moves on. Netlify positions them for batch processing, scraping and slower API workflows. A failed invocation retries after one minute, then again two minutes later.
• Scheduled functions run on a regular schedule, much like a cron job.
• Edge Functions run at the network edge for fast, personalized web experiences. They carry tighter per-request limits: 50 ms of CPU execution time per request and a 40-second response header timeout.

Find your workload in the table below to see which limit you'll hit. Limits change, so treat these figures as current, not permanent.

The last two rows are inferences from how functions run, not a separate Netlify limit. Netlify Functions are serverless functions that let you build without managing servers. Each invocation has a fixed execution limit, and none of those limits is configurable. A WebSocket server or queue consumer is a different kind of program: one process that stays up, holds connections open and waits for the next message, with no planned end. The obstacle is that no long-lived process exists to hold the connection.

Scheduled functions deserve special attention. Their 30-second limit is shorter than the 60-second synchronous limit. A scheduled task that does real work, such as rebuilding a search index or generating monthly invoices, often runs past it.

Always-on services on Render

Render runs your backend as dedicated services, including web services, private services, background workers and cron jobs. The following table maps each limit from the previous section to a Render service type:

Every Render workspace plan includes automatic private networking. When your API, worker and cron job share a region, they can reach each other and the database without crossing the public internet. For multistep jobs, Render Workflows adds orchestrated task chains with automatic retries.

Render runs native runtimes for Node.js, Bun, Python, Ruby, Go, Rust and Elixir.

The tradeoff is the billing model. Render charges for provisioned compute, prorated to the second, rather than per invocation. A web service on a paid instance type keeps running whether or not it receives traffic and bills for that running time, prorated to the second. Only Free web services spin down, after 15 minutes without inbound traffic. Cron jobs bill only while they're running, with a $1 monthly minimum per cron job. To learn how the pieces fit together, see multi-service architectures and the service types overview.

Static hosting on each platform

Netlify links your Git repository and deploys to its CDN on every push. It also builds a deploy preview for each pull request. Render redeploys your static site whenever you push to your linked branch. It can generate a preview instance with its own URL for each pull request. Render workspaces retain 5 builds for instant rollback on Hobby and 15 on Pro. Render static sites are free to deploy. Outbound bandwidth and pipeline minutes count against your workspace's included amounts.

Netlify has real frontend strengths, and in several cases it means less work for you:

• Forms. Netlify Forms is a customizable form service with spam protection support, and submissions are free on credit plans. Without it, you'd write and host a small endpoint to receive them.
• Identity. Netlify Identity handles user sign-up and login, and it's included at no extra cost on all credit-based plans. For a small team, invite-only Identity is one login with no auth code to write.
• Build plugins. Netlify runs your build with your tool of choice on every push. If that build already depends on Netlify build plugins, keeping the frontend on Netlify means you don't rebuild that pipeline.
• Edge features. Traffic rules and basic rate limiting come with the Free plan and carry into every higher plan. Edge Functions handle fast, personalized responses at the network edge.

Databases on each platform

Render Postgres provides fully managed relational storage. Each database has an internal URL for Render services in the same region and an external URL for everything else. On every workspace plan, inbound IP rules let you accept incoming connections to Postgres and Key Value only from IP ranges you specify. All paid databases include point-in-time recovery, with a 3-day window on Hobby and 7 days on Pro. Larger instances add read replicas and high availability. Paid instances start at $6 per month. Free databases expire 30 days after creation. For caching and job queues, Render Key Value is fully managed Redis-compatible storage.

Netlify now has its own database. Netlify Database is a fully managed Postgres database built into the platform, which you can query from Functions, Edge Functions, builds and Agent Runners. It's available only on credit-based plans. Netlify bills it on actual usage of compute and bandwidth. Database compute costs 10 credits per compute unit. In Netlify's billing example, the default settings auto-scale between 1 and 4 compute units and the database sleeps after 5 minutes of idle time. Netlify's Database billing and usage docs say storage is billed no earlier than July 1, 2026, with rates announced in advance. That date has passed, so check that page for the current storage rate before you estimate your own costs. You can also connect any Postgres provider instead. That route means a second account and a second bill.

The tie back to functions is connection handling. Netlify ships a driver for Netlify Database that's automatically configured and optimized for its platform. On Render, a background worker runs on an ongoing, continuous basis. Because a Render web service or worker is one long-running process, it can hold a connection pool open to Postgres over the internal URL, which serves connections from other Render services in the same region. Each function invocation, by contrast, is short-lived and ends at a fixed execution limit.

The pricing crossover

Prices, plan names and limits change on both platforms. Use the figures below as a snapshot and confirm current numbers on Netlify's pricing page and Render's pricing page. All prices are in US dollars as published on those pages. Every usage-based total below is an illustrative estimate built on the stated assumptions.

Two terms drive the Netlify math. A credit is the unit Netlify's credit-based plans use to meter usage. A GB-hour is function memory allocation multiplied by execution time. GB-hours apply to function compute. Netlify Database compute is metered separately, in compute units.

The plans involved

On Netlify's Free plan, projects pause when credits run out. The Netlify Personal plan targets individuals. Netlify Pro adds organization-level features for teams.

Illustrative assumptions

• Stage 1, static only. 10 GB bandwidth, 200,000 web requests and 20 production deploys per month.
• Stage 2, light API. Stage 1 plus 300,000 function calls per month, each running 200 ms at 1 GB of memory.
• Stage 3, full backend. Stage 2 plus a video job that takes 20 minutes per run, a nightly report that takes 45 minutes, and a Postgres database that stays active all month with 5 GB of storage. On Render, the video job runs on an always-on worker, and the report runs as a cron job for 45 minutes × 30 nights = 1,350 minutes. A 512 MB worker may not have enough memory for real video processing, so treat the worker line as a placeholder and size it to your workload.

Netlify path (illustrative)

Stage 3 uses Pro because Personal's auto recharge adds 500 credits for $5, so 8,067 credits on Personal would cost $9 + 15 × $5 = $84, more than Pro's 10,000-credit tier at $63.

Stage 2 compute is 300,000 × 0.2 seconds × 1 GB = 60,000 GB-seconds, or about 16.7 GB-hours at 10 credits each. Stage 3 database compute assumes the minimum 1 compute unit for 730 hours. Netlify's Database billing page meters compute units per hour at 10 credits per unit (its example bills 33 hours at 1 unit as 33 units), so 730 hours at 1 unit is 730 units, or 7,300 credits. Netlify announces database storage rates separately, so treat the stage 3 Netlify figure as a floor rather than a full total.

Render path (illustrative, Hobby workspace)

Stage 3 breaks down as $7.75 + $7 + $1 + $19 + $1.50 = $36.25. The cron job's 1,350 minutes cost $0.22, below Render's $1 monthly minimum per cron job.

Pairing path (illustrative)

This estimate assumes the API's traffic stays within Render Hobby's 5 GB of included bandwidth. It also assumes the frontend calls the API on its own subdomain. If you proxy the API through Netlify instead, those requests and their bandwidth also consume Netlify credits (2 credits per 10,000 requests, 20 credits per GB), which these totals don't include.

Team plans (illustrative)

Teams that need organization features need Netlify Pro. Render Pro includes 25 GB of bandwidth, so the 10 GB in these assumptions fits within it and produces no bandwidth charge.

The Netlify stage 3 figure excludes the video job and nightly report, which exceed Netlify's function limits, and database storage, which Netlify announces separately. The Render and pairing figures include all three.

For teams, pairing costs the most because you pay two workspace fees. That difference buys you Netlify's frontend features.

Where the crossover happens

Through stage 2, the estimates sit within a few dollars of each other: $9 on Netlify Personal against $7.75 on Render Hobby. Stage 3 changes the comparison in two ways:

• Long jobs exceed Netlify's fixed limits. The 20-minute video job exceeds the 15-minute background execution limit. The 45-minute nightly report exceeds both the 30-second scheduled execution limit and the 15-minute background execution limit, and none of these limits is configurable. You'd have to split those jobs into smaller chunks or run them somewhere else, so no clean cost comparison exists.
• An always-active database drives the bill up. That one line moves the Netlify estimate from 767 credits to 8,067.

Render's compute model tends to cost less for long-running work and steady traffic, while serverless tends to cost less for short, intermittent tasks. You reach the crossover when your backend gains steady or long-running work.

Using both: Netlify frontend, Render backend

Keep Forms, Identity, any build plugins and edge rules on Netlify. Run APIs, workers, cron jobs and Postgres on Render.

Plan these integration points:

• Routing. Either call the backend from its own subdomain, or proxy a path through Netlify. Netlify's redirect rules in netlify.toml support proxy redirects, including signed proxy redirects. A typical pattern is app.example.com for the frontend and api.example.com for the Render web service.
• CORS. With a separate API subdomain, configure your backend to accept requests from your frontend's origin. A same-origin proxy avoids this step.
• Backend URL. Store the API URL as an environment variable in your Netlify build. Netlify Pro adds shared environment variables for teams. Render services support environment variables and secret files on every plan.
• Authorization. Signing a user in on the frontend doesn't authorize them on your Render API. Have the frontend send the signed-in user's token with each API call, and have the backend validate that token before it returns data.
• Private database. Connect your Render services to Postgres over its internal URL. On Hobby and Pro workspaces, inbound IP rules apply to datastores (Postgres and Key Value), and Scale and Enterprise extend them to all services. Inbound IP rules allow incoming connections only from IP ranges you specify.

Pairing has costs. You manage two platforms, two bills and two dashboards. Every API call crosses providers, and proxying through Netlify adds a hop, so measure latency for both routing options before you commit.

If Netlify's frontend features stop pulling their weight, consolidating on Render removes the second platform. If you replace Forms with your own endpoint, or move auth into your backend, the frontend becomes a plain static build. At that point, a free Render static site removes the second platform.

Which path fits your app

Netlify's strengths are concrete. Forms submissions are free on credit plans. Identity is included at no extra cost on credit-based plans. Traffic rules and basic rate limiting are included from the Free plan up. An existing Netlify build pipeline is also a reason to keep the frontend where it is.

Render's case gets stronger once your backend becomes a set of running processes. Web services hold responses for up to 100 minutes, cron jobs run for up to 12 hours, and background workers run continuously. These services connect privately to managed Postgres in the same region. Move the app to Render once it needs a backend that outlives a request. Pairing keeps Netlify's frontend features while you move the backend first.

Frequently asked questions