Back to blog

Netlify alternatives for a full-stack TypeScript app with Postgres (2026)

Five Netlify alternatives for a full-stack TypeScript app with Postgres: Prisma Compute with Prisma Postgres, Railway, Render, Fly.io, and Vercel with a Marketplace database. Also covered: Supabase, Neon, PlanetScale, and Amazon Aurora, and when staying on Netlify is the better choice.

Shane NeubauerSeptember 16, 2026Updated October 14, 2026

Five Netlify alternatives host a full-stack TypeScript app's server and its Postgres database: Prisma Compute with Prisma Postgres, Railway, Render, Fly.io, and Vercel with a Marketplace database. Prisma Compute runs your Node.js, Bun or Next.js server on Bun as an instance next to managed PostgreSQL 17 with pooling, in one project and region; you add a declaration for Prisma Composer and deploy with

npx prisma deploy module.ts

, with no Dockerfile. Vercel runs the backend as functions and adds Postgres from its Marketplace, where Prisma Postgres, Neon and Supabase are listed. We make Prisma Compute and Prisma Postgres.

You declare each service, its database, and the calls between them in TypeScript, and a root module wires them together. The compiler rejects a service that points at the wrong API or the wrong database schema, and one deploy command creates everything the root module describes.

Netlify builds and publishes your site and its functions together. The connections between separate services, and the database each one uses, are yours to set up and keep correct.

"Prisma" here means more than the ORM:

• Prisma ORM 8 is the typed data layer. It is the version npm installs by default, and it runs on any host, including Netlify.
• Prisma Postgres is the managed database.
• Prisma Compute hosts TypeScript services.
• Prisma Composer declares how services and databases connect and deploys them to Compute and Prisma Postgres. Deploys on a Git push go through Composer too.

This post first looks at why teams leave Netlify and at the main alternatives. It then compares Prisma Compute and Prisma Postgres, including the Composer deploy path, with Netlify in detail. A later section covers running Prisma ORM and Prisma Postgres on Netlify.

Pick by app type

Each row is an app shape. Rows run from shapes Prisma Compute fits to shapes where another host fits better, and the last column says why.

App	Good fits	Why
Full-stack TypeScript app leaving Netlify	Prisma Compute + Prisma Postgres; Railway; Render; Fly.io; or Vercel + a Marketplace Postgres	Compute runs the app's Node.js, Bun or Next.js server on Bun next to managed PostgreSQL 17 with pooling, in one project, deployed from one repo, with one region per service; WebSocket servers are not supported on Compute; Railway, Render and Fly.io run any long-lived process; Vercel runs the backend as functions
Next.js SaaS with Postgres	Prisma Compute + Prisma Postgres; or Vercel + a Marketplace Postgres (Prisma Postgres, Neon or Supabase) when a global CDN matters	Compute runs the Next.js server next to the database; Vercel serves from its CDN and runs functions
Express, Hono or NestJS API with a frontend served by Next.js, Astro, TanStack Start or your own Node.js or Bun server	Prisma Compute + Prisma Postgres; Railway; Render	Compute runs the whole HTTP server as an instance next to the database; Railway and Render run any long-lived process
MVP on a free plan	Prisma Free (app and database, no usage billing, no credit card); Neon Free or Supabase Free when you need only the database	Prisma Free includes Compute plus 200,000 database operations a month, 2 GB of storage and 50 databases; Neon Free has 1 GB of storage per project; Supabase Free has a 500 MB database and pauses projects after a week of inactivity
Realtime app holding WebSocket connections, or background workers	Render, Railway or Fly.io	All three run WebSocket servers and always-on workers; Compute does not run WebSocket servers, and its background work runs after a request under waitUntil
Several regions	Fly.io	One Fly.io app can run in several regions at once; each Compute service runs in one region
Mostly static pages and assets, with functions on the side	Stay on Netlify	Its edge network serves them

Sources, checked 2026-10-08: Prisma pricing and Compute limitations; Vercel Marketplace storage; Neon pricing; Supabase pricing; Render WebSockets and background workers; Railway specs and limits and services; Fly.io WebSockets, process groups and scaling across regions.

Also for the first row, checked 2026-10-14: Prisma Postgres docs and Compute FAQ; Vercel Functions.

Compute runs your Node.js, Bun or Next.js server on Bun, as an instance that scales to zero when idle. Only the first byte of a response has a deadline: it must go out within 60 seconds, and a streamed response keeps going after that.

