Render बनाम Vercel: कब एक असली सर्वर चुनें

एक क्लाइंट डेढ़ साल पहले मुझे घबराहट में फोन किया। उन्होंने Vercel पर एक Node.js API लॉन्च किया था, टेस्टिंग के दौरान सब कुछ ठीक दिख रहा था, और फिर उनका पहला असली concurrent load आया और WebSocket कनेक्शन बस... टूट गए। चुप्पे से। डैशबोर्ड में कोई error नहीं, कोई alert नहीं, कुछ नहीं। मुझे उन्हें समझाना पड़ा कि उनका चुना हुआ प्लेटफॉर्म literally एक persistent connection को खुला नहीं रख सकता। यह कोई bug नहीं है। यह serverless का पूरा point है। हमने उसी हफ्ते के अंत तक Render को migrate कर दिया।

यह कहानी असामान्य नहीं है। मैंने Seahawk Media में इसे दर्जनों बार देखा है। डेवलपर्स Vercel को चुनते हैं क्योंकि यह जो करता है उसके लिए सच में बेहतरीन है, फिर वे एक use case को जोड़ते हैं जिसके लिए यह कभी डिजाइन नहीं किया गया था और सोचते हैं कि चीजें क्यों टूट जाती हैं। तो यहाँ मेरी असली सोच है कि कब कौन सा उपयोग करें, असली projects को ship करने के आधार पर, benchmark पर नहीं।

Vercel वाकई किस चीज में अच्छा है

मुझे स्पष्ट होने दीजिए: मैं Vercel का उपयोग करता हूँ। बहुत ज्यादा। मार्केटिंग साइटों के लिए, Next.js ऐप्स के लिए, content-heavy frontends के लिए जहाँ API layer पतली हो, Vercel अभी भी git push से एक live URL तक जाने का सबसे तेज़ तरीका है जिसके आगे एक CDN हो। Vercel Edge Network static और ISR content के लिए सच में impressive है। Preview deployments क्लाइंट handoffs के लिए जादुई हैं।

यह विशेष रूप से यहाँ चमकता है:

Next.js ऐप्स जो ISR या SSG का उपयोग करते हैं जहाँ पेजेस पहले से रेंडर होते हैं या एक शेड्यूल पर पुनः जेनरेट होते हैं
Frontend-heavy प्रोजेक्ट्स जहाँ बैकएंड एक तीसरे पक्ष का API है (Stripe, Sanity, Shopify)
टीमें जो बार-बार डिप्लॉय करती हैं और QA के लिए ब्रांच प्रीव्यूज की जरूरत होती है
कोई भी चीज़ जहाँ cold start latency स्वीकार्य है क्योंकि ट्रैफ़िक पूर्वानुमानित और burst वाला है

मूल्य निर्धारण इन वर्कलोड्स के लिए भी ठीक है। Pro plan पर $20/month का एक छोटा SaaS बिल्कुल समझदारी है अगर आपके functions short-lived और stateless हैं।

Serverless की वह Constraint जिस पर आप बहस नहीं कर सकते

Vercel पर Functions timeout हो जाते हैं। डिफ़ॉल्ट रूप से Hobby plan पर 10 सेकंड, Enterprise पर 300 सेकंड तक। और भी महत्वपूर्ण, हर invocation isolated है। requests के बीच कोई shared memory नहीं। कोई persistent file system नहीं। कोई long-running process नहीं जो बैकग्राउंड में बैठकर काम कर रहा हो।

ज्यादातर web apps के लिए, ईमानदारी से कहें तो, यह ठीक है। लेकिन चीज़ों की एक पूरी श्रेणी है जो सीधे उन constraints के अंदर काम ही नहीं करती।

Serverless आपको कहाँ से चोट पहुँचाने लगता है

2021 में, Seahawk के पास एक fintech प्रोजेक्ट था जहाँ क्लाइंट को एक dashboard पर real-time transaction feeds push करने की जरूरत थी। मूल developer ने इसे हर दो सेकंड polling के साथ ठीक करने की कोशिश की थी। भयानक। हमें WebSockets की जरूरत थी। सही, persistent, stateful connections। Vercel तुरंत टेबल से बाहर था।

