Railway 料金比較：Renderとの違いと選び方【2026年版】

Railway 料金比較でまず見るべきは、Railwayのように実際に使ったリソースへ課金する方式と、Renderのように決まった処理能力を確保する方式のどちらが合うかです。本記事の小規模アプリの試算では、月額はRailway Hobbyが$15.11、Render Hobbyが$20になります。ただし、Renderにはデータベースの復旧機能が含まれ、Railwayの試算にはその費用を含めていません。リソースを柔軟に使いたいならRailway、インスタンス費用の見通しやPostgresの復旧機能を重視するならRenderが候補です。

RailwayとRender、どちらを選ぶべきですか？

アプリとバックグラウンドワーカーを常時動かし、復旧機能付きの有料Postgresを使いたい創業者には、Renderが向いています。 ワーカーとは、メール送信やレポート作成などを別のプロセスで処理し、ユーザーを待たせないための仕組みです。Renderではサービスごとにコンピュートのサイズを選ぶため、基本となる月額費用を見積もりやすくなります。

複数のサービスを柔軟に組み合わせて動かしたい方で、リソースの使用量を継続的に確認できるなら、Railwayが向いています。 Railwayは、サービスが使用したCPUとメモリに応じて課金するアプリホスティング基盤です。プロジェクトを視覚的に把握できるキャンバスでは、アプリ、ワーカー、データベースのつながりを追いやすくなっています。常時稼働させていても、CPU使用量が少なければ費用を抑えられます。

小規模チームでは、マシンの料金に加えてワークスペースのプランも比較してください。Railway Proの最低料金にはリソース使用料が含まれますが、Render Proではコンピュート料金にワークスペース料金が加算されます。個人で事業を立ち上げる場合は、どちらのHobbyワークスペースも検討できます。ただし、安くデプロイできることと、本番運用に耐えるデータベース構成になっていることは別です。

料金と機能は、2026年10月18日に両社の公開料金ページとドキュメントで確認しています。 判断の基準は、課金方式、標準の復旧機能、バックグラウンドジョブの挙動、スケーリングの制御方法です。料金例は、公表単価と明示した前提条件に基づく計算です。実際のデプロイ試験や性能ベンチマークではありません。

これらの違いは、RailwayのPostgresドキュメント、Renderの復旧ドキュメント、および後述する各プラットフォームのスケーリング仕様に基づいています。

Railway 料金比較：同じ小規模アプリをRenderで動かすといくらですか？

今回のCPU使用量が少ないモデルではRailwayが安く、稼働前にコンピュート料金の小計を把握しやすい点ではRenderが有利です。 どちらかが常に安いという意味ではありません。Railwayは実際の使用量を計測し、Renderは選んだインスタンスの稼働時間に応じて課金します。Renderでは、月の一部だけ稼働した場合、その時間分の料金になります。

Railwayの現行プランは、Freeが$0、Hobbyが月額最低$5、Proが最低$20、Enterpriseが個別見積もりです。HobbyとProの最低料金は、それぞれリソース使用料に充当されます。Proではワークスペースの席数が無制限です。Railwayの料金。

Renderの現行ワークスペースプランは、Hobbyが$0、Proが月額$25、Scaleが$499、Enterpriseが個別見積もりで、コンピュート料金は別途かかります。Proは席数無制限で、開発者ごとの課金ではありません。Hobbyには5 GB、Proには25 GBのデータ転送量が含まれ、超過分は1 GBあたり$0.15です。Renderの料金。

試算するワークロードの前提

創業者が運営する小規模な予約アプリを想定します。構成は、Web/APIサービス、既存のPostgresを使ってジョブを処理する常時稼働ワーカー、単一ノードのPostgresサービスがそれぞれ一つです。キューのために別のキャッシュが必要なら、その費用も増えますが、ここでは含めません。

試算期間は30日、つまり2,592,000秒です。すべてのサービスを常時稼働させます。課金対象となるメモリの平均使用量は、Webサービスが0.5 GB、ワーカーが0.5 GB、Postgresが0.25 GBで、合計1.25 GBです。平均アクティブCPU使用量は順に0.05、0.05、0.02 vCPUで、合計0.12 vCPUとします。vCPUは処理能力の単位です。平均0.12 vCPUとは、月を通して平均するとその分のCPU処理を行ったという意味であり、その値がマシンの公称サイズを表すという意味ではありません。