waitUntil

keeps the instance awake to finish work after the response is sent, on a best-effort basis. Compute does not run WebSocket servers, and each service runs in one region. If your code depends on Node.js behavior that Bun does not provide, that is a reason not to move.

Netlify is the better fit when your app is mostly pages and assets served from its edge network, or when you want every preview to start with a copy of production data. On Prisma, a preview's database is created by you or by a Composer stage deploy, and it starts empty.

Why teams leave Netlify

Netlify is rarely the wrong choice for the app you started with. It becomes the wrong choice when the app changes shape, and the reasons repeat:

• The backend outgrew functions. What began as a few endpoints became several services that call each other, and Netlify Functions have no way to express that. You end up with URLs in environment variables and types kept in sync by hand.
• A request needs to stay open. Netlify Functions can stream a model response, but a streaming function stops after 60 seconds, and Netlify Functions do not serve WebSockets.
• The database lived somewhere else. Teams that started before Netlify Database, or chose another Postgres, run the site and functions on Netlify and the database with a second vendor: a second bill, and a connection string to keep in sync unless an integration such as the Prisma Postgres extension sets it. Netlify Database, billed from the same credits as the site, removes that split.
• The bill stopped being predictable. Credit-based metering is hard to forecast before you have traffic, and easy to misread after. Moving to another usage-metered host, Prisma Compute included, does not remove the forecasting problem, so price your own traffic on each one before you move.
• Node.js was assumed. If your stack moved to Bun, or you want to, the runtime is fixed: Netlify Functions run on Node.js, and Edge Functions run on Deno.

Which of those applies decides where you should go:

• If the backend outgrew functions, Prisma Compute runs it on Bun next to its Postgres database, as one TypeScript service or several that call each other. Render and Railway fit a backend that ships as a Docker image.
• If a request needs to stay open, separate streams from sockets. A streamed response, such as a model's output, works on Prisma Compute as long as the first bytes go out within 60 seconds, and a started stream is not cut off after that. WebSocket servers need a host that supports them, such as Render web services, Neon Functions, or Vercel Functions, where WebSockets are in beta. Compute does not support WebSocket servers.
• If the database lived somewhere else, Prisma, Render, and Railway run the app and its Postgres with one vendor, and Neon now runs backend functions next to its database. A Vercel Marketplace database can bill through your Vercel account but is still another company's product.
• If the bill stopped being predictable, compare meters, not plan names. The pricing section below sets Prisma's meters against Netlify's credits.
• If you want Bun, Prisma Compute runs on it, and Render and Vercel both offer a Bun runtime. If your code depends on Node.js behavior Bun does not provide, that is a reason not to choose Compute.

The profiles below say which of these each option answers.

The alternatives, by what you are replacing

The profiles below say when each option is the better choice.

Prisma Compute and Prisma Postgres. The app and the database in one project, with the connection string injected instead of copied when you deploy with Composer, a database per branch that you or a Composer stage deploy create, and pooling included. Best when you want a TypeScript app and its Postgres database in one project from one vendor; Starter is a $10 base with Compute usage metered on top. Compute runs TypeScript services on Bun: Node.js, Bun or Next.js apps, declared with Composer's

node

or

nextjs

build adapter. You give up Edge Functions and an edge network. The rest of this post is the detailed version.

Vercel. Vercel maintains Next.js, which makes it the closest like-for-like swap for a Next.js site. It has a global CDN, Image Optimization, and Blob storage, and its Functions run Node.js, Bun, Python, and other runtimes. It has no Postgres of its own: you add one from the Vercel Marketplace, which injects the connection string as environment variables and can bill through your Vercel account. Prisma Postgres has an official integration there that sets

DATABASE_URL

in your Vercel project, and Neon and Supabase are listed too. The database is still a second company's product, but it is not a separate bill or a copied connection string. Vercel Services, in beta, also let one backend in a project call another over an internal binding.

Render. Long-running web services plus managed Postgres, declared in a

render.yaml

Blueprint committed to the repo. It fits when the backend needs what a conventional service gives it: Render web services allow HTTP responses to take up to 100 minutes, accept WebSocket connections, and run Node.js, Bun, other native runtimes, or a Docker image. Render Postgres includes PgBouncer pooling on paid databases once you enable it.

Railway. The same territory as Render, with long-running services and a Postgres deployed from a template into the same project. 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).

