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

If your app is a few TypeScript services that share a Postgres database, and those services can run on Bun in one region, Prisma is the better fit. 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.

Netlify is the better fit when your app is mostly pages and assets, or when your code depends on Node.js behavior that Bun does not provide. It is also the better fit if you need background jobs that run for minutes, or if you want every preview to start with a copy of production data.

Prisma's hosting runs on Bun in one region and gives each request 60 seconds to start responding. A preview gets a database only when you create one or a Composer stage deploy does, and that database starts empty.

"Prisma" here means more than the ORM:

• Prisma ORM 8 is the typed data layer. It is a release candidate, with general availability expected in October 2026, and it runs on any host, including Netlify.
• Prisma Postgres is the managed database.
• Prisma Compute hosts TypeScript services.
• Prisma Composer, in early access, 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.

Updated (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.

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, look at Render or Railway for a conventional long-running service, or at Prisma Compute if the backend is several TypeScript services sharing Postgres.
• 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 has to stay on Node.js, 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

Each of these is a reasonable answer to a different question, and none of them is a better Netlify.

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 the backend is several TypeScript services sharing Postgres. Your code has to run on Bun instead of Node.js, and you give up Edge Functions and an edge network. Like Netlify Functions, each service runs in one region and does not serve WebSockets. 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, such as Neon, Supabase, or Prisma Postgres, which injects the connection string as environment variables and can bill through your Vercel account. 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 outgrew functions and you want a conventional service: 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's own docs call its database templates unmanaged, so backups, tuning, security, and maintenance are yours to handle. Weigh that before treating it as the low-maintenance option for an ordinary CRUD API.

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 also has backend services around the database, generally available since September 2026: Neon Functions run JavaScript and TypeScript APIs on Node.js next to your data, including WebSocket servers, alongside object storage and managed auth. Functions do not host websites, so the frontend still needs a host. 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.

Sources for the table, by column:

• Netlify: functions configuration, Edge Functions, Netlify Database, Identity, and Image CDN.
• Prisma: Compute limitations, connection pooling, and Object Store.
• Vercel: runtimes, Functions limits, WebSockets, Marketplace storage, and Blob.
• Supabase: Edge Functions limits, 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 and Neon are covered by their profiles above, not by columns in the table.

The decision in brief

Choose Prisma if:

• 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 every Git branch to be a full environment with its own services and variables. You are willing to create, migrate, and connect its database yourself, or let a Composer stage deploy do it.
• Your services run on Bun, or can, and one region is enough.
• You accept pre-release tooling. Prisma ORM 8 is a release candidate, Composer is in early access, and the prisma/cloud-deploy-action GitHub Action that deploys on push is marked experimental. ORM 8 still lacks some ORM 7 features, including filtering inside JSON columns, atomic increment, and most nested writes, and it replaces $extends with middleware, so check what is not available yet before you move an existing app to it.

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.

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, using the experimental prisma/cloud-deploy-action, that runs 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:

1. Declare each service in TypeScript, together with what it depends on: other services, a Prisma Postgres database, a cron schedule, or object storage.
2. Give each service a contract, meaning typed request and response schemas written with arktype, zod, or any Standard Schema validator.
3. Declare the contracts a service calls as its dependencies. At runtime the service receives a typed client for each one.
4. 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.
5. 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 and a cron job 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 small server changes that involves. Without Composer, a single service deploys from the Console instead. When a second service or a scheduled job 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:

1. Create a database on the branch: npx prisma postgres create preview-db --branch feature/search.
2. Point the branch at it: npx prisma project env add "DATABASE_URL=<printed-url>" --branch feature/search.
3. 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>".
4. 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.
5. 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:

1. Alice adds phone on her branch and Bob adds avatarUrl on his. Each tests against their own database.
2. Bob's branch merges first. Alice's database has phone, Bob's has avatarUrl, and staging and production have neither.
3. 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.
4. 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.
5. 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. The exception to scale-to-zero is an app with a Composer cron schedule: the scheduler never sleeps, so every deployed app or stage keeps one instance awake. Other 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 triggered by a Composer cron schedule or an external scheduler.

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 unless the app has a Composer cron schedule. Its scheduler keeps one instance awake in every deployed app or stage, and that instance's memory is billed at $0.006 per GB-hour around the clock. 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.

Prisma Postgres is billed per operation and per GB of storage under the same plan as Compute, 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

Which one to pick

Pick Prisma if your backend is several TypeScript services that share Postgres and you can live with Bun, one region, and pre-release tooling. The compiler then checks the wiring between those services, and the deploy creates it. Start with the Composer getting-started guide, which runs two services locally without an account.

Stay on Netlify if your app is a site with functions, needs Node.js, 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.