यहीं पर मैं लगातार देखता हूँ कि serverless अपनी सीमा तक पहुँचता है:

WebSocket connections. AWS Lambda पर बनाया गया कोई भी platform socket को open रख नहीं सकता। बिल्कुल।
Background jobs और queues। अगर आपको ऐसा worker चाहिए जो हर 15 मिनट में जागे और job queue को process करे, तो आपको एक ऐसी process चाहिए जो persist करे। Vercel Functions वह नहीं हैं।
Long-running computations। PDF generation, video transcoding, बड़े report exports। 300-second की limit के साथ भी, आप architecture के साथ काम करने की जगह उसके चारों ओर patch लगा रहे हैं।
In-memory caching। अगर आप node-cache जैसी कोई चीज़ use कर रहे हैं requests के बीच RAM में data store करने के लिए, तो वह cache हर function invocation के बाद destroy हो जाता है। आप बिना किसी वजह के अपने database connection pool को जला देंगे।
Database connection pooling। यह लोगों को लगातार काटता है। Prisma जैसे ORMs हर function call के लिए एक नया connection खोलते हैं। किसी भी reasonable traffic level पर आप अपनी Postgres connection limit को exhaust कर देंगे। आप PgBouncer या Supabase के connection pooler को workaround के रूप में add करते हैं, जो काम करता है, लेकिन आप platform से लड़ रहे हैं।

Render क्या सही करता है

Render actual persistent processes चलाता है। Web services, background workers, cron jobs। जब आपकी Node process शुरू होती है, तो वह चलती रहती है। इसका मतलब है in-memory state, WebSocket servers, long-running jobs, सब कुछ वैसे काम करता है जैसे आप किसी भी Linux box पर expect करते।

Free tier staging environments के लिए useful है (हालांकि यह 15 मिनट की inactivity के बाद cold-start होता है, जो irritating है)। $7/month की Individual plan आपको एक persistent service देती है जिसमें कोई cold starts नहीं हैं, और $25/month की plan RAM को बढ़ाती है और आपको SSH access देती है, जिसे मैं constantly debugging के लिए use करता हूँ।

Backend Services के लिए Pricing जो समझदारी भरी है

एक backend API के लिए जिसे massive scale की ज़रूरत नहीं है, Render काफ़ी cost-predictable है। आप instance के लिए pay करते हो, per invocation के लिए नहीं। यह matter करता है जब आपके पास कोई service steady, consistent काम कर रही हो। Vercel पर, एक function जो हर घंटे हज़ारों बार run होता है, वह उन तरीकों से जमा होता है जो आप पर सरपटे आते हैं। Render पर, यह एक flat monthly fee है।

मैंने पिछले साल एक client के लिए comparison चलाया जिसके पास एक Node.js API था जो औसतन लगभग 50k requests per day कर रहा था। उनका Vercel bill £180/month तक पहुंच गया था। हमने API को Render के $25 instance पर move किया, इसे उनके existing Vercel frontend से connect किया, और उनका backend hosting £25 तक गिर गया। Frontend Vercel पर बना रहा क्योंकि वही वह जगह है जहां Vercel belong करता है।

आर्किटेक्चर जो मैं अब वास्तव में उपयोग करता हूँ

इनमें से काफ़ी कुछ build करने के बाद, मैं एक बिल्कुल स्पष्ट mental model पर settle हो गया हूं। यह either/or नहीं है।

Frontend (Next.js, Astro, whatever) Vercel पर जाता है। Branch previews, edge CDN, instant rollbacks। कोई contest नहीं।
कोई भी stateful backend, persistent connections वाला API, या worker process Render पर जाता है।
Postgres या MySQL Railway पर या Render के अपने managed Postgres पर, budget के आधार पर।
Redis Upstash पर अगर यह serverless-compatible usage है, या एक Render Redis instance पर अगर app को persistence guarantees की ज़रूरत है।

यह split मुझे embarrassingly लंबा समय लगा land करने में। एक समय के लिए मैं सब कुछ Vercel में fit करने की कोशिश कर रहा था क्योंकि DX बहुत अच्छा है। लेकिन platform की constraints के खिलाफ़ लड़ना आपको convenience जो बचाती है उससे ज़्यादा समय खर्च करता है।

