diff --git a/content/200-orm/050-overview/500-databases/600-mongodb.mdx b/content/200-orm/050-overview/500-databases/600-mongodb.mdx
index b5348e4cda..cc35fad0c7 100644
--- a/content/200-orm/050-overview/500-databases/600-mongodb.mdx
+++ b/content/200-orm/050-overview/500-databases/600-mongodb.mdx
@@ -488,7 +488,7 @@ Currently, there are no plans to add support for [Prisma Migrate](/orm/prisma-mi
The [`@@id`](/orm/reference/prisma-schema-reference#id-1) attribute (an ID for multiple fields) is not supported because primary keys in MongoDB are always on the `_id` field of a model.
-The [`autoincrement()`](/orm/reference/prisma-schema-reference#generate-autoincrementing-integers-as-ids) function (which creates incrementing `@id` values) is not supported because `autoincrement()` does not work with the `ObjectID` type that the `_id` field has in MongoDB.
+The [`autoincrement()`](/orm/reference/prisma-schema-reference#generate-autoincrementing-integers-as-ids-relational-databases-only) function (which creates incrementing `@id` values) is not supported because `autoincrement()` does not work with the `ObjectID` type that the `_id` field has in MongoDB.
### Cyclic references and referential actions
diff --git a/content/200-orm/200-prisma-client/500-deployment/301-edge/450-deploy-to-cloudflare-workers.mdx b/content/200-orm/200-prisma-client/500-deployment/301-edge/450-deploy-to-cloudflare-workers.mdx
deleted file mode 100644
index 5276eb88e8..0000000000
--- a/content/200-orm/200-prisma-client/500-deployment/301-edge/450-deploy-to-cloudflare-workers.mdx
+++ /dev/null
@@ -1,310 +0,0 @@
----
-title: 'Deploy to Cloudflare Workers'
-metaTitle: 'Deploy to Cloudflare Workers'
-metaDescription: 'Learn how to deploy a TypeScript application to Cloudflare Workers that connects to PostgreSQL.'
----
-
-
-
-Today you'll be deploying a Cloudflare Worker that uses Prisma ORM to save every request to a PostgreSQL database and fetches 20 of the most recent logs.
-
-This guide covers Prisma ORM, TypeScript, PostgreSQL, Prisma Accelerate, and Cloudflare Workers.
-
-
-
-## Prerequisites
-
-- A PostgreSQL database that is publicly accessible
-- [Cloudflare Workers](https://workers.cloudflare.com/) account
-- [Prisma Data Platform](https://console.prisma.io/) account
-- Node.js & npm installed
-- Git installed
-
-## 1. Set up your application
-
-Wrangler is the official Cloudflare Worker CLI. You will use it to develop and deploy to Cloudflare Workers. This guide uses [Wrangler v3](https://developers.cloudflare.com/workers/wrangler/).
-
-Open your terminal and navigate to a location of your choice. First, initialize your project using the [create-cloudflare-cli](https://www.npmjs.com/package/create-cloudflare). To do this, run the following command in your terminal:
-
-```terminal
-npm create cloudflare@latest
-```
-
-This will ask you a few questions.
-
-```terminal
-In which directory do you want to create your application?
-```
-
-Enter the name of your project, for example: `prisma-cloudflare-accelerate`
-
-```terminal
-What type of application do you want to create?
-```
-
-Select the `"Hello World" Worker` option.
-
-```terminal
-Would you like to use TypeScript? (y/n)
-```
-
-We also want to use TypeScript, so answer yes.
-
-```terminal
-Would you like to use git to manage this Worker? (y/n)
-```
-
-We want to use Git, so answer yes.
-
-The command this will create a new project with a minimal preset configuration. Once `create-cloudflare-cli` is done, navigate to the project and open it on your editor of choice.
-
-Next, authenticate the Wrangler CLI with your Cloudflare Workers account. To do this, run the following command in your terminal:
-
-```terminal
-npx wrangler login
-```
-
-You can now verify that you're logged in by running `npx wrangler whoami`.
-
-```terminal
-npx wrangler whoami
-```
-
-## 2. Set up Prisma ORM
-
-Now you're ready to add Prisma ORM to the project.
-
-Install `prisma` as a development dependency:
-
-```terminal
-npm install --save-dev prisma
-```
-
-Next, initialize Prisma ORM in your project with the following command:
-
-```terminal
-npx prisma init
-```
-
-This creates a Prisma schema in `prisma/schema.prisma`.
-
-
-
-**Note:**
-
-`prisma init` also creates an `.env` file. The `.env` file will contain a placeholder `DATABASE_URL` variable that will be used to update your database schema using Prisma Migrate. Update this value with your database's connection string.
-
-
-
-Update your Prisma schema with the following data model:
-
-```prisma
-generator client {
- provider = "prisma-client-js"
-}
-
-datasource db {
- provider = "postgresql"
- url = env("DATABASE_URL")
-}
-
-model Log {
- id Int @id @default(autoincrement())
- level Level
- message String
- meta Json
-}
-
-enum Level {
- Info
- Warn
- Error
-}
-```
-
-The above data model will be used to persist and retrieve logs from your Cloudflare Worker
-
-## 3. Update your database schema
-
-To map your data model to the database schema, you need to use the `prisma migrate dev` CLI command:
-
-```terminal
-npx prisma migrate dev --name init
-```
-
-The command does two things:
-
-1. It creates a new SQL migration file for this migration
-1. It runs the SQL migration file against the database
-
-## 4. Enable Accelerate in the Prisma Data Platform
-
-Prisma ORM currently does not work on Cloudflare Workers yet. However, you can use Prisma ORM on Cloudflare Workers through [Prisma Accelerate](/accelerate).
-
-To get started with Prisma Accelerate:
-
-1. Sign up for a free [Prisma Data Platform account](https://console.prisma.io/)
-1. Create a project
-1. Navigate to the project you created
-1. Enable Accelerate
-1. Generate an Accelerate connection string and copy it to your clipboard
-
-## 5. Configure the Accelerate connection string in your project
-
-1. Rename the existing `DATABASE_URL` environment variable to `DIRECT_URL`. The `DIRECT_URL` variable will be used perform migrations and introspections.
-1. Add the Prisma Accelerate connection string to your `.env` file.
-
- ```diff file=.env
- -DATABASE_URL="postgres://..."
- +DATABASE_URL="prisma://accelerate.prisma-data.net/?api_key=__API_KEY__"
- +DIRECT_URL="postgres://..."
- ```
-
- Add [`directUrl`](/orm/reference/prisma-schema-reference#fields) property in `datasource` block in the `schema.prisma` file.
-
- ```prisma highlight=4;add file=prisma/schema.prisma showLineNumbers
- datasource db {
- provider = "postgresql"
- url = env("DATABASE_URL")
- //add-next-line
- directUrl = env("DIRECT_URL")
- }
- ```
-
- > The `directUrl` field is not required for Prisma Accelerate. It allows you to introspect and perform schema migrations.
-
-1. In `wrangler.toml` file, add a `[vars]` key and your connection string.
-
- ```diff file=wrangler.toml
- name = "prisma-cloudflare-accelerate"
- main = "src/main.ts"
- compatibility_date = "2022-11-07"
-
- + [vars]
- + DATABASE_URL = "prisma://accelerate.prisma-data.net/?api_key=__API_KEY__"
- ```
-
-
-
- Cloudflare Workers does not support `.env` files. To set environment variables, you can either adding the `[vars]` key in your `wrangler.toml` file or saving your environment variables in a `.dev.vars` file. Refer to [Cloudflare's documentation](https://developers.cloudflare.com/pages/platform/functions/bindings/#interact-with-your-environment-variables-locally) to learn more.
-
-
-
-1. Install the Prisma Accelerate extension
-
- ```bash
- npm install @prisma/extension-accelerate
- ```
-
-You are now ready to generate a Prisma Client.
-
-## 6. Generate a Prisma Client
-
-Next, generate Prisma Client that connects to your database through [Prisma Accelerate](/accelerate) over HTTP.
-
-```terminal
-npx prisma generate --no-engine
-```
-
-
-
-The `--no-engine` flag is available from Prisma ORM 5.2.0 and later. If you're using an earlier version of Prisma ORM, use the `--accelerate` flag.
-
-```terminal
-npx prisma generate --accelerate
-```
-
-
-
-The generated Client has a smaller bundle size and is optimized for edge environments like Cloudflare Workers.
-
-The smaller bundle size is due to the fact that the interfaces talking to the database (the [Prisma ORM engines](/orm/more/under-the-hood/engines)) are no longer bundled with Prisma Client as this logic is now handled by Prisma Accelerate.
-
-## 7. Develop the Cloudflare Worker function
-
-You're now ready to create a Cloudflare Worker. Create a `src/index.ts` file with the following code:
-
-```ts
-import { PrismaClient } from '@prisma/client/edge'
-import { withAccelerate } from '@prisma/extension-accelerate'
-
-export interface Env {
- DATABASE_URL: string
-}
-
-export default {
- async fetch(
- request: Request,
- env: Env,
- ctx: ExecutionContext
- ): Promise {
- const prisma = new PrismaClient({
- datasourceUrl: env.DATABASE_URL,
- }).$extends(withAccelerate())
-
- await prisma.log.create({
- data: {
- level: 'Info',
- message: `${request.method} ${request.url}`,
- meta: {
- headers: JSON.stringify(request.headers),
- },
- },
- })
-
- const { data, info } = await prisma.log
- .findMany({
- take: 20,
- orderBy: {
- id: 'desc',
- },
- })
- .withAccelerateInfo()
-
- console.log(JSON.stringify(info))
-
- return new Response(`request method: ${request.method}!`)
- },
-}
-```
-
-> The [`info`](/accelerate/api-reference#return-type) object has additional information which can be useful for debugging.
-> Accelerate can also be used to cache your query results. You can find more information on caching with Prisma Accelerate in [here](/accelerate).
-
-Run `npm run dev` to see your worker in development:
-
-```
-👂 Listening on http://127.0.0.1:8787
-```
-
-Go ahead and open `http://127.0.0.1:8787`. If all goes well, you should see:
-
-```
-request method: GET!
-```
-
-Refresh the page a couple times to verify that it's working.
-
-## 8. Publish to Cloudflare Workers
-
-You're now ready to deploy to Cloudflare Workers. Run the following command:
-
-```terminal
-npm run deploy
-```
-
-This will package and upload to Cloudflare. With a bit of luck, you'll see the following:
-
-```
-✨ Built successfully, built project size is 94 KiB.
-✨ Successfully published your script to
-https://prisma-cloudflare-accelerate.ankman.workers.dev
-```
-
-Visit your deployment URL and you'll again see:
-
-```
-request method: GET!
-```
-
-You're all set! You've successfully deployed a Cloudflare Worker written in TypeScript that uses Prisma ORM to talk to your PostgreSQL database.
diff --git a/content/200-orm/200-prisma-client/500-deployment/301-edge/450-deploy-to-cloudflare.mdx b/content/200-orm/200-prisma-client/500-deployment/301-edge/450-deploy-to-cloudflare.mdx
new file mode 100644
index 0000000000..101b0ff350
--- /dev/null
+++ b/content/200-orm/200-prisma-client/500-deployment/301-edge/450-deploy-to-cloudflare.mdx
@@ -0,0 +1,742 @@
+---
+title: 'Deploy to Cloudflare Workers & Pages'
+sidebar_label: Deploy to Cloudflare
+metaTitle: 'Deploy to Cloudflare Workers & Pages'
+metaDescription: 'Learn the things you need to know in order to deploy an app that uses Prisma Client for talking to a database to a Cloudflare Worker or to Cloudflare Pages.'
+tocDepth: 3
+preview: true
+---
+
+
+
+This page covers everything you need to know to deploy an app with Prisma ORM to a [Cloudflare Worker](https://developers.cloudflare.com/workers/) or to [Cloudflare Pages](https://developers.cloudflare.com/pages).
+
+
+
+## General considerations when deploying to Cloudflare Workers
+
+This section covers _general_ things you need to be aware of when deploying to Cloudflare Workers or Pages and are using Prisma ORM, regardless of the database provider you use.
+
+### Using an edge-compatible driver
+
+When deploying a Cloudflare Worker that uses Prisma ORM, you need to use an [edge-compatible driver](/orm/prisma-client/deployment/edge/overview#edge-compatibility-of-database-drivers) and its respective [driver adapter](/orm/overview/databases/database-drivers#driver-adapters) for Prisma ORM.
+
+The edge-compatible drivers for Cloudflare Workers and Pages are:
+
+- [Neon Serverless](https://neon.tech/docs/serverless/serverless-driver) uses HTTP to access the database
+- [PlanetScale Serverless](https://planetscale.com/docs/tutorials/planetscale-serverless-driver) uses HTTP to access the database
+- [`node-postgres`](https://node-postgres.com/) (`pg`) uses Cloudflare's `connect()` (TCP) to access the database
+- [`@libsql/client`](https://github.com/tursodatabase/libsql-client-ts) is used to access Turso databases via HTTP
+- [Cloudflare D1](/orm/prisma-client/deployment/edge/deploy-to-cloudflare#cloudflare-d1) is used to access D1 databases
+
+There's [also work being done](https://github.com/sidorares/node-mysql2/pull/2289) on the `node-mysql2` driver which will enable access to traditional MySQL databases from Cloudflare Workers and Pages in the future as well.
+
+> **Note**: [Prisma Accelerate](/accelerate) enables you to access _any_ database from _any_ edge function provider. No edge-compatible driver is necessary.
+
+### Setting your database connection URL as an environment variable
+
+First, ensure that the `DATABASE_URL` is set as the `url` of the `datasource` in your Prisma schema:
+
+```prisma
+datasource db {
+ provider = "postgresql" // this might also be `mysql` or another value depending on your database
+ url = env("DATABASE_URL")
+}
+```
+
+#### Development
+
+When using your Worker in **development**, you can configure your database connection via the [`.dev.vars` file](https://developers.cloudflare.com/workers/configuration/secrets/#secrets-in-development) locally.
+
+Assuming you use the `DATABASE_URL` environment variable from above, you can set it inside `.dev.vars` as follows:
+
+```bash file=.dev.vars
+DATABASE_URL="your-database-connection-string"
+```
+
+In the above snippet, `your-database-connection-string` is a placeholder that you need to replace with the value of your own connection string, for example:
+
+```bash file=.dev.vars
+DATABASE_URL="postgresql://admin:mypassword42@somehost.aws.com:5432/mydb"
+```
+
+Note that the `.dev.vars` file is not compatible with `.env` files which are typically used by Prisma ORM.
+
+This means that you need to make sure that Prisma ORM gets access to the environment variable when needed, e.g. when running a Prisma CLI command like `prisma migrate dev`.
+
+There are several options for achieving this:
+
+- Run your Prisma CLI commands using [`dotenv`](https://www.npmjs.com/package/dotenv-cli) to specify from where the CLI should read the environment variable, for example:
+ ```terminal
+ dotenv -e .dev.vars -- npx prisma migrate dev
+ ```
+- Create a script in `package.json` that reads `.dev.vars` via [`dotenv`](https://www.npmjs.com/package/dotenv-cli). You can then execute `prisma` commands as follows: `npm run env -- npx prisma migrate dev`. Here's a reference for the script:
+ ```js file=package.json
+ "scripts": { "env": "dotenv -e .dev.vars" }
+ ```
+- Duplicate the `DATABASE_URL` and any other relevant env vars into a new file called `.env` which can then be used by Prisma ORM.
+
+> **Note**: If you're using an approach that requires `dotenv`, you need to have the [`dotenv-cli`](https://www.npmjs.com/package/dotenv-cli) package installed. You can do this e.g. by using this command to install the package locally in your project: `npm install -D dotenv-cli`.
+
+#### Production
+
+When deploying your Worker to **production**, you'll need to set the database connection using the `wrangler` CLI:
+
+```terminal
+npx wrangler secret put DATABASE_URL
+```
+
+The command is interactive and will ask you to enter the value for the `DATABASE_URL` env var as the next step in the terminal.
+
+> **Note**: This command requires you to be authenticated, and will ask you to log in to your Cloudflare account in case you are not.
+
+### Size limits on free accounts
+
+Cloudflare has a [size limit of 1 MB for Workers on the free plan](https://developers.cloudflare.com/workers/platform/limits/). If your application bundle with Prisma ORM exceeds that size, we recommend upgrading to a paid Worker plan or using Prisma Accelerate to deploy your application.
+
+If you're running into this problem with `pg` and the `@prisma/adapter-pg` package, you can replace the `pg` with the custom [`@prisma/pg-worker`](https://github.com/prisma/prisma/tree/main/packages/pg-worker) package and use the [`@prisma/adapter-pg-worker`](https://github.com/prisma/prisma/tree/main/packages/adapter-pg-worker) adapter that belongs to it.
+
+`@prisma/pg-worker` is an optimized and lightweight version of `pg` that is designed to be used in a Worker. It is a drop-in replacement for `pg` and is fully compatible with Prisma ORM.
+
+### Deploying a Next.js app to Cloudflare Pages with `@cloudflare/next-on-pages`
+
+Cloudflare offers an option to run Next.js apps on Cloudflare Pages with [`@cloudflare/next-on-pages`](https://github.com/cloudflare/next-on-pages), see the [docs](https://developers.cloudflare.com/pages/framework-guides/deploy-a-nextjs-site) for instructions.
+
+Based on some testing, we found the following:
+
+- You can deploy using the PlanetScale or Neon Serverless Driver.
+- Traditional PostgreSQL deployments using `pg` don't work because `pg` itself currently does not work with `@cloudflare/next-on-pages` (see [here](https://github.com/cloudflare/next-on-pages/issues/605)).
+
+Feel free to reach out to us on [Discord](https://pris.ly/discord) if you find that anything has changed about this.
+
+### Set `PRISMA_CLIENT_FORCE_WASM=1` when running locally with `node`
+
+Some frameworks (e.g. [hono](https://hono.dev/)) use `node` instead of `wrangler` for running Workers locally. If you're using such a framework or are running your Worker locally with `node` for another reason, you need to set the `PRISMA_CLIENT_FORCE_WASM` environment variable:
+
+```
+export PRISMA_CLIENT_FORCE_WASM=1
+```
+
+## Database-specific considerations & examples
+
+This section provides database-specific instructions for deploying a Cloudflare Worker with Prisma ORM.
+
+### Prerequisites
+
+As a prerequisite for the following section, you need to have a Cloudflare Worker running locally and the Prisma CLI installed.
+
+If you don't have that yet, you can run these commands:
+
+```terminal
+npm create cloudflare@latest prisma-cloudflare-worker-example -- --type hello-world
+cd prisma-cloudflare-worker-example
+npm install prisma --save-dev
+npx prisma init
+```
+
+You'll further need a database instance of your database provider of choice available. Refer to the respective documentation of the provider for setting up that instance.
+
+We'll use the default `User` model for the example below:
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+}
+```
+
+### PostgreSQL (traditional)
+
+If you are using a traditional PostgreSQL database that's accessed via TCP and the `pg` driver, you need to:
+
+- use the `@prisma/adapter-pg` database adapter (via the `driverAdapters` Preview feature)
+- set `node_compat = true` in `wrangler.toml` (see the [Cloudflare docs](https://developers.cloudflare.com/workers/wrangler/configuration/#add-polyfills-using-wrangler))
+
+If you are running into a size issue and can't deploy your application because of that, you can use our slimmer variant of the `pg` driver package [`@prisma/pg-worker`](https://github.com/prisma/prisma/tree/main/packages/pg-worker) and the [`@prisma/adapter-pg-worker`](https://github.com/prisma/prisma/tree/main/packages/adapter-pg-worker) adapter that belongs to it.
+
+`@prisma/pg-worker` is an optimized and lightweight version of `pg` that is designed to be used in a Worker. It is a drop-in replacement for `pg` and is fully compatible with Prisma ORM.
+
+#### 1. Configure Prisma schema & database connection
+
+> **Note**: If you don't have a project to deploy, follow the instructions in the [Prerequisites](#prerequisites) to bootstrap a basic Cloudflare Worker with Prisma ORM in it.
+
+First, ensure that the database connection is configured properly. In your Prisma schema, set the `url` of the `datasource` block to the `DATABASE_URL` environment variable. You also need to enable the `driverAdapters` feature flag:
+
+```prisma file=schema.prisma
+generator client {
+ provider = "prisma-client-js"
+ previewFeatures = ["driverAdapters"]
+}
+
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+```
+
+Next, you need to set the `DATABASE_URL` environment variable to the value of your database connection string. You'll do this in a file called `.dev.vars` used by Cloudflare:
+
+```bash file=.dev.vars
+DATABASE_URL="postgresql://admin:mypassword42@somehost.aws.com:5432/mydb"
+```
+
+Because the Prisma CLI by default is only compatible with `.env` files, you can adjust your `package.json` with the following script that loads the env vars from `.dev.vars`. You can then use this script to load the env vars before executing a `prisma` command.
+
+Add this script to your `package.json`:
+
+```js file=package.json highlight=5;add
+{
+ // ...
+ "scripts": {
+ // ....
+ "env": "dotenv -e .dev.vars"
+ },
+ // ...
+}
+```
+
+Now you can execute Prisma CLI commands as follows while ensuring that the command has access to the env vars in `.dev.vars`:
+
+```terminal
+npm run env -- npx prisma
+```
+
+#### 2. Install dependencies
+
+Next, install the required packages:
+
+```terminal
+npm install @prisma/adapter-pg
+npm install pg
+npm install @types/pg --save-dev # if you're using TypeScript
+```
+
+#### 3. Set `node_compat = true` in `wrangler.toml`
+
+In your `wrangler.toml` file, add the following line:
+
+```toml file=wrangler.toml
+node_compat = true
+```
+
+> **Note**: For Cloudflare Pages, using `node_compat` is not officially supported. If you want to use `pg` in Cloudflare Pages, you can find a workaround [here](https://github.com/cloudflare/workers-sdk/pull/2541#issuecomment-1954209855).
+
+#### 4. Migrate your database schema (if applicable)
+
+If you ran `npx prisma init` above, you need to migrate your database schema to create the `User` table that's defined in your Prisma schema (if you already have all the tables you need in your database, you can skip this step):
+
+```terminal
+npm run env -- npx prisma migrate dev --name init
+```
+
+#### 5. Use Prisma Client in your Worker to send a query to the database
+
+Here is a sample code snippet that you can use to instantiate `PrismaClient` and send a query to your database:
+
+```ts
+import { PrismaClient } from '@prisma/client'
+import { PrismaPg } from '@prisma/adapter-pg'
+import { Pool } from 'pg'
+
+export default {
+ async fetch(request, env, ctx) {
+ const pool = new Pool({ connectionString: env.DATABASE_URL })
+ const adapter = new PrismaPg(pool)
+ const prisma = new PrismaClient({ adapter })
+
+ const users = await prisma.user.findMany()
+ const result = JSON.stringify(users)
+ return new Response(result)
+ },
+}
+```
+
+#### 6. Run the Worker locally
+
+To run the Worker locally, you can run the `wrangler dev` command:
+
+```terminal
+npx wrangler dev
+```
+
+#### 7. Set the `DATABASE_URL` environment variable and deploy the Worker
+
+To deploy the Worker, you first need to the `DATABASE_URL` environment variable [via the `wrangler` CLI](https://developers.cloudflare.com/workers/configuration/secrets/#secrets-on-deployed-workers):
+
+```terminal
+npx wrangler secret put DATABASE_URL
+```
+
+The command is interactive and will ask you to enter the value for the `DATABASE_URL` env var as the next step in the terminal.
+
+> **Note**: This command requires you to be authenticated, and will ask you to log in to your Cloudflare account in case you are not.
+
+Then you can go ahead then deploy the Worker:
+
+```terminal
+npx wrangler deploy
+```
+
+The command will output the URL where you can access the deployed Worker.
+
+### PlanetScale
+
+If you are using a PlanetScale database, you need to:
+
+- use the `@prisma/adapter-planetscale` database adapter (via the `driverAdapters` Preview feature)
+- manually remove the conflicting `cache` field ([learn more]()):
+
+ ```ts
+ export default {
+ async fetch(request, env, ctx) {
+ const client = new Client({
+ url: env.DATABASE_URL,
+ // see https://github.com/cloudflare/workerd/issues/698
+ fetch(url, init) {
+ delete init['cache']
+ return fetch(url, init)
+ },
+ })
+ const adapter = new PrismaPlanetScale(client)
+ const prisma = new PrismaClient({ adapter })
+
+ // ...
+ },
+ }
+ ```
+
+#### 1. Configure Prisma schema & database connection
+
+> **Note**: If you don't have a project to deploy, follow the instructions in the [Prerequisites](#prerequisites) to bootstrap a basic Cloudflare Worker with Prisma ORM in it.
+
+First, ensure that the database connection is configured properly. In your Prisma schema, set the `url` of the `datasource` block to the `DATABASE_URL` environment variable. You also need to enable the `driverAdapters` feature flag:
+
+```prisma file=schema.prisma
+generator client {
+ provider = "prisma-client-js"
+ previewFeatures = ["driverAdapters"]
+}
+
+datasource db {
+ provider = "mysql"
+ url = env("DATABASE_URL")
+ relationMode = "prisma" // required for PlanetScale (as by default foreign keys are disabled)
+}
+```
+
+Next, you need to set the `DATABASE_URL` environment variable to the value of your database connection string. You'll do this in a file called `.dev.vars` used by Cloudflare:
+
+```bash file=.dev.vars
+DATABASE_URL="mysql://32qxa2r7hfl3102wrccj:password@us-east.connect.psdb.cloud/demo-cf-worker-ps?sslaccept=strict"
+```
+
+Because the Prisma CLI by default is only compatible with `.env` files, you can adjust your `package.json` with the following script that loads the env vars from `.dev.vars`. You can then use this script to load the env vars before executing a `prisma` command.
+
+Add this script to your `package.json`:
+
+```js file=package.json highlight=5;add
+{
+ // ...
+ "scripts": {
+ // ....
+ "env": "dotenv -e .dev.vars"
+ },
+ // ...
+}
+```
+
+Now you can execute Prisma CLI commands as follows while ensuring that the command has access to the env vars in `.dev.vars`:
+
+```terminal
+npm run env -- npx prisma
+```
+
+#### 2. Install dependencies
+
+Next, install the required packages:
+
+```terminal
+npm install @prisma/adapter-planetscale
+npm install @planetscale/database
+```
+
+#### 3. Migrate your database schema (if applicable)
+
+If you ran `npx prisma init` above, you need to migrate your database schema to create the `User` table that's defined in your Prisma schema (if you already have all the tables you need in your database, you can skip this step):
+
+```terminal
+npm run env -- npx prisma db push
+```
+
+#### 4. Use Prisma Client in your Worker to send a query to the database
+
+Here is a sample code snippet that you can use to instantiate `PrismaClient` and send a query to your database:
+
+```ts
+import { PrismaClient } from '@prisma/client'
+import { PrismaPlanetScale } from '@prisma/adapter-planetscale'
+import { Client } from '@planetscale/database'
+
+export default {
+ async fetch(request, env, ctx) {
+ const client = new Client({
+ url: env.DATABASE_URL,
+ // see https://github.com/cloudflare/workerd/issues/698
+ fetch(url, init) {
+ delete init['cache']
+ return fetch(url, init)
+ },
+ })
+ const adapter = new PrismaPlanetScale(client)
+ const prisma = new PrismaClient({ adapter })
+
+ const users = await prisma.user.findMany()
+ const result = JSON.stringify(users)
+ return new Response(result)
+ },
+}
+```
+
+#### 6. Run the Worker locally
+
+To run the Worker locally, you can run the `wrangler dev` command:
+
+```terminal
+npx wrangler dev
+```
+
+#### 7. Set the `DATABASE_URL` environment variable and deploy the Worker
+
+To deploy the Worker, you first need to the `DATABASE_URL` environment variable [via the `wrangler` CLI](https://developers.cloudflare.com/workers/configuration/secrets/#secrets-on-deployed-workers):
+
+```terminal
+npx wrangler secret put DATABASE_URL
+```
+
+The command is interactive and will ask you to enter the value for the `DATABASE_URL` env var as the next step in the terminal.
+
+> **Note**: This command requires you to be authenticated, and will ask you to log in to your Cloudflare account in case you are not.
+
+Then you can go ahead then deploy the Worker:
+
+```terminal
+npx wrangler deploy
+```
+
+The command will output the URL where you can access the deployed Worker.
+
+### Neon
+
+If you are using a Neon database, you need to:
+
+- use the `@prisma/adapter-neon` database adapter (via the `driverAdapters` Preview feature)
+
+#### 1. Configure Prisma schema & database connection
+
+> **Note**: If you don't have a project to deploy, follow the instructions in the [Prerequisites](#prerequisites) to bootstrap a basic Cloudflare Worker with Prisma ORM in it.
+
+First, ensure that the database connection is configured properly. In your Prisma schema, set the `url` of the `datasource` block to the `DATABASE_URL` environment variable. You also need to enable the `driverAdapters` feature flag:
+
+```prisma file=schema.prisma
+generator client {
+ provider = "prisma-client-js"
+ previewFeatures = ["driverAdapters"]
+}
+
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+```
+
+Next, you need to set the `DATABASE_URL` environment variable to the value of your database connection string. You'll do this in a file called `.dev.vars` used by Cloudflare:
+
+```bash file=.dev.vars
+DATABASE_URL="postgresql://janedoe:password@ep-nameless-pond-a23b1mdz.eu-central-1.aws.neon.tech/neondb?sslmode=require"
+```
+
+Because the Prisma CLI by default is only compatible with `.env` files, you can adjust your `package.json` with the following script that loads the env vars from `.dev.vars`. You can then use this script to load the env vars before executing a `prisma` command.
+
+Add this script to your `package.json`:
+
+```js file=package.json highlight=5;add
+{
+ // ...
+ "scripts": {
+ // ....
+ "env": "dotenv -e .dev.vars"
+ },
+ // ...
+}
+```
+
+Now you can execute Prisma CLI commands as follows while ensuring that the command has access to the env vars in `.dev.vars`:
+
+```terminal
+npm run env -- npx prisma
+```
+
+#### 2. Install dependencies
+
+Next, install the required packages:
+
+```terminal
+npm install @prisma/adapter-neon
+npm install @neondatabase/serverless
+```
+
+#### 3. Migrate your database schema (if applicable)
+
+If you ran `npx prisma init` above, you need to migrate your database schema to create the `User` table that's defined in your Prisma schema (if you already have all the tables you need in your database, you can skip this step):
+
+```terminal
+npm run env -- npx prisma migrate dev --name init
+```
+
+#### 5. Use Prisma Client in your Worker to send a query to the database
+
+Here is a sample code snippet that you can use to instantiate `PrismaClient` and send a query to your database:
+
+```ts
+import { PrismaClient } from '@prisma/client'
+import { PrismaNeon } from '@prisma/adapter-neon'
+import { Pool } from '@neondatabase/serverless'
+
+export default {
+ async fetch(request, env, ctx) {
+ const neon = new Pool({ connectionString: env.DATABASE_URL })
+ const adapter = new PrismaNeon(neon)
+ const prisma = new PrismaClient({ adapter })
+
+ const users = await prisma.user.findMany()
+ const result = JSON.stringify(users)
+ return new Response(result)
+ },
+}
+```
+
+#### 6. Run the Worker locally
+
+To run the Worker locally, you can run the `wrangler dev` command:
+
+```terminal
+npx wrangler dev
+```
+
+#### 7. Set the `DATABASE_URL` environment variable and deploy the Worker
+
+To deploy the Worker, you first need to the `DATABASE_URL` environment variable [via the `wrangler` CLI](https://developers.cloudflare.com/workers/configuration/secrets/#secrets-on-deployed-workers):
+
+```terminal
+npx wrangler secret put DATABASE_URL
+```
+
+The command is interactive and will ask you to enter the value for the `DATABASE_URL` env var as the next step in the terminal.
+
+> **Note**: This command requires you to be authenticated, and will ask you to log in to your Cloudflare account in case you are not.
+
+Then you can go ahead then deploy the Worker:
+
+```terminal
+npx wrangler deploy
+```
+
+The command will output the URL where you can access the deployed Worker.
+
+### Cloudflare D1
+
+If you are using a D1 database, you need to:
+
+- use the `@prisma/adapter-d1` database adapter (via the `driverAdapters` Preview feature)
+- set `sqlite` as the `datasource` provider in your Prisma schema
+- manually generate SQL statements for schema changes using `prisma migrate diff` but execute them using [D1's migration system](https://developers.cloudflare.com/d1/reference/migrations/)
+
+You can find a [deployment-ready example on GitHub](https://github.com/prisma/prisma-examples/blob/latest/deployment-platforms/edge/cloudflare-workers/with-d1).
+
+#### 1. Configure Prisma schema
+
+> **Note**: If you don't have a project to deploy, follow the instructions in the [Prerequisites](#prerequisites) to bootstrap a basic Cloudflare Worker with Prisma ORM in it.
+
+In your Prisma schema, add the `driverAdapters` Preview feature to the `generator` block and set the `provider` of the `datasource` to `sqlite`. If you just bootstrapped the Prisma schema with `prisma init`, also be sure to add the following `User` model to it:
+
+```prisma file=schema.prisma
+generator client {
+ provider = "prisma-client-js"
+ previewFeatures = ["driverAdapters"]
+}
+
+datasource db {
+ provider = "sqlite"
+ url = env("DATABASE_URL")
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+}
+```
+
+Note that in this tutorial, you won't need the `.env` file since the connection between Prisma ORM and D1 will happen through a [binding](https://developers.cloudflare.com/workers/configuration/bindings/).
+
+#### 2. Install dependencies
+
+Next, install the required packages:
+
+```terminal
+npm install @prisma/adapter-d1
+```
+
+Also, be sure to use a version of the Wrangler CLI that's above [`wrangler@^3.39.0`](https://github.com/cloudflare/workers-sdk/releases/tag/wrangler%403.39.0), otherwise the `--remote` flag that's used in the next sections won't be available.
+
+#### 3. Set the D1 database connection via a binding
+
+To connect your Workers with the D1 instance, add the following binding to your `wrangler.toml` (if you don't have a D1 instance yet, you can create one using the [Cloudflare Dashboard](https://dash.cloudflare.com/) or with the [`wrangler d1 create`](https://developers.cloudflare.com/workers/wrangler/commands/#create) command):
+
+```toml file=wrangler.toml
+name = "prisma-cloudflare-worker-example"
+main = "src/index.ts"
+compatibility_date = "2024-03-20"
+compatibility_flags = ["nodejs_compat"]
+
+[[d1_databases]]
+binding = "DB" # i.e. available in your Worker on env.DB
+database_name = "__YOUR_D1_DATABASE_NAME__" # to be replaced
+database_id = "__YOUR_D1_DATABASE_ID__" # to be replaced
+```
+
+Note that `__YOUR_D1_DATABASE_NAME__` and `__YOUR_D1_DATABASE_ID__` in the snippet above are placeholders that should be replaced with the database name and ID of your own D1 instance.
+
+If you weren't able to grab this ID from the terminal output, you can also find it in the Cloudflare Dashboard or by running `npx wrangler d1 list` and `npx wrangler d1 info __YOUR_D1_DATABASE_NAME__` in your terminal.
+
+#### 4. Migrate your database schema (if applicable)
+
+If your Prisma schema only contains the `User` model but your D1 database is still empty, you need to make sure that there is a table in D1 that mirrors the structure of the `User` model.
+
+D1 comes with its own [migration system](https://developers.cloudflare.com/d1/reference/migrations/) that lets you manage migration files in your file system. While this is convenient for creating and applying migration files, it doesn't help you identifying the actual SQL statements that you need to put into these migration files. That's where Prisma Migrate comes into play, because you can generate SQL statements for schema changes using the [`prisma migrate diff`](/orm/reference/prisma-cli-reference#migrate-diff) command.
+
+First, create the `migrations` directory and initial migration file using the [`wrangler d1 migrations`](https://developers.cloudflare.com/workers/wrangler/commands/#migrations-create) command as follows:
+
+```terminal
+npx wrangler d1 migrations create __YOUR_D1_DATABASE_NAME__ create_user_table
+```
+
+Replace `__YOUR_D1_DATABASE_NAME__` with the name of your database again and, when prompted, confirm that you want to create the `migrations` directory. After having run this command, there should be a new folder called `migrations` with a file called `0001_create_user_table.sql` inside of it.
+
+You can now generate the required SQL statement for creating a `User` table that can be mapped to the `User` model in your the Prisma schema as follows:
+
+```terminal
+npx prisma migrate diff --from-empty --to-schema-datamodel ./prisma/schema.prisma --script --output migrations/0001_create_user_table.sql
+```
+
+Note that the resulting SQL statement is stored in a file in the `migrations` directory called `0001_create_user_table.sql` which looks as follows:
+
+```sql file=migrations/0001_create_user_table.sql no-copy
+-- CreateTable
+CREATE TABLE "User" (
+ "id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
+ "email" TEXT NOT NULL,
+ "name" TEXT
+);
+
+-- CreateIndex
+CREATE UNIQUE INDEX "User_email_key" ON "User"("email");
+```
+
+You now need to use the [`wrangler d1 migrations apply`](https://developers.cloudflare.com/workers/wrangler/commands/#migrations-apply) command to send this SQL statement to D1. Note that this command accepts two options:
+
+- `--local`: Executes the statement against a _local_ version of D1. This local version of D1 is a SQLite database file that'll be located in your project. This approach is useful, when you want to develop and test your Worker on your local machine. Learn more in the [Cloudflare docs](https://developers.cloudflare.com/d1/configuration/local-development/).
+- `--remote`: Executes the statement against your _remote_ version of D1. This version is used by your _deployed_ Cloudflare Workers. Learn more in the [Cloudflare docs](https://developers.cloudflare.com/d1/configuration/remote-development/).
+
+In this tutorial, you'll do both: test the Worker locally _and_ deploy it afterwards. So, you need to run both commands. Open your terminal and paste the following commands:
+
+```terminal
+# For the local database
+npx wrangler d1 migrations apply __YOUR_D1_DATABASE_NAME__ --local
+
+# For the remote database
+npx wrangler d1 migrations apply __YOUR_D1_DATABASE_NAME__ --remote
+```
+
+As before, you need to replace `__YOUR_D1_DATABASE_NAME__` with the name of your D1 database.
+
+Let's also create some dummy data that we can query once the Worker is running. This time, you'll run the SQL statement without storing it in a file:
+
+```terminal
+# For the local database
+npx wrangler d1 execute __YOUR_D1_DATABASE_NAME__ --command "INSERT INTO \"User\" (\"email\", \"name\") VALUES
+('jane@prisma.io', 'Jane Doe (Local)');" --local
+
+# For the remote database
+npx wrangler d1 execute __YOUR_D1_DATABASE_NAME__ --command "INSERT INTO \"User\" (\"email\", \"name\") VALUES
+('jane@prisma.io', 'Jane Doe (Remote)');" --remote
+```
+
+#### 5. Use Prisma Client in your Worker to send a query to the database
+
+Before adding a Prisma Client query to your Worker, you need to generate Prisma Client with the following command:
+
+```
+npx prisma generate
+```
+
+In order to query your database from the Worker using Prisma ORM, you need to:
+
+1. Add the `DB` binding to the `Env` interface. (Alternatively, you can run [`npx wrangler types`](https://developers.cloudflare.com/workers/wrangler/commands/#types) to generate the `Env` type from the binding in a separate file called `worker-configuration.d.ts`.)
+2. Instantiate `PrismaClient` using the `PrismaD1` driver adapter.
+3. Send a query using Prisma Client and return the result.
+
+Open `src/index.ts` and replace the entire content with the following:
+
+```typescript file=src/index.ts
+import { PrismaClient } from '@prisma/client'
+import { PrismaD1 } from '@prisma/adapter-d1'
+
+export interface Env {
+ DB: D1Database
+}
+
+export default {
+ async fetch(
+ request: Request,
+ env: Env,
+ ctx: ExecutionContext
+ ): Promise {
+ const adapter = new PrismaD1(env.DB)
+ const prisma = new PrismaClient({ adapter })
+
+ const users = await prisma.user.findMany()
+ const result = JSON.stringify(users)
+ return new Response(result)
+ },
+}
+```
+
+#### 6. Run the Worker locally
+
+With the database query in place and Prisma Client generated, you can go ahead and run the Worker locally:
+
+```
+npm run dev
+```
+
+Now you can open your browser at [`http://localhost:8787`](http://localhost:8787/) to see the result of the database query:
+
+```js no-copy
+;[{ id: 1, email: 'jane@prisma.io', name: 'Jane Doe (Local)' }]
+```
+
+#### 7. Set the `DATABASE_URL` environment variable and deploy the Worker
+
+To deploy the Worker, run the the following command:
+
+```
+npm run deploy
+```
+
+Your deployed Worker is accessible via `https://prisma-d1-example.USERNAME.workers.dev`. If you navigate your browser to that URL, you should see the following data that's queried from your remote D1 database:
+
+```js no-copy
+;[{ id: 1, email: 'jane@prisma.io', name: 'Jane Doe (Remote)' }]
+```
diff --git a/content/200-orm/800-more/300-upgrade-guides/800-upgrade-from-prisma-1/03-upgrading-the-prisma-layer-mysql.mdx b/content/200-orm/800-more/300-upgrade-guides/800-upgrade-from-prisma-1/03-upgrading-the-prisma-layer-mysql.mdx
index d69a824392..a77a671bee 100644
--- a/content/200-orm/800-more/300-upgrade-guides/800-upgrade-from-prisma-1/03-upgrading-the-prisma-layer-mysql.mdx
+++ b/content/200-orm/800-more/300-upgrade-guides/800-upgrade-from-prisma-1/03-upgrading-the-prisma-layer-mysql.mdx
@@ -21,7 +21,7 @@ This page explains the first step of your upgrade process: Taking your Prisma 1
1. Create your Prisma ORM 2 schema
1. Determine your connection URL and connect to your database
1. Introspect your database (that was so far managed with Prisma 1)
-1. Use the [Prisma 1 Upgrade CLI](/orm/more/upgrade-guides/upgrade-from-prisma-1/how-to-upgrade#prisma-1-upgrade-cli) to resolve the [schema incompatibilities](/orm/more/upgrade-guides/upgrade-from-prisma-1/schema-incompatibilities-postgresql) in the new Prisma ORM 2 data model
+1. Use the [Prisma 1 Upgrade CLI](/orm/more/upgrade-guides/upgrade-from-prisma-1/how-to-upgrade#prisma-1-upgrade-cli) to resolve the [schema incompatibilities](/orm/more/upgrade-guides/upgrade-from-prisma-1/schema-incompatibilities-mysql) in the new Prisma ORM 2 data model
1. Install and generate Prisma Client
Once done with these steps, you can move on to the next guide that explains how you can upgrade the application layer to use Prisma Client for your database queries.
@@ -151,7 +151,7 @@ Your initial Prisma schema looks as follows:
// learn more about it in the docs: https://pris.ly/d/prisma-schema
datasource db {
- provider = "postgresql"
+ provider = "mysql"
url = env("DATABASE_URL")
}
@@ -422,7 +422,7 @@ For example, Prisma ORM now won't guarantee that a `User` is connected to _at mo
Another issue is that you can store whatever text for the `jsonData` and `role` fields, regardless of whether it's valid JSON or represents a value of the `Role` enum.
-To learn more about these inconsistencies check out the [Schema incompatibilities](/orm/more/upgrade-guides/upgrade-from-prisma-1/schema-incompatibilities-postgresql) page.
+To learn more about these inconsistencies check out the [Schema incompatibilities](/orm/more/upgrade-guides/upgrade-from-prisma-1/schema-incompatibilities-mysql) page.
In the following, we'll go through these incompatibilities and fix them one by one using the Prisma schema upgrade CLI.
@@ -560,7 +560,7 @@ https://pris.ly/d/how-to-upgrade'
> **Note**: If you're seeing the note about breaking changes, you can ignore it for now. We'll discuss it later.
-The shown SQL statements are categorized into a number of "buckets", all aiming to resolve a certain [schema incompatibility](/orm/more/upgrade-guides/upgrade-from-prisma-1/schema-incompatibilities-postgresql):
+The shown SQL statements are categorized into a number of "buckets", all aiming to resolve a certain [schema incompatibility](/orm/more/upgrade-guides/upgrade-from-prisma-1/schema-incompatibilities-mysql):
- Fix columns with ENUM data types
- Add missing `DEFAULT` constraints to the database
@@ -595,7 +595,7 @@ Go ahead and run these statements against your database now.
### 5.1.2. Add missing `DEFAULT` constraints to the database
-Next, the Upgrade CLI helps you resolve the issue that [default values aren't represented in the database](/orm/more/upgrade-guides/upgrade-from-prisma-1/schema-incompatibilities-postgresql#default-values-arent-represented-in-database) by generating SQL statements that add the respective `DEFAULT` constraints directly to the database.
+Next, the Upgrade CLI helps you resolve the issue that [default values aren't represented in the database](/orm/more/upgrade-guides/upgrade-from-prisma-1/schema-incompatibilities-mysql#default-values-arent-represented-in-database) by generating SQL statements that add the respective `DEFAULT` constraints directly to the database.
In this case, two `DEFAULT` constraints are missing which are suggested by the tool:
@@ -632,7 +632,7 @@ You can now run these SQL statements against your database either using a comman
### 5.1.4. Replicate `@createdAt` behavior in Prisma ORM 2
-The next thing the tools does is help you resolve the issue that the behavior of [`@createdAt` isn't represented in database](/orm/more/upgrade-guides/upgrade-from-prisma-1/schema-incompatibilities-postgresql#default-values-arent-represented-in-database)
+The next thing the tools does is help you resolve the issue that the behavior of [`@createdAt` isn't represented in database](/orm/more/upgrade-guides/upgrade-from-prisma-1/schema-incompatibilities-mysql#default-values-arent-represented-in-database)
The CLI currently shows the following output:
@@ -647,7 +647,7 @@ You can now run these SQL statements against your database either using a comman
### 5.1.5. Fix 1-1 relations by adding `UNIQUE` constraints
-Now, the tool will help you [turn the current 1-n relation between `User` ↔ `Profile` back into a 1-1 relation](/orm/more/upgrade-guides/upgrade-from-prisma-1/schema-incompatibilities-postgresql#inline-1-1-relations-are-recognized-as-1-n-missing-unique-constraint) by adding a `UNIQUE` constraint to the foreign key column called `user` (named after the relation field in the Prisma 1 datamodel) in the database.
+Now, the tool will help you [turn the current 1-n relation between `User` ↔ `Profile` back into a 1-1 relation](/orm/more/upgrade-guides/upgrade-from-prisma-1/schema-incompatibilities-mysql#inline-1-1-relations-are-recognized-as-1-n-missing-unique-constraint) by adding a `UNIQUE` constraint to the foreign key column called `user` (named after the relation field in the Prisma 1 datamodel) in the database.
The CLI currently shows the following output:
@@ -664,7 +664,7 @@ You can now run these SQL statements against your database either using a comman
> **Note**: These SQL statements will keep appearing in the Upgrade CLI even after you have changed the column types in the underlying database. This is a currently a limitation in the Upgrade CLI.
-Finally, the tool will help you [turn the current ID columns of type `VARCHAR(25)` into `VARCHAR(30)`](/orm/more/upgrade-guides/upgrade-from-prisma-1/schema-incompatibilities-postgresql#mismatching-cuid-length) by adding a `UNIQUE` constraint to the foreign key column called `user` (named after the relation field in the Prisma 1 datamodel) in the database.
+Finally, the tool will help you [turn the current ID columns of type `VARCHAR(25)` into `VARCHAR(30)`](/orm/more/upgrade-guides/upgrade-from-prisma-1/schema-incompatibilities-mysql#mismatching-cuid-length) by adding a `UNIQUE` constraint to the foreign key column called `user` (named after the relation field in the Prisma 1 datamodel) in the database.
The CLI currently shows the following output:
@@ -700,7 +700,7 @@ In this section, you'll resolve the schema incompatibilities that are breaking y
### 5.2.1. Fix incorrect m-n relations
-Now, the Upgrade CLI helps you fix all 1-1 and 1-n relations that Prisma 1 represents with relation tables and that [currently only exist as m-n relations](/orm/more/upgrade-guides/upgrade-from-prisma-1/schema-incompatibilities-postgresql#all-non-inline-relations-are-recognized-as-m-n) in your new Prisma ORM 2 schema. Concretely, this is the case for the `User` ↔ `Post` relation which currently is defined as m-n but _should_ really be a 1-n relation.
+Now, the Upgrade CLI helps you fix all 1-1 and 1-n relations that Prisma 1 represents with relation tables and that [currently only exist as m-n relations](/orm/more/upgrade-guides/upgrade-from-prisma-1/schema-incompatibilities-mysql#all-non-inline-relations-are-recognized-as-m-n) in your new Prisma ORM 2 schema. Concretely, this is the case for the `User` ↔ `Post` relation which currently is defined as m-n but _should_ really be a 1-n relation.
To fix this, you'll need to perform the following migration:
@@ -1025,7 +1025,7 @@ model Category {
### 5.5. Resolving remaining schema incompatibilities
-There are a few schema incompatibilities that were not yet resolved by the Upgrade CLI. At this point you still haven't fixed [scalar lists](/orm/more/upgrade-guides/upgrade-from-prisma-1/schema-incompatibilities-postgresql#scalar-lists-arrays-are-maintained-with-extra-table) and [cascading deletes](/orm/more/upgrade-guides/upgrade-from-prisma-1/schema-incompatibilities-postgresql#cascading-deletes-are-not-supported-in-prisma-orm-2). You can find the recommended workarounds for these on the [Schema incompatibilities](/orm/more/upgrade-guides/upgrade-from-prisma-1/schema-incompatibilities-postgresql) page.
+There are a few schema incompatibilities that were not yet resolved by the Upgrade CLI. At this point you still haven't fixed [scalar lists](/orm/more/upgrade-guides/upgrade-from-prisma-1/schema-incompatibilities-mysql#scalar-lists-arrays-are-maintained-with-extra-table). You can find the recommended workarounds for this and others on the [Schema incompatibilities](/orm/more/upgrade-guides/upgrade-from-prisma-1/schema-incompatibilities-mysql) page.
## 6. Install and generate Prisma Client
diff --git a/content/200-orm/800-more/300-upgrade-guides/800-upgrade-from-prisma-1/03-upgrading-the-prisma-layer-postgresql.mdx b/content/200-orm/800-more/300-upgrade-guides/800-upgrade-from-prisma-1/03-upgrading-the-prisma-layer-postgresql.mdx
index 86935fea81..aa8389c4a7 100644
--- a/content/200-orm/800-more/300-upgrade-guides/800-upgrade-from-prisma-1/03-upgrading-the-prisma-layer-postgresql.mdx
+++ b/content/200-orm/800-more/300-upgrade-guides/800-upgrade-from-prisma-1/03-upgrading-the-prisma-layer-postgresql.mdx
@@ -1035,7 +1035,7 @@ model Category {
### 5.5. Resolving remaining schema incompatibilities
-There are a few schema incompatibilities that were not yet resolved by the Upgrade CLI. At this point you still haven't fixed [scalar lists](/orm/more/upgrade-guides/upgrade-from-prisma-1/schema-incompatibilities-postgresql#scalar-lists-arrays-are-maintained-with-extra-table) and [cascading deletes](/orm/more/upgrade-guides/upgrade-from-prisma-1/schema-incompatibilities-postgresql#cascading-deletes-are-not-supported-in-prisma-orm-2). You can find the recommended workarounds for these on the [Schema incompatibilities](/orm/more/upgrade-guides/upgrade-from-prisma-1/schema-incompatibilities-postgresql) page.
+There are a few schema incompatibilities that were not yet resolved by the Upgrade CLI. At this point you still haven't fixed [scalar lists](/orm/more/upgrade-guides/upgrade-from-prisma-1/schema-incompatibilities-postgresql#scalar-lists-arrays-are-maintained-with-extra-table). You can find the recommended workarounds for this and others on the [Schema incompatibilities](/orm/more/upgrade-guides/upgrade-from-prisma-1/schema-incompatibilities-postgresql) page.
## 6. Install and generate Prisma Client
diff --git a/content/600-about/200-prisma-docs/30-docs-components/03-frontmatter.mdx b/content/600-about/200-prisma-docs/30-docs-components/03-frontmatter.mdx
index 4a6b64617d..571da927a2 100644
--- a/content/600-about/200-prisma-docs/30-docs-components/03-frontmatter.mdx
+++ b/content/600-about/200-prisma-docs/30-docs-components/03-frontmatter.mdx
@@ -51,14 +51,6 @@ Note:
Front matter that configured the navigation.
-### `staticLink`
-
-Accepts `true` or `false` (defaults to `false`).
-
-If `true`, this option turns the page into a heading in the left-hand navigation. This heading cannot be clicked by the docs user. For example on [this page](/orm/overview).
-
-> **Note**: The page still exists, but docs users can only navigate to it with the breadcrumb trail. We recommend that you add a [subsections](/about/prisma-docs/docs-components/mdx-examples#subsections) MDX component to the page, so that it contains useful content when a user navigates to it with the breadcrumb trail.
-
### `duration`
Accepts a string specifying the duration to read the article.
@@ -77,21 +69,6 @@ Accepts `true` or `false` (defaults to `false`).
Adds a `Deprecated` label to a page in the left-hand navigation.
-### `hidePage`
-
-Accepts `true` or `false` (defaults to `false`).
-
-When set to `true`, hides the page from all navigation.
-
-```
-hidePage: true
-```
-
-Note:
-
-- A page hidden with `hidePage` is not listed by the [subsections](/about/prisma-docs/docs-components/mdx-examples#subsections) MDX component.
-- A page hidden with `hidePage` is still findable by docs users with a search. To omit a page from the search results, use the [`search`](#search) tag.
-
## Table of Contents (right sidebar)
### `toc`
diff --git a/docusaurus.config.ts b/docusaurus.config.ts
index 0d2525bb14..ce428a83fb 100644
--- a/docusaurus.config.ts
+++ b/docusaurus.config.ts
@@ -14,8 +14,9 @@ const config: Config = {
baseUrl: process.env.DOCUSAURUS_BASE_URL ?? '/',
trailingSlash: false,
- onBrokenLinks: 'warn',
- onBrokenMarkdownLinks: 'warn',
+ onBrokenLinks: 'throw',
+ onBrokenAnchors: 'throw',
+ onBrokenMarkdownLinks: 'throw',
// Even if you don't use internationalization, you can use this field to set
// useful metadata like html lang. For example, if your site is Chinese, you