データベースのボリューム使用量は月を通して1 GB、インターネットへの送信データ量は1 GBとします。データベースへの接続はプライベートネットワーク内に収め、ビルドはプランの付属枠内とします。レプリカ、ステージング環境、追加ディスク、高可用性用のノードは設けません。税金、ドメイン登録料、アプリが利用するAPIの料金も含めません。

Renderでは、Web用に**$7の0.5c-512mb**、ワーカー用にも**$7の0.5c-512mb**、Postgres用に**$6の0.1c-256mb**インスタンスを選びます。料金ページにはデータベースストレージ1 GBを含むと記載されており、作成手順のドキュメントでもこの初期サイズを選べます。あえて小さなインスタンスで比較しているのであって、すべての本番アプリがこのサイズに収まると勧めているわけではありません。コンピュート料金、データベースストレージの設定。

そろえているのはアプリの構成要素と想定負荷であり、ハードウェア性能ではありません。Railway側のメモリとCPUは実使用量として試算に入れる値で、Render側のインスタンスサイズは利用できる容量の上限です。その上限で足りると判断する前に、自分のアプリで負荷テストを行ってください。

月額料金を実際に計算する

Railwayの表示単価は、メモリが1 GB・秒あたり$0.00000386、CPUが1 vCPU・秒あたり$0.00000772、ボリュームストレージが1 GB・秒あたり$0.00000006、サービスからの送信データが1 GBあたり$0.05です。この表示単価をそのまま前提条件に掛けると、次のようになります。Railwayのリソース料金。

リソース単価はRailway、インスタンスとワークスペースの料金はRender、Railwayの最低料金を利用料に充当する扱いはプランのドキュメントに基づきます。途中の計算結果は丸めずに合計しています。Railwayが掲載する丸め済みの月額参考単価を使うとセント単位でわずかな差が出るため、ここでは30日間の計算を一貫して表示の秒単価で行っています。

どの使用量で料金が逆転しますか？

今回のHobby比較では、三つのサービスを合わせた平均アクティブCPU使用量が約0.364 vCPUを超えると、Renderの方が安くなります。 ただし、各サービスが選択したRenderインスタンスの容量内に収まることが条件です。メモリ、ボリューム使用量、データ転送量、インスタンス数を変えなければ、Railwayの月間リソース料金は**$12.71192 + $20.01024 × 平均アクティブvCPU**です。これをRenderの$20と等しくなるように解くと、逆転する使用量が求められます。

平均0.12 vCPUなら、Railwayは$15.11です。0.30では$18.71、0.50では$22.72、0.70では$26.72になります。Renderが$20のままで済むのは、選択したインスタンスでその負荷を処理できる間だけです。これは使用量を変えた場合の料金試算であり、性能の実測値や秒間リクエスト数の推定ではありません。

アクセスが増えなくても、メモリ使用量によって料金は変わります。今回の試算期間では、平均メモリ使用量が1 GB増えるごとに、Railwayのリソース料金は約$10.01増えます。これはプランの最低料金による影響を考慮する前の金額です。ジョブを待っているワーカーもメモリを保持することがあるため、「アイドル状態」でも「無料」とは限りません。

費用の見通しを立てやすいのはRenderです。 インスタンスのサイズと数を固定すれば、コンピュート料金の小計が決まります。データ転送、付属枠を超えるビルド、ストレージの増加分は別に予算を確保してください。Railwayでは使用量アラートを設定し、実際の消費量を確認しましょう。コンピュート料金のハードリミットに達するとワークロードは停止します。これは支出を止める仕組みであり、定額で無制限のアクセスを処理し続ける仕組みではありません。

無料枠はどこまで使えますか？デモ向けの条件と制限

無料のWebデモならRenderが有利ですが、今回の構成全体を本番運用する標準的な選択肢としては、どちらの無料枠も適していません。 Renderでは、ワークスペースごとに毎暦月750時間分の無料Webインスタンスを利用できます。ただし、無料Webサービスは外部からのアクセスが15分間ないとスリープします。無料Postgresは30日で期限が切れ、バックグラウンドワーカーとcronジョブには無料のインスタンスタイプがありません。Renderの無料サービスの制限。