Fly.io. Runs almost any app that has a Dockerfile, and one app can run in several regions at once. It fits when the same app has to be close to users on more than one continent. Fly.io also runs a managed Postgres service.

Supabase. Postgres with auth, storage, realtime, and Edge Functions from one vendor. It fits when what you miss is those surrounding services, and it fits poorly if all you need is a database and a host for a Node.js or Bun server, because its Edge Functions run on a Deno-compatible runtime.

Neon. Postgres with copy-on-write branching, and the database Netlify Database is built on. Neon Functions (generally available since 2026-09-17, also on Free) run Node.js 24 HTTP handlers next to the database, including WebSockets and SSE, alongside Neon's object storage and managed auth. Neon's full-stack guide keeps the UI on Vercel, Netlify or another frontend host (neon.com, checked 2026-10-08). Each Neon branch gets its own copy of the data and its own deployment of the functions, which can give each pull request a copy of production data, as Deploy Previews do on Netlify.

PlanetScale. A database, not a host, so it replaces Netlify Database and leaves Netlify in place. It runs Postgres alongside its MySQL-compatible Vitess databases, with single-node Postgres from $5 a month that PlanetScale pitches at development, prototyping, and small projects, and branching workflows for testing schema changes safely. It leads with speed and scale, which matter more once the database is under real load.

Amazon Aurora is AWS's managed database, compatible with Postgres and MySQL, which AWS pitches on availability and scale across regions. Like PlanetScale, it replaces Netlify Database and does not host your app.

Feature parity at a glance

What you get from one vendor, which is usually the real question behind leaving.

	Netlify	Prisma	Vercel	Supabase	Render
App hosting	Yes	Yes	Yes	Edge Functions only	Yes
Runtime	Node.js functions; Deno Edge Functions	Node.js, Bun or Next.js apps, run on Bun; they scale to zero when idle	Node.js, Bun, Python, and others	Deno-compatible Edge Functions	Node.js, Bun, and other native runtimes, or Docker
Longest request	60 seconds; Background Functions up to 15 minutes	60 seconds to first byte, then a started stream keeps going	300 seconds by default, up to 800 on Pro and Enterprise; 30 minutes in beta on Pro and Enterprise for Node.js and Python functions	150 seconds to respond; wall-clock limit 150 seconds on Free, 400 on paid plans	100 minutes
Realtime or WebSocket servers	No	No	WebSockets in Functions (beta); no managed realtime service	Realtime service	WebSockets on web services; no managed realtime service
Managed Postgres	Netlify Database, built on Neon	Prisma Postgres	No; add one from the Marketplace	Yes	Yes
Connection pooling included	Not documented; the @netlify/database driver picks the connection method	Dedicated PgBouncer per database	Depends on the database	Shared pooler, plus a dedicated pooler on paid plans	Built-in PgBouncer on paid databases, opt-in
Auth	Netlify Identity	No	No	Yes	No
Object storage	Blobs	Object Store buckets (pricing not yet published)	Blob	Yes	No
Edge network and image CDN	Yes	No	Yes	Storage CDN; image transformations on Pro and above	Global CDN for static sites and paid web services; no image CDN
Preview per branch	Deploy Preview; database branch with a copy of production data	Branch environment; database created by you or a Composer stage deploy, starts empty	Preview deployment	Branching on Pro and above, empty by default	Preview environment on Pro workspace and above

Sources for the table, by column:

• Netlify: functions configuration, Edge Functions, Netlify Database, Identity, and Image CDN.
• Prisma: Compute FAQ, Compute limitations, connection pooling, and Object Store.
• Vercel: runtimes, Functions limits (checked 2026-10-14), WebSockets, Marketplace storage, and Blob.
• Supabase: Edge Functions limits (checked 2026-10-14), connecting to Postgres, Storage CDN, branching, and pricing.
• Render: native runtimes, Render vs Vercel, WebSockets, connection pooling, static sites, and preview environments.

Start from the rows your app cannot do without, and rule out every column that cannot meet one of them. The sections below cover the trade-offs among what is left. Railway, Fly.io, and Neon are covered by their profiles above, not by columns in the table.

The decision in brief

Choose Prisma if:

• Your app is a TypeScript frontend, an API, and a Postgres database, and you want all three deployed from one repo, with no Docker image to maintain.
• Your server is Node.js, Bun or Next.js code that runs on Bun, one region is enough, and the server does not hold WebSocket connections open.
• You want every pushed feature branch to get its own preview, with its own services and a database built from your migrations, once deploy on push is set up. That database starts empty, without production data.
• Several TypeScript services call each other, and you want a mismatched API contract or a missing handler to fail the type check instead of a deploy or a production request.
• You want to keep the Postgres client you have. Prisma ORM is optional on Compute, so moving does not mean upgrading to Prisma ORM 8, which still lacks some ORM 7 features (what is not available yet).

Choose Netlify if:

• Your app is mostly pages and assets, and you want a global edge network, caching, and an Image CDN without building them into the app.
• Your code runs on Node.js and you do not want to move it to Bun.
• You have background work that runs for minutes. Netlify Background Functions run up to 15 minutes and retry twice on error, and Async Workloads add configurable retries and multi-step jobs.
• You want preview databases that start as a copy of production. Netlify Database creates one for every Deploy Preview.

	Prisma	Netlify
Hosting	TypeScript services on Prisma Compute, on Bun, one region each	Serverless and Edge Functions deployed with the site
Managed Postgres	Prisma Postgres, usable from any client	Netlify Database, built on Neon
Typed data access	Prisma ORM 8 or any client	Drizzle or any driver or ORM, including Prisma ORM
Service-to-service calls	Composer binds each dependency to a typed contract and checks it at compile time	Site and functions share types by import; separate services are wired by hand
Previews	One environment per pushed branch; with GitHub connected, torn down when the Git branch is deleted	A Deploy Preview per pull request, plus branch deploys
Preview databases	One per branch, created by you or by a Composer stage deploy, no production data	A database branch per Deploy Preview with a copy of production
Long-running work	60 seconds to first byte, then streaming or waitUntil; no WebSockets	Background Functions up to 15 minutes, with two retries on error; Async Workloads
Billing	Plan base fee (Starter $10) with included requests and operations; Compute memory, CPU and bandwidth metered on top	Credits for compute, requests, bandwidth, and production deploys

Sources for the table: Prisma's Compute limitations, Compute pricing, branching, object storage (which states Compute apps run on Bun), Composer, and Prisma Postgres pages; Netlify's Netlify Database, database tooling, Background Functions, Async Workloads, and pricing pages; and Netlify's Netlify Database announcement for the Neon partnership.

What each platform sets up for you

Both platforms can deploy on every Git push, but the setup differs. Netlify builds your production branch and every pull request once you connect the repository. On Prisma you connect the repository and also commit a GitHub Actions workflow that uses prisma/cloud-deploy-action to run

prisma deploy

on your Composer module. The platforms also differ in how much of your app's structure they know about.

On Netlify, you connect a repository and a build command. Each push builds the frontend and its serverless functions together and publishes them as one site. A page and the function it calls always come from the same commit, and they can share TypeScript types through normal imports.

Netlify has no concept of one deployed service calling another. If your backend grows into several services, you connect them with URLs and environment variables, and you keep their types in sync yourself.

On Prisma, Composer works at the level of services:

• Declare each service in TypeScript, together with what it depends on: other services, a Prisma Postgres database, or object storage.
• Give each service a contract, meaning typed request and response schemas written with arktype, zod, or any Standard Schema validator.
• Declare the contracts a service calls as its dependencies. At runtime the service receives a typed client for each one.
• Wire everything in a root module. TypeScript checks the wiring, so binding a dependency to a service with a different contract, or leaving out a handler the contract requires, is a compile error.
• Run npx prisma deploy module.ts, or push once the deploy workflow is committed. It creates the services on Prisma Compute, the databases on Prisma Postgres, and the authenticated connections between them. Application code never builds a URL from process.env.

The two files below declare a storefront that asks a catalog service for a price. The storefront names the catalog's contract in

deps

, and the root module decides which running service satisfies it.

import nextjs from "@prisma/composer/nextjs";
import { rpc } from "@prisma/composer/service-rpc";
import { compute } from "@prisma/composer-prisma-cloud";
import { catalogContract } from "../catalog/contract.ts";

export default compute({
  name: "storefront",
  deps: { catalog: rpc(catalogContract) }, 
  build: nextjs({ module: import.meta.url, appDir: "." }), // the Next.js app root, relative to this file
});

Suppose the catalog team changes the

product

type in its contract so that a price is an amount and a currency instead of a single

