Vercel vs Railway

Yes, it runs them fine as Node services. What you give up is what makes Vercel the frontend default: the global edge network, per-request scaling, and the pull-request preview flow that makes design review cheap. For a public marketing site or content site, those are usually worth more than container control.

Often further than people expect. Vercel functions handle APIs, streaming, and substantial workloads without a separate server. Where we draw the line is state and duration: databases, queues, and long-running workers want a persistent process with a disk and a private network, and that is Railway’s home turf.

Very well, and it is our default split on product builds: the SvelteKit or Next.js frontend deploys to Vercel, while Railway runs the Postgres database, background workers, and any service that must stay resident. The frontend talks to the backend over HTTPS, and each platform does the job it is built around.

If the stack includes Railway, its managed Postgres next to your services on the private network is the simple answer. If the build is Vercel-only, we provision a database through a managed vendor and connect it via integration. What we avoid is treating serverless functions as a place to hold connections carelessly; pooling is part of the implementation either way.

More often than not. Marketing sites, content sites, and most application frontends with API routes need nothing else. Railway enters when the architecture grows real backend weight: persistent workers, scheduled jobs beyond simple crons, sockets between services, or a database you want on a private network with the app.