Railwayには現在、継続して利用できるFreeプランがあります。新規アカウントには、最長30日間使える$5のトライアルクレジットが一度付与され、その後は毎月$1の無料クレジットを受け取れます。無料サービスではメモリとボリュームの上限が厳しく、このプランでcronを使えるのはトライアル期間中だけです。毎月のクレジットは少額の利用枠であり、三つのサービスで構成されたアプリなら、どれでも無料で動かせるという保証ではありません。Railwayの無料プランの詳細。

デモならスリープを許容できる場合もあります。しかし、有料の予約を入れようとしている顧客にアプリの起動を待たせたり、データベースの期限切れで使えなくなったりするのは、費用を抑える代償として大きすぎます。有料サービスの構成を意識して選んでください。Renderではワークスペースだけをアップグレードしても、無料サービスのコンピュートプランは変わりません。

マネージドPostgres：復旧機能を標準で含むRenderが有利

小さな有料データベースでも復旧機能を最初から使いたいならRender、設定の手間をかけてもデータベース基盤を柔軟に構成したいならRailwayが向いています。 PostgreSQLは一般にPostgresと略され、ユーザー、注文、予約といったレコードを保存するリレーショナルデータベースです。

Renderは有料Postgresインスタンスを継続的にバックアップし、過去の任意の時点へデータを戻せるポイントインタイムリカバリを提供します。復旧できる期間はHobbyワークスペースで3日間、Pro以上で7日間です。復元すると別のデータベースが作成されるため、その内容を検証してからアプリの接続先を切り替えます。Renderの復旧とエクスポート。

Railwayの現行Postgresテンプレートは、Railway自身がメンテナンスしています。高可用性構成への変換機能と、オプションのポイントインタイムリカバリも用意されています。全体を「アンマネージドのPostgres」と呼ぶと、この違いを見落とします。ただし、テンプレートのイメージ、起動コマンド、変数を変更すると、管理責任が利用者側に戻る場合があります。Railwayが管理するPostgresの範囲。

Railwayの復旧機能は有効化が必要です。アーカイブはストレージバケットに保存され、その保存料とデータベースからのアップロード通信料がかかります。Postgresのドキュメントでは、アーカイブが蓄積されると、およそ四週間分の復旧履歴を利用できると説明されています。便利な機能ですが、復旧可能な期間が料金に含まれるRenderとは、設定も課金方式も異なります。Railwayのポイントインタイムリカバリ。

データの復旧と自動フェイルオーバーは何が違いますか？

バックアップはデータの消失に備えるもの、高可用性はデータベースノードが利用できなくなる事態に備えるものです。 誤ったマイグレーションで予約データを削除すると、その削除がスタンバイにも複製されることがあります。この場合に必要なのは、削除前の状態へ戻せることです。一方、プライマリデータベースが停止した場合には、アーカイブからデータベースを再構築しなくても、スタンバイに処理を引き継がせられます。

Renderの高可用性（HA）構成には、少なくとも1 CPUを備えたPostgresのコンピュートプランが必要です。スタンバイにも、プライマリと同じコンピュート単価とストレージ単価で課金されます。試算に使った$6のデータベースは対象外です。RenderのHA要件。

Railwayで高可用性（HA）構成へ変換すると、データベースのレプリカ、協調制御用のサービス、接続プロキシが追加されます。自動変換が対応するのはRailway公式のPostgresイメージで、PostGISやTimescaleDBなどのカスタムイメージは、この変換方式に対応していません。こうしたイメージに依存するアプリでは、重要な制約になります。RailwayのHA前提条件。

小規模向けプランには明確な上限もあります。Railway Hobbyのボリュームストレージは最大5 GBです。一方、今回のRenderのPostgresインスタンスはRAMが256 MBで、接続数の上限は100です。データ量の増加や多数のデータベース接続によって、CPU料金を比較する前に構成を変えなければならないことがあります。Railwayの上限、Renderのデータベースサイズ。

創業者にとって実務上の問題は、誰が異常に気づき、データを復元し、予約情報が正しいかを確認するかです。自分たちで運用できる復旧構成を選び、失うと取り戻せないデータを保存する前に、復元の手順を一度試してください。

ワーカーとcron：ジョブの制御が明確なRenderが有利

Web、ワーカー、定期実行ジョブをそれぞれ別のサービスとして定義したいチームには、Renderが分かりやすい選択肢です。 Renderのバックグラウンドワーカーは常時稼働し、外部からのネットワーク通信を受け付けずに、キューに入った処理を実行します。Railwayでも、公開エンドポイントを設けずに、常時稼働サービスとしてワーカーを動かせます。バックグラウンド処理の実行に、ワーカー専用という製品区分が必須なわけではありません。Renderのワーカー、Railwayのサービスモデル。