priceCents

number. Every caller that still expects a number fails to compile. A shared-types package in a monorepo gives you that much.

The root module adds a second check. If it binds

storefront

to a service that serves a different contract, that is a compile error too, not a 404 after the deploy. The store example in the Composer repository is a fuller version of this app. It adds an orders service alongside the storefront and catalog, and keeps each one under

modules/

instead of

src/

.

Databases are declared the same way. A service lists a

postgres()

dependency typed by your data contract, the

contract.prisma

schema file that replaced

schema.prisma

in ORM 8, and receives the connection and a typed client from

service.load()

, with no

DATABASE_URL

to set. The module that owns the database provisions it. The deploy applies the database's migrations before the service starts, and it refuses to connect a service to a database whose schema does not match the contract the service was compiled against.

You do not need contracts or several services to start. Deploys on a Git push run through the prisma/cloud-deploy-action GitHub Action, which runs

prisma deploy

on a Composer module (

module.ts

by default). So even a single service needs a one-service module to deploy on push, and the porting guide shows the three server changes that involves. Without Composer, a single service deploys from the Console instead. When a second service appears, add it to the module.

Previews and their databases

Both platforms can give every branch a running preview. They differ in what sits behind it, and that decides how much setup you do before a preview is useful.

On Prisma, a Git branch maps to a platform branch with its own services, environment variables, and any databases created on it. When the project is connected to GitHub, deleting the Git branch tears down that platform branch and its resources, although production and the default branch are never torn down. The database is not created for you unless you use Composer. For a single service deployed without Composer:

• Create a database on the branch: npx prisma postgres create preview-db --branch feature/search.
• Point the branch at it: npx prisma project env add "DATABASE_URL=<printed-url>" --branch feature/search.
• Apply your migrations to it over the direct connection string, which is the printed URL with the host db.prisma.io in place of pooled.db.prisma.io: npx prisma db migrate --db "<direct-url>".
• Redeploy the branch so it picks up the new DATABASE_URL, because variables are resolved at deploy time and changing one does not trigger a redeploy.
• Seed it if the feature needs realistic rows, because it starts empty.

With Composer, the deploy action deploys each pushed branch as a stage, and

npx prisma deploy module.ts --stage <branch>

does the same from your terminal. A stage deploy replaces the first four steps: it creates the databases the module declares, passes each service its connection, and applies the committed migrations of each

postgres()

database before the services start. Those databases still start empty, because preview data is not copied from production.

A preview uses whatever

DATABASE_URL

its preview scope or branch override gives it, so if that value is the production connection string, the preview writes to production. Keep production and preview values in separate scopes, as the environment variables docs describe.

On Netlify, each Deploy Preview gets a database branch that already holds a copy of production data from when the preview was created. Netlify applies migration files committed to Git on both production and preview deploys, and changes made in the preview branch never reach production.

For testing against production-shaped data, this is the more convenient setup, because there is nothing to seed and nothing to point.

On both platforms, schema changes live in Git as migration files. On Netlify, a deploy applies the ones in Netlify's own migrations directory. On Prisma, a Composer deploy applies them for each

postgres()

database, while a single service deployed without Composer does not apply them, so you run

db migrate

against each branch's database yourself. Prisma ORM 8 helps when two branches change the schema at the same time:

• Alice adds phone on her branch and Bob adds avatarUrl on his. Each tests against their own database.
• Bob's branch merges first. Alice's database has phone, Bob's has avatarUrl, and staging and production have neither.
• In Prisma ORM 6 and 7, migrations ran in timestamp order, so every database had to be walked through the same list. ORM 8 records, for each migration, which schema version it starts from and which it produces, so the migrations form a graph.
• Alice, merging second, rebases onto main and plans one migration from the state production is headed to: npx prisma migration plan --name alice_merge --from prod, where prod is a ref that main points at the state Bob's migration produces. Her original migration can stay on disk, but it never runs.
• From then on, db migrate brings staging, production, and Bob's database to the merged schema. Alice brings her own development database, still on her pre-merge state, to the merged schema with npx prisma db update.

Two migrations that change the same column still need a person to resolve them.

The graph belongs to Prisma ORM 8, not to Prisma's hosting, so you get it on Netlify by running ORM 8 there. The hosting adds a database per branch to test against, created by you or a Composer stage deploy, and with Composer, a deploy that runs the migrations for you.