Vercel Frontend को Render Backend से Connect करना

तकनीकी रूप से यह सीधा है। आप Vercel में अपना NEXT_PUBLIC_API_URL environment variable अपने Render service URL पर सेट करते हैं, Render की ओर से CORS को संभालते हैं, और बस इतना ही है। Render आपको बॉक्स से बाहर एक स्थिर subdomain देता है (yourservice.onrender.com) और आप आसानी से एक custom domain जोड़ सकते हैं।

एक चीज़ का ध्यान रखें: Render की free tier services 15 मिनट की inactivity के बाद sleep में चली जाती हैं। अगर आपका frontend Vercel पर है और आपका backend free Render service पर है, तो उपयोगकर्ताओं को कभी-कभी 30-सेकंड की cold start का सामना करना पड़ेगा जब Render container जागता है। Production के लिए, बस $7 plan के लिए भुगतान करें। UX को नुकसान पहुंचाने लायक नहीं है।

विशिष्ट परिदृश्य और मैं वास्तव में क्या चुनूंगा

मैं यहाँ सीधे कहूंगा, क्योंकि यह वह जगह है जहाँ ज्यादातर तुलना posts अस्पष्ट हो जाते हैं।

परिदृश्य 1: contact form के साथ Next.js marketing site। Vercel। स्पष्ट है। content pages के लिए ISR, form के लिए एक simple API route जो SendGrid को कॉल करता है। Render को introduce करने का कोई कारण नहीं।

परिदृश्य 2: Node/Express REST API, Postgres, और कभी-कभार background jobs के साथ SaaS app। Frontend Vercel पर, backend API Render ($25 plan) पर, Postgres Render के managed database पर। Background jobs Render Background Workers के रूप में। यह शायद मेरा अभी का सबसे सामान्य setup है।

परिदृश्य 3: Socket.io का उपयोग करके real-time collaborative app। Render, बिना किसी संदेह के। आपको एक persistent process की ज़रूरत है। मैं वास्तव में कम से कम 512MB RAM वाले Render service की ओर झुकूंगा जो कुछ दिलचस्प करने वाले Socket.io app के लिए हो।

परिदृश्य 4: simple headless WordPress frontend। Vercel। WPGraphQL से pull करने वाली Next.js के साथ ISR। "backend" WordPress है, Render तस्वीर में नहीं आता।

परिदृश्य 5: Python FastAPI या Django app। Render। Vercel के पास Python runtime support है लेकिन यह सीमित है और आप लगातार function duration ceiling से टकराएंगे। Render बस आपकी Python process को एक normal server की तरह चलाता है।

Cold Start Problem, ईमानदारी से

लोग Vercel के cold starts के बारे में ऐसे बात करते हैं जैसे वह कोई मामूली परेशानी हों। ज्यादातर frontend workloads के लिए, वह हैं। लेकिन मैंने देखा है कि Vercel functions को Hobby plan पर 3-4 सेकंड का cold start लग सकता है जब आपके पास bundled में भारी dependencies हों। यह एक user के लिए एक भयानक पहली experience है।

Render के non-free tiers बिल्कुल cold start नहीं करते। आपका process up है। AWS Lambda cold starts Vercel के इस समस्या का अंतर्निहित कारण हैं, क्योंकि Vercel के functions hood के तहत Lambda पर चलते हैं। यह बिल्कुल Vercel की गलती नहीं है, यह serverless model का trade-off है।

Latency-sensitive APIs के लिए, खासकर कुछ भी जो user-facing हो और हर request पर चलता हो, Render पर एक persistent server अक्सर व्यावहारिक रूप से ज्यादा तेज़ लगता है भले ही raw specs comparable दिखें।

जब कोई भी सही विकल्प नहीं है