予約確認メールの送信など、一日を通して随時発生するジョブにはワーカーを使います。毎晩のレポート作成のような処理には、決まった時刻にコマンドを起動するcronを使います。常にポーリングするワーカーと、短時間だけ動く定期実行ジョブではリソースの使い方が違うため、一方の料金をそのまま他方の見積もりに使わないでください。

Railwayでは、サービス設定から標準のcronスケジュールを設定できます。実行間隔は最短5分で、時刻はUTCです。ジョブは処理を終えたら終了しなければなりません。データベース接続を開いたままにするなどして実行中の状態が続くと、Railwayは次の予定実行をスキップします。Railwayのcron仕様。

Renderも時刻にはUTCを使います。前のジョブが実行中なら次の予定実行を遅らせ、実行時間が12時間に達したジョブは停止します。cronサービスごとに月額最低$1がかかり、コンピュート料金は秒単位で計算されます。手動で実行を開始すると、まず実行中のジョブがキャンセルされます。Renderのcronの挙動。

夜間の照合作業では、「スキップする」か「遅らせて実行する」かの違いが重要になります。ジョブは安全に再実行できるようにし、完了を記録し、結果が出ていない場合は通知する仕組みを用意してください。ホスティング基盤はコマンドを起動できますが、業務上の処理が完了したかどうかは、アプリ側で把握する必要があります。

RailwayのオプションであるServerlessを有効にしても、キューワーカーが必ずスリープするとは限りません。データベース接続などの外向き通信によってスリープに入れないことがあり、スリープしたサービスを起こす際にはコールドスタートが発生します。継続的にポーリングするプロセスは、そのまま稼働し続ける可能性があります。Railway Serverlessの挙動。

リージョンとスケーリング：必要な拡張方法で選ぶ

同じサービスのレプリカを複数リージョンに配置するならRailway、CPUやメモリの目標値に合わせてレプリカ数を自動調整するならRenderが有利です。 垂直スケーリングは、一つのインスタンスに割り当てるリソースを増やすことです。水平スケーリングは、動かすインスタンスの数を増やすことです。それぞれ解消できるボトルネックが異なります。

Railwayは、設定した上限までリソース使用量を自動的に拡張します。一方、水平スケーリングのレプリカ数は手動で設定します。複数リージョンのレプリカを使うと、公開サービスへのトラフィックは最寄りのリージョンへ送られます。Renderでインスタンスあたりのリソースを増やすには、より大きなコンピュートプランを選ぶ必要があります。Pro以上のワークスペースでは、CPUやメモリの目標値に応じたインスタンス数の自動調整が可能です。Railwayのスケーリング、Renderのスケーリング。

Railwayが掲載しているリージョンは、カリフォルニア、バージニア、アムステルダム、シンガポールです。Renderは、オレゴン、オハイオ、バージニア、フランクフルト、シンガポールです。どちらかが常に速いという根拠のない主張ではなく、ユーザーの所在地とデータを置くべき場所に合わせて選んでください。Railwayのリージョン、Renderのリージョン。

小規模アプリでは、まずAPI、ワーカー、データベースを同じ場所に配置しましょう。APIを分散しても、データベースへの書き込みまで自動的に分散するわけではありません。拠点を増やせば、データベース処理の多いリクエストが必ず速くなるとも限りません。

運用上の制約もあります。Renderのプライベートネットワークはリージョン単位です。既存のサービスやデータベースのリージョンをそのまま変更することはできず、移行先に新しく作成して移す必要があります。Railwayではリージョンを変更できますが、ボリュームを接続したサービスを移すには、ボリュームの移行とダウンタイムが必要です。また、Renderで永続ディスクを接続したサービスは、複数インスタンスにスケールできません。顧客がアップロードしたファイルをアプリのローカルディスクに保存する前に、確認しておきたい制約です。

プラットフォームの移行：データと運用手順を一緒に移す

乗り換えは、確認できた制約や継続的な費用差が移行を正当化するときに検討してください。管理画面が使いやすそうという理由だけでは不十分です。 Railwayのキャンバスは、サービス同士を視覚的につなぎたい創業者に向いています。RenderのサービスタイプとBlueprintsは、インフラ構成を再現可能な形で管理したいチームに向いています。どちらもリポジトリやコンテナイメージからデプロイできるため、アプリは移しやすい仕組みです。ただし、データベースと運用設定は計画的に移行する必要があります。Renderの移行ガイド、Railwayの移行ガイド。