Runtime limits

Prisma Compute runs TypeScript HTTP services on Bun. You run the build yourself: the GitHub deploy action runs your build command verbatim, and a Composer service declares its build with the

node

or

nextjs

adapter. An existing Node.js app has to run under Bun to move. The limitations page lists the constraints:

• Each service runs in one region, and there is no edge runtime.
• WebSocket servers are not supported.
• A request has 60 seconds to start responding before Compute cancels it. A response that has started streaming is not cut off.
• Work that continues after the response, such as processing a webhook after returning 202, uses waitUntil. That keeps the instance alive but does not retry a failure or survive a redeploy.

An instance scales to zero when idle, so a quiet preview costs nothing. The next request after a quiet period resumes the instance from a memory snapshot, which the Compute docs put at milliseconds, and a first call into a sleeping service can fail with

ECONNRESET

, which Composer's generated RPC client retries. Work that must keep an instance awake uses waitUntil or KeepAwakeGuard.

Compute runs your app next to Prisma Postgres, and every Prisma Postgres database runs a dedicated PgBouncer instance beside it, so pooling needs no setup even from a serverless caller. Each database has a pooled connection string for application traffic and a direct one for migrations and admin tools. Netlify's docs do not say whether

NETLIFY_DB_URL

is a pooled endpoint: the

@netlify/database

client picks a connection method for each environment, but a Prisma app that reads the variable directly has no documented pooling to rely on. Render Postgres includes PgBouncer on paid databases once you enable it. On a host paired with a database you brought yourself, the pooler is yours to arrange, and Postgres allocates memory per connection, so a connection limit arrives long before a CPU limit. One caveat on Compute: because it scales to zero, idle database connections get closed, so keep the pool small and reconnect-friendly.

Compute does not require Prisma ORM, so moving to it does not mean upgrading to ORM 8. The Bun runtime and the limits above still apply. ORM 6 receives security patches only until 19 November 2026, and the migration behavior above assumes ORM 8.

Netlify Functions run on Node.js, and static assets are cached on the edge network without any application code. Function responses are cached only when they set cache headers, and the Image CDN transforms images requested through

/.netlify/images

URLs or a supported framework's image component. For asynchronous work, Background Functions run for up to 15 minutes and retry twice on error, and Async Workloads add configurable retries and multi-step jobs. If your app already has a queue-and-worker shape, Netlify supports it directly. On Compute, that work moves into short requests, best-effort background work under

waitUntil

, or persisted steps that an external scheduler triggers with a request.

What you pay for

Prisma Compute charges a plan fee plus four usage meters. Memory is billed while an instance is running or kept awake, and nothing is billed once it has scaled to zero, so an idle preview costs nothing. Creating a deployment or a preview branch is not billed, and there are no seat charges.

Netlify bills metered usage in credits from a monthly allowance. Production deploys consume credits. Creating a Deploy Preview or branch deploy does not, but requests, bandwidth, and compute on those previews draw from the same credit allowance as production traffic. The dollar column below converts credits at the Pro rate of $20 for 3,000 credits, which is the same per-credit price as Netlify's Pro add-on.

Meter	Prisma	Netlify (credits, in dollars at the Pro rate)
Plan	Free, or $10, $49, or $129 a month for Compute and Prisma Postgres together, with 5, 20, or 100 million requests and 1, 10, or 50 million database operations included	Pro from $20 a month for 3,000 credits
Requests	$1 per million after the included amount	2 credits per 10,000, about $1.33 per million
Compute	$0.006 per GB-hour of memory plus $0.064 per vCPU-hour of CPU	10 credits per GB-hour, about $0.067, with no separate CPU meter
Bandwidth	$0.025 per GB	20 credits per GB, about $0.13
Database	In the same project as Compute; 10, 50, or 100 GB of storage included on Starter, Pro, or Business, then $8, $2, or $1 per million operations and $2, $1.50, or $1 per GB of storage	Database compute at 10 credits per GB-hour, about $0.067
Production deploys	Not billed	15 credits each, about $0.10
Preview and branch deploys	Not billed; the preview's usage is billed like production	0 credits; the preview's requests, bandwidth, and compute use credits like production

Prisma Postgres runs in the same project as Compute and is billed per operation and per GB of storage, not as a separate subscription, and every paid plan includes a spend limit. The pricing page lists what each plan includes. Netlify Database's compute and bandwidth come out of the same credit allowance as the site.