अगर आप कुछ ऐसा चला रहे हैं जिसे demand पर दर्जनों instances तक horizontally scale करने की जरूरत है, तो आप शायद AWS पर ECS, Google Cloud Run, या Fly.io को देख रहे हैं। Render का autoscaling मौजूद है लेकिन यह genuinely variable traffic के लिए जितना fine-grained नहीं है जितना आप चाहेंगे। Vercel जाहिरा तौर पर horizontally scale करता है default से क्योंकि हर function invocation independent है।

Fly.io यहाँ mention करने लायक है। यह conceptually Render के करीब है (persistent VMs) लेकिन बेहतर global distribution और अधिक control के साथ। मैंने इसे latency-sensitive apps के लिए use किया है जहाँ मुझे specific regions में instances की जरूरत थी। Render की तुलना में थोड़ी ज्यादा DevOps overhead है।

FAQ

Frontend hosting के लिए क्या Render, Vercel से धीमा है?

Pure frontend hosting के लिए, हाँ, आम तौर पर। Vercel का CDN specifically इसके लिए optimised है। Render का static site hosting ठीक काम करता है लेकिन इसके पास same edge network reach नहीं है। अगर आप एक frontend host कर रहे हैं, तो delivery speed पर Vercel जीतता है।

क्या मैं Render पर एक Next.js app चला सकता हूँ?

आप कर सकते हैं। Render, Node.js को सपोर्ट करता है, तो आप एक Render वेब सर्विस पर next start चला सकते हैं। आप वह चीजें खो देंगे जैसे ISR जिस तरह से Vercel इसे नेटिवली हैंडल करता है, और आपको बॉक्स से बाहर प्रीव्यू डिप्लॉयमेंट नहीं मिलेंगे। एक Next.js ऐप के लिए, Vercel अभी भी बेहतर विकल्प है जब तक कि आपके पास इससे बचने के लिए खास कारण न हों।

क्या Vercel बिल्कुल WebSockets के साथ काम करता है?

परंपरागत अर्थ में नहीं। Vercel के पास उनकी नई streaming फीचर्स के माध्यम से लंबे समय तक चलने वाले कनेक्शन के लिए कुछ सपोर्ट है, लेकिन यह एक सही WebSocket सर्वर के लिए कोई विकल्प नहीं है। अगर आपका ऐप socket.io या स्टेटफुल कनेक्शन वाली किसी समान लाइब्रेरी पर निर्भर है, तो इसे Render या Fly.io पर चलाएं।

Netlify के बारे में क्या? आप इसका उल्लेख बहुत ज्यादा क्यों नहीं करते?

Netlify ठीक है। यह इस बातचीत के लिए प्रभावी रूप से Vercel जैसी ही कैटेगरी में है: serverless functions, CDN, static और SSR फ्रंटएंड के लिए शानदार। वही persistent-server सीमाएं लागू होती हैं। मैं सिर्फ Seahawk में Vercel ज्यादा इस्तेमाल करता हूं, तो यह वह तुलना है जिसके बारे में मैं ईमानदारी से बात कर सकता हूं।

डेटाबेस होस्टिंग इसमें कैसे फैक्टर होती है?

अपने प्रोडक्शन डेटाबेस को Render free इंस्टेंस पर न चलाएं। Render पर free Postgres डेवलपमेंट और staging के लिए ठीक है लेकिन स्टोरेज लिमिट कड़ी है और यह suspend हो जाता है। प्रोडक्शन के लिए मैं आम तौर पर Render का paid managed Postgres ($7/महीने स्टार्टर) या Supabase इस्तेमाल करता हूं अगर क्लाइंट Row Level Security चाहता है और Supabase टूलिंग चाहता है।

---

संक्षिप्त संस्करण: Vercel एक फ्रंटएंड प्लेटफॉर्म है जो server-side कोड चलाता भी है। Render एक सर्वर प्लेटफॉर्म है जिसके पास एक शानदार UI भी है। एक बार जब आप इस अंतर को आंतरिक कर लेते हैं, तो किसी भी दिए गए प्रोजेक्ट के लिए निर्णय लगभग तीस सेकंड में हो जाता है। दोनों का इस्तेमाल करें। वे सच में अलग-अलग चीजों के लिए अच्छे हैं और एक हाइब्रिड सेटअप चलाने की कीमत मूलतः कुछ भी नहीं है।