約18ヶ月前、あるクライアントがパニック状態で電話をくれました。彼らはNode.js APIをVercelで起動し、テスト中はすべてが良好に見えていたのに、最初の本当の同時接続負荷がかかった時、WebSocket接続がただ...ドロップしてしまったのです。静かに。ダッシュボードにはエラーもなく、アラートもなく、何もない。彼らが選んだプラットフォームが文字通り永続的な接続を開いたままにしておくことができないことを彼らに説明しなければなりませんでした。それはバグではありません。それはサーバーレスの全体的な要点です。その同じ週の終わりまでにRenderに移行しました。
その話は珍しくありません。Seahawk Mediaではそれを何度も見かけています。開発者はVercelを選びます。なぜならそれが本当に優れているからです。その後、それが設計されたことのないユースケースを付け加え、なぜ物事がうまくいかないのか不思議に思います。ですから、ここに私の実際の考えがあります。どちらをいつ使うかについて、ブログのベンチマークではなく、実際のプロジェクトを出荷することに基づいています。
Vercelが実際に得意な事
はっきり言っておきます。私はVercelを使います。たくさん使います。マーケティングサイト、Next.jsアプリ、APIレイヤーが薄いコンテンツが豊富なフロントエンドについては、Vercelは相変わらず、gitプッシュからライブURLへと、その前にCDNがある状態で移動する最速の方法です。Vercel Edge Networkは本当にスタティックとISRコンテンツに対して印象的です。プレビューデプロイメントはクライアントハンドオフのために魔法のようなものです。Vercel Edge Network is genuinely impressive for static and ISR content. Preview deployments are magic for client handoffs.
特に輝く場所：
- ページが事前レンダリングされたり、スケジュールに基づいて再生成されたりするISRまたはSSGを使用するNext.jsアプリ
- バックエンドが第三者のAPI（Stripe、Sanity、Shopify）であるフロントエンド中心のプロジェクト
- 頻繁にデプロイし、QA用のブランチプレビューが必要なチーム
- コールドスタートレイテンシーが許容できるすべての場合。トラフィックが予測可能でバースト的だから
料金設定もこれらのワークロードに適しています。Pro プラン月額$20 の小規模 SaaS であれば、関数が短期間で、ステートレスであれば完全に合理的です。
議論の余地のないサーバーレス制約
Vercel上の関数はタイムアウトします。デフォルトではHobbyプランで10秒、Enterpriseで最大300秒です。さらに重要なのは、各呼び出しが分離されていることです。リクエスト間で共有メモリがありません。永続的なファイルシステムがありません。バックグラウンドで実行される長時間実行プロセスがありません。
ほとんどのウェブアプリではぶっちゃけ問題ありません。しかし、これらの制約の中では単に動作しないカテゴリー全体があります。
サーバーレスが痛くなり始めるところ
2021年にさかのぼって、Seahawk はダッシュボードにリアルタイムのトランザクションフィードをプッシュする必要があるフィンテックプロジェクトに携わっていました。元の開発者は2秒ごとにポーリングすることでこれを誤魔化そうとしていました。最悪です。WebSocketが必要でした。適切で、永続的で、ステートフルな接続です。Vercelはすぐに選択肢から外れました。
サーバーレスが限界に達する場面を一貫して見てきた箇所がここだ：
- WebSocket接続。AWS Lambdaをベースにしたプラットフォームは、ソケットをオープンのままにしておくことができない。それだけだ。 Any platform built on AWS Lambda underneath cannot hold a socket open. Full stop.
- バックグラウンドジョブとキュー。15分ごとにジョブキューを処理するために起動するワーカーが必要な場合、永続するプロセスが必要だ。Vercel Functionsではそれができない。 If you need a worker that wakes up every 15 minutes to process a job queue, you need a process that persists. Vercel Functions aren't that.
- 長時間実行される計算処理。PDF生成、ビデオトランスコーディング、大規模なレポートエクスポート。300秒の制限があっても、アーキテクチャに合わせるのではなくアーキテクチャをパッチで対応することになる。 PDF generation, video transcoding, large report exports. Even with the 300-second limit, you're patching around the architecture rather than working with it.
- インメモリキャッシング。node-cacheのようなものを使ってRAMにデータをリクエスト間で保存する場合、そのキャッシュは関数実行のたびに破棄される。データベース接続プールを無意味に消費することになる。 If you're using something like
node-cacheto store data in RAM between requests, that cache is destroyed after every function invocation. You'll burn your database connection pool for no reason. - データベース接続プーリング。これは多くの人が引っかかる。PrismaのようなORMは関数呼び出しごとに新しい接続を開く。適切なトラフィックレベルでは、Postgresの接続制限を超過する。結局PgBouncer、またはSupabaseの接続プーラーを回避策として追加することになり、それで動作するが、プラットフォームに逆らっている。 This one bites people constantly. ORMs like Prisma open a new connection per function call. At any reasonable traffic level you'll exhaust your Postgres connection limit. You end up adding PgBouncer or Supabase's connection pooler as a workaround, which works, but you're fighting the platform.
Renderが正しくやっていること
Renderは実際の永続プロセスを実行する。Webサービス、バックグラウンドワーカー、cronジョブ。Nodeプロセスが起動したら、稼働し続ける。つまり、インメモリ状態、WebSocketサーバー、長時間実行ジョブ、すべてがLinuxボックスで期待する通りに動作する。
無料ティアはステージング環境に便利だ（ただし15分の非アクティビティ後にコールドスタートする。それは煩わしい）。月7ドルのIndividualプランはコールドスタートなしの永続サービスを提供し、月25ドルのプランはRAMを増やしてSSHアクセスを付与するので、デバッグに常に活用している。
バックエンドサービスに対して意味のある価格設定
スケールの大きさを必要としないバックエンド API であれば、Render は非常にコスト予測可能です。インボケーション単位ではなく、インスタンスに対して課金されます。これは、サービスが安定した一貫した動作をしている場合に大きな違いになります。Vercel では、1時間に数千回実行される関数があると、気づかないうちに請求額が膨らみます。Render では、月額固定料金です。
去年、1日あたり約 50k のリクエストを処理していた Node.js API を使用していたクライアント向けに比較を実施しました。Vercel の請求額は £180/月 まで増加していました。API を Render の $25 インスタンスに移行し、既存の Vercel フロントエンドに接続したところ、バックエンド ホスティングは £25 に削減されました。フロントエンドは Vercel に留まったままです。それが Vercel の本来の使い方だからです。
現在実際に使用しているアーキテクチャ
これだけ多くの案件をこなしてみると、かなり明確な思考モデルに落ち着きます。どちらか一方という話ではありません。
- フロントエンド (Next.js、Astro、その他) は Vercel に配置します。ブランチプレビュー、エッジ CDN、インスタント ロールバック。議論の余地はありません。
- ステートフルなバックエンド、永続的な接続を持つ API、またはワーカープロセスは Render に配置します。
- Postgres または MySQL は Railway か Render 独自のマネージド Postgres に配置します。予算に応じて選択します。Railway or Render's own managed Postgres, depending on budget.
- Redis は、サーバーレス互換の用途であれば Upstash に、アプリがペシステンス保証を必要とする場合は Render Redis インスタンスに配置します。
この設計に落ち着くまで、恥ずかしいほど長くかかりました。しばらくの間、DX が非常に優れているため、すべてを Vercel に合わせようとしていました。しかし、プラットフォームの制約に対抗することは、利便性がもたらす時間短縮よりも多くの時間を消費することになります。
Vercel フロントエンドを Render バックエンドに接続する
技術的には単純です。Vercelで NEXT_PUBLIC_API_URL 環境変数をRenderのサービスURLに設定し、Render側でCORSを処理すれば、基本的にそれで完了です。Renderは初期状態で安定したサブドメイン（yourservice.onrender.com）を提供しており、カスタムドメインの接続も簡単です。NEXT_PUBLIC_API_URL environment variable in Vercel to your Render service URL, handle CORS on the Render side, and that's basically it. Render gives you a stable subdomain out of the box ( yourservice.onrender.com) and you can attach a custom domain easily enough.
注意点が1つあります。Renderの無料プランはサービスが15分間の非アクティブ後にスリープ状態になります。フロントエンドがVercel、バックエンドが無料のRenderサービスの場合、ユーザーがRenderコンテナの起動を待つ間に時々30秒のコールドスタートに遭遇します。本番環境なら$7プランを有料にしてください。UXへのダメージは払う価値がありません。
具体的なシナリオと私が実際に選ぶもの
ここではっきり言いますが、ほとんどの比較記事がこの部分で曖昧になっているからです。
シナリオ1：Next.jsマーケティングサイトにお問い合わせフォーム。Vercelです。当然です。コンテンツページはISR、フォーム用の簡単なAPIルートはSendGridを呼び出します。Renderを導入する理由はありません。 Vercel. Obviously. ISR for the content pages, a simple API route for the form that calls SendGrid. No reason to introduce Render.
シナリオ2：Node/Express REST API、Postgres、たまに背景ジョブがあるSaaSアプリ。フロントエンドはVercel、バックエンドAPIはRender（$25プラン）、PostgresはRenderのマネージドデータベース。背景ジョブはRender Background Workersで実行。これが現在、私が最も頻繁に使うセットアップです。 Frontend on Vercel, backend API on Render ($25 plan), Postgres on Render's managed database. Background jobs as Render Background Workers. This is probably my most common setup right now.
シナリオ3：Socket.ioを使ったリアルタイム協働アプリ。Renderです、それ以上。永続的なプロセスが必要です。実際にはSocket.ioアプリで何か興味深いことをするなら、最低512MB RAMのRenderサービスを選びます。 Render, full stop. You need a persistent process. I'd actually lean toward a Render service with at least 512MB RAM for a Socket.io app doing anything interesting.
シナリオ4：シンプルなヘッドレスWordPressフロントエンド。Vercelです。WPGraphQLからデータを取得するISR付きNext.js。「バックエンド」はWordPressで、Renderは登場しません。 Vercel. Next.js with ISR pulling from WPGraphQL. The "backend" is WordPress, Render doesn't enter the picture.
シナリオ5：Python FastAPIまたはDjangoアプリ。Renderです。Vercelはランタイムサポートがありますが限定的で、常に関数の実行時間上限に引っかかります。RenderはPythonプロセスを通常のサーバーのように単純に実行するだけです。 Render. Vercel has Python runtime support but it's limited and you'll constantly bump into the function duration ceiling. Render just runs your Python process like a normal server.
コールドスタート問題、正直に言うと
Vercelのコールドスタートについて、人々は軽微な不便さのように話しますが、ほとんどのフロントエンドワークロードではそうです。しかし、Hobbyプランで重い依存関係をバンドルした場合、Vercelの関数が3〜4秒のコールドスタートを取るのを見たことがあります。これはユーザーにとって非常に悪い最初の体験です。
Renderの非無料階層はコールドスタートが発生しません。プロセスは稼働しています。AWS Lambdaのコールドスタートが、Vercelがこの問題を抱えている根本的な理由です。Vercelの関数は内部的にLambda上で実行されるからです。Vercelの落ち度ではなく、サーバーレスモデルのトレードオフです。AWS Lambda cold starts are the underlying reason Vercel has this problem, since Vercel's functions run on Lambda under the hood. It's not Vercel's fault exactly, it's the serverless model's trade-off.
レイテンシに敏感なAPI、特にすべてのリクエストで実行されるユーザー対応のものについては、Renderの永続サーバーは仕様上は同等に見えても、実際には高速に感じることが多いです。
どちらも適切ではない場合
必要に応じて数十のインスタンスに水平スケーリングする必要があるものを実行している場合、AWS上のECS、Google Cloud Run、またはFly.ioを探しているでしょう。Renderのオートスケーリングは存在しますが、トラフィックが実際に変動する場合には望むほど細かくありません。Vercelは各関数呼び出しが独立しているため、当然ながら水平スケーリングがデフォルトです。
Fly.ioはここで言及する価値があります。概念的にはRenderに近い（永続VM）ですが、グローバル分布が良く、制御がより多くあります。レイテンシに敏感なアプリで特定のリージョンのインスタンスが必要だった場合に使用しました。Renderよりは少しDevOpsのオーバーヘッドがありますが。
FAQ
フロントエンドホスティングでRenderはVercelより遅いですか？
純粋なフロントエンドホスティングでは、一般的にそうです。VercelのCDNはこのために特別に最適化されています。Renderのスタティックサイトホスティングは問題なく機能しますが、同じエッジネットワークのリーチを持っていません。フロントエンドをホストしている場合、Vercelが配信速度で優れています。
RenderでNext.jsアプリを実行できますか？
可能です。RenderはNode.jsをサポートしているため、Renderのウェブサービス上でnext startを実行できます。ただし、ISRがVercelのようにネイティブに機能しないこと、プレビューデプロイメントが標準では提供されないといった制限があります。Next.jsアプリの場合、特別な理由がない限り、Vercelの方が依然として良い選択です。next start on a Render web service. You lose things like ISR working the way Vercel handles it natively, and you won't get preview deployments out of the box. For a Next.js app, Vercel is still the better choice unless you have specific reasons to avoid it.
Vercelはウェブソケットに対応していますか？
従来の意味では対応していません。Vercelは最新のストリーミング機能を通じて長時間接続をサポートしていますが、適切なウェブソケットサーバーの代わりにはなりません。あなたのアプリがsocket.ioや同様のステートフルな接続を持つライブラリに依存している場合は、RenderまたはFly.ioで実行してください。socket.io or a similar library with stateful connections, run it on Render or Fly.io.
Netlifyはどうですか？なぜあまり言及しないのですか？
Netlifyは良いです。この議論ではVercelと実質的に同じカテゴリーです。サーバーレス関数、CDN、スタティックおよびSSRフロントエンドに最適です。同じ永続サーバーの制限が適用されます。私はSeahawk Mediaでより頻繁にVercelを使うため、正直に比較できるのはVercelなんです。
データベースホスティングはどのように関係してきますか？
本番環境のデータベースをRenderの無料インスタンスで実行しないでください。Renderの無料Postgresは開発環境とステージング環境には適していますが、ストレージ上限がきつく、サスペンドされます。本番環境では通常、Renderの有料マネージドPostgres（月額$7のスターター）またはクライアントがRow Level SecurityとSupabaseツールを望む場合はSupabaseを使用しています。
---
簡潔に言うと、Vercelはサーバー側コードを実行する機能を持つフロントエンドプラットフォームです。Renderは優れたUIを持つサーバープラットフォームです。この違いを理解すれば、特定のプロジェクトごとの決定は約30秒で済みます。両方を使ってください。ハイブリッドセットアップを実行するコストは基本的にゼロであり、両者は本当に異なることに長けています。