Using Prisma ORM and Prisma Postgres on Netlify

Prisma ORM does not require Prisma's hosting. Netlify Database is Postgres, so the ORM connects to it like any other Postgres database once it exists, and the tooling page confirms that any driver or ORM works. Without the

@netlify/database

package, Netlify does not provision the database for you, so create it under Data & Storage > Database in the Netlify UI.

The migration command below is Prisma ORM 8's, and its CLI needs Node.js 22.18 or newer (24.11 or newer on the 24 line). Older Netlify sites stay pinned to the Node.js version that was the default when they were created, so set

NODE_VERSION

to

24

if yours is older. To migrate a Deploy Preview's database branch, run

npx prisma db migrate --db "$NETLIFY_DB_URL"

in the Deploy Preview build command only, for example as the

command

under

[context.deploy-preview]

in

netlify.toml

, so production builds do not run it. Netlify exposes each preview's database branch through that variable.

Netlify has no hook that runs when a deploy is published, so apply production migrations out of band, and backwards-compatible, before you publish, as Netlify's migrations page recommends. Keep Prisma's migration files out of

netlify/database/migrations

, because Netlify applies anything in that directory automatically. On Prisma ORM 7, set

datasource.url

in

prisma.config.ts

to

env("NETLIFY_DB_URL")

and run

npx prisma@7 migrate deploy

instead, because that command reads its database URL from the config file.

Prisma Postgres is also available to Netlify sites through the official Netlify extension, which sets

DATABASE_URL

for you. The Netlify guide walks through it and is written for Prisma ORM 7 today.

Frequently asked questions

Prisma Compute runs a server, not separate functions. It runs your whole HTTP server process, a Node.js, Bun or Next.js app run on Bun, as an instance. The instance scales to zero when idle and resumes from a memory snapshot with its memory intact. Your service has 60 seconds to start responding to a request; the deadline covers the wait for the first bytes, so a streaming response that has started keeps going. waitUntil keeps the instance awake to finish work after the response is sent, on a best-effort basis: it does not retry a failure or continue through a restart or a new deployment. Compute does not run WebSocket servers, and it has no cron scheduling. See Known limitations and Request timeout.

Prisma replaces part of what Netlify does. For a TypeScript app that runs on Bun, or can move to it, Prisma Compute can host the app and its API, and Prisma Postgres can replace Netlify Database. Prisma does not replace Netlify's edge network, caching, Image CDN, or Identity. Compute has no WebSockets, runs each service in one region, and gives a request 60 seconds to start responding.

Each preview gets its own database once you or a Composer stage deploy create it, and that database starts without production data. Each Git branch is an isolated environment. With Composer, the stage deploy creates the database, applies its migrations, and passes the connection to your services. Without Composer, you create the database with the CLI, point a preview-scoped or branch-scoped

DATABASE_URL

at it, apply your migrations, and redeploy, and that separate

DATABASE_URL

keeps the preview off production.

The migration graph is a record of which schema version each migration starts from and produces. After two branches merge, you plan one migration to the merged schema, and

db migrate

follows the recorded migrations from each deployed database's current version to reach it. A development database left on a pre-merge state is brought to the merged schema with

db update

. It is an ORM feature and works on any host, including Netlify.

Five Netlify alternatives host a full-stack TypeScript app with a Postgres database: Prisma Compute with Prisma Postgres, Railway, Render, Fly.io, and Vercel with a Marketplace database. Prisma Compute and Prisma Postgres run the app and its database in one project, deployed on every push through the repository connection and the prisma/cloud-deploy-action workflow. The Free plan includes 200,000 database operations a month and 50 databases, with no credit card and no usage billing. Starter is a $10 a month base that includes 1 million operations a month and 10 GB of storage, plus metered compute. Choose Railway or Render instead if you need a WebSocket server or a Docker image, and Fly.io for many regions. Vercel is the closest swap for a Next.js frontend, and its database comes from the Vercel Marketplace, where Prisma Postgres has an official integration and Neon and Supabase are listed too. Render's Postgres is managed. 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).

Prisma ORM works with Netlify Database, which is PostgreSQL built on Neon, and it connects to it like any other PostgreSQL database once the database exists. Without the

@netlify/database

package, create the database in the Netlify UI first. Run preview migrations in the Deploy Preview build command, and apply production migrations out of band before you publish, since Netlify has no publish-time hook. Prisma Postgres is also available through the official Netlify extension.

