Railway vs Render: compare the whole app bill

Published on November 8, 2026 by Steven Jones

Railway vs Render looks like a $20 versus $25 decision until you put an entire application on the invoice. We compared an always-on API, a background worker, PostgreSQL and one persistent preview environment, including memory, CPU, disk and outbound traffic. The calculations use published US dollar tariffs checked on 8 November 2026, not claimed deployment tests.

For the example below, Railway costs $50.75/month. Render costs $77.40 for a solo developer maintaining a preview manually on Hobby, or $99.40 on Pro with full-stack preview features. The difference is partly metered compute versus fixed instances, but also the database service and workspace features you are buying.

Railway vs Render: the decision matrix

Buying question	Railway	Render	Practical winner
Low average CPU, several small services	Pay for measured CPU and RAM	Pay for the selected instance size	Railway in our example
Predictable cost for a continuously busy service	CPU usage raises the bill	Fixed-price compute tier	Render if its tier fits
One developer with a manually maintained staging stack	Hobby: $5 minimum including $5 usage	Hobby: no workspace fee	Calculate the full stack
Three developers and automated full-stack PR previews	Pro: $20 usage minimum; seats included	Pro: $25 workspace fee; seats included	Railway on this workload
PostgreSQL recovery without configuring the backup system yourself	Backups and point-in-time recovery need enabling and verification	Paid managed Postgres includes point-in-time recovery	Render for lower operating effort
Large memory increase in one worker	Additional measured RAM increases cost gradually	May require a jump to a larger instance	Depends on measured usage

One correction to older comparisons: Render removed per-member fees from its new Pro plan in April 2026 and completed the migration from legacy plans in August. Railway Pro also includes workspace seats at no extra charge. A three-person team is not three times either platform’s advertised plan price.

---

---

The workload: six running services, not one web app

Our test case is a small transactional application. Production has a public API, a continuously running job worker and a PostgreSQL database. Preview duplicates those three services, uses a separate database and stays available for the entire 30-day comparison month. We assume a single instance of each service, no high-availability replica, no Redis and no separate persistent upload disk.

Service	Production average RAM	Production average vCPU used	Preview average RAM	Preview average vCPU used	Render compute price per instance
API	0.5 GB	0.10	0.5 GB	0.02	$7/month, 0.5 CPU / 512 MB
Worker	0.5 GB	0.05	0.5 GB	0.01	$7/month, 0.5 CPU / 512 MB
PostgreSQL	1 GB	0.10	1 GB	0.02	$19/month, 1 GB database

Each database reserves 5 GB of storage. Outbound traffic totals 65 GB/month, split into 60 GB from production and 5 GB from preview. The worker runs continuously even when its queue is empty. The RAM figures are assumed to be measured usage on Railway, whereas Render prices a provisioned capacity: equal-looking numbers do not guarantee identical throughput or memory headroom.

Reproduce the monthly invoice, line by line.

Railway’s published application rates are $10 per GB-month of RAM, $20 per vCPU-month of CPU use, $0.15 per GB-month of volume storage and $0.05 per GB of service egress. Its Hobby and Pro subscriptions are minimum spend commitments: the first $5 or $20 of usage is already included, not added again. The official Railway billing explanation shows how the usage offset works.

Railway line item	Calculation for 30 days	Cost
Production RAM and CPU	(2 GB x $10) + (0.25 vCPU x $20)	$25.00
Preview RAM and CPU	(2 GB x $10) + (0.05 vCPU x $20)	$21.00
Postgres volumes	(5 GB + 5 GB) x $0.15	$1.50
Service egress	65 GB x $0.05	$3.25
Total, Hobby or Pro	MAX($5 or $20 plan minimum, $50.75 usage)	$50.75

Render charges the selected compute plan while it runs. We use two $7 services and a $19 managed PostgreSQL instance per environment. Each paid database includes its first 1 GB of storage; the other 4 GB costs $0.30 per GB-month. The current Hobby workspace includes 5 GB of outbound bandwidth, while Pro includes 25 GB. Both charge $0.15 per GB over the allowance.

Render line item	Hobby, manual preview	Pro, full-stack preview
API, worker, Postgres in production	$33.00	$33.00
Same three instances in preview	$33.00	$33.00
Extra PostgreSQL storage	$2.40	$2.40
65 GB outbound traffic after allowance	$9.00	$6.00
Workspace subscription	$0.00	$25.00
Total	$77.40	$99.40

Render Hobby is a valid solo-developer comparison only when the second environment is built and maintained manually. Its automatic full-stack pull-request preview feature requires Pro. Render’s preview environments provision fresh databases rather than copying production data, and automatically clean up when the associated pull request closes. Persistent staging, full-stack PR previews and single-service previews are different products; do not price them as interchangeable.

The reusable cost worksheet

Change the RAM, average CPU, volume size, outbound traffic and preview lifetime to fit your application. Use a 30-day month and the published monthly equivalents below. preview_fraction is preview days divided by 30. The example’s value is 1 for an always-on preview or 0.1 for three days.

Railway usage =
  (production_RAM_GB + preview_RAM_GB * preview_fraction) * 10
+ (production_avg_vCPU + preview_avg_vCPU * preview_fraction) * 20
+ (production_volume_GB + preview_volume_GB * preview_fraction) * 0.15
+ total_egress_GB * 0.05

