Add Prisma vs Vercel platform comparison blog post

apps/blog/content/blog/prisma-vs-vercel/index.mdx

@@ -0,0 +1,117 @@
+---
+title: "Prisma vs Vercel: where should you build your next TypeScript app?"
+slug: "prisma-vs-vercel"
+date: "2026-09-16"
+authors:
+  - "Shane Neubauer"
+metaTitle: "Prisma vs Vercel: comparing TypeScript application platforms"
+metaDescription: "Compare Prisma and Vercel for TypeScript apps: ORM 8, Postgres, Compute, Composer, service contracts, preview databases, deployment workflows, and pricing."
+excerpt: "Prisma and Vercel both host full-stack applications. Compare how they connect services, manage database changes, deploy previews, and charge for usage."
+tags:
+  - "platform"
+  - "prisma-postgres"
+  - "orm"
+---
+
+Prisma and Vercel both host full-stack applications and deploy Git branches as previews you can review before merging. Prisma connects the data model, managed Postgres, and application services through TypeScript definitions. Vercel builds your framework's frontend and backend code and serves the deployed application through its delivery network. Databases connect through its Marketplace.
+
+That difference matters when a feature crosses several parts of the application. A new checkout flow might need a database table, an orders service, and a frontend that calls it. Prisma puts the data and service contracts in the codebase, where a developer or coding agent can inspect them and TypeScript can check that the callers match the APIs they use.
+
+The Prisma platform includes **[Prisma ORM 8](https://www.prisma.io/docs/orm), [Postgres](https://www.prisma.io/docs/postgres), [Compute](https://www.prisma.io/docs/compute), and [Composer](https://www.prisma.io/docs/composer)**. Together, they cover typed data access, database hosting, application execution, and the connections between services.
+
+## Choose Prisma when…
+
+- You're building a TypeScript application and want the data model, managed Postgres, and application hosting to work together from the start.
+- Your services depend on each other, and you want typed API contracts and resource dependencies declared alongside the application code.
+- You want to test the running application and its schema changes before merging, with a preview deployment and separate database for each Git branch, and schema changes brought together through Prisma ORM's migration graph.
+- You're building with a coding agent and want it to inspect the data contract, service contracts, and infrastructure definitions in the same repository.
+
+## Choose Vercel when…
+
+- Your main priorities are framework integration and global web delivery, particularly for a Next.js application.
+- You want to choose a database provider through the Marketplace and use its integration to provision databases for your application and previews.
+- You're deploying a frontend and backends in different languages, such as Next.js and Python, within one Vercel project.
+
+## How do Prisma and Vercel compare?
+
+The practical differences show up in what the platform connects for you and what you describe in application code:
+
+| What you need | Prisma | Vercel |
+| --- | --- | --- |
+| Application hosting | TypeScript HTTP services on Prisma Compute | Framework deployments and Vercel Functions; Services can group multiple frontends and backends |
+| Managed PostgreSQL | Prisma Postgres, usable with any PostgreSQL client | Marketplace providers, including Prisma Postgres and Neon |
+| Typed data access | Prisma ORM 8, or your preferred PostgreSQL client | Your choice of ORM or database client, including Prisma ORM |
+| Application composition | Composer declares resources, service contracts, and typed dependencies | Services declares build units, routing, and private service bindings |
+| Application previews | Deploy each Git branch to an isolated environment for review before merging | Deploy Git branches to preview URLs for review before merging |
+| Preview databases | A separate database per Git branch, with schema changes managed through Prisma ORM | Provider-specific isolation; Neon's preview integration creates copy-on-write database branches |
+| Runtime billing | Requests, provisioned memory, active CPU, and outbound bandwidth | Fluid compute usage, plus applicable delivery and other platform usage |
+
+The table draws on the [Prisma Compute](https://www.prisma.io/docs/compute) and [Composer](https://www.prisma.io/docs/composer) docs, and Vercel's [Services](https://vercel.com/docs/services), [storage integrations](https://vercel.com/docs/storage), and [Fluid compute pricing](https://vercel.com/docs/functions/usage-and-pricing) documentation. The preview and billing differences are explained below.
+
+## How do you define and change the application?
+
+Prisma Composer lets you describe an application's services and infrastructure in TypeScript. Each service declares what it needs, and the application's root module connects those dependencies to the services or resources that provide them.
+
+Take a storefront that calls a catalog service and an orders service. Orders asks the catalog for a product's price before saving a purchase. With Composer, those APIs have typed contracts, and the callers receive typed clients for their dependencies.
+
+Now change the catalog's response from a single price to an amount and a currency. When callers use the updated contract, TypeScript can identify code that still expects the old shape. The service relationship and API definition are both in the repository, where a teammate or coding agent can inspect them. The [Composer store example](https://github.com/prisma/composer/tree/main/examples/store) shows this pattern.
+
+Composer also provisions the declared resources and sets up authenticated connections between services. Its contracts describe RPC calls over HTTP. You build your code first, then Composer assembles the output for deployment.
+
+Prisma ORM 8 is a complete TypeScript rewrite built around a separate contract for the database: a JSON description of its structure with accompanying TypeScript types. Queries and migration tooling work from that description. The ORM contract describes the data; Composer's contracts describe the APIs between services. You can review both alongside the feature code. The [ORM architecture](https://github.com/prisma/orm/blob/main/ARCHITECTURE.md) explains how the data contract works.
+
+Vercel also supports applications with multiple services. Its [Services model](https://vercel.com/docs/services) groups frontends and backends into one deployment, with routing and private bindings declared in configuration. That includes applications combining different languages, such as a Next.js frontend and a Python backend.
+
+A [Vercel binding](https://vercel.com/docs/services/bindings) makes another service reachable through an injected URL. Composer's RPC dependency supplies a client typed against the service contract. For our storefront, Composer includes the catalog API's input and output types in the dependency declaration. Changing that contract gives the compiler something to check in the orders service. A Vercel application can add shared types or generated clients to check those calls; Composer makes the contract part of how you connect the services.
+
+You can start smaller. A single service can use Prisma Compute and Postgres directly, then adopt Composer when declaring more of the application together becomes useful.
+
+## How do you deploy and test changes?
+
+Both platforms let you review a running application before merging. With Prisma's GitHub integration and deploy-on-push configured, each push to a feature branch deploys the application to that branch's preview environment. Each branch owns its services and deployments, so the team can test the feature in isolation from production. The [branching documentation](https://www.prisma.io/docs/compute/branching) explains how Git branches map to these environments.
+
+Prisma pairs those application previews with a **separate database per Git branch**, with schema changes managed in code through Prisma ORM. You provision the database for the branch's application environment, directly or through Composer, and configure its database connection so you can test the application and schema changes together. When you supply a `DATABASE_URL` yourself, give the preview its own preview-scoped value: a database reached through that variable is only as isolated as the URL you set, so a preview pointed at production writes to production. The [environment variables documentation](https://www.prisma.io/docs/compute/environment-variables) covers per-branch values.
+
+The useful part comes when those changes need to come back together. Suppose one developer adds a `phone` field and another adds an `avatarUrl` field. Each tests against their own database. After merging the contract changes in Git, Prisma ORM can plan migrations from each previous schema state to the combined one.
+
+Prisma ORM 8's [migration graph](https://www.prisma.io/docs/orm/migrations/the-migration-graph) records those paths. A database that already has `phone` needs a different next migration from one that already has `avatarUrl`. Once you've resolved the contract and planned the connecting migrations, each database can reach the combined schema from its own starting point.
+
+The schema definitions and migration files are what you merge. Your release process applies the resulting migrations to production's own data. Test records stay in the branch databases.
+
+With Vercel's Git integration configured, a push to a feature branch triggers a build and creates a preview URL. The team can review the running application before merging; a merge into the production branch triggers a production deployment. This is the build-and-review process described in Vercel's [environment documentation](https://vercel.com/docs/deployments/environments).
+
+The preview's database comes from the configured integration and connection string. For example, the [Neon preview integration](https://vercel.com/integrations/neon) creates a database branch for each preview deployment. That branch uses copy-on-write storage to start with the parent's data and schema, as Vercel describes in its [preview environment guide](https://vercel.com/i/ephemeral-environments). Prisma's separate branch databases aren't automatically populated with production data.
+
+Copy-on-write makes an isolated database copy efficient to create. Bringing changes back together still takes a migration process. Production might have received new orders while a developer changed the schema and edited test records in the preview. Combining the database states would require deciding which of those changes belong in production.
+
+Prisma combines separate databases for parallel work with an ORM that understands how schema states connect. That gives the team a reviewable path from a branch's schema change to the production migration. The same migration graph is available when you use Prisma ORM on Vercel.
+
+## What can you run, and what will it cost?
+
+Prisma Compute runs TypeScript HTTP services on Bun, alongside Prisma Postgres. Your application starts a server and handles requests. Composer also provides modules for scheduled jobs, storage, and event streams, so you can declare those dependencies with the rest of the application.
+
+Each Compute service runs in one region. If your application specifically needs WebSocket servers, those aren't currently supported; the [runtime documentation](https://www.prisma.io/docs/compute/limitations) covers that boundary and background execution.
+
+Vercel's [Next.js integration](https://vercel.com/docs/frameworks/full-stack/nextjs) handles framework features such as caching and on-demand image optimisation. For a storefront or content-heavy application, those are concrete parts of the delivery work the platform takes care of.
+
+Both platforms separate active CPU usage from memory allocation. An application waiting on a database or model API can use little CPU while still holding memory. Prisma Compute and Vercel's [Fluid compute billing](https://vercel.com/docs/functions/usage-and-pricing) account for those resources separately.
+
+Prisma Compute bills requests, provisioned memory, active CPU, and outbound bandwidth. Deployments and preview branch creation have no separate charge, but resources used by a preview still count. Include the platform plan and database usage when estimating the full bill. See [Prisma Compute pricing](https://www.prisma.io/docs/compute/pricing).
+
+Vercel's bill includes its plan, compute and delivery usage, builds, and any additional products you use. Its [Pro plan](https://vercel.com/docs/plans/pro-plan) includes a usage credit and charges for additional deploying seats. Include your database provider's charges too, and use the current plan allowances when comparing totals.
+
+Compare one representative month: requests that reach application code, active CPU, memory held during execution, data transfer, builds, and team seats. Apply each plan's allowances and credits before comparing totals. A cached storefront and an API that waits on external services can have very different costs at the same traffic level.
+
+## Can you use Prisma with Vercel?
+
+Yes. Prisma ORM works in Vercel-hosted applications, and [Prisma Postgres is available in the Vercel Marketplace](https://vercel.com/marketplace/prisma). The [integration guide](https://www.prisma.io/docs/guides/postgres/vercel) covers provisioning a database and connecting it to your application.
+
+That gives you another practical option: keep Vercel's application hosting and use Prisma for typed queries, managed Postgres, and schema migrations. Configure the database connection and migration workflow for each environment.
+
+Using Prisma Compute and Composer extends Prisma's approach to the service relationships as well. The data contract describes what a service stores, the RPC contracts describe what it exposes, and the application module declares the resources and connections it needs. Those definitions become part of the same review as the feature code.
+
+## Start with one real workflow
+
+Try a feature that changes both data and application behaviour. Add a field, update an API, and use it from the frontend. Run the typechecks, deploy a preview with an isolated database, then prepare the migrations that bring the change into production.
+
+The [Composer getting-started guide](https://www.prisma.io/docs/composer/getting-started) walks through a two-service application. Get it running, change a service contract, and see what the compiler catches. Then change the schema and follow the migration into the database. That's the experience we're building across Prisma: the definitions for the application and the tools to run it, working together.