Which one to pick

Prisma Compute and Prisma Postgres deploy a full-stack TypeScript app's frontend, API, and Postgres database from one repo, and once deploy on push is set up, every pushed feature branch gets a preview with its own services and a new database for each Prisma Postgres database the Composer module declares. To move an app you already have, add a Composer declaration next to your server code, a

service.ts

for each server and one

module.ts

, and make the three server changes the porting guide lists, such as reading the port from

service.port()

instead of

process.env

. To try it before you move anything, the Composer getting-started guide runs two services locally without an account.

Pick another host when the app needs something Compute does not do. Railway and Render run WebSocket servers (Railway, Render) and deploy from a Docker image (Railway, Render). Fly.io runs one app in several regions at once. Vercel fits a Next.js-first frontend on its global CDN, with Prisma Postgres added from the Vercel Marketplace as its database.

Stay on Netlify if your app is a site with functions, depends on the Node.js runtime itself rather than Bun, needs long background jobs or a global edge, or if you want previews that arrive with production data. The Netlify guide connects Prisma Postgres to a Netlify site through the official extension. It is written for Prisma ORM 7 today.

Update history

• 2026-10-14: moved the two paragraphs on the Compute runtime and when Netlify is the better fit below the "Pick by app type" table, added a first row to that table for a full-stack TypeScript app leaving Netlify that names all five alternatives and two Compute limits, and updated two cells in the longest-request row of the feature-parity table from each vendor's limits page: Vercel lists a 30-minute maximum in beta on Pro and Enterprise, and a Supabase Edge Function has 150 seconds to respond on every plan; updated Prisma Postgres Free storage from 1.01 GB to 2 GB.
• 2026-10-12: reworded the FAQ answer on Netlify alternatives and the first paragraph of the closing section to describe the options side by side.
• 2026-10-08: rewrote the description and the opening to name five alternatives side by side, added a "Pick by app type" table and an FAQ on whether Compute runs functions or a server, updated the Railway and Neon profiles from their docs, stated the Starter base fee and metered Compute usage in the Prisma profile and the billing row, made the closing section say that Netlify fits code that depends on the Node.js runtime itself rather than Bun, and moved this history to the end.
• 2026-10-07: changed the opening and the feature-parity table to describe the Compute runtime in the wording of the Compute FAQ, and the closing verdict to match the opening. The Vercel profile now links the Prisma Postgres integration on the Vercel Marketplace, a Fly.io profile was added, and the sentences about Composer cron schedules were removed. The Vercel, Railway, Render, and Fly.io facts added that day were checked against each vendor's own pages.
• 2026-10-06: changed the opening, the introduction to the alternatives, and the FAQ answer on Netlify alternatives to lead with Prisma Compute and Prisma Postgres, and the Prisma profile to the runtime wording from the Compute docs. The Railway, Render, Fly.io, and Vercel facts in that answer were checked against each vendor's own documentation that day.
• 2026-10-05: changed the title to name the subject.
• September 2026: added the reasons teams move off Netlify, short profiles of the other alternatives, a feature-parity table, and connection pooling and scale-to-zero in the runtime section. Prisma, Netlify, and other vendor figures were checked against each vendor's own documentation between 2026-09-24 and 2026-09-26.
• 2026-09-16: first published.

About the author

Shane Neubauer

Shane is a product leader at Prisma with more than 15 years in technology, including five years prototyping new products at Google and founding a venture-backed startup of his own. He writes about product strategy, go-to-market, and building tools developers genuinely want to use.

Keep reading

[Case StudyJune 30, 2026

How One Founder Builds a Live Sports Platform Without a Database Team

How Xeito uses Prisma ORM and Prisma Postgres to ship live scoring, leagues, payments, and player workflows without a database team.

Gregory Boch](https://www.prisma.io/blog/how-xeito-builds-features-not-database-infrastructure-with-prisma)

[PlatformSeptember 16, 2026Updated October 13, 2026

Prisma vs Vercel: where should you build your next TypeScript app?

Prisma vs Vercel compared for TypeScript apps: what each platform provisions and checks for you, preview databases, migrations, runtime limits, and pricing.

Shane Neubauer](https://www.prisma.io/blog/prisma-vs-vercel)

Build your next app with Prisma

Start free. Scale when you’re ready.

Try Prisma