1. 1

   稼働中の構成を洗い出す

   Webの起動コマンド、ワーカーのコマンド、cronスケジュール、環境変数、シークレット、データベース拡張、ストレージ、ドメインを一覧にします。移行中に二重実行してはいけないジョブも特定してください。

2. 2

   データベース移行を事前に試す

   移行先のデータベースを作成し、エクスポートと復元を試します。スキーマの互換性、必要な拡張、レコード数、アプリの重要なクエリを確認してください。認証情報はソース管理に含めないでください。

3. 3

   最終移行時の書き込みをどう扱うか決める

   最終的なデータ転送中に、書き込みを停止するのか、同期するのかを決めます。必要に応じて定期実行ジョブとワーカーを止め、両方のプラットフォームから同じ確認通知を送ったり、同じ決済を処理したりしないようにしてください。

4. 4

   接続先を切り替え、動作を確認する

   接続文字列とドメインを更新し、実際のアプリの利用フローを試して、バックグラウンドジョブと復旧設定を確認します。旧サービスを廃止する前に、移行先で発生した新たな書き込みも考慮したロールバック計画を用意してください。

今回のHobbyのわずかな差額だけを理由に、正常に動いているアプリを移すのは避けてください。まず移行作業と、一時的に両方を稼働させる費用を見積もる必要があります。顧客データの要件として自動フェイルオーバーが必要なら、拡張したデータベース構成同士で先に比較してください。基本的な三サービス構成の料金だけでは、その判断はできません。

プルリクエストのプレビュー機能と一体化したNext.jsフロントエンドが中心なら、Vercelの方が適しています。このワークフローはNext.jsのデプロイドキュメントで説明されています。当サイトのVercelとNetlifyの比較とVercelの料金ガイドも選定に役立ちます。

仮想マシンのライフサイクル、リソース、地理的な配置を直接制御したいなら、Fly.ioの方が適しています。Machinesのドキュメントで、それらの制御方法を確認できます。

RenderとRailwayを選ぶときの判断基準

サーバー管理を避けたい主な理由が、Postgresの復旧機能を標準で使えることと、インスタンス単位で予算を組めることなら、Renderから検討してください。サービス構成の柔軟性と、使用量に応じた課金を重視するなら、Railwayから検討してください。 Railwayは、複数のサービスからなるアプリでRenderの有力な代替候補になります。ただし、選ぶ以上は、使用量の前提と復旧構成を自分たちで管理する必要があります。

来週は、実際のWeb、ワーカー、データベースの要件を今回の例に当てはめてみてください。メモリ、CPU、送信データ量の仮定を代表的なワークロードの実測値に置き換え、必要な復旧設定を加えたうえで、ワークスペース全体の合計額を比較します。すでにどちらかで問題なく運用できているなら、乗り換えは当然行うべき改善ではなく、費用のかかる事業上のプロジェクトとして判断してください。

よくある質問

RailwayとRenderの無料枠はどう違いますか？

Renderの無料Webサービスは15分間アクセスがないとスリープし、無料Postgresは30日で期限が切れます。Railwayには初回$5のトライアルがあり、その後は毎月$1の無料クレジットを利用できます。Web、ワーカー、データベースを常時稼働させる今回の構成全体に、無制限の無料リソースを提供するものはどちらにもありません。

RailwayとRenderの料金はどちらが安いですか？

前提条件を明示した今回の小規模アプリでは、Railway Hobbyが$15.11、Render Hobbyが$20です。Proワークスペースではそれぞれ$20と$45になります。これは条件を置いた試算であり、どのアプリにも当てはまる料金ではありません。Railwayの復旧用アーカイブ費用は含めておらず、Renderの有料データベースの復旧機能は料金に含まれます。

バックエンドにはRailwayとRenderのどちらが向いていますか？

どちらもAPI、バックグラウンド処理、Postgresを動かせます。有料データベースに含まれる復旧機能や、Proの目標値に基づく水平オートスケーリングを重視するならRenderです。使用量に応じた課金、サービスのつながりを見渡せるキャンバス、複数リージョンのレプリカを重視するならRailwayです。RailwayのHA自動変換を使う場合は、事前にデータベースイメージの互換性を確認してください。