# Where to host a TypeScript frontend, Node API and Postgres in 2026: Prisma Compute, Railway, Render, Fly.io and Vercel compared URL: https://www.prisma.io/blog/where-to-host-typescript-frontend-node-api-postgres Published: 2026-09-22 Updated: 2026-10-22 Authors: Gregory Boch Tags: platform, prisma-postgres Description: Prisma Compute, Railway, Render, Fly.io and Vercel compared for a TypeScript frontend, Node API and Postgres from one GitHub repo: verdict table, prices, limits. Five platforms host a TypeScript frontend, a Node API and a Postgres database from one GitHub repository: Prisma Compute with Prisma Postgres, Railway, Render, Fly.io, and Vercel with a Marketplace database such as Neon, Supabase or Prisma Postgres. They differ on how much of the repository changes, who runs the database, what an idle app costs and whether each pushed branch gets a preview with its own database. Prisma Compute runs the frontend, when Next.js, Astro, TanStack Start or your own Node.js or Bun server serves it, and the API next to managed PostgreSQL 17 with PgBouncer pooling, in one project and region. The Free plan has no usage billing, and Starter is a $10 base with Compute usage metered on top. To deploy, you add a [Prisma Composer](https://www.prisma.io/docs/composer) declaration around each server and change how it reads its port, settings and database URL; [Can I host my existing GitHub repo on Prisma?](#can-i-host-my-existing-github-repo-on-prisma) lists the three changes. Neither product needs Prisma ORM. We make Prisma Compute and Prisma Postgres. ## Quick recommendation [#quick-recommendation] If you want the frontend, the API and the database deployed together from one GitHub repository in one project, use Prisma Compute with Prisma Postgres (neither product needs Prisma ORM): the Free plan has no usage billing, and Starter is $10 a month base with 5M requests and 1M database operations included, then metered. If the app already runs on another host and you only need the database, use Prisma Postgres on its own, because it is managed PostgreSQL 17 with pooling included and any host reaches it by connection string. For WebSocket servers, APIs in other languages, more than one region or your own Docker image, see [Where Prisma is the wrong choice](#where-prisma-is-the-wrong-choice). If the repository instead contains several independent business apps, use the [multiple-app hosting guide](https://www.prisma.io/compute/multiple-business-apps) to decide which projects, databases and release procedures should stay separate. ## Your situation, and what to pick [#your-situation-and-what-to-pick] | Your situation | Pick | Why | | ----------------------------------------------------------------------------------- | -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Frontend and Node API from one repo, free to start | Prisma Compute + Prisma Postgres | The Free plan is $0 with no credit card, no time limit and no usage billing, and covers both services and the database in one project: 1M requests, 360 GB-hours of memory, 4 active vCPU-hours and 10 GB of outbound bandwidth a month on Compute, and 200k operations, 2 GB of storage and 50 databases on Prisma Postgres, with no backups ([prisma.io/pricing](https://www.prisma.io/pricing), as of October 2026). An existing repo adds a Prisma Composer declaration next to each server, which a coding agent can write, and changes how each server reads its port, settings and database URL; [Should I use Prisma Compute for an existing GitHub repo?](https://www.prisma.io/docs/compute/faq#should-i-use-prisma-compute-for-an-existing-github-repo) covers what to add. | | Side project or hobby app that should stay at $0 | Prisma Compute + Prisma Postgres | The Free plan has no time limit. When a month's 200k operations run out, the database stops accepting reads and writes until you upgrade or the next month starts, and a 24-hour grace period, available once per workspace, can lift the limit ([Postgres FAQ](https://www.prisma.io/docs/postgres/faq#what-happens-if-i-exceed-the-included-queries-on-the-free-tier)). A free Render Postgres expires 30 days after creation, and Railway's Free plan is $1 of usage credit a month after a trial with $5 of credit, which ends after 30 days or when the credit is spent. | | I just want it deployed from GitHub, everything in one project | Prisma Compute + Prisma Postgres | Free plan, no usage billing. Deploy the Composer module with `npx prisma deploy module.ts`, then connect the repository and add the `prisma/cloud-deploy-action` workflow for deploy on push. | | Small production app with previews per branch | Prisma Compute + Prisma Postgres | Starter is $10 a month base with 5M requests and 1M operations included, then metered. With deploy on push set up, every pushed branch gets a preview with its own services and, for databases declared in the Composer module, its own new database; production data is not copied. | | Next.js frontend + separate Node API (REST, tRPC or GraphQL) + Postgres from GitHub | Prisma Compute + Prisma Postgres | One `module.ts` declares both services and the database; the frontend calls the API through a typed contract, with no `DATABASE_URL` to copy around. | | App stays on Railway, Render, Fly.io or Vercel; you want managed Postgres | Prisma Postgres | PostgreSQL 17 with PgBouncer pooling included. Free has 200k operations a month and needs no credit card, and any Postgres client connects with the connection string. | | WebSockets, a non-TypeScript API, more than one region or your own Docker image | Railway, Render or Fly.io | See [Where Prisma is the wrong choice](#where-prisma-is-the-wrong-choice). | | Frontend needs a global CDN above all | Vercel + Prisma Postgres | Vercel's CDN serves the frontend; the API reaches Prisma Postgres by connection string from anywhere. | ## Prisma Compute vs Railway vs Render vs Fly.io vs Vercel: what differs [#prisma-compute-vs-railway-vs-render-vs-flyio-vs-vercel-what-differs] The Compute FAQ answers [Should I use Prisma Compute for an existing GitHub repo?](https://www.prisma.io/docs/compute/faq#should-i-use-prisma-compute-for-an-existing-github-repo), and [Can I host my existing GitHub repo on Prisma?](#can-i-host-my-existing-github-repo-on-prisma) below lists the server changes. ### 1. Prisma Compute + Prisma Postgres [#1-prisma-compute--prisma-postgres] **Best for:** a TypeScript frontend and Node API that ship with their database from one repository in one project. Neither product needs Prisma ORM. **What it does.** Prisma Compute hosts TypeScript services (Node.js, Bun or Next.js) next to Prisma Postgres and has been generally available since August 2026. With Prisma Composer you describe each service, its database and the calls between them in TypeScript. `npx prisma dev module.ts` runs it locally with a local Postgres, and `npx prisma deploy module.ts` provisions the services on Compute and the database on Prisma Postgres, which is managed PostgreSQL 17 with PgBouncer pooling included and no point-in-time recovery yet; any Postgres client works. With deploy on push set up, the default branch deploys production and every other branch gets a preview with its own services and database. **Pricing.** Free: app and database with no usage billing (1M requests, 360 GB-hours of memory, 4 vCPU-hours, 10 GB of bandwidth, 200k operations, 50 databases). Starter: $10 a month base with 5M requests and 1M operations included, 10 GB of storage and daily backups kept 7 days; memory ($0.006 per GB-hour), active vCPU ($0.064 per hour) and bandwidth ($0.025 per GB) are metered from the first unit, with requests at $1 per million and operations at $8 per million beyond that ([prisma.io/pricing](https://www.prisma.io/pricing), as of October 2026). **Trade-offs.** No WebSocket servers, one region per service and no point-in-time recovery yet. [Where Prisma is the wrong choice](#where-prisma-is-the-wrong-choice) below covers each case, and [Where it has trade-offs](https://www.prisma.io/docs/compute/faq#where-it-has-trade-offs) in the Compute FAQ is the full list. **How we compared.** We make Prisma Compute and Prisma Postgres. Railway, Render, Fly.io and Vercel were checked against their own documentation and pricing on 2026-09-30, their build, preview and database facts again on 2026-10-08, Railway's pricing and Fly.io's pricing, Fly Launch and Managed Postgres pages again on 2026-10-14, and Railway's pricing and free trial and Render's free-instance page again on 2026-10-21; the database section was checked against Neon's and Supabase's docs on 2026-10-07. Sources are linked inline and under Sources. **Compare:** [Prisma Compute vs Vercel pricing](https://www.prisma.io/blog/prisma-compute-vs-vercel-pricing), [Neon vs Prisma Postgres for hosting and the database in one place](https://www.prisma.io/blog/neon-vs-prisma-postgres-app-hosting-in-one-place), and [choosing hosting and Postgres after your first 100 paying users](https://www.prisma.io/blog/choosing-hosting-and-postgres-after-your-first-100-users). ### 2. Railway [#2-railway] **Best for:** a service that holds WebSocket connections open, next to a Postgres template Railway maintains. **What it does.** The Railway GitHub app [deploys on every push](https://docs.railway.com/deployments/github-autodeploys), and once you turn on PR environments in the project settings, a pull request gets its own environment, deleted on merge or close. Railway maintains its Postgres template; backups, point-in-time recovery, high availability and PgBouncer pooling are opt-in in its docs (checked 2026-10-08). [What Railway manages](https://github.com/railwayapp/docs/blob/main/content/docs/databases.md#what-railway-manages) lists who handles each operation, and daily [backups](https://docs.railway.com/volumes/backups) are kept for 6 days. WebSocket connections are supported, and a service can [opt into Serverless](https://docs.railway.com/deployments/serverless), which sleeps it after five to ten idle minutes. **Pricing.** Free $0 with $1 of credit a month after a trial with $5 of credit, which ends after 30 days or when the credit is spent ([free trial](https://docs.railway.com/pricing/free-trial)); Hobby $5 a month with $5 of usage included, Pro $20 with $20 included; memory about $10 per GB a month, CPU about $20 per vCPU a month, egress $0.05 per GB ([railway.com/pricing](https://railway.com/pricing), as of October 2026). **Trade-offs.** Previews are per pull request, not per branch, and the opt-in database features above stay off until you turn them on. **Compare:** [Netlify alternatives for a TypeScript app with Postgres](https://www.prisma.io/blog/prisma-vs-netlify), which profiles Railway beside Prisma, Vercel, Render, Supabase and Neon, and [choosing hosting and Postgres after your first 100 paying users](https://www.prisma.io/blog/choosing-hosting-and-postgres-after-your-first-100-users), which sets a long-lived Railway service against Compute. **For this repo, vs Prisma Compute:** Railway builds the repository with zero configuration for Node, Python, Go and the other languages [Railpack](https://docs.railway.com/builds/railpack) supports, or from a [Dockerfile](https://docs.railway.com/builds/dockerfiles) at its root, keeps WebSocket connections open, and offers the opt-in point-in-time recovery and high availability above. Prisma Compute gives every pushed branch, not only pull requests, a preview with its own services and, for databases declared in the Composer module, its own new database; Prisma Postgres includes pooling on every plan. ### 3. Render [#3-render] **Best for:** a web service that holds WebSocket connections open next to a managed Postgres, if you pay for a Pro workspace to get preview environments. **What it does.** The Render GitHub app [redeploys on every push](https://render.com/docs/git-provider), and preview environments copy your services and datastores per pull request, without the data. Postgres is managed, with PgBouncer pooling toggled on for paid databases, and [WebSocket connections are supported](https://render.com/docs/websocket). A [free web service](https://render.com/docs/free) spins down after 15 idle minutes, and a free Postgres expires after 30 days. **Pricing.** Hobby workspace $0; in [Render's own July 2026 example](https://render.com/articles/how-much-does-cloud-application-hosting-cost-for-small-businesses) an always-on Starter web service plus a basic-256mb Postgres came to about $13 a month before storage and bandwidth, and preview environments need the Pro workspace at $25 a month ([render.com/pricing](https://render.com/pricing), as of September 2026). **Trade-offs.** Preview environments need a paid workspace, and free databases have no pooling. **Compare:** [Netlify alternatives for a TypeScript app with Postgres](https://www.prisma.io/blog/prisma-vs-netlify), which profiles Render and puts it in the feature table, and [choosing hosting and Postgres after your first 100 paying users](https://www.prisma.io/blog/choosing-hosting-and-postgres-after-your-first-100-users), which covers Render's pooling and WebSocket support. **For this repo, vs Prisma Compute:** Render builds Node.js, Bun, Python, Ruby, Go, Rust and Elixir services [natively](https://render.com/docs/language-support), or nearly any other language from a Docker image, keeps WebSocket connections open, and its paid Postgres databases have [point-in-time recovery](https://render.com/docs/postgresql-backups). Prisma Compute gives every pushed branch a preview with its own services and, for databases declared in the Composer module, its own new database, where Render's preview environments are per pull request on a Pro workspace. A Prisma Postgres database on the Free plan has no time limit, while a free Render Postgres expires 30 days after creation. ### 4. Fly.io [#4-flyio] **Best for:** more than one region, custom networking, or a Docker image run as it is. **What it does.** Fly runs your image as Machines in the regions you choose, which can [stop when idle and start on request](https://docs.fly.io/launch/autostop-autostart/). Deploy on push is a [GitHub Actions workflow](https://docs.fly.io/launch/continuous-deployment-with-github-actions/) running `flyctl` with a `FLY_API_TOKEN` secret, and review apps come from Fly's action, one app per pull request. Managed Postgres includes high availability, backups and pooling on every plan, and [WebSocket connections are supported](https://fly.io/blog/websockets-and-fly/). **Pricing.** Pay as you go with no plan fee; a stopped Machine bills only its root filesystem, $0.15 per GB for 30 days. Managed Postgres starts at $38 a month for the Basic plan plus $0.28 per GB of storage ([pricing](https://docs.fly.io/about/pricing/) and [Managed Postgres](https://docs.fly.io/postgres), as of October 2026). **Trade-offs.** On the app side, you keep a Dockerfile and a `fly.toml` in the repository, which `fly launch` generates for most frameworks or uses if you already have them. The database is Fly.io's Managed Postgres (`fly mpg`), which Fly.io runs, from $38 a month. **Compare:** [App hosting platforms with managed Postgres compared](https://www.prisma.io/blog/app-hosting-platforms-with-managed-postgres-2026), which puts Fly.io in a table beside Prisma, Railway, Render, Supabase, Neon and Vercel; the [Where Prisma is the wrong choice](#where-prisma-is-the-wrong-choice) section below covers the cases that send you to Fly.io. **For this repo, vs Prisma Compute:** Fly.io runs your Docker image as Machines in the regions you choose, keeps WebSocket connections open, and includes high availability, backups and pooling on every [Managed Postgres](https://docs.fly.io/postgres) plan. Prisma Compute runs the app and its database on a Free plan with no usage billing, where Managed Postgres on Fly.io starts at $38 a month; one deploy workflow gives every pushed branch a preview, where Fly's review apps are per pull request. ### 5. Vercel [#5-vercel] **Best for:** a frontend whose main requirement is a global CDN, with the API and database elsewhere. **What it does.** Vercel [deploys on every push](https://vercel.com/docs/git) and gives every non-production branch a preview deployment. It hosts no Postgres; a database comes from a Marketplace provider such as Prisma Postgres, or any connection string. [WebSocket support in Vercel Functions](https://vercel.com/docs/functions/websockets) is in beta as of September 2026, and a connection closes at the function's maximum duration. **Pricing.** Hobby $0 for personal, non-commercial use; Pro $20 a month, which includes one deploying seat, $20 of usage credit and 1 TB of CDN data transfer; function invocations draw on the credit at $0.60 per million, then bill on demand ([vercel.com/pricing](https://vercel.com/pricing) and the [Pro plan](https://vercel.com/docs/plans/pro-plan), as of September 2026). **Trade-offs.** No database of its own, and the Hobby plan excludes commercial use. **Compare:** [Prisma vs Vercel](https://www.prisma.io/blog/prisma-vs-vercel). **For this repo, vs Prisma Compute:** Vercel serves the frontend from its [global CDN](https://vercel.com/docs/cdn), builds on its own machines and gives every non-production branch a preview deployment. Prisma Compute runs the API as a TypeScript server on Bun, next to Prisma Postgres in one project and region, with the database declared in the same Composer module, where on Vercel an Express API runs as a [Vercel Function](https://vercel.com/docs/frameworks/backend/express) and the database is a separate Marketplace integration. ## Just the database: Prisma Postgres, Neon or Supabase [#just-the-database-prisma-postgres-neon-or-supabase] If the app already runs on Railway, Render, Fly.io or Vercel and you only want a managed database for it, use [Prisma Postgres](https://www.prisma.io/postgres). It is PostgreSQL 17 with [PgBouncer pooling](https://www.prisma.io/docs/postgres/database/connection-pooling) included, and your app connects with a connection string, so `pg`, Drizzle, Kysely, `psql` or Prisma ORM all work and nothing about your hosting changes. Pick the region closest to the app from the [six regions](https://www.prisma.io/docs/postgres/faq#what-regions-is-prisma-postgres-available-in), because every query crosses the network between the two providers. Free has 200k operations a month and 50 databases, with no credit card. Starter is $10 a month with 1M operations and 10 GB of storage included, then $8 per million operations and $2 per GB, and data transfer is unlimited on every plan ([prisma.io/pricing](https://www.prisma.io/pricing), as of October 2026). Neon or Supabase is the pick if you need point-in-time recovery today. Prisma Postgres keeps [daily snapshots](https://www.prisma.io/docs/postgres/database/backups) on paid plans, for 7 days on Starter and Pro and 30 on Business, and has no point-in-time recovery yet. Neon's [instant restore](https://neon.com/docs/postgres/backup-restore/branch-restore) returns a root branch to any moment in its history window, and Supabase sells [point-in-time recovery](https://supabase.com/docs/guides/platform/backups) as an add-on on Pro and higher plans, for projects on at least the Small compute add-on (as of October 2026). ## Can I host my existing GitHub repo on Prisma? [#can-i-host-my-existing-github-repo-on-prisma] Yes, and you keep the database client you have: `pg`, Drizzle, Prisma ORM or any other Postgres client builds from the connection string the service receives, and you run migrations as you do today. What you add is a [Prisma Composer](https://www.prisma.io/docs/composer) declaration around each server: a `service.ts` next to it, one root `module.ts` that composes the services, and the `composer` section in `prisma.config.ts`, which only the CLI reads. The server itself needs the three changes that [Port an existing app](https://www.prisma.io/docs/composer/porting-an-app) lists: it reads its port from `service.port()` and binds `0.0.0.0`, its other `process.env` reads become service inputs or dependencies, and it builds its database client from the injected `db.url` instead of `process.env.DATABASE_URL`. The guide covers a Node.js or Bun service, a Next.js app and several services together, and a coding agent can make these changes from its [porting prompt](https://www.prisma.io/docs/composer/porting-an-app#use-with-your-agent). After your build, `npx prisma deploy module.ts` deploys the app, and once you connect the repository and add the `prisma/cloud-deploy-action` workflow, every push deploys. For an API that keeps its current Postgres client, the declaration looks like this: ```ts title="api/service.ts" import node from '@prisma/composer/node'; import { compute, rawPostgres } from '@prisma/composer-prisma-cloud'; export default compute({ name: 'api', deps: { db: rawPostgres() }, build: node({ module: import.meta.url, entry: '../dist/server.mjs' }), }); ``` ```ts title="module.ts" import { module } from '@prisma/composer'; import { rawPostgres } from '@prisma/composer-prisma-cloud'; import apiService from './api/service.ts'; export default module('my-app', ({ provision }) => { const db = provision(rawPostgres({ name: 'database' })); provision(apiService, { deps: { db } }); }); ``` `rawPostgres()` delivers `{ url }`, and you build `pg`, Drizzle or whichever client you use today from it. The Next.js frontend gets its own `service.ts` with the `nextjs` build adapter, and `module.ts` provisions it beside the API. If you want the deploy to apply migrations for you, declare `postgres()` with a [Prisma ORM 8](https://www.prisma.io/docs/orm) data contract instead; Prisma ORM 8 does not have every Prisma ORM 7 feature yet, and [what is not available yet](https://www.prisma.io/docs/orm/coming-from-prisma-orm-7#not-available-yet) lists them. ### Hand it to your agent [#hand-it-to-your-agent] The porting guide ships a [prompt for a coding agent](https://www.prisma.io/docs/composer/porting-an-app#use-with-your-agent) that surveys every server and its `process.env` reads, writes the `compute()` declarations and `module.ts`, builds the existing database client from the injected `db.url`, verifies with `npx tsc --noEmit` and `npx prisma dev module.ts`, and shows the diff before deploying. The [Prisma MCP server](https://www.prisma.io/docs/ai/tools/mcp-server) at `mcp.prisma.io` connects Claude, ChatGPT, Cursor, Codex and other MCP clients to your workspace, every CLI command accepts `--json`, `--format markdown` and `--no-interactive`, and the [Codex plugin](https://www.prisma.io/docs/ai/tools/codex) bundles both. Ali Fatemi, who had Claude deploy generated sites to Compute, [said](https://www.prisma.io/blog/claude-generated-50-websites-overnight-prisma-compute): "AIs are great with CLIs. I just told Claude: this is the docs, install the CLI and use the CLI to do stuff." ## The port, step by step [#the-port-step-by-step] 1. **Declare each server.** Add the `service.ts` and `module.ts` above, plus the `composer` section in `prisma.config.ts` (the deploy config) from the [deploy quickstart](https://www.prisma.io/docs/prisma-compute/deploy#bring-an-app-you-already-have). Then make the three changes to each Node.js or Bun server that [Port an existing app](https://www.prisma.io/docs/composer/porting-an-app#a-nodejs-or-bun-service) lists (a Next.js app uses the `nextjs` build adapter instead and follows the guide's [Next.js section](https://www.prisma.io/docs/composer/porting-an-app#a-nextjs-app)): 1. Read the port from `service.port()`, never `process.env`, and bind `0.0.0.0`. 2. Replace every other `process.env` read: config and credentials become fields of the service's input schema, and anything another service provides becomes a dependency. 3. If the server talks to Postgres, declare the database as a dependency and build your existing client from the injected `db.url` instead of a connection-string variable. The build must produce a self-contained entry file; `bun build --target=bun` does if yours does not. 2. **Run it locally.** `npm run build`, then `npx prisma dev module.ts`; every service starts with a local URL and a local Postgres. 3. **Deploy once from your machine.** `npx prisma deploy module.ts` creates the project, and a new project needs a region, set once in the deploy config or the environment. 4. **Connect the repository.** `npx prisma git connect https://github.com/you/my-app` installs the Prisma GitHub App and registers the repository. Connecting deploys nothing; it lets workflow runs authenticate and subscribes the project to branch events. 5. **Add the deploy workflow.** Commit this file: ```yaml title=".github/workflows/prisma-deploy.yml" name: prisma-deploy on: push: concurrency: group: prisma-deploy-${{ github.ref }} cancel-in-progress: false permissions: contents: read id-token: write jobs: deploy: if: github.ref_type == 'branch' runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 22 - uses: oven-sh/setup-bun@v2 - uses: prisma/cloud-deploy-action@v1 with: build-command: npm run build ``` `id-token: write` lets the job exchange GitHub's OIDC token for a 30-minute Prisma workspace token, so the repository holds no Prisma credential; from an unconnected repository the action sets its `outcome` to `skipped-no-credential` and the run stays green. 6. **Push.** The default branch deploys production; any other branch deploys a preview named after it, with its own services, databases and URL, torn down when the branch is deleted. In your code, the frontend calls the API's contract instead of a URL (a contract endpoint returns `401` to browsers, so browser-side calls move into a Next.js page or server action), the server reads port and config from the service, and the runtime is Bun. Existing data does not move: the deploy provisions a new database and copies no data into it. Two runtime properties shape the code as well. A request has 60 seconds to send its first byte, and streaming continues after that. Compute scales to zero and closes idle database connections, so keep the pool small and able to reconnect. [Composer limitations](https://www.prisma.io/docs/composer/limitations) lists what the framework does not do yet. ## Where Prisma is the wrong choice [#where-prisma-is-the-wrong-choice] * **Your API holds WebSocket connections open, or streams to other services.** Compute has no WebSocket servers, and Composer contracts are RPC over HTTP with no streaming; use Railway, Render or Fly.io. * **You are not writing TypeScript.** Compute runs TypeScript services built for Node.js, Bun or Next.js, not Python or Go; deployed apps run on Bun. A Python or Go API belongs on Railway, Render, Fly.io or a VPS. * **You need more than one region.** Each Compute service runs in one of six regions; Fly.io places Machines where you choose. * **You want to run your own Docker image.** Compute deploys the built output of Composer's `node` or `nextjs` adapter rather than an image you supply; Railway, Render and Fly.io run a container you build. * **Your frontend needs a global CDN above all.** Prisma Compute is not a CDN or edge platform, so put the frontend on Vercel and keep the database on Prisma Postgres. * **Your database needs point-in-time recovery today.** Prisma Postgres has daily snapshots on paid plans and no point-in-time recovery yet; [Just the database](#just-the-database-prisma-postgres-neon-or-supabase) names the databases that have it. * **You want the platform to run the build.** Prisma's deploys run in your GitHub Actions; Railway and Render build on their own machines. * **Your code is not on GitHub.** Deploy on push is GitHub only; other CI can run `npx prisma deploy` with a service token, but you script stages and teardown yourself. * **You want the lowest bill and will run servers yourself.** Past the free tiers, a VPS you patch yourself is the lowest monthly bill here; backups, upgrades and uptime are on you. ## Frequently asked questions [#frequently-asked-questions] ### Does connecting a GitHub repository to Prisma deploy it? [#does-connecting-a-github-repository-to-prisma-deploy-it] Connecting a repository does not deploy it. The connection lets GitHub Actions runs authenticate; deploys come from the `prisma/cloud-deploy-action` workflow, so a connected repository without it deploys nothing. ### Do I need to switch to Prisma ORM? [#do-i-need-to-switch-to-prisma-orm] No, you keep the client you have. `rawPostgres()` gives your service the connection string, and `pg`, Drizzle or any other Postgres client builds from it, with migrations run as today. The typed client and deploy-applied migrations are the `postgres()` path, which needs Prisma ORM 8. ### Does every preview branch get its own database on Prisma? [#does-every-preview-branch-get-its-own-database-on-prisma] Once deploy on push is set up, yes: every pushed branch other than the default one gets a preview with its own services and, for databases declared in the Composer module, its own new database; production data is not copied. The preview is named after the branch and deploys whether or not the branch has a pull request. On the `postgres()` path the deploy applies your committed migrations, and on `rawPostgres()` you run your own. If the app reads its connection string from a variable such as `DATABASE_URL` instead, the preview is only as separate as that value, so set a preview-scoped `DATABASE_URL` that points at a non-production database ([deploy on push](https://www.prisma.io/docs/compute/deploy-on-push)). ## Sources [#sources] * Prisma: [Deploy on push](https://www.prisma.io/docs/compute/deploy-on-push), [Known limitations](https://www.prisma.io/docs/compute/limitations), [Compute pricing](https://www.prisma.io/docs/compute/pricing), [Backups](https://www.prisma.io/docs/postgres/database/backups), [Port an existing app](https://www.prisma.io/docs/composer/porting-an-app) and [Composer databases](https://www.prisma.io/docs/composer/databases). * Railway: [pricing](https://railway.com/pricing), [environments](https://docs.railway.com/environments), [PostgreSQL](https://docs.railway.com/databases/postgresql), [what Railway manages](https://github.com/railwayapp/docs/blob/main/content/docs/databases.md#what-railway-manages), [backups](https://docs.railway.com/volumes/backups), [point-in-time recovery](https://docs.railway.com/volumes/point-in-time-recovery), [Railpack](https://docs.railway.com/builds/railpack), [Dockerfiles](https://docs.railway.com/builds/dockerfiles) and [SSE vs WebSockets](https://docs.railway.com/guides/sse-vs-websockets). * Render: [pricing](https://render.com/pricing), [preview environments](https://render.com/docs/preview-environments), [connection pooling](https://render.com/docs/postgresql-connection-pooling), [free instances](https://render.com/docs/free), [Postgres recovery and backups](https://render.com/docs/postgresql-backups) and [supported languages](https://render.com/docs/language-support). * Fly.io: [pricing](https://docs.fly.io/about/pricing/), [Managed Postgres](https://docs.fly.io/postgres), [Fly Launch](https://docs.fly.io/launch/create/) and [review apps](https://docs.fly.io/blueprints/review-apps-guide/). * Vercel: [pricing](https://vercel.com/pricing), [Pro plan](https://vercel.com/docs/plans/pro-plan), [fluid compute pricing](https://vercel.com/docs/functions/usage-and-pricing), [Git deployments](https://vercel.com/docs/git), [CDN](https://vercel.com/docs/cdn) and [Express on Vercel](https://vercel.com/docs/frameworks/backend/express). * Neon: [instant restore](https://neon.com/docs/postgres/backup-restore/branch-restore). Supabase: [database backups](https://supabase.com/docs/guides/platform/backups). The Railway, Render, Fly.io and Vercel pages were checked on 2026-09-30, their build, preview and database facts used in this post were checked again on 2026-10-08, and Railway's pricing and Fly.io's pricing, Fly Launch and Managed Postgres pages were checked again on 2026-10-14; Railway's pricing and free trial and Render's free-instance page were checked again on 2026-10-21. The Neon and Supabase pages were checked on 2026-10-07. They change often. ## Update history [#update-history] * 2026-10-22: pointed the "What Railway manages" links at that table in Railway's docs source, because Railway's databases overview page returns 404; the Railway statements are unchanged and were checked against the table on 2026-10-22. * 2026-10-21: added two rows to the top of the situation table, one for a frontend and Node API from one repository on the Free plan, with its Compute and Prisma Postgres limits from prisma.io/pricing and one link to the Compute FAQ answer on existing repositories, and one for a side project that should stay at $0, with what happens when the Free operations run out, including the one-time 24-hour grace period, and the free plans of Render and Railway; dropped the Composer declaration step from the deploy-from-GitHub row, since the new first row covers it; used the same trial wording in the Railway pricing line; put Prisma Compute first in the comparison heading, matching the order of the sections below it; said in the Prisma Compute "Best for" line that neither product needs Prisma ORM; and said under "Where Prisma is the wrong choice" that Prisma Compute is not a CDN or edge platform. Railway's pricing and free trial, Render's free-instance page and prisma.io/pricing were checked on 2026-10-21. * 2026-10-14: linked the Compute FAQ answer on existing repositories and this post's list of server changes once instead of repeating the porting steps in each platform's comparison, said in the quick recommendation that neither product needs Prisma ORM, added Railway's Free plan ($0 with $1 of credit a month after a 30-day trial with $5 of credit) to its pricing line, replaced "the most to operate of the five" in the Fly.io trade-offs with the Dockerfile and `fly.toml` you keep in the repository, which `fly launch` generates for most frameworks, said that Fly.io runs Managed Postgres (`fly mpg`), and moved the Railway and Fly.io pricing lines to October 2026, checked against railway.com/pricing and Fly.io's pricing, Fly Launch and Managed Postgres docs on 2026-10-14. * 2026-10-08: opened with the five platforms side by side, listed the three server changes a port needs, moved the cases for other platforms into one table row and "Where Prisma is the wrong choice", ended each competitor section with how it compares with Prisma Compute for this repository, noted that Railway maintains its Postgres template, changed the deploy config to the `composer` section of `prisma.config.ts`, and said in the opening that the app and the database run in one project, with the Free and Starter pricing as its own sentence. * 2026-10-07: answered the existing-repository question in the opening with the files you add and the client you keep, added a database-only row and a "Just the database" section for apps that stay on another host, kept the cases for other platforms in "Where Prisma is the wrong choice" instead of repeating them, shortened the meta title and dropped the Free plan storage figure. * 2026-10-05: linked the managed Postgres platform comparison from the Fly.io entry, pointed the limits link at the trade-offs list in the Compute FAQ, noted that Railway PR environments are a project setting, and updated Railway, Render and Fly.io links to their current paths. * 2026-09-30: rewrote the recommendation as a situation table with existing-repository rows first, added Vercel, moved the port below the table, re-checked vendor prices and docs. * 2026-09-22: first published.