Railway bill = MAX(plan_minimum, Railway usage)

Render bill = workspace_fee
+ production_instance_prices
+ preview_instance_prices * preview_fraction
+ (MAX(production_DB_GB - 1, 0)
   + MAX(preview_DB_GB - 1, 0) * preview_fraction) * 0.30
+ MAX(total_egress_GB - included_bandwidth_GB, 0) * 0.15

Here is the simplest useful sensitivity test: cut preview runtime from 30 days to 72 hours without changing total traffic. All preview compute and database storage are prorated; production remains online for the month.

Preview runtime	Railway	Render Hobby, manual	Render Pro
30 days	$50.75	$77.40	$99.40
72 hours	$31.18	$46.62	$68.62

These are workload estimates, not guaranteed invoices. Extra replicas, backup storage or exports, custom domains beyond allowances, external object storage, build-minute overages, third-party monitoring and taxes are excluded. Railway’s separate Agent or sandbox usage is excluded too. If you use a managed database from another supplier, replace the database compute and storage rows with that supplier’s real charges.

Two changes that can reverse the cheaper-platform decision

Measure CPU before choosing the cheaper instance

At 0.5 GB of RAM, a Railway service costs $5/month in memory plus $20 for every average vCPU used. At an average 0.10 vCPU, it reaches $7 in compute, equal to Render’s 512 MB starter tier. At 0.20 vCPU it reaches $9, while the Render tier remains $7 if the service still fits its CPU and memory limits. That is a service-level crossover, not a promise that Render wins the whole invoice: workspace fees, Postgres, and egress still count.

Watch the step up from 512 MB

If the worker actually needs 0.8 GB of RAM, Railway’s memory charge rises by approximately $3/month for each continuously running worker, assuming CPU stays constant. Render’s next general service tier is 2 GB at $25/month, an $18 jump from the $7 tier, across production and a permanent preview that is $6 extra on Railway versus $36 extra on Render. Render buys more reserved CPU and memory in that upgrade, so compare performance requirements before treating the price difference as waste.

The database is an operating decision, not just another line item.

Render’s paid managed PostgreSQL includes continuous point-in-time recovery. The advertised recovery window is three days on Hobby and seven on Pro, but a restore creates another billable instance that you must validate before switching application connections. Railway offers PostgreSQL provisioning, backups, point-in-time recovery, and high-availability options, but those protections need proper configuration and ongoing checks. Neither platform can make an unsafe schema migration disappear by rolling back application code.

The strongest reason to accept Render’s higher modelled bill is not the brand name. It is a preference for its managed database operating model, predictable instance charges and explicit restoration workflow. Railway gives more freedom to pay for measured low utilisation, but you still need an owner for alerting, backup retention, restore drills, connection pooling and capacity limits. If losing two hours of orders is unacceptable, specify an achievable recovery point and recovery time before comparing prices.

Persistent disks introduce another trap. On Render, attaching a disk to an application service prevents zero-downtime deploys and multi-instance scaling for that service. Keep uploads in object storage where suitable, and leave the API and worker replaceable. That keeps a cheap disk from becoming a deployment constraint.

Your search, your sources

Make DIY AI a preferred source

See more of our reporting in Google Top Stories, AI Overviews and AI Mode.

Add DIY AI on Google

How to keep preview environments from becoming permanent costs

Developer reports repeatedly praise how quickly these platforms get an API online, then reveal a less obvious pattern: the worker, preview database and forgotten test environment consume the budget after the first successful deployment. Prevent that with operational rules rather than a smaller headline plan.

• Limit lifespan. On Render, set a preview expiry policy and consider manual generation for expensive stacks. On Railway, use pull-request environments that are deleted after a PR closes rather than keeping every test branch alive.
• Use safe preview data. Seed synthetic records, replace payment and email credentials, and never assume a copied configuration is safe to expose.
• Size preview separately. Reduce worker replicas or use a smaller database only when the preview still tests the failure modes you care about.
• Audit bills weekly. Compare measured RAM, average CPU, volume size and egress against the worksheet; set alerts below any hard spending limit. A hard limit that stops production is not a free substitute for cost forecasting.
• Perform one restore drill. Time the database recovery and the reconnection of both the API and worker. Keep any temporary recovery database on the bill until you deliberately delete it.

Which should you choose for your next application?

Choose Railway when your API and worker have low average CPU, memory use is variable, the database operations are within your team’s abilities, and you want granular usage billing. The DIY AI Railway hosting review examines its deployment, database and production-readiness limitations in more detail. You can check Railway’s current plans before budgeting.

Choose Render when you value managed PostgreSQL recovery, prefer fixed instance sizing and can justify the workspace feature set. The current $25 Pro plan has unlimited members rather than the old per-member charge. If you only need a solo project with manual staging, avoid buying Pro solely because a comparison has confused staging with full-stack PR previews. Explore Render once you have chosen the appropriate plan.

For an alternative outside both platforms, the application-hosting section of our guide to hosting recommendations from developers explains when a self-managed VPS is worth the administration overhead. The final purchasing test is a week of real workload metrics, a verified database restore and a preview left running long enough to expose its actual cost. No tariff table can establish deployment speed, rollback success or uptime without doing those tests.