diff --git a/apps/blog/content/blog/building-the-stack-for-the-next-million-products/index.mdx b/apps/blog/content/blog/building-the-stack-for-the-next-million-products/index.mdx
index 0a4cbc32311..0de2fb54988 100644
--- a/apps/blog/content/blog/building-the-stack-for-the-next-million-products/index.mdx
+++ b/apps/blog/content/blog/building-the-stack-for-the-next-million-products/index.mdx
@@ -117,7 +117,7 @@ That is the stack we want to build.
 
 ## Start building with Prisma Compute
 
-Prisma Compute is the newest step toward that vision. It works with the coding agents you already use, including Claude, Codex, and Composer, and comes with Prisma Postgres and [Object Storage](https://www.prisma.io/docs/storage) so you can give an agent a real project, let it build against real infrastructure, and run what it made.
+Prisma Compute is the newest step toward that vision. It works with the coding agents you already use, including Claude, Codex, and Cursor, and comes with Prisma Postgres and [Object Storage](https://www.prisma.io/docs/storage) so you can give an agent a real project, let it build against real infrastructure, and run what it made.
 
 <Button asChild variant="ink" size="2xl">
   <a href="https://console.prisma.io/?utm_source=blog&utm_medium=blog&utm_campaign=prisma-rebrand-2026&utm_content=launch-post">Start building in Prisma Console</a>
diff --git a/apps/blog/content/blog/launching-prisma-compute-public-beta/index.mdx b/apps/blog/content/blog/launching-prisma-compute-public-beta/index.mdx
index a91c674743d..d15296893e0 100644
--- a/apps/blog/content/blog/launching-prisma-compute-public-beta/index.mdx
+++ b/apps/blog/content/blog/launching-prisma-compute-public-beta/index.mdx
@@ -61,6 +61,6 @@ One prompt, and the agent reads the project, provisions a branch database, appli
 
 Want the full walkthrough, from signing in to connecting GitHub for deploy-on-push? Read the [Compute quickstart](https://www.prisma.io/docs/compute/getting-started).
 
-We're early and shipping fast, so tell us what breaks or feels rough in [the `prisma-compute` channel on our Discord](https://pris.ly/discord-compute).
+We're early and shipping fast, so tell us what breaks or feels rough in the `prisma-compute` channel on [our Discord](https://pris.ly/discord).
 
 Go build something.
diff --git a/apps/docs/content/docs/(index)/prisma-compute/deploy.mdx b/apps/docs/content/docs/(index)/prisma-compute/deploy.mdx
index 885c7f8ad32..6cf530b6b58 100644
--- a/apps/docs/content/docs/(index)/prisma-compute/deploy.mdx
+++ b/apps/docs/content/docs/(index)/prisma-compute/deploy.mdx
@@ -75,12 +75,14 @@ import { definePrismaConfig } from "prisma/config";
 
 export default definePrismaConfig({
   composer: composer({
-    extensions: [prismaCloud(), nodeBuild()],
+    extensions: [prismaCloud({ region: "us-east-1" }), nodeBuild()],
     state: prismaState(),
   }),
 });
 ```
 
+The `region` is where the first deploy creates the project. Pick any region listed under [Known limitations](/compute/limitations#runtime), or leave it out and set `PRISMA_REGION` when you deploy; a project that already exists keeps its region.
+
 You own the build; Composer assembles what you built. Add a build script that produces one self-contained file per service:
 
 ```json title="package.json"
@@ -100,7 +102,7 @@ npx prisma dev module.ts
 
 `dev` prints the service's local URL; `curl` it and you get `Hello from Prisma Compute`. See [Local development](/local-development) for the local database, storage, and log workflow.
 
-From here the app grows by declaration: `deps: { db: postgres() }` gives the service a [Prisma Postgres database](/composer/databases), [`bucket()`](/composer/object-storage) gives it object storage, and a second service with a [typed contract](/composer/getting-started) turns cross-service calls into checked function calls. When the app runs locally, continue to [Deploy](#2-deploy).
+From here the app grows by declaration: `deps: { db: rawPostgres() }` gives the service a [Prisma Postgres database](/composer/databases) (or `postgres(contract)` from `@prisma/composer-prisma-cloud/orm` for one typed by Prisma ORM), [`bucket()`](/composer/object-storage) gives it object storage, and a second service with a [typed contract](/composer/getting-started) turns cross-service calls into checked function calls. When the app runs locally, continue to [Deploy](#2-deploy).
 
 ### Bring an app you already have
 
@@ -108,15 +110,15 @@ Porting an app does not mean rewriting it. Your server code stays the server, yo
 
 **1. Install the Composer packages.** Same as [step 1 of the scratch path](/composer/getting-started#1-set-up-the-project): install `@prisma/composer` and `@prisma/composer-prisma-cloud`, and install `prisma` as a dev dependency. Composer pins `effect` for you; if one of your existing dependencies pins a different `effect`, use the override in [When prisma.config.ts fails on an effect version conflict](/composer/deploying#when-prismaconfigts-fails-on-an-effect-version-conflict).
 
-**2. Declare each service.** A `service.ts` next to each server names the service, declares what it consumes as dependencies, and points at your built output. A Postgres connection becomes `postgres()`; S3 credentials become `bucket()`:
+**2. Declare each service.** A `service.ts` next to each server names the service, declares what it consumes as dependencies, and points at your built output. A Postgres connection becomes `rawPostgres()`; S3 credentials become `bucket()`:
 
 ```ts title="src/api/service.ts"
 import node from "@prisma/composer/node";
-import { compute, postgres } from "@prisma/composer-prisma-cloud";
+import { compute, rawPostgres } from "@prisma/composer-prisma-cloud";
 
 export default compute({
   name: "api",
-  deps: { db: postgres() },
+  deps: { db: rawPostgres() },
   build: node({ module: import.meta.url, entry: "../../dist/api.mjs" }),
 });
 ```
@@ -136,12 +138,12 @@ export default compute({
 
 ```ts title="module.ts"
 import { module } from "@prisma/composer";
-import { bucket, postgres } from "@prisma/composer-prisma-cloud";
+import { bucket, rawPostgres } from "@prisma/composer-prisma-cloud";
 import apiService from "./src/api/service.ts";
 import filesService from "./src/files/service.ts";
 
 export default module("my-app", ({ provision }) => {
-  const db = provision(postgres({ name: "database" }));
+  const db = provision(rawPostgres({ name: "database" }));
   const store = provision(bucket({ name: "uploads" }));
   provision(apiService, { deps: { db } });
   provision(filesService, { deps: { store } });
@@ -160,7 +162,7 @@ import service from "./service.ts";
 
 // before: new SQL({ url: process.env.DATABASE_URL })
 const { db } = service.load();
-const sql = new SQL({ url: db.url, max: 1, idleTimeout: 10 });
+const sql = new SQL({ url: db.url, max: 1, idleTimeout: 10, prepare: false });
 
 Bun.serve({ port: service.port(), hostname: "0.0.0.0", fetch: handler });
 ```
@@ -204,7 +206,7 @@ npm run build
 npx prisma deploy module.ts
 ```
 
-The CLI creates a project named after your root module, provisions the services on Compute and any databases on Prisma Postgres, wires the dependencies, and starts everything. The project name identifies the app in your workspace: redeploying reuses the project this module created, and a same-name project whose hosted state the CLI cannot verify stops the command with `HostedStateBootstrapError`. Deploy under another name with `--name <unique-name>` when that happens.
+The CLI creates a project named after your root module in the region from `prismaCloud({ region })` or `PRISMA_REGION` (without one, the first deploy stops with `project "<name>" does not exist yet and no deploy region is configured`), provisions the services on Compute and any databases on Prisma Postgres, wires the dependencies, and starts everything. The project name identifies the app in your workspace: redeploying reuses the project this module created, and a same-name project whose hosted state the CLI cannot verify stops the command with `HostedStateBootstrapError`. Deploy under another name with `--name <unique-name>` when that happens.
 
 ## 3. Verify the deployment
 
@@ -249,7 +251,8 @@ Notes:
 - Composer needs Node.js 22.18 or newer, and server code targets Bun. Read the port with `service.port()` and bind 0.0.0.0. For a Next.js service, use the nextjs build adapter and set `output: "standalone"`.
 - Composer does not build; produce one self-contained entry file per service (for example `bun build --target=bun`), then run it locally with `npx prisma dev module.ts` and verify each service's local URL responds.
 - Deploy with `npx prisma deploy module.ts` and verify the printed public URL with curl.
-- To give a service a database, declare `deps: { db: postgres() }` and build the client from the injected `db.url`; do not read connection strings from process.env.
+- To give a service a database, declare `deps: { db: rawPostgres() }` (imported from @prisma/composer-prisma-cloud) and build the client from the injected `db.url`; do not read connection strings from process.env. For a database typed by Prisma ORM, use `postgres(contract)` from @prisma/composer-prisma-cloud/orm instead.
+- A new project needs a region: set `prismaCloud({ region: "us-east-1" })` (or another region) in the `composer` section of prisma.config.ts, or set PRISMA_REGION, before the first deploy.
 - Current docs: https://www.prisma.io/docs/composer.md and https://www.prisma.io/docs/prisma-compute/deploy.md
 ```
 
diff --git a/apps/docs/content/docs/(index)/prisma-orm/from-scratch.mdx b/apps/docs/content/docs/(index)/prisma-orm/from-scratch.mdx
index e09b195b9c9..75eeb196ef8 100644
--- a/apps/docs/content/docs/(index)/prisma-orm/from-scratch.mdx
+++ b/apps/docs/content/docs/(index)/prisma-orm/from-scratch.mdx
@@ -43,7 +43,7 @@ npm install @prisma/orm-postgres dotenv
 npm install --save-dev prisma tsx typescript
 ```
 
-`@prisma/orm-postgres` is the library your code imports, and `prisma` is the command-line tool. `dotenv` loads `.env`, `tsx` runs `index.ts` without a build step, and `typescript` 5.9 or newer is a peer dependency of `@prisma/orm-postgres`. So is `temporal-polyfill`, which npm installs for you; with Yarn, add it yourself. The two Prisma packages have different version numbers (for example, `prisma` 8.0.0-rc.21 and `@prisma/orm-postgres` 8.0.0-rc.16); that is normal, and any two `latest` versions work together.
+`@prisma/orm-postgres` is the library your code imports, and `prisma` is the command-line tool. `dotenv` loads `.env`, `tsx` runs `index.ts` without a build step, and `typescript` 5.9 or newer is a peer dependency of `@prisma/orm-postgres`. So is `temporal-polyfill`, which npm installs for you; with Yarn, add it yourself. The two Prisma packages have different version numbers (for example, `prisma` 8.0.0-rc.21 and `@prisma/orm-postgres` 8.0.0-rc.17); that is normal, and any two `latest` versions work together.
 
 ## 2. Create the config file and `.env`
 
diff --git a/apps/docs/content/docs/cli/service.mdx b/apps/docs/content/docs/cli/service.mdx
index e1eb3852803..698138569e2 100644
--- a/apps/docs/content/docs/cli/service.mdx
+++ b/apps/docs/content/docs/cli/service.mdx
@@ -8,7 +8,7 @@ metaDescription: 'Learn how to manage Prisma Compute services, service versions,
 
 Use `service` commands to manage the services in a project. A deploy produces a **version** of a service; one version is live at a time. Deploys start from [`deploy`](/cli/deploy) for a Composer app, from a git push once you [set up deploy on push](/compute/deploy-on-push), or from the [Console](https://pris.ly/pdp). The commands below inspect and manage services and the versions that already exist.
 
-Commands are targeted by parameters, not by ambient state. A command that acts on a service takes the service as its first positional argument (`service show <service>`), with `PRISMA_SERVICE_ID` as the environment fallback; the argument wins when both are set. Scope with `--branch <name>` and `--project <id-or-name>`. There is no interactive picker: a missing target fails with a structured `SERVICE.TARGET_REQUIRED` error (exit 2) before any network call, even in an interactive terminal. Commands targeted by a globally unique version id (`service version promote|start|stop|delete <version-id>`) need no other context.
+Commands are targeted by parameters, not by ambient state. A command that acts on a service takes the service as its first positional argument (`service show <service>`); the CLI does not read a service from the environment. Scope with `--branch <name>` and `--project <id-or-name>`. There is no interactive picker: a missing target fails with a structured `SERVICE.TARGET_REQUIRED` error (exit 2) before any network call, even in an interactive terminal. Commands targeted by a globally unique version id (`service version promote|start|stop|delete <version-id>`) need no other context.
 
 ## Usage
 
diff --git a/apps/docs/content/docs/composer/apps-and-modules.mdx b/apps/docs/content/docs/composer/apps-and-modules.mdx
index 209eb8707e8..82fdbc0b571 100644
--- a/apps/docs/content/docs/composer/apps-and-modules.mdx
+++ b/apps/docs/content/docs/composer/apps-and-modules.mdx
@@ -19,7 +19,7 @@ A service declares everything about itself in one `compute()` call. It is pure d
 ```ts
 compute({
   name: 'auth',                  // the service's name in the app graph
-  deps: { db: postgres() },      // what it needs         -> read via service.load()
+  deps: { db: rawPostgres() },   // what it needs         -> read via service.load()
   input: authInput,              // its incoming config   -> read via service.input()
   build: node({ module: import.meta.url, entry: '../dist/server.mjs' }),
   expose: { rpc: authContract }, // what it offers to other services
@@ -60,7 +60,7 @@ A Module declares its boundary (what it needs, what it offers) in the second arg
 
 ```ts title="src/auth/module.ts"
 import { module, secret } from '@prisma/composer';
-import { postgres } from '@prisma/composer-prisma-cloud';
+import { rawPostgres } from '@prisma/composer-prisma-cloud';
 import { authContract } from './contract.ts';
 import authService from './service.ts';
 
@@ -68,7 +68,7 @@ export default module(
   'auth',
   { secrets: { signingKey: secret() }, expose: { rpc: authContract } },
   ({ secrets, provision }) => {
-    const db = provision(postgres({ name: 'database' }));
+    const db = provision(rawPostgres({ name: 'database' }));
     const service = provision(authService, {
       id: 'service',
       deps: { db },
diff --git a/apps/docs/content/docs/composer/databases.mdx b/apps/docs/content/docs/composer/databases.mdx
index 4bffe1e4332..f68f6b8eb90 100644
--- a/apps/docs/content/docs/composer/databases.mdx
+++ b/apps/docs/content/docs/composer/databases.mdx
@@ -32,10 +32,10 @@ export default compute({
 import { SQL } from 'bun';
 
 const { db } = service.load();
-const sql = new SQL({ url: db.url, max: 1, idleTimeout: 10 });
+const sql = new SQL({ url: db.url, max: 1, idleTimeout: 10, prepare: false });
 ```
 
-Those pool settings matter. Prisma Compute scales to zero and closes idle connections, so keep the pool small and reconnect-friendly. See [Deploying](/composer/deploying#production-behavior).
+Those pool settings matter. Prisma Compute scales to zero and closes idle connections, so keep the pool small and reconnect-friendly. `prepare: false` turns off Bun's named prepared statements: the local Postgres that `npx prisma dev` runs shares one session across client connections, so after the pool reconnects, the first query fails with `prepared statement "..." already exists` unless prepared statements are off. See [Deploying](/composer/deploying#production-behavior).
 
 The module that owns the database provisions it:
 
diff --git a/apps/docs/content/docs/composer/deploying.mdx b/apps/docs/content/docs/composer/deploying.mdx
index fe54fd3942b..642788046de 100644
--- a/apps/docs/content/docs/composer/deploying.mdx
+++ b/apps/docs/content/docs/composer/deploying.mdx
@@ -183,10 +183,10 @@ Fix it at whichever end is wrong: add the name to the outputs the producer retur
 
 Behavior you will run into once the app is deployed, and what to do about it:
 
-- **Compute scales to zero, and idle database connections get closed.** A long-lived client that treats a dropped connection as fatal will crash-loop through 502s. Keep the pool small and reconnect-friendly, and do not let an async error kill the process:
+- **Compute scales to zero, and idle database connections get closed.** A long-lived client that treats a dropped connection as fatal will crash-loop through 502s. Keep the pool small and reconnect-friendly, turn off named prepared statements so a reconnect against the local `prisma dev` database does not fail with `prepared statement "..." already exists`, and do not let an async error kill the process:
 
   ```ts
-  const sql = new SQL({ url: db.url, max: 1, idleTimeout: 10 });
+  const sql = new SQL({ url: db.url, max: 1, idleTimeout: 10, prepare: false });
   process.on('uncaughtException', (err) => console.error('uncaughtException', err));
   process.on('unhandledRejection', (err) => console.error('unhandledRejection', err));
   ```
diff --git a/apps/docs/content/docs/composer/index.mdx b/apps/docs/content/docs/composer/index.mdx
index b9087d39c71..78165d0ab39 100644
--- a/apps/docs/content/docs/composer/index.mdx
+++ b/apps/docs/content/docs/composer/index.mdx
@@ -9,7 +9,7 @@ metaDescription: Prisma Composer lets you declare services, their contracts, and
 
 With Prisma Composer, you describe your whole application in TypeScript: each service, plus whatever it depends on, such as other services, [Prisma Postgres](/postgres) databases, scheduled jobs, object storage, and secrets. One deploy command then provisions the services on [Prisma Compute](/compute), the databases on Prisma Postgres, and the authenticated connections between them.
 
-You do not need Composer to deploy to Prisma Compute. If your application is a single service, you can deploy it to Compute directly. See [Deployments](/compute/deployments) for those paths.
+The Prisma CLI's `deploy` command, the GitHub deploy action, and the Deploy Button all deploy a Composer module. You do not need Composer to deploy to Prisma Compute through the [REST API](/rest-api), though: it creates a deployment for a service and returns an upload URL for your built artifact, and tools such as [Alchemy](/compute/alchemy) deploy that way. See [Deployments](/compute/deployments) for every path.
 
 :::info[Early Access]
 
diff --git a/apps/docs/content/docs/composer/porting-an-app.mdx b/apps/docs/content/docs/composer/porting-an-app.mdx
index 4faafe61292..844bb114346 100644
--- a/apps/docs/content/docs/composer/porting-an-app.mdx
+++ b/apps/docs/content/docs/composer/porting-an-app.mdx
@@ -17,11 +17,11 @@ To delegate the port, run this from your project's root and hand the prompt to y
 ```text
 Port this app to Prisma Composer.
 
-1. Install `@prisma/composer` and `@prisma/composer-prisma-cloud`, then install the Composer skill with `npx prisma@latest skills sync` (the skill ships inside the package; run `npx prisma@latest skills list` to confirm). Then read https://www.prisma.io/docs/composer/porting-an-app.md and follow it for this repository.
+1. Install `@prisma/composer` and `@prisma/composer-prisma-cloud`, and install `prisma` as a dev dependency (the deploy config in `prisma.config.ts` imports `prisma/config`), then install the Composer skill with `npx prisma@latest skills sync` (the skill ships inside the package; run `npx prisma@latest skills list` to confirm). Then read https://www.prisma.io/docs/composer/porting-an-app.md and follow it for this repository.
 2. Survey the repo before changing anything and report back: every deployable server, its runtime (Node, Bun, or Next.js), its build command and entry file, every `process.env` read, and any database it connects to. Ask me about anything ambiguous.
 3. Declare each server as a service with `compute()`, using the `node` or `nextjs` build adapter as appropriate, and compose them in a single `module.ts`.
 4. Replace the `process.env` reads: the listen port becomes `service.port()` bound to `0.0.0.0`, config and credentials become fields of the service input schema, and anything another service provides becomes a typed dependency. Replace the URLs services use to reach each other with contracts.
-5. If the app talks to Postgres, declare `postgres()` as a dependency and build the existing client from the injected `db.url` instead of a connection-string variable.
+5. If the app talks to Postgres, declare `rawPostgres()` (from `@prisma/composer-prisma-cloud`) as a dependency and build the existing client from the injected `db.url` instead of a connection-string variable.
 6. Verify with `npx tsc --noEmit`, then build and run `npx prisma dev module.ts` and confirm every service boots with a local URL. Do not deploy; show me the diff first.
 ```
 
@@ -39,7 +39,7 @@ Add a `service.ts` with `compute({ name, deps, build: node({ module, entry }) })
 
 2. **Replace every other `process.env` read.** Config and credentials become fields of the service's [input schema](/composer/service-input). Anything another service provides becomes a [dependency](/composer/services-and-contracts). If a value differs per stage (an app origin, an external URL), bind it with `envParam`. Bind a credential with `envSecret`.
 
-3. **If it talks to Postgres**: declare `deps: { db: postgres() }` and build your existing client (`pg`, Bun's `SQL`, whatever you use today) from the injected `db.url` instead of a connection-string env var. See [Databases](/composer/databases).
+3. **If it talks to Postgres**: declare `deps: { db: rawPostgres() }`, imported from `@prisma/composer-prisma-cloud`, and build your existing client (`pg`, Bun's `SQL`, whatever you use today) from the injected `db.url` instead of a connection-string env var. See [Databases](/composer/databases).
 
 Your build must produce a self-contained entry file, with everything inlined except runtime built-ins. Keep your own build if it already does this. Otherwise, a one-line `bun build --target=bun` produces one. See [Getting started](/composer/getting-started#5-build).
 
diff --git a/apps/docs/content/docs/composer/service-input.mdx b/apps/docs/content/docs/composer/service-input.mdx
index c54f502c116..f610dbc8867 100644
--- a/apps/docs/content/docs/composer/service-input.mdx
+++ b/apps/docs/content/docs/composer/service-input.mdx
@@ -10,7 +10,7 @@ Everything a running service receives arrives through one of two channels, and c
 
 | The value is... | Declare it as | Provide it | Read it |
 | --- | --- | --- | --- |
-| Produced by another node (a database, another service) | a dependency: `deps: { db: postgres() }` | wire it at `provision()` | `service.load()` |
+| Produced by another node (a database, another service) | a dependency: `deps: { db: rawPostgres() }` | wire it at `provision()` | `service.load()` |
 | Anything else (a region, a flag, a job list, a credential) | one field of the service's `input` schema | bind it at `provision()`: a literal, `envParam()`, or `envSecret()` | `service.input()` |
 
 Dependencies are covered in [Services and contracts](/composer/services-and-contracts) and [Databases](/composer/databases). This page is the second row.
diff --git a/apps/docs/content/docs/compute/deploy-on-push.mdx b/apps/docs/content/docs/compute/deploy-on-push.mdx
index f37426df248..caaceb29df0 100644
--- a/apps/docs/content/docs/compute/deploy-on-push.mdx
+++ b/apps/docs/content/docs/compute/deploy-on-push.mdx
@@ -57,7 +57,7 @@ gh repo create my-app --private --source . --push
 
 ## 2. Link the directory to the project
 
-The `git` commands operate on the project this directory is linked to. If you have deployed from this directory before, it is already linked and you can skip this step. Otherwise, link it to the project your deploys created:
+The `git` commands operate on the project this directory is linked to. `deploy` creates and updates the project but does not link the directory, so link it to the project your deploys created, unless you already ran `project link` or `project create` here:
 
 ```npm
 npx prisma project link my-app
diff --git a/apps/docs/content/docs/compute/deployments.mdx b/apps/docs/content/docs/compute/deployments.mdx
index 2f2fbc3ab80..df872d2e6ec 100644
--- a/apps/docs/content/docs/compute/deployments.mdx
+++ b/apps/docs/content/docs/compute/deployments.mdx
@@ -10,11 +10,12 @@ A deploy produces a **version** of a service: one built artifact that can serve
 
 ## Where versions come from
 
-Versions are created three ways:
+Versions are created four ways:
 
-- **A git push.** After you [set up deploy on push](/compute/deploy-on-push), your repository's GitHub Actions workflow builds and deploys each pushed branch: the default Git branch deploys to production, and every other branch gets an isolated preview.
+- **A git push.** After you [set up deploy on push](/compute/deploy-on-push), your repository's GitHub Actions workflow builds each pushed branch and runs `deploy` on its [Prisma Composer](/composer) module: the default Git branch deploys to production, and every other branch gets an isolated preview.
 - **The [Console](https://pris.ly/pdp).** Trigger a build and deploy from the browser.
 - **[`deploy`](/cli/deploy).** For a [Prisma Composer](/composer) app, `deploy` assembles the services you have already built and provisions them from your terminal or CI.
+- **The [REST API](/rest-api), without Composer.** `POST /v1/services/{serviceId}/deployments` creates a version and returns a pre-signed upload URL for your built artifact; the endpoint is marked experimental in the [OpenAPI specification](https://api.prisma.io/v1/swagger-editor). Tools such as [Alchemy](/compute/alchemy) deploy this way.
 
 The `service` commands below manage the versions those flows create. They are targeted explicitly: the service is the first positional argument, and version-scoped commands take a globally unique version id, so there is no interactive picker and no dependence on your current git branch.
 
diff --git a/apps/docs/content/docs/compute/faq.mdx b/apps/docs/content/docs/compute/faq.mdx
index c737bd23a7a..37ece3a978d 100644
--- a/apps/docs/content/docs/compute/faq.mdx
+++ b/apps/docs/content/docs/compute/faq.mdx
@@ -3,7 +3,7 @@ title: "Should I use Prisma Compute? FAQ"
 description: Who Prisma Compute is built for, what it does well, where it has trade-offs, how it compares with Railway, Render, Fly.io and Vercel, and quick answers to common questions.
 url: /compute/faq
 metaTitle: "Should I use Prisma Compute? FAQ | Prisma Compute"
-metaDescription: Who Prisma Compute is built for, its trade-offs (one region per service, no WebSocket servers, Bun runtime, no cron), how it compares with Railway, Render, Fly.io and Vercel, and quick answers on deploys, preview and staging branches, variables and domains.
+metaDescription: Who Prisma Compute is built for, its trade-offs (one region per service, no WebSocket servers, Bun runtime, no built-in cron), how it compares with Railway, Render, Fly.io and Vercel, and quick answers on deploys, preview and staging branches, variables and domains.
 ---
 
 Prisma Compute hosts TypeScript apps (Node.js, Bun or Next.js) next to [Prisma Postgres](/postgres) on one plan. It has been generally available since August 2026, and the Free plan runs an app and a database with no credit card and no usage billing. It is not a fit for a WebSocket server, an API written in Python or Go, an app that needs more than one region, a frontend that needs a global CDN above all, or a database that needs point-in-time recovery today; Railway, Render, Fly.io, Vercel with Prisma Postgres, and Neon or Supabase fit there. Prisma makes Prisma ORM, Prisma Postgres and Prisma Compute. The sections below are for the decision, and the questions that come up once you deploy follow them.
@@ -38,7 +38,7 @@ This is the full list of what Compute and Prisma Postgres do not do today.
 - Bun runtime. Compute runs TypeScript services on Bun, declared with Composer's `node` or `nextjs` build adapter for Node.js, Bun and Next.js apps; it does not run Python, Go or Docker images.
 - A Composer declaration for existing repos. An app you already have needs a `service.ts` per server and one `module.ts`; the server code stays, but the port comes from `service.port()` and `process.env` reads become service input. `deploy` does not build for you, so you run your build first; see Composer's [limitations](/composer/limitations) before committing to a design.
 - Deploy on push has two parts. Connecting the repository deploys nothing; pushes deploy through the `prisma/cloud-deploy-action` workflow you add, GitHub is the only supported provider, and other CI deploys with a service token.
-- No cron scheduling and no persistent filesystem. Compute runs HTTP services, so a scheduled trigger has to come from outside, and files you need to keep go to [Object Store](/compute/object-storage) or the database.
+- No built-in cron and no persistent filesystem. Compute runs HTTP services, so a schedule comes from Composer's [`cron` building block](/composer/building-blocks#cron), which adds a scheduler service that never scales to zero, or from an external scheduler that calls your service, and files you need to keep go to [Object Store](/compute/object-storage) or the database.
 - No point-in-time recovery on Prisma Postgres. Paid plans take daily snapshots, kept 7 days on Starter and Pro and 30 days on Business; the Free plan has no backups, and restoring to an arbitrary moment is not available yet. `pg_dump` over a direct connection makes your own copies; see [Backups](/postgres/database/backups).
 - No query cache. Prisma Postgres includes connection pooling but has no query cache of its own.
 - Previews are not copies of production. A preview branch gets its own database with no production data in it; the deploy applies your `migrations/` to a Composer `postgres()` database before the service starts, and a `rawPostgres()` database is yours to migrate.
@@ -48,7 +48,7 @@ This is the full list of what Compute and Prisma Postgres do not do today.
 
 ## How it stacks up
 
-The table compares Prisma Compute with Railway, Render, Fly.io and Vercel on the eight questions that decide most hosting choices. The Prisma column comes from these docs; every other vendor named on this page was checked against its own documentation and pricing pages as of September 2026, and each competitor cell links to the page it rests on. Vendors change these often, so re-check the row you rely on. We make Prisma Compute and Prisma Postgres, so the honest rows are the ones where the others do things Compute does not: WebSocket servers, more than one region, cron jobs and disks.
+The table compares Prisma Compute with Railway, Render, Fly.io and Vercel on the eight questions that decide most hosting choices. The Prisma column comes from these docs; every other vendor named on this page was checked against its own documentation and pricing pages as of September 2026, and each competitor cell links to the page it rests on. Vendors change these often, so re-check the row you rely on. We make Prisma Compute and Prisma Postgres, so the honest rows are the ones where the others do things Compute does not: WebSocket servers, more than one region, built-in cron jobs and disks.
 
 | | Prisma Compute | Railway | Render | Fly.io | Vercel |
 | --- | --- | --- | --- | --- | --- |
@@ -58,7 +58,7 @@ The table compares Prisma Compute with Railway, Render, Fly.io and Vercel on the
 | Preview per branch | Once deploy on push is set up, every pushed branch gets its own services and databases, built from your migrations, and is torn down with the branch ([Deploy on push](/compute/deploy-on-push#6-preview-a-branch)) | An environment per pull request, deleted when the PR merges or closes ([environments](https://docs.railway.com/guides/environments)) | An environment per pull request; database copies start without production data; needs a Pro workspace or higher ([preview environments](https://render.com/docs/preview-environments)) | Review apps per pull request through the `fly-pr-review-apps` action; databases are yours to add in the workflow ([review apps](https://docs.fly.io/blueprints/review-apps-guide/)) | A preview deployment for every push to a non-production branch; a preview database depends on the provider ([environments](https://vercel.com/docs/deployments/environments)) |
 | Regions | One region per service, chosen from six; no multi-region deployments ([limitations](/compute/limitations#runtime)) | Four regions (US West, US East, EU West, Southeast Asia); multi-region replicas available ([regions](https://docs.railway.com/reference/deployment-regions), [scaling](https://docs.railway.com/reference/scaling)) | Five regions (Oregon, Ohio, Virginia, Frankfurt, Singapore); one region per service ([regions](https://render.com/docs/regions)) | More than a dozen regions, and one app can run Machines in several at once ([regions](https://docs.fly.io/reference/regions/)) | Functions run in one region by default (`iad1`); Hobby is single-region, Pro up to five, Enterprise all ([regions](https://vercel.com/docs/functions/configuring-functions/region)) |
 | WebSocket servers | No; streaming responses work ([limitations](/compute/limitations#runtime)) | Yes; WebSocket connections are exempt from request timeouts ([specs and limits](https://docs.railway.com/networking/public-networking/specs-and-limits)) | Yes; web services accept inbound WebSocket connections ([WebSockets](https://render.com/docs/websocket)) | Yes; the app runs as an ordinary server ([WebSockets with Next.js](https://fly.io/javascript-journal/websockets-with-nextjs/)) | Yes, in beta, on Fluid compute; a connection closes when the function reaches its maximum duration ([WebSockets](https://vercel.com/docs/functions/websockets)) |
-| Cron jobs and persistent disk | Neither: no cron scheduling and no persistent filesystem ([limitations](/compute/limitations#runtime)) | Cron jobs and volumes, one volume per service ([cron jobs](https://docs.railway.com/reference/cron-jobs), [volumes](https://docs.railway.com/reference/volumes)) | Cron jobs and persistent disks; a disk pins the service to one instance ([cron jobs](https://render.com/docs/cronjobs), [disks](https://render.com/docs/disks)) | Scheduled Machines or a Cron Manager app, and Fly Volumes tied to one Machine ([task scheduling](https://docs.fly.io/blueprints/task-scheduling/), [volumes](https://docs.fly.io/volumes/overview/)) | Cron jobs; functions get a read-only filesystem with a 500 MB `/tmp` ([cron jobs](https://vercel.com/docs/cron-jobs), [runtimes](https://vercel.com/docs/functions/runtimes)) |
+| Cron jobs and persistent disk | No built-in cron (Composer's [`cron` block](/composer/building-blocks#cron) adds a scheduler service that stays awake) and no persistent filesystem ([limitations](/compute/limitations#runtime)) | Cron jobs and volumes, one volume per service ([cron jobs](https://docs.railway.com/reference/cron-jobs), [volumes](https://docs.railway.com/reference/volumes)) | Cron jobs and persistent disks; a disk pins the service to one instance ([cron jobs](https://render.com/docs/cronjobs), [disks](https://render.com/docs/disks)) | Scheduled Machines or a Cron Manager app, and Fly Volumes tied to one Machine ([task scheduling](https://docs.fly.io/blueprints/task-scheduling/), [volumes](https://docs.fly.io/volumes/overview/)) | Cron jobs; functions get a read-only filesystem with a 500 MB `/tmp` ([cron jobs](https://vercel.com/docs/cron-jobs), [runtimes](https://vercel.com/docs/functions/runtimes)) |
 | Free plan and lowest paid plan | Free: 1M requests, 360 GB-hours of memory, 4 vCPU-hours, 10 GB of bandwidth, 200k database operations, 1.01 GB of storage, 50 databases, no usage billing, no credit card. Starter: $10 a month base with 5M requests and 1M operations included, then metered ([pricing](https://www.prisma.io/pricing), [Compute pricing](/compute/pricing)) | Free plan with $1 of credit a month; Hobby is $5 a month including $5 of usage ([plans](https://docs.railway.com/reference/pricing/plans)) | Hobby workspace with no monthly fee; free web services spin down after 15 minutes idle. Pro workspace is $25 a month plus compute ([free tier](https://render.com/docs/free), [pricing](https://render.com/pricing)) | No free plan; pay as you go with no plan fee, and the smallest Machine is about $2 a month ([pricing](https://docs.fly.io/about/pricing/)) | Hobby is free for non-commercial use; Pro is $20 a month including one seat and $20 of usage credit ([Hobby](https://vercel.com/docs/plans/hobby), [Pro](https://vercel.com/docs/plans/pro-plan)) |
 
 The Prisma blog compares more vendors and situations. [App hosting platforms with managed Postgres compared (2026)](https://www.prisma.io/blog/app-hosting-platforms-with-managed-postgres-2026) adds Supabase and Neon and prices each option at small scale. If your database is on Neon and you want the app hosted next to it, read [Neon alternatives with app hosting and Postgres in one place](https://www.prisma.io/blog/neon-vs-prisma-postgres-app-hosting-in-one-place), and if you are moving off Netlify, read [Netlify alternatives for a full-stack TypeScript app with Postgres](https://www.prisma.io/blog/prisma-vs-netlify).
diff --git a/apps/docs/content/docs/compute/getting-started.mdx b/apps/docs/content/docs/compute/getting-started.mdx
index 36dd924ec52..cd6c4e3fa3d 100644
--- a/apps/docs/content/docs/compute/getting-started.mdx
+++ b/apps/docs/content/docs/compute/getting-started.mdx
@@ -69,7 +69,7 @@ To learn how versions are promoted, rolled back, started, and stopped, see [Depl
 
 ## Link a project
 
-A project groups your services, branches, and databases. The `service` and `git` commands act on the project this directory is linked to. If you deployed from this directory, it is already linked. To work from another checkout, or with a project your team already deployed, link to it by name:
+A project groups your services, branches, and databases. The `service` and `git` commands act on the project this directory is linked to. `deploy` creates the project but does not link the directory to it; only `project link` and `project create` do. Link this directory, another checkout, or a project your team already deployed by name:
 
 ```npm
 npx prisma project link my-app
diff --git a/apps/docs/content/docs/compute/limitations.mdx b/apps/docs/content/docs/compute/limitations.mdx
index 78ff515e7da..758a15bced3 100644
--- a/apps/docs/content/docs/compute/limitations.mdx
+++ b/apps/docs/content/docs/compute/limitations.mdx
@@ -13,7 +13,7 @@ This page lists what Prisma Compute can and can't do.
 - The quickest way to run the CLI is `npx prisma <command>` (or `bunx`/`pnpm dlx`), with Node.js 22.18 or newer.
 - The platform command groups are `auth`, `project` (including `project env`), `postgres`, `bucket`, `branch`, `git`, `service` (including `service version` and `service domain`), and `agent`, plus the root-level [`dev`](/cli/dev) and [`deploy`](/cli/deploy) verbs for Composer apps. The same binary also carries the [Prisma ORM data commands](/cli) (`contract`, `db`, `migration`). There is no `compute` namespace: Compute is managed through the resource groups above.
 - Commands are targeted by parameters, not ambient state: the subject resource is the first positional argument, and there is no interactive picker. A missing target fails with a structured error (exit 2) before any network call.
-- There is no committed compute config file. A Composer app describes itself, including each service's build, in its module. `.prisma/local.json` is gitignored and only stores your local link to the workspace and project. In CI, set `PRISMA_PROJECT_ID` / `PRISMA_SERVICE_ID` to override the linked project and service.
+- There is no committed compute config file. A Composer app describes itself, including each service's build, in its module. `.prisma/local.json` is gitignored and only stores your local link to the workspace and project. In CI, pass `--project` and the service name on each command; the CLI does not read a project or service from the environment.
 
 ## Projects and branches
 
@@ -55,10 +55,10 @@ This page lists what Prisma Compute can and can't do.
 
 ## Runtime
 
-- This release focuses on HTTP services. Background work between requests is supported through the `@prisma/compute` keep-awake primitives; see [Keeping instances awake](/compute/keeping-instances-awake). Cron scheduling, a persistent filesystem, and edge runtimes are not part of it.
+- This release focuses on HTTP services. Background work between requests is supported through the `@prisma/compute` keep-awake primitives; see [Keeping instances awake](/compute/keeping-instances-awake). Compute has no built-in cron scheduler, persistent filesystem, or edge runtime. Scheduled jobs come from Composer's [`cron` building block](/composer/building-blocks#cron), which adds a scheduler service that never scales to zero, or from an external scheduler that calls your service.
 - Your service has 60 seconds to start responding to a request. If it sends nothing in that time, the client gets `504 Gateway Time-out` and Compute cancels the request, which surfaces in your handler as the request's abort signal rather than an error. The deadline covers the wait for the first bytes, so a response that has started streaming is not cut off. Move longer work out of the request; see [Request timeout](/compute/request-timeout).
 - WebSocket servers are not currently supported. `waitUntil` and `KeepAwakeGuard` only prevent an instance from scaling to zero; they do not change [connection-lifetime limits](/compute/request-timeout) or guarantee continuity through restarts or deployments.
-- No multi-region deployments. Each service lives in one region, chosen at creation (`service create --region`): `us-east-1`, `us-west-1`, `eu-west-3`, `eu-central-1`, `ap-northeast-1`, or `ap-southeast-1`. When you do not choose one, the service takes its project's region, and a project created without a region is in `us-east-1`.
+- No multi-region deployments. Each service lives in one region, chosen at creation (`service create --region`): `us-east-1`, `us-west-1`, `eu-west-3`, `eu-central-1`, `ap-northeast-1`, or `ap-southeast-1`. When you do not choose one, the service takes its project's region, and a project created without a region is in `us-east-1`. The exception is the first [`deploy`](/cli/deploy) of a Composer app: it creates the project only once you set a region, with `prismaCloud({ region })` or `PRISMA_REGION`, and stops with `no deploy region is configured` otherwise.
 
 ## Databases and migrations
 
diff --git a/apps/docs/content/docs/compute/request-timeout.mdx b/apps/docs/content/docs/compute/request-timeout.mdx
index 21ec381c685..b1567a30243 100644
--- a/apps/docs/content/docs/compute/request-timeout.mdx
+++ b/apps/docs/content/docs/compute/request-timeout.mdx
@@ -58,7 +58,7 @@ export default {
 
 ### Persist, then process in steps
 
-For work that must not be lost, have the inbound request store the job, as a database row or a queue message, and process it from a separate trigger. Compute does not run scheduled jobs for you, so the trigger is a request from an external scheduler or a worker you run elsewhere. See [Known limitations](/compute/limitations).
+For work that must not be lost, have the inbound request store the job, as a database row or a queue message, and process it from a separate trigger. Compute has no built-in scheduler, so the trigger is a job from Composer's [`cron` building block](/composer/building-blocks#cron), a request from an external scheduler, or a worker you run elsewhere. See [Known limitations](/compute/limitations).
 
 Size each step to finish inside one request, and record progress as you go. A later run resumes from the last step you recorded. The step that was interrupted runs again from its start, so make every step safe to repeat rather than assuming it ran once.
 
diff --git a/apps/docs/content/docs/guides/frameworks/solid-start.mdx b/apps/docs/content/docs/guides/frameworks/solid-start.mdx
index ae3916e3104..665db9da358 100644
--- a/apps/docs/content/docs/guides/frameworks/solid-start.mdx
+++ b/apps/docs/content/docs/guides/frameworks/solid-start.mdx
@@ -395,7 +395,7 @@ project:  ~/my-solid-prisma-app
 check:    enabled
 
 Skill                          Package               Version      Installed into
-prisma-8                       @prisma/orm-postgres  8.0.0-rc.16  .claude/skills, .cursor/skills, .agents/skills, .devin/skills
+prisma-8                       @prisma/orm-postgres  8.0.0-rc.17  .claude/skills, .cursor/skills, .agents/skills, .devin/skills
 prisma-composer-core-concepts  @prisma/composer      0.25.0       .claude/skills, .cursor/skills, .agents/skills, .devin/skills
 prisma-platform-core-concepts  prisma                8.0.0-rc.21  .claude/skills, .cursor/skills, .agents/skills, .devin/skills
 
diff --git a/apps/docs/content/docs/guides/upgrade-prisma-orm/mongodb.mdx b/apps/docs/content/docs/guides/upgrade-prisma-orm/mongodb.mdx
index bfa9932ed47..6cfcdff431a 100644
--- a/apps/docs/content/docs/guides/upgrade-prisma-orm/mongodb.mdx
+++ b/apps/docs/content/docs/guides/upgrade-prisma-orm/mongodb.mdx
@@ -24,7 +24,7 @@ Install the companion [prisma-mongodb-upgrade](https://github.com/prisma/skills/
 
 :::info
 
-Install the `latest` version of `@prisma/orm-mongo`, which is what `orm init` in step 1 does. This guide was written for `8.0.0-rc.16`, and MongoDB support in Prisma ORM 8 still changes between release candidates, so a newer version may behave differently from what this guide shows. To see which version you have, run `npm ls @prisma/orm-mongo`.
+Install the `latest` version of `@prisma/orm-mongo`, which is what `orm init` in step 1 does. This guide was written as of `8.0.0-rc.16`, and MongoDB support in Prisma ORM 8 still changes between release candidates, so a newer version may behave differently from what this guide shows. To see which version you have, run `npm ls @prisma/orm-mongo`.
 
 :::
 
diff --git a/apps/docs/content/docs/guides/upgrade-prisma-orm/postgresql.mdx b/apps/docs/content/docs/guides/upgrade-prisma-orm/postgresql.mdx
index 0e446f2f2e2..d0197cd15df 100644
--- a/apps/docs/content/docs/guides/upgrade-prisma-orm/postgresql.mdx
+++ b/apps/docs/content/docs/guides/upgrade-prisma-orm/postgresql.mdx
@@ -14,7 +14,7 @@ The guide covers **PostgreSQL only**. Guidance for other databases will follow.
 
 :::info
 
-Step 2.1 installs the `latest` version of both Prisma ORM 8 packages: `prisma`, the Prisma ORM 8 CLI, and `@prisma/orm-postgres`. This guide was written with `prisma` at `8.0.0-rc.21` and `@prisma/orm-postgres` at `8.0.0-rc.16`: the CLI is released separately, so the two numbers differ. Prisma ORM 7 stays at `7.10.0`: the example app in step 1.1 starts on it, and step 1.2 installs `@prisma/prisma7@7.10.0`.
+Step 2.1 installs the `latest` version of both Prisma ORM 8 packages: `prisma`, the Prisma ORM 8 CLI, and `@prisma/orm-postgres`. This guide was written with `prisma` at `8.0.0-rc.21` and `@prisma/orm-postgres` as of `8.0.0-rc.16`: the CLI is released separately, so the two numbers differ. Prisma ORM 7 stays at `7.10.0`: the example app in step 1.1 starts on it, and step 1.2 installs `@prisma/prisma7@7.10.0`.
 
 :::
 
diff --git a/apps/docs/content/docs/orm/release-status.mdx b/apps/docs/content/docs/orm/release-status.mdx
index edc5b5b214d..f5db3863aa0 100644
--- a/apps/docs/content/docs/orm/release-status.mdx
+++ b/apps/docs/content/docs/orm/release-status.mdx
@@ -39,11 +39,11 @@ For MongoDB the library is `@prisma/orm-mongo`. [Supported databases](/orm/suppo
 
 The two packages have different version numbers, and that is normal: they are released separately, and the command-line tool gets more frequent releases. Install both at `latest`; any two `latest` versions work together, and you do not pair the numbers yourself.
 
-| Package | `latest` on 7 October 2026 |
+| Package | `latest` on 8 October 2026 |
 | --- | --- |
 | `prisma` (the command-line tool) | `8.0.0-rc.21` |
-| `@prisma/orm-postgres` (the library) | `8.0.0-rc.16` |
-| `@prisma/orm-mongo` (the MongoDB library) | `8.0.0-rc.16` |
+| `@prisma/orm-postgres` (the library) | `8.0.0-rc.17` |
+| `@prisma/orm-mongo` (the MongoDB library) | `8.0.0-rc.17` |
 
 To see the `latest` version of each package today, run `npm view prisma dist-tags`, `npm view @prisma/orm-postgres dist-tags`, and `npm view @prisma/orm-mongo dist-tags`, and read the `latest` entry in each result. You need all three commands because the command-line tool and the libraries are versioned separately.
 
diff --git a/apps/site/src/components/sections/pricing-calculator.tsx b/apps/site/src/components/sections/pricing-calculator.tsx
index 15392c4dae1..fc8a67231a5 100644
--- a/apps/site/src/components/sections/pricing-calculator.tsx
+++ b/apps/site/src/components/sections/pricing-calculator.tsx
@@ -129,8 +129,8 @@ export function PricingCalculator() {
               <div className="mt-auto flex items-center gap-2.5 border-t border-black/[0.06] pt-5">
                 <CheckBold className="size-4 shrink-0 text-prism-cyan-500" aria-hidden />
                 <p className="text-sm text-muted-foreground">
-                  <span className="font-semibold text-foreground">Data transfer</span> — unlimited,
-                  included free
+                  <span className="font-semibold text-foreground">Database data transfer</span> —
+                  unlimited, included free
                 </p>
               </div>
             </div>
diff --git a/apps/site/src/components/sections/pricing-comparison.tsx b/apps/site/src/components/sections/pricing-comparison.tsx
index 5629b925514..832b566daa7 100644
--- a/apps/site/src/components/sections/pricing-comparison.tsx
+++ b/apps/site/src/components/sections/pricing-comparison.tsx
@@ -210,8 +210,8 @@ export function PricingComparison() {
             <Reveal delay={0.1}>
               <p className="mx-auto mt-6 max-w-3xl text-pretty text-center text-base leading-relaxed text-muted-foreground">
                 Prisma charges per operation: each query your app runs against your database counts
-                as one. No seats. No egress fees. And every paid plan includes a hard spend limit so
-                there are no surprises.
+                as one. No seats. No database egress fees. And every paid plan includes a hard spend
+                limit so there are no surprises.
               </p>
             </Reveal>
             <Reveal delay={0.15}>
@@ -220,7 +220,7 @@ export function PricingComparison() {
                 <strong className="font-semibold text-foreground">
                   Prisma Pro can cost up to 5x less than a typical Neon + Vercel setup
                 </strong>
-                , with one bill, included data transfer, and spend limits on by default.
+                , with one bill, included database data transfer, and spend limits on by default.
               </p>
             </Reveal>
 
diff --git a/apps/site/src/components/sections/pricing-scale.tsx b/apps/site/src/components/sections/pricing-scale.tsx
index 9c168f9585f..0313aaf6b6a 100644
--- a/apps/site/src/components/sections/pricing-scale.tsx
+++ b/apps/site/src/components/sections/pricing-scale.tsx
@@ -34,8 +34,8 @@ const BULLETS = [
     rest: ", so your bill never surprises you",
   },
   {
-    lead: "Unlimited data transfer included",
-    rest: ", no bandwidth bill-shock",
+    lead: "Unlimited database data transfer included",
+    rest: ", no database egress bill-shock",
   },
   {
     lead: "Prisma ORM is free, always",
@@ -73,7 +73,7 @@ const SCENARIOS: Scenario[] = [
     ],
     prisma: [
       "No credit card required",
-      "Data transfer included",
+      "Database data transfer included",
       "Hard free-tier cap, no surprises",
     ],
   },
@@ -87,7 +87,11 @@ const SCENARIOS: Scenario[] = [
       "Data transfer billed per GB",
       "Spend limits not standard",
     ],
-    prisma: ["One bill, one platform", "Data transfer included", "Spend limits on by default"],
+    prisma: [
+      "One bill, one platform",
+      "Database data transfer included",
+      "Spend limits on by default",
+    ],
   },
   {
     tab: "At scale",
@@ -99,7 +103,11 @@ const SCENARIOS: Scenario[] = [
       "Data transfer billed per GB",
       "Spend limits not standard",
     ],
-    prisma: ["One bill, one platform", "Data transfer included", "Spend limits on by default"],
+    prisma: [
+      "One bill, one platform",
+      "Database data transfer included",
+      "Spend limits on by default",
+    ],
   },
 ];
 
@@ -273,8 +281,8 @@ export function PricingScale() {
               <p className="mt-5 max-w-[54ch] text-pretty leading-relaxed text-muted-foreground">
                 Start free with the ORM, which will always be free. Prisma Postgres has a free tier
                 with a hard cap, so you can build without a credit card. When you outgrow it,
-                you&apos;re on operation-based pricing with spend limits, and data transfer is
-                always included.
+                you&apos;re on operation-based pricing with spend limits, and database data transfer
+                is always included.
               </p>
             </Reveal>
 
diff --git a/apps/site/src/lib/markdown/home.ts b/apps/site/src/lib/markdown/home.ts
index 9b91bbf3f67..652c2b66718 100644
--- a/apps/site/src/lib/markdown/home.ts
+++ b/apps/site/src/lib/markdown/home.ts
@@ -218,13 +218,13 @@ export function renderHomeMarkdown(): string {
     paragraphs(
       "Start free with the ORM, which will always be free. Prisma Postgres has a free tier with " +
         "a hard cap, so you can build without a credit card. When you outgrow it, you're on " +
-        "operation-based pricing with spend limits, and data transfer is always included.",
+        "operation-based pricing with spend limits, and database data transfer is always included.",
     ),
     ctaList([{ label: "See pricing", href: "/pricing" }]),
     bulletList([
       "**Free Postgres tier** with a hard cap, no credit card required",
       "**Spend limits on every paid tier**, so your bill never surprises you",
-      "**Unlimited data transfer included**, no bandwidth bill-shock",
+      "**Unlimited database data transfer included**, no database egress bill-shock",
       "**Prisma ORM is free, always**",
       "**Per-branch databases included**, no surcharge",
       "**SOC2, HIPAA, ISO 27001, and GDPR** at the Business tier",
@@ -241,7 +241,7 @@ export function renderHomeMarkdown(): string {
     paragraphs("Prisma: $0 per month"),
     bulletList([
       "No credit card required",
-      "Data transfer included",
+      "Database data transfer included",
       "Hard free-tier cap, no surprises",
     ]),
     heading(3, "Growing SaaS (~50K MAU)"),
@@ -252,7 +252,11 @@ export function renderHomeMarkdown(): string {
       "Spend limits not standard",
     ]),
     paragraphs("Prisma: $70-90 per month"),
-    bulletList(["One bill, one platform", "Data transfer included", "Spend limits on by default"]),
+    bulletList([
+      "One bill, one platform",
+      "Database data transfer included",
+      "Spend limits on by default",
+    ]),
     heading(3, "At scale (~500K MAU)"),
     paragraphs("Typical stack (Neon + Vercel): $2,800-3,400 per month"),
     bulletList([
@@ -261,7 +265,11 @@ export function renderHomeMarkdown(): string {
       "Spend limits not standard",
     ]),
     paragraphs("Prisma: $640-780 per month"),
-    bulletList(["One bill, one platform", "Data transfer included", "Spend limits on by default"]),
+    bulletList([
+      "One bill, one platform",
+      "Database data transfer included",
+      "Spend limits on by default",
+    ]),
 
     // ---- TestimonialsReveal (testimonials-reveal.tsx) ----
     // Shared renderer: the section is reused on other pages, and it already
diff --git a/apps/site/src/lib/markdown/pricing.ts b/apps/site/src/lib/markdown/pricing.ts
index 3fad075ac88..d8a16113e56 100644
--- a/apps/site/src/lib/markdown/pricing.ts
+++ b/apps/site/src/lib/markdown/pricing.ts
@@ -411,7 +411,7 @@ export function renderPricingMarkdown(): string {
     bulletList([
       "Database operations per month — 1 query = 1 operation",
       "Storage in gigabytes",
-      "Data transfer — unlimited, included free",
+      "Database data transfer — unlimited, included free",
     ]),
     definitionList(CALCULATOR_PLAN_TERMS),
     paragraphs("Hard spend limit, on by default — never a surprise bill."),
@@ -419,10 +419,10 @@ export function renderPricingMarkdown(): string {
     heading(2, "See how Prisma compares at scale"),
     paragraphs([
       "Prisma charges per operation: each query your app runs against your database counts as " +
-        "one. No seats. No egress fees. And every paid plan includes a hard spend limit so there " +
+        "one. No seats. No database egress fees. And every paid plan includes a hard spend limit so there " +
         "are no surprises.",
       "At around 50K monthly active users, Prisma Pro can cost up to 5x less than a typical " +
-        "Neon + Vercel setup, with one bill, included data transfer, and spend limits on by " +
+        "Neon + Vercel setup, with one bill, included database data transfer, and spend limits on by " +
         "default.",
       // The badge on the Prisma Pro column; its multiple is derived from the
       // costs in the table below.