{children}
diff --git a/versioned_docs/version-6.0.0/100-getting-started/01-quickstart-prismaPostgres.mdx b/versioned_docs/version-6.0.0/100-getting-started/01-quickstart-prismaPostgres.mdx
new file mode 100644
index 0000000000..404c632267
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/01-quickstart-prismaPostgres.mdx
@@ -0,0 +1,159 @@
+---
+title: 'Quickstart with Prisma Postgres'
+sidebar_label: 'Quickstart'
+metaTitle: 'Quickstart with TypeScript & Prisma Postgres'
+metaDescription: 'Get started with Prisma ORM in 5 minutes. You will learn how to run migrations and send queries with a Prisma Postgres database.'
+search: true
+sidebar_class_name: hidden-sidebar
+dbSwitcher: ['prismaPostgres', 'sqlite']
+slugSwitch: /getting-started/quickstart-
+sidebar_custom_props: { badge: '5 min' }
+community_section: true
+---
+
+In this Quickstart guide, you'll learn how to get started from scratch with Prisma ORM and a **Prisma Postgres** database in a plain **TypeScript** project. It covers the following workflows:
+
+- Creating a [Prisma Postgres](https://www.prisma.io/postgres?utm_source=docs) database
+- Schema migrations and queries (via [Prisma ORM](https://www.prisma.io/orm))
+- Connection pooling and caching (via [Prisma Accelerate](https://www.prisma.io/accelerate))
+
+:::note
+
+If you want to use Prisma Postgres with another ORM or database library (like Drizzle ORM, TypeORM or Kysely), you can follow the instructions [here](/postgres/introduction/getting-started#connect-via-any-database-library--tool).
+
+:::
+
+## Prerequisites
+
+To successfully complete this tutorial, you need:
+- a [Prisma Data Platform](https://console.prisma.io/) (PDP) account
+- [Node.js](https://nodejs.org/en/) installed on your machine (see [system requirements](/orm/reference/system-requirements) for officially supported versions)
+
+## 1. Set up a Prisma Postgres database in the Platform Console
+
+Follow these steps to create your Prisma Postgres database:
+
+1. Log in to [Prisma Data Platform](https://console.prisma.io/) and open the Console.
+1. In a [workspace](/platform/about#workspace) of your choice, click the **New project** button.
+1. Type a name for your project in the **Name** field, e.g. **hello-ppg**.
+1. In the **Prisma Postgres** section, click the **Get started** button.
+1. In the **Region** dropdown, select the region that's closest to your current location, e.g. **US East (N. Virginia)**.
+1. Click the **Create project** button.
+
+At this point, you'll be redirected to the **Database** page where you will need to wait for a few seconds while the status of your database changes from **`PROVISIONING`** to **`CONNECTED`**.
+
+Once the green **`CONNECTED`** label appears, your database is ready to use!
+
+## 2. Download example and install dependencies
+
+Copy the `try-prisma` command that's shown in the Console, paste it into your terminal and execute it.
+
+For reference, this is what the command looks like:
+
+```terminal
+npx try-prisma@latest \
+ --template databases/prisma-postgres \
+ --name hello-prisma \
+ --install npm
+```
+
+Once the `try-prisma` command has terminated, navigate into the project directory:
+
+```terminal
+cd hello-prisma
+```
+
+## 3. Set database connection URL
+
+The connection to your database is configured via an environment variable in a `.env` file.
+
+First, rename the existing `.env.example` file to just `.env`:
+
+```terminal
+mv .env.example .env
+```
+
+Then, in your project environment in the Platform console, find your database credentials in the **Set up database access** section, copy the `DATABASE_URL` environment variable and paste them into the `.env` file.
+
+For reference, the file should now look similar to this:
+
+```bash no-copy
+DATABASE_URL="prisma+postgres://accelerate.prisma-data.net/?api_key=ey...."
+```
+
+## 4. Create database tables (with a schema migration)
+
+Next, you need to create the tables in your database. You can do this by creating and executing a schema migration with the following command of the Prisma CLI:
+
+```terminal
+npx prisma migrate dev --name init
+```
+
+This will map the `User` and `Post` models that are defined in your [Prisma schema](/orm/prisma-schema/) to your database. You can also review the SQL migration that was executed and created the tables in the newly created `prisma/migrations` directory.
+
+## 5. Execute queries with Prisma ORM
+
+The [`src/queries.ts`](https://github.com/prisma/prisma-examples/blob/latest/databases/prisma-postgres/src/queries.ts) script contains a number of CRUD queries that will write and read data in your database. You can execute it by running the following command in your terminal:
+
+```terminal
+npm run queries
+```
+
+Once the script has completed, you can inspect the logs in your terminal or use Prisma Studio to explore what records have been created in the database:
+
+```terminal
+npx prisma studio
+```
+
+## 6. Explore caching with Prisma Accelerate
+
+The [`src/caching.ts`](https://github.com/prisma/prisma-examples/blob/latest/databases/prisma-postgres/src/caching.ts) script contains a sample query that uses [Stale-While-Revalidate](/postgres/database/caching#stale-while-revalidate-swr) (SWR) and [Time-To-Live](/postgres/database/caching#time-to-live-ttl) (TTL) to cache a database query using Prisma Accelerate. You can execute it as follows:
+
+```terminal
+npm run caching
+```
+
+Take note of the time that it took to execute the query, e.g.:
+
+```no-copy
+The query took 2009.2467149999998ms.
+```
+
+Now, run the script again:
+
+```terminal
+npm run caching
+```
+
+You'll notice that the time the query took will be a lot shorter this time, e.g.:
+
+```no-copy
+The query took 300.5655280000001ms.
+```
+
+## 7. Next steps
+
+In this Quickstart guide, you have learned how to get started with Prisma ORM in a plain TypeScript project. Feel free to explore the Prisma Client API a bit more on your own, e.g. by including filtering, sorting, and pagination options in the `findMany` query or exploring more operations like `update` and `delete` queries.
+
+### Explore the data in Prisma Studio
+
+Prisma ORM comes with a built-in GUI to view and edit the data in your database. You can open it using the following command:
+
+```terminal
+npx prisma studio
+```
+
+With Prisma Postgres, you can also directly use Prisma Studio inside the [Console](https://console.prisma.io) by selecting the **Studio** tab in your project.
+
+### Build a fullstack app with Next.js
+
+Learn how to use Prisma Postgres in a fullstack app:
+
+- [Build a fullstack app with Next.js 15](/guides/nextjs)
+- [Next.js 15 example app](https://github.com/prisma/nextjs-prisma-postgres-demo) (including authentication)
+
+### Explore ready-to-run Prisma ORM examples
+
+Check out the [`prisma-examples`](https://github.com/prisma/prisma-examples/) repository on GitHub to see how Prisma ORM can be used with your favorite library. The repo contains examples with Express, NestJS, GraphQL as well as fullstack examples with Next.js and Vue.js, and a lot more.
+
+These examples use SQLite by default but you can follow the instructions in the project README to switch to Prisma Postgres in a few simple steps.
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/100-getting-started/01-quickstart-sqlite.mdx b/versioned_docs/version-6.0.0/100-getting-started/01-quickstart-sqlite.mdx
new file mode 100644
index 0000000000..79feb9783b
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/01-quickstart-sqlite.mdx
@@ -0,0 +1,465 @@
+---
+title: 'Quickstart with SQLite'
+sidebar_label: 'Quickstart'
+metaTitle: 'Quickstart with TypeScript & SQLite'
+metaDescription: 'Get started with Prisma ORM in 5 minutes. You will learn how to send queries to a SQLite database in a plain TypeScript script using Prisma Client.'
+search: true
+sidebar_class_name: hidden-sidebar
+dbSwitcher: ['prismaPostgres', 'sqlite']
+slugSwitch: /getting-started/quickstart-
+sidebar_custom_props: { badge: '5 min' }
+community_section: true
+---
+
+In this Quickstart guide, you'll learn how to get started with Prisma ORM from scratch using a plain **TypeScript** project and a local **SQLite** database file. It covers **data modeling**, **migrations** and **querying** a database.
+
+If you want to use Prisma ORM with your own PostgreSQL, MySQL, MongoDB or any other supported database, go here instead:
+
+- [Start with Prisma ORM from scratch](/getting-started/setup-prisma/start-from-scratch/relational-databases-typescript-postgresql)
+- [Add Prisma ORM to an existing project](/getting-started/setup-prisma/add-to-existing-project/relational-databases-typescript-postgresql)
+
+## Prerequisites
+
+You need [Node.js](https://nodejs.org/en/) installed on your machine (see [system requirements](/orm/reference/system-requirements) for officially supported versions).
+
+## 1. Create TypeScript project and set up Prisma ORM
+
+As a first step, create a project directory and navigate into it:
+
+```terminal
+mkdir hello-prisma
+cd hello-prisma
+```
+
+Next, initialize a TypeScript project using npm:
+
+```terminal
+npm init -y
+npm install typescript tsx @types/node --save-dev
+```
+
+This creates a `package.json` with an initial setup for your TypeScript app.
+
+:::info
+
+See [installation instructions](/orm/tools/prisma-cli#installation) to learn how to install Prisma using a different package manager.
+
+:::
+
+Now, initialize TypeScript:
+
+```terminal
+npx tsc --init
+```
+
+Then, install the Prisma CLI as a development dependency in the project:
+
+```terminal
+npm install prisma --save-dev
+```
+
+Finally, set up Prisma ORM with the `init` command of the Prisma CLI:
+
+```terminal
+npx prisma init --datasource-provider sqlite --output ../generated/prisma
+```
+
+This creates a new `prisma` directory with a `schema.prisma` file and configures SQLite as your database. You're now ready to model your data and create your database with some tables.
+
+## 2. Model your data in the Prisma schema
+
+The Prisma schema provides an intuitive way to model data. Add the following models to your `schema.prisma` file:
+
+```prisma file=prisma/schema.prisma showLineNumbers
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ posts Post[]
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ content String?
+ published Boolean @default(false)
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+}
+```
+
+Models in the Prisma schema have two main purposes:
+
+- Represent the tables in the underlying database
+- Serve as foundation for the generated Prisma Client API
+
+In the next section, you will map these models to database tables using Prisma Migrate.
+
+## 3. Run a migration to create your database tables with Prisma Migrate
+
+At this point, you have a Prisma schema but no database yet. Run the following command in your terminal to create the SQLite database and the `User` and `Post` tables represented by your models:
+
+```terminal
+npx prisma migrate dev --name init
+```
+
+This command did three things:
+
+1. It created a new SQL migration file for this migration in the `prisma/migrations` directory.
+2. It executed the SQL migration file against the database.
+3. It ran `prisma generate` under the hood (which installed the `@prisma/client` package and generated a tailored Prisma Client API based on your models).
+
+Because the SQLite database file didn't exist before, the command also created it inside the `prisma` directory with the name `dev.db` as defined via the environment variable in the `.env` file.
+
+Congratulations, you now have your database and tables ready. Let's go and learn how you can send some queries to read and write data!
+
+## 4. Explore how to send queries to your database with Prisma Client
+
+To get started with Prisma Client, you need to install the `@prisma/client` package:
+
+```terminal copy
+npm install @prisma/client
+```
+
+The install command invokes `prisma generate` for you which reads your Prisma schema and generates a version of Prisma Client that is _tailored_ to your models.
+
+To send queries to the database, you will need a TypeScript file to execute your Prisma Client queries. Create a new file called `script.ts` for this purpose:
+
+```terminal
+touch script.ts
+```
+
+Then, paste the following boilerplate into it:
+
+```ts file=script.ts showLineNumbers
+import { PrismaClient } from './generated/prisma'
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // ... you will write your Prisma Client queries here
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+This code contains a `main` function that's invoked at the end of the script. It also instantiates `PrismaClient` which represents the query interface to your database.
+
+### 4.1. Create a new `User` record
+
+Let's start with a small query to create a new `User` record in the database and log the resulting object to the console. Add the following code to your `script.ts` file:
+
+```ts file=script.ts highlight=6-12;add showLineNumbers
+import { PrismaClient } from './generated/prisma'
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // add-start
+ const user = await prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ },
+ })
+ console.log(user)
+ // add-end
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Instead of copying the code, you can type it out in your editor to experience the autocompletion Prisma Client provides. You can also actively invoke the autocompletion by pressing the CTRL+SPACE keys on your keyboard.
+
+Next, execute the script with the following command:
+
+
+
+
+
+```terminal
+npx tsx script.ts
+```
+
+
+
+
+```code no-copy
+{ id: 1, email: 'alice@prisma.io', name: 'Alice' }
+```
+
+
+
+
+
+Great job, you just created your first database record with Prisma Client! 🎉
+
+In the next section, you'll learn how to read data from the database.
+
+### 4.2. Retrieve all `User` records
+
+Prisma Client offers various queries to read data from your database. In this section, you'll use the `findMany` query that returns _all_ the records in the database for a given model.
+
+Delete the previous Prisma Client query and add the new `findMany` query instead:
+
+```ts file=script.ts highlight=6-7;add showLineNumbers
+import { PrismaClient } from './generated/prisma'
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // add-start
+ const users = await prisma.user.findMany()
+ console.log(users)
+ // add-end
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Execute the script again:
+
+
+
+
+
+```terminal
+npx tsx script.ts
+```
+
+
+
+
+
+```code no-copy
+[{ id: 1, email: 'alice@prisma.io', name: 'Alice' }]
+```
+
+
+
+
+
+Notice how the single `User` object is now enclosed with square brackets in the console. That's because the `findMany` returned an array with a single object inside.
+
+### 4.3. Explore relation queries with Prisma Client
+
+One of the main features of Prisma Client is the ease of working with [relations](/orm/prisma-schema/data-model/relations). In this section, you'll learn how to create a `User` and a `Post` record in a nested write query. Afterwards, you'll see how you can retrieve the relation from the database using the `include` option.
+
+First, adjust your script to include the nested query:
+
+```ts file=script.ts highlight=6-24;add showLineNumbers
+import { PrismaClient } from './generated/prisma'
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // add-start
+ const user = await prisma.user.create({
+ data: {
+ name: 'Bob',
+ email: 'bob@prisma.io',
+ posts: {
+ create: [
+ {
+ title: 'Hello World',
+ published: true
+ },
+ {
+ title: 'My second post',
+ content: 'This is still a draft'
+ }
+ ],
+ },
+ },
+ })
+ console.log(user)
+ // add-end
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Run the query by executing the script again:
+
+
+
+
+
+```terminal
+npx tsx script.ts
+```
+
+
+
+
+
+```code no-copy
+{ id: 2, email: 'bob@prisma.io', name: 'Bob' }
+```
+
+
+
+
+
+By default, Prisma Client only returns _scalar_ fields in the result objects of a query. That's why, even though you also created a new `Post` record for the new `User` record, the console only printed an object with three scalar fields: `id`, `email` and `name`.
+
+In order to also retrieve the `Post` records that belong to a `User`, you can use the `include` option via the `posts` relation field:
+
+```ts file=script.ts highlight=6-11;add showLineNumbers
+import { PrismaClient } from './generated/prisma'
+
+const prisma = new PrismaClient()
+
+async function main() {
+// add-start
+ const usersWithPosts = await prisma.user.findMany({
+ include: {
+ posts: true,
+ },
+ })
+ console.dir(usersWithPosts, { depth: null })
+ // add-end
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Run the script again to see the results of the nested read query:
+
+
+
+
+
+```terminal
+npx tsx script.ts
+```
+
+
+
+
+
+```code no-copy
+[
+ { id: 1, email: 'alice@prisma.io', name: 'Alice', posts: [] },
+ {
+ id: 2,
+ email: 'bob@prisma.io',
+ name: 'Bob',
+ posts: [
+ {
+ id: 1,
+ title: 'Hello World',
+ content: null,
+ published: true,
+ authorId: 2
+ },
+ {
+ id: 2,
+ title: 'My second post',
+ content: 'This is still a draft',
+ published: false,
+ authorId: 2
+ }
+ ]
+ }
+]
+```
+
+
+
+
+
+This time, you're seeing two `User` objects being printed. Both of them have a `posts` field (which is empty for `"Alice"` and populated with two `Post` objects for `"Bob"`) that represents the `Post` records associated with them.
+
+Notice that the objects in the `usersWithPosts` array are fully typed as well. This means you will get autocompletion and the TypeScript compiler will prevent you from accidentally typing them.
+
+## 5. Next steps
+
+In this Quickstart guide, you have learned how to get started with Prisma ORM in a plain TypeScript project. Feel free to explore the Prisma Client API a bit more on your own, e.g. by including filtering, sorting, and pagination options in the `findMany` query or exploring more operations like `update` and `delete` queries.
+
+### Explore the data in Prisma Studio
+
+Prisma ORM comes with a built-in GUI to view and edit the data in your database. You can open it using the following command:
+
+```terminal
+npx prisma studio
+```
+
+### Set up Prisma ORM with your own database
+
+If you want to move forward with Prisma ORM using your own PostgreSQL, MySQL, MongoDB or any other supported database, follow the Set Up Prisma ORM guides:
+
+- [Start with Prisma ORM from scratch](/getting-started/setup-prisma/start-from-scratch/relational-databases-typescript-postgresql)
+- [Add Prisma ORM to an existing project](/getting-started/setup-prisma/add-to-existing-project)
+
+### Get query insights and analytics with Prisma Optimize
+
+[Prisma Optimize](/optimize) helps you generate insights and provides recommendations that can help you make your database queries faster.
+
+Optimize aims to help developers of all skill levels write efficient database queries, reducing database load and making applications more responsive.
+
+### Explore ready-to-run Prisma ORM examples
+
+Check out the [`prisma-examples`](https://github.com/prisma/prisma-examples/) repository on GitHub to see how Prisma ORM can be used with your favorite library. The repo contains examples with Express, NestJS, GraphQL as well as fullstack examples with Next.js and Vue.js, and a lot more.
+
+### Speed up your database queries with Prisma Accelerate
+
+[Prisma Accelerate](/accelerate) is a connection pooler and global database cache that can drastically speed up your database queries. Check out the [Speed Test](https://accelerate-speed-test.prisma.io/) or try Accelerate with your favorite framework:
+
+| Demo | Description |
+| ----------------------------------------------- | -------------------------------------------------------------------------- |
+| [`nextjs-starter`](https://github.com/prisma/prisma-examples/tree/latest/accelerate/nextjs-starter) | A Next.js project using Prisma Accelerate's caching and connection pooling |
+| [`svelte-starter`](https://github.com/prisma/prisma-examples/tree/latest/accelerate/svelte-starter) | A SvelteKit project using Prisma Accelerate's caching and connection pooling |
+| [`solidstart-starter`](https://github.com/prisma/prisma-examples/tree/latest/accelerate/solidstart-starter) | A Solidstart project using Prisma Accelerate's caching and connection pooling |
+| [`remix-starter`](https://github.com/prisma/prisma-examples/tree/latest/accelerate/remix-starter) | A Remix project using Prisma Accelerate's caching and connection pooling |
+| [`nuxt-starter`](https://github.com/prisma/prisma-examples/tree/latest/accelerate/nuxtjs-starter) | A Nuxt.js project using Prisma Accelerate's caching and connection pooling |
+| [`astro-starter`](https://github.com/prisma/prisma-examples/tree/latest/accelerate/astro-starter) | An Astro project using Prisma Accelerate's caching and connection pooling |
+
+
+### Build an app with Prisma ORM
+
+The Prisma blog features comprehensive tutorials about Prisma ORM, check out our latest ones:
+
+- [Build a fullstack app with Next.js](https://www.youtube.com/watch?v=QXxy8Uv1LnQ&ab_channel=ByteGrad)
+- [Build a fullstack app with Remix](https://www.prisma.io/blog/fullstack-remix-prisma-mongodb-1-7D0BfTXBmB6r) (5 parts, including videos)
+- [Build a REST API with NestJS](https://www.prisma.io/blog/nestjs-prisma-rest-api-7D056s1BmOL0)
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-node-cockroachdb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-node-cockroachdb.mdx
new file mode 100644
index 0000000000..c9b8a135e3
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-node-cockroachdb.mdx
@@ -0,0 +1,52 @@
+---
+title: 'Relational databases (JavaScript and CockroachDB)'
+sidebar_label: 'Relational databases'
+metaTitle: 'Start from scratch with Prisma ORM using JavaScript and CockroachDB (15 min)'
+metaDescription: 'Learn how to create a new Node.js project from scratch by connecting Prisma ORM to your CockroachDB database and generating a Prisma Client for database access.'
+hide_table_of_contents: true
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_custom_props: { badge: '15 min' }
+sidebar_class_name: hidden-sidebar
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-node-cockroachdb
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases-
+---
+
+
+
+Learn how to create a new Node.js or TypeScript project from scratch by connecting Prisma ORM to your database and generating a Prisma Client for database access. The following tutorial introduces you to the [Prisma CLI](/orm/tools/prisma-cli), [Prisma Client](/orm/prisma-client), and [Prisma Migrate](/orm/prisma-migrate).
+
+
+
+## Prerequisites
+
+In order to successfully complete this guide, you need:
+
+- [Node.js](https://nodejs.org/en/) installed on your machine (see [system requirements](/orm/reference/system-requirements) for officially supported versions)
+- a [CockroachDB](https://www.cockroachlabs.com/) database server running
+
+> See [System requirements](/orm/reference/system-requirements) for exact version requirements.
+
+Make sure you have your database [connection URL](/orm/reference/connection-urls) at hand. If you don't have a database server running and just want to explore Prisma ORM, check out the [Quickstart](/getting-started/quickstart-sqlite).
+
+## Create project setup
+
+As a first step, create a project directory and navigate into it:
+
+```terminal copy
+mkdir hello-prisma
+cd hello-prisma
+```
+
+Next, initialize a Node.js project and add the Prisma CLI as a development dependency to it:
+
+```terminal copy
+npm init -y
+npm install prisma --save-dev
+```
+
+This creates a `package.json` with an initial setup for a Node.js app.
+
+import PrismaInitPartial from './_prisma-init-partial.mdx'
+
+
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-node-mysql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-node-mysql.mdx
new file mode 100644
index 0000000000..b0397ccd45
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-node-mysql.mdx
@@ -0,0 +1,58 @@
+---
+title: 'Relational databases (JavaScript and MySQL)'
+sidebar_label: 'Relational databases'
+metaTitle: 'Start from scratch with Prisma ORM using JavaScript and MySQL (15 min)'
+metaDescription: 'Learn how to create a new Node.js project from scratch by connecting Prisma ORM to your MySQL database and generating a Prisma Client for database access.'
+hide_table_of_contents: true
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_custom_props: { badge: '15 min' }
+sidebar_class_name: hidden-sidebar
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-node-mysql
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases-
+---
+
+
+
+Learn how to create a new Node.js or TypeScript project from scratch by connecting Prisma ORM to your database and generating a Prisma Client for database access. The following tutorial introduces you to the [Prisma CLI](/orm/tools/prisma-cli), [Prisma Client](/orm/prisma-client), and [Prisma Migrate](/orm/prisma-migrate).
+
+
+
+## Prerequisites
+
+In order to successfully complete this guide, you need:
+
+- [Node.js](https://nodejs.org/en/) installed on your machine (see [system requirements](/orm/reference/system-requirements) for officially supported versions)
+- a [MySQL](https://www.mysql.com/) database server running
+
+> See [System requirements](/orm/reference/system-requirements) for exact version requirements.
+
+Make sure you have your database [connection URL](/orm/reference/connection-urls) at hand. If you don't have a database server running and just want to explore Prisma ORM, check out the [Quickstart](/getting-started/quickstart-sqlite).
+
+## Create project setup
+
+As a first step, create a project directory and navigate into it:
+
+```terminal copy
+mkdir hello-prisma
+cd hello-prisma
+```
+
+Next, initialize a Node.js project and add the Prisma CLI as a development dependency to it:
+
+```terminal copy
+npm init -y
+npm install prisma --save-dev
+```
+
+This creates a `package.json` with an initial setup for a Node.js app.
+
+:::info
+
+See [installation instructions](/orm/tools/prisma-cli#installation) to learn how to install Prisma using a different package manager.
+
+:::
+
+import PrismaInitPartial from './_prisma-init-partial.mdx'
+
+
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-node-planetscale.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-node-planetscale.mdx
new file mode 100644
index 0000000000..ec9ef078fe
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-node-planetscale.mdx
@@ -0,0 +1,51 @@
+---
+title: 'Relational databases (JavaScript and PlanetScale)'
+sidebar_label: 'Relational databases'
+metaTitle: 'Start from scratch with Prisma ORM using JavaScript and PlanetScale (15 min)'
+metaDescription: 'Learn how to create a new Node.js project from scratch by connecting Prisma ORM to your PlanetScale database and generating a Prisma Client for database access.'
+hide_table_of_contents: true
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_custom_props: { badge: '15 min' }
+sidebar_class_name: hidden-sidebar
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-node-planetscale
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases-
+---
+
+
+
+Learn how to create a new Node.js or TypeScript project from scratch by connecting Prisma ORM to your database and generating a Prisma Client for database access. The following tutorial introduces you to the [Prisma CLI](/orm/tools/prisma-cli), [Prisma Client](/orm/prisma-client), and [Prisma Migrate](/orm/prisma-migrate).
+
+
+
+## Prerequisites
+
+In order to successfully complete this guide, you need:
+
+- [Node.js](https://nodejs.org/en/) installed on your machine (see [system requirements](/orm/reference/system-requirements) for officially supported versions)
+- a [PlanetScale](https://planetscale.com/) database server running
+
+
+
+This tutorial will also assume that you can push to the `main` branch of your database. Do not do this if your `main` branch has been promoted to production.
+
+
+
+Next, initialize a Node.js project and add the Prisma CLI as a development dependency to it:
+
+```terminal copy
+npm init -y
+npm install prisma --save-dev
+```
+
+This creates a `package.json` with an initial setup for a Node.js app.
+
+:::info
+
+See [installation instructions](/orm/tools/prisma-cli#installation) to learn how to install Prisma using a different package manager.
+
+:::
+
+import PrismaInitPartial from './_prisma-init-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-node-postgresql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-node-postgresql.mdx
new file mode 100644
index 0000000000..81fe5d9135
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-node-postgresql.mdx
@@ -0,0 +1,58 @@
+---
+title: 'Relational databases (JavaScript and PostgreSQL)'
+sidebar_label: 'Relational databases'
+metaTitle: 'Start from scratch with Prisma ORM using JavaScript and PostgreSQL (15 min)'
+metaDescription: 'Learn how to create a new Node.js project from scratch by connecting Prisma ORM to your PostgreSQL database and generating a Prisma Client for database access.'
+hide_table_of_contents: true
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_custom_props: { badge: '15 min' }
+sidebar_class_name: hidden-sidebar
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-node-postgresql
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases-
+---
+
+
+
+Learn how to create a new Node.js or TypeScript project from scratch by connecting Prisma ORM to your database and generating a Prisma Client for database access. The following tutorial introduces you to the [Prisma CLI](/orm/tools/prisma-cli), [Prisma Client](/orm/prisma-client), and [Prisma Migrate](/orm/prisma-migrate).
+
+
+
+## Prerequisites
+
+In order to successfully complete this guide, you need:
+
+- [Node.js](https://nodejs.org/en/) installed on your machine (see [system requirements](/orm/reference/system-requirements) for officially supported versions)
+- a [PostgreSQL](https://www.postgresql.org/) database server running
+
+> See [System requirements](/orm/reference/system-requirements) for exact version requirements.
+
+Make sure you have your database [connection URL](/orm/reference/connection-urls) at hand. If you don't have a database server running and just want to explore Prisma ORM, check out the [Quickstart](/getting-started/quickstart-sqlite).
+
+## Create project setup
+
+As a first step, create a project directory and navigate into it:
+
+```terminal copy
+mkdir hello-prisma
+cd hello-prisma
+```
+
+Next, initialize a Node.js project and add the Prisma CLI as a development dependency to it:
+
+```terminal copy
+npm init -y
+npm install prisma --save-dev
+```
+
+This creates a `package.json` with an initial setup for a Node.js app.
+
+:::info
+
+See [installation instructions](/orm/tools/prisma-cli#installation) to learn how to install Prisma using a different package manager.
+
+:::
+
+import PrismaInitPartial from './_prisma-init-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-node-sqlserver.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-node-sqlserver.mdx
new file mode 100644
index 0000000000..92f8f25f9a
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-node-sqlserver.mdx
@@ -0,0 +1,61 @@
+---
+title: 'Relational databases (JavaScript and SQL Server)'
+sidebar_label: 'Relational databases'
+metaTitle: 'Start from scratch with Prisma ORM using JavaScript and SQL Server (15 min)'
+metaDescription: 'Learn how to create a new Node.js project from scratch by connecting Prisma ORM to your SQL Server database and generating a Prisma Client for database access.'
+hide_table_of_contents: true
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_custom_props: { badge: '15 min' }
+sidebar_class_name: hidden-sidebar
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-node-sqlserver
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases-
+---
+
+
+
+Learn how to create a new Node.js or TypeScript project from scratch by connecting Prisma ORM to your database and generating a Prisma Client for database access. The following tutorial introduces you to the [Prisma CLI](/orm/tools/prisma-cli), [Prisma Client](/orm/prisma-client), and [Prisma Migrate](/orm/prisma-migrate).
+
+
+
+## Prerequisites
+
+In order to successfully complete this guide, you need:
+
+- [Node.js](https://nodejs.org/en/) installed on your machine (see [system requirements](/orm/reference/system-requirements) for officially supported versions)
+- A [Microsoft SQL Server](https://learn.microsoft.com/en-us/sql/?view=sql-server-ver16) database
+ - [Microsoft SQL Server on Linux for Docker](/orm/overview/databases/sql-server/sql-server-docker)
+ - [Microsoft SQL Server on Windows (local)](/orm/overview/databases/sql-server/sql-server-local)
+
+
+> See [System requirements](/orm/reference/system-requirements) for exact version requirements.
+
+Make sure you have your database [connection URL](/orm/reference/connection-urls) at hand. If you don't have a database server running and just want to explore Prisma ORM, check out the [Quickstart](/getting-started/quickstart-sqlite).
+
+## Create project setup
+
+As a first step, create a project directory and navigate into it:
+
+```terminal copy
+mkdir hello-prisma
+cd hello-prisma
+```
+
+Next, initialize a Node.js project and add the Prisma CLI as a development dependency to it:
+
+```terminal copy
+npm init -y
+npm install prisma --save-dev
+```
+
+This creates a `package.json` with an initial setup for a Node.js app.
+
+:::info
+
+See [installation instructions](/orm/tools/prisma-cli#installation) to learn how to install Prisma using a different package manager.
+
+:::
+
+import PrismaInitPartial from './_prisma-init-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-typescript-cockroachdb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-typescript-cockroachdb.mdx
new file mode 100644
index 0000000000..ca1f6a19f2
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-typescript-cockroachdb.mdx
@@ -0,0 +1,64 @@
+---
+title: 'Relational databases (TypeScript and CockroachDB)'
+sidebar_label: 'Relational databases'
+metaTitle: 'Start from scratch with Prisma ORM using TypeScript and CockroachDB (15 min)'
+metaDescription: 'Learn how to create a new TypeScript project from scratch by connecting Prisma ORM to your CockroachDB database and generating a Prisma Client for database access.'
+hide_table_of_contents: true
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+sidebar_custom_props: { badge: '15 min' }
+sidebar_class_name: hidden-sidebar
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-typescript-cockroachdb
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases-
+---
+
+
+
+Learn how to create a new Node.js or TypeScript project from scratch by connecting Prisma ORM to your database and generating a Prisma Client for database access. The following tutorial introduces you to the [Prisma CLI](/orm/tools/prisma-cli), [Prisma Client](/orm/prisma-client), and [Prisma Migrate](/orm/prisma-migrate).
+
+
+
+## Prerequisites
+
+In order to successfully complete this guide, you need:
+
+- [Node.js](https://nodejs.org/en/) installed on your machine (see [system requirements](/orm/reference/system-requirements) for officially supported versions)
+- a [CockroachDB](https://www.cockroachlabs.com/) database server running
+
+> See [System requirements](/orm/reference/system-requirements) for exact version requirements.
+
+Make sure you have your database [connection URL](/orm/reference/connection-urls) at hand. If you don't have a database server running and just want to explore Prisma ORM, check out the [Quickstart](/getting-started/quickstart-sqlite).
+
+## Create project setup
+
+As a first step, create a project directory and navigate into it:
+
+```terminal copy
+mkdir hello-prisma
+cd hello-prisma
+```
+
+Next, initialize a TypeScript project and add the Prisma CLI as a development dependency to it:
+
+```terminal copy
+npm init -y
+npm install prisma typescript tsx @types/node --save-dev
+```
+
+This creates a `package.json` with an initial setup for your TypeScript app.
+
+Next, initialize TypeScript:
+
+```terminal copy
+npx tsc --init
+```
+
+:::info
+
+See [installation instructions](/orm/tools/prisma-cli#installation) to learn how to install Prisma using a different package manager.
+
+:::
+
+import PrismaInitPartial from './_prisma-init-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-typescript-mysql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-typescript-mysql.mdx
new file mode 100644
index 0000000000..1c61373522
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-typescript-mysql.mdx
@@ -0,0 +1,64 @@
+---
+title: 'Relational databases (TypeScript and MySQL)'
+sidebar_label: 'Relational databases'
+metaTitle: 'Start from scratch with Prisma ORM using TypeScript and MySQL (15 min)'
+metaDescription: 'Learn how to create a new TypeScript project from scratch by connecting Prisma ORM to your MySQL database and generating a Prisma Client for database access.'
+hide_table_of_contents: true
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+sidebar_custom_props: { badge: '15 min' }
+sidebar_class_name: hidden-sidebar
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-typescript-mysql
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases-
+---
+
+
+
+Learn how to create a new Node.js or TypeScript project from scratch by connecting Prisma ORM to your database and generating a Prisma Client for database access. The following tutorial introduces you to the [Prisma CLI](/orm/tools/prisma-cli), [Prisma Client](/orm/prisma-client), and [Prisma Migrate](/orm/prisma-migrate).
+
+
+
+## Prerequisites
+
+In order to successfully complete this guide, you need:
+
+- [Node.js](https://nodejs.org/en/) installed on your machine (see [system requirements](/orm/reference/system-requirements) for officially supported versions)
+- a [MySQL](https://www.mysql.com/) database server running
+
+> See [System requirements](/orm/reference/system-requirements) for exact version requirements.
+
+Make sure you have your database [connection URL](/orm/reference/connection-urls) at hand. If you don't have a database server running and just want to explore Prisma ORM, check out the [Quickstart](/getting-started/quickstart-sqlite).
+
+## Create project setup
+
+As a first step, create a project directory and navigate into it:
+
+```terminal copy
+mkdir hello-prisma
+cd hello-prisma
+```
+
+Next, initialize a TypeScript project and add the Prisma CLI as a development dependency to it:
+
+```terminal copy
+npm init -y
+npm install prisma typescript tsx @types/node --save-dev
+```
+
+This creates a `package.json` with an initial setup for your TypeScript app.
+
+Next, initialize TypeScript:
+
+```terminal copy
+npx tsc --init
+```
+
+:::info
+
+See [installation instructions](/orm/tools/prisma-cli#installation) to learn how to install Prisma using a different package manager.
+
+:::
+
+import PrismaInitPartial from './_prisma-init-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-typescript-planetscale.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-typescript-planetscale.mdx
new file mode 100644
index 0000000000..5243330350
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-typescript-planetscale.mdx
@@ -0,0 +1,70 @@
+---
+title: 'Relational databases (TypeScript and PlanetScale)'
+sidebar_label: 'Relational databases'
+metaTitle: 'Start from scratch with Prisma ORM using TypeScript and PlanetScale (15 min)'
+metaDescription: 'Learn how to create a new TypeScript project from scratch by connecting Prisma ORM to your PlanetScale database and generating a Prisma Client for database access.'
+hide_table_of_contents: true
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+sidebar_custom_props: { badge: '15 min' }
+sidebar_class_name: hidden-sidebar
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-typescript-planetscale
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases-
+---
+
+
+
+Learn how to create a new Node.js or TypeScript project from scratch by connecting Prisma ORM to your database and generating a Prisma Client for database access. The following tutorial introduces you to the [Prisma CLI](/orm/tools/prisma-cli), [Prisma Client](/orm/prisma-client), and [Prisma Migrate](/orm/prisma-migrate).
+
+
+
+## Prerequisites
+
+In order to successfully complete this guide, you need:
+
+- [Node.js](https://nodejs.org/en/) installed on your machine (see [system requirements](/orm/reference/system-requirements) for officially supported versions)
+- a [PlanetScale](https://planetscale.com/) database server running
+
+
+
+This tutorial will also assume that you can push to the `main` branch of your database. Do not do this if your `main` branch has been promoted to production.
+
+
+
+> See [System requirements](/orm/reference/system-requirements) for exact version requirements.
+
+Make sure you have your database [connection URL](/orm/reference/connection-urls) at hand. If you don't have a database server running and just want to explore Prisma ORM, check out the [Quickstart](/getting-started/quickstart-sqlite).
+
+## Create project setup
+
+As a first step, create a project directory and navigate into it:
+
+```terminal copy
+mkdir hello-prisma
+cd hello-prisma
+```
+
+Next, initialize a TypeScript project and add the Prisma CLI as a development dependency to it:
+
+```terminal copy
+npm init -y
+npm install prisma typescript tsx @types/node --save-dev
+```
+
+This creates a `package.json` with an initial setup for your TypeScript app.
+
+Next, initialize TypeScript:
+
+```terminal copy
+npx tsc --init
+```
+
+:::info
+
+See [installation instructions](/orm/tools/prisma-cli#installation) to learn how to install Prisma using a different package manager.
+
+:::
+
+import PrismaInitPartial from './_prisma-init-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-typescript-postgresql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-typescript-postgresql.mdx
new file mode 100644
index 0000000000..18e56a42b5
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-typescript-postgresql.mdx
@@ -0,0 +1,59 @@
+---
+title: 'Relational databases (TypeScript and PostgreSQL)'
+sidebar_label: 'Relational databases'
+metaTitle: 'Start from scratch with Prisma ORM using TypeScript and PostgreSQL (15 min)'
+metaDescription: 'Learn how to create a new TypeScript project from scratch by connecting Prisma ORM to your PostgreSQL database and generating a Prisma Client for database access.'
+hide_table_of_contents: true
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+sidebar_custom_props: { badge: '15 min' }
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-typescript-postgresql
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases-
+---
+
+Learn how to create a new Node.js or TypeScript project from scratch by connecting Prisma ORM to your database and generating a Prisma Client for database access. The following tutorial introduces you to the [Prisma CLI](/orm/tools/prisma-cli), [Prisma Client](/orm/prisma-client), and [Prisma Migrate](/orm/prisma-migrate).
+
+## Prerequisites
+
+In order to successfully complete this guide, you need:
+
+- [Node.js](https://nodejs.org/en/) installed on your machine (see [system requirements](/orm/reference/system-requirements) for officially supported versions)
+- a [PostgreSQL](https://www.postgresql.org/) database server running
+
+> See [System requirements](/orm/reference/system-requirements) for exact version requirements.
+
+Make sure you have your database [connection URL](/orm/reference/connection-urls) at hand. If you don't have a database server running and just want to explore Prisma ORM, check out the [Quickstart](/getting-started/quickstart-sqlite).
+
+## Create project setup
+
+As a first step, create a project directory and navigate into it:
+
+```terminal copy
+mkdir hello-prisma
+cd hello-prisma
+```
+
+Next, initialize a TypeScript project and add the Prisma CLI as a development dependency to it:
+
+```terminal copy
+npm init -y
+npm install prisma typescript tsx @types/node --save-dev
+```
+
+This creates a `package.json` with an initial setup for your TypeScript app.
+
+Next, initialize TypeScript:
+
+```terminal copy
+npx tsc --init
+```
+
+:::info
+
+See [installation instructions](/orm/tools/prisma-cli#installation) to learn how to install Prisma using a different package manager.
+
+:::
+
+import PrismaInitPartial from './_prisma-init-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-typescript-prismaPostgres.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-typescript-prismaPostgres.mdx
new file mode 100644
index 0000000000..ed8342b018
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-typescript-prismaPostgres.mdx
@@ -0,0 +1,70 @@
+---
+title: 'Relational databases (TypeScript and Prisma Postgres)'
+sidebar_label: 'Relational databases'
+metaTitle: 'Start from scratch with Prisma ORM using TypeScript and Prisma Postgres (15 min)'
+metaDescription: 'Learn how to create a new TypeScript project from scratch by connecting Prisma ORM to your Prisma Postgres database and generating a Prisma Client for database access.'
+hide_table_of_contents: true
+langSwitcher: ['typescript']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+sidebar_custom_props: { badge: '15 min' }
+sidebar_class_name: hidden-sidebar
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-typescript-prismaPostgres
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases-
+---
+
+Learn how to create a new TypeScript project with a Prisma Postgres database from scratch. This tutorial introduces you to the [Prisma CLI](/orm/tools/prisma-cli), [Prisma Client](/orm/prisma-client), and [Prisma Migrate](/orm/prisma-migrate) and covers the following workflows:
+
+- Creating a TypeScript project on your local machine from scratch
+- Creating a [Prisma Postgres](https://www.prisma.io/postgres?utm_source=docs) database
+- Schema migrations and queries (via [Prisma ORM](https://www.prisma.io/orm))
+- Connection pooling and caching (via [Prisma Accelerate](https://www.prisma.io/accelerate))
+
+## Prerequisites
+
+To successfully complete this tutorial, you need:
+- a [Prisma Data Platform](https://console.prisma.io/) (PDP) account
+- [Node.js](https://nodejs.org/en/) installed on your machine (see [system requirements](/orm/reference/system-requirements) for officially supported versions) (see [system requirements](/orm/reference/system-requirements) for officially supported versions)
+
+## Create project setup
+
+Create a project directory and navigate into it:
+
+```terminal copy
+mkdir hello-prisma
+cd hello-prisma
+```
+
+Next, initialize a TypeScript project and add the Prisma CLI as a development dependency to it:
+
+```terminal copy
+npm init -y
+npm install prisma typescript tsx @types/node --save-dev
+```
+
+This creates a `package.json` with an initial setup for your TypeScript app.
+
+Next, initialize TypeScript:
+
+```terminal copy
+npx tsc --init
+```
+
+You can now invoke the Prisma CLI by prefixing it with `npx`:
+
+```terminal
+npx prisma
+```
+
+Next, set up your Prisma ORM project by creating your [Prisma Schema](/orm/prisma-schema) file with the following command:
+
+```terminal copy
+npx prisma init --db --output ../generated/prisma
+```
+
+This command does a few things:
+
+- Creates a new directory called `prisma` that contains a file called `schema.prisma`, which contains the Prisma Schema with your database connection variable and schema models.
+- Sets the `output` to a custom location.
+- Creates a [`.env`](/orm/more/development-environment/environment-variables) file in the root directory of the project, which is used for defining environment variables (such as your database connection and API keys).
+
+In the next section, you'll learn how to connect your Prisma Postgres database to the project you just created on your file system.
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-typescript-sqlserver.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-typescript-sqlserver.mdx
new file mode 100644
index 0000000000..2459fa217c
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases-typescript-sqlserver.mdx
@@ -0,0 +1,66 @@
+---
+title: 'Relational databases (TypeScript and SQL Server)'
+sidebar_label: 'Relational databases'
+metaTitle: 'Start from scratch with Prisma ORM using TypeScript and SQL Server (15 min)'
+metaDescription: 'Learn how to create a new TypeScript project from scratch by connecting Prisma ORM to your SQL Server database and generating a Prisma Client for database access.'
+hide_table_of_contents: true
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+sidebar_custom_props: { badge: '15 min' }
+sidebar_class_name: hidden-sidebar
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-typescript-sqlserver
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases-
+---
+
+
+
+Learn how to create a new Node.js or TypeScript project from scratch by connecting Prisma ORM to your database and generating a Prisma Client for database access. The following tutorial introduces you to the [Prisma CLI](/orm/tools/prisma-cli), [Prisma Client](/orm/prisma-client), and [Prisma Migrate](/orm/prisma-migrate).
+
+
+
+## Prerequisites
+
+In order to successfully complete this guide, you need:
+
+- [Node.js](https://nodejs.org/en/) installed on your machine (see [system requirements](/orm/reference/system-requirements) for officially supported versions)
+- A [Microsoft SQL Server](https://learn.microsoft.com/en-us/sql/?view=sql-server-ver16) database
+ - [Microsoft SQL Server on Linux for Docker](/orm/overview/databases/sql-server/sql-server-docker)
+ - [Microsoft SQL Server on Windows (local)](/orm/overview/databases/sql-server/sql-server-local)
+
+> See [System requirements](/orm/reference/system-requirements) for exact version requirements.
+
+Make sure you have your database [connection URL](/orm/reference/connection-urls) at hand. If you don't have a database server running and just want to explore Prisma ORM, check out the [Quickstart](/getting-started/quickstart-sqlite).
+
+## Create project setup
+
+As a first step, create a project directory and navigate into it:
+
+```terminal copy
+mkdir hello-prisma
+cd hello-prisma
+```
+
+Next, initialize a TypeScript project and add the Prisma CLI as a development dependency to it:
+
+```terminal copy
+npm init -y
+npm install prisma typescript tsx @types/node --save-dev
+```
+
+This creates a `package.json` with an initial setup for your TypeScript app.
+
+Next, initialize TypeScript:
+
+```terminal copy
+npx tsc --init
+```
+
+:::info
+
+See [installation instructions](/orm/tools/prisma-cli#installation) to learn how to install Prisma using a different package manager.
+
+:::
+
+import PrismaInitPartial from './_prisma-init-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-node-cockroachdb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-node-cockroachdb.mdx
new file mode 100644
index 0000000000..de67fb16a7
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-node-cockroachdb.mdx
@@ -0,0 +1,54 @@
+---
+title: 'Connect your database using JavaScript and CockroachDB'
+sidebar_label: 'Connect your database'
+metaTitle: 'Connect your database using JavaScript and CockroachDB'
+metaDescription: 'Connect your database to your project using JavaScript and CockroachDB'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases-node-cockroachdb
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-node-cockroachdb
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-
+---
+
+To connect your database, you need to set the `url` field of the `datasource` block in your Prisma schema to your database [connection URL](/orm/reference/connection-urls):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+```
+
+The `url` is [set via an environment variable](/orm/more/development-environment/environment-variables) which is defined in `.env`. You now need to adjust the connection URL to point to your own database.
+
+The [format of the connection URL](/orm/reference/connection-urls) for your database depends on the database you use. CockroachDB uses the PostgreSQL connection URL format, which has the following structure (the parts spelled all-uppercased are _placeholders_ for your specific connection details):
+
+```no-lines
+postgresql://USER:PASSWORD@HOST:PORT/DATABASE?PARAMETERS
+```
+
+Here's a short explanation of each component:
+
+- `USER`: The name of your database user
+- `PASSWORD`: The password for your database user
+- `PORT`: The port where your database server is running. The default for CockroachDB is `26257`.
+- `DATABASE`: The name of the database
+- `PARAMETERS`: Any additional connection parameters. See the CockroachDB documentation [here](https://www.cockroachlabs.com/docs/stable/connection-parameters.html#additional-connection-parameters).
+
+For a [CockroachDB Serverless](https://www.cockroachlabs.com/docs/cockroachcloud/quickstart.html) or [Cockroach Dedicated](https://www.cockroachlabs.com/docs/cockroachcloud/quickstart-trial-cluster) database hosted on [CockroachDB Cloud](https://www.cockroachlabs.com/docs/cockroachcloud/quickstart/), the [connection URL](/orm/reference/connection-urls) looks similar to this:
+
+```bash file=.env
+DATABASE_URL="postgresql://:@..cockroachlabs.cloud:26257/defaultdb?sslmode=verify-full&sslrootcert=$HOME/.postgresql/root.crt&options=--"
+```
+
+To find your connection string on CockroachDB Cloud, click the 'Connect' button on the overview page for your database cluster, and select the 'Connection string' tab.
+
+For a [CockroachDB database hosted locally](https://www.cockroachlabs.com/docs/stable/secure-a-cluster.html), the [connection URL](/orm/reference/connection-urls) looks similar to this:
+
+```bash file=.env
+DATABASE_URL="postgresql://root@localhost:26257?sslmode=disable"
+```
+
+Your connection string is displayed as part of the welcome text when starting CockroachDB from the command line.
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-node-mysql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-node-mysql.mdx
new file mode 100644
index 0000000000..4a01cb0314
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-node-mysql.mdx
@@ -0,0 +1,61 @@
+---
+title: 'Connect your database using JavaScript and MySQL'
+sidebar_label: 'Connect your database'
+metaTitle: 'Connect your database using JavaScript and MySQL'
+metaDescription: 'Connect your database to your project using JavaScript and MySQL'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_class_name: hidden-sidebar
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases-node-mysql
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-node-mysql
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-
+---
+
+To connect your database, you need to set the `url` field of the `datasource` block in your Prisma schema to your database [connection URL](/orm/reference/connection-urls):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "mysql"
+ url = env("DATABASE_URL")
+}
+```
+
+In this case, the `url` is [set via an environment variable](/orm/prisma-schema/overview#accessing-environment-variables-from-the-schema) which is defined in `.env`:
+
+```bash file=.env
+DATABASE_URL="mysql://johndoe:randompassword@localhost:3306/mydb"
+```
+
+
+
+We recommend adding `.env` to your `.gitignore` file to prevent committing your environment variables.
+
+
+
+You now need to adjust the connection URL to point to your own database.
+
+The [format of the connection URL](/orm/reference/connection-urls) for your database typically depends on the database you use. For MySQL, it looks as follows (the parts spelled all-uppercased are _placeholders_ for your specific connection details):
+
+```no-lines
+mysql://USER:PASSWORD@HOST:PORT/DATABASE
+```
+
+Here's a short explanation of each component:
+
+- `USER`: The name of your database user
+- `PASSWORD`: The password for your database user
+- `PORT`: The port where your database server is running (typically `3306` for MySQL)
+- `DATABASE`: The name of the [database](https://dev.mysql.com/doc/refman/8.0/en/creating-database.html)
+
+As an example, for a MySQL database hosted on AWS RDS, the [connection URL](/orm/reference/connection-urls) might look similar to this:
+
+```bash file=.env
+DATABASE_URL="mysql://johndoe:XXX@mysql–instance1.123456789012.us-east-1.rds.amazonaws.com:3306/mydb"
+```
+
+When running MySQL locally, your connection URL typically looks similar to this:
+
+```bash file=.env
+DATABASE_URL="mysql://root:randompassword@localhost:3306/mydb"
+```
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-node-planetscale.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-node-planetscale.mdx
new file mode 100644
index 0000000000..85aa2f3447
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-node-planetscale.mdx
@@ -0,0 +1,89 @@
+---
+title: 'Connect your database using JavaScript and PlanetScale'
+sidebar_label: 'Connect your database'
+metaTitle: 'Connect your database using JavaScript and PlanetScale'
+metaDescription: 'Connect your database to your project using JavaScript and PlanetScale'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_class_name: hidden-sidebar
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases-node-planetscale
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-node-planetscale
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-
+---
+
+To connect your database, you need to set the `url` field of the `datasource` block in your Prisma schema to your database [connection URL](/orm/reference/connection-urls):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+```
+
+You will also need to set the relation mode type to `prisma` in order to [emulate foreign key constraints](/orm/overview/databases/planetscale#option-1-emulate-relations-in-prisma-client) in the `datasource` block:
+
+```prisma file=schema.prisma highlight=4;add showLineNumbers
+datasource db {
+ provider = "mysql"
+ url = env("DATABASE_URL")
+ //add-next-line
+ relationMode = "prisma"
+}
+```
+
+> **Note**: Since February 2024, you can alternatively [use foreign key constraints on a database-level in PlanetScale](/orm/overview/databases/planetscale#option-2-enable-foreign-key-constraints-in-the-planetscale-database-settings), which omits the need for setting `relationMode = "prisma"`.
+
+The `url` is [set via an environment variable](/orm/prisma-schema/overview#accessing-environment-variables-from-the-schema) which is defined in `.env`:
+
+```bash file=.env
+DATABASE_URL="mysql://janedoe:mypassword@server.us-east-2.psdb.cloud/mydb?sslaccept=strict"
+```
+
+You now need to adjust the connection URL to point to your own database.
+
+The [format of the connection URL](/orm/reference/connection-urls) for your database typically depends on the database you use. PlanetScale uses the MySQL connection URL format, which has the following structure (the parts spelled all-uppercased are _placeholders_ for your specific connection details):
+
+```no-lines
+mysql://USER:PASSWORD@HOST:PORT/DATABASE
+```
+
+Here's a short explanation of each component:
+
+- `USER`: The name of your database user
+- `PASSWORD`: The password for your database user
+- `PORT`: The port where your database server is running (typically `3306` for MySQL)
+- `DATABASE`: The name of the [database](https://dev.mysql.com/doc/refman/8.0/en/creating-database.html)
+
+For a database hosted with PlanetScale, the [connection URL](/orm/reference/connection-urls) looks similar to this:
+
+```bash file=.env
+DATABASE_URL="mysql://myusername:mypassword@server.us-east-2.psdb.cloud/mydb?sslaccept=strict"
+```
+
+The connection URL for a given database branch can be found from your PlanetScale account by going to the overview page for the branch and selecting the 'Connect' dropdown. In the 'Passwords' section, generate a new password and select 'Prisma' to get the Prisma format for the connection URL.
+
+
+Alternative method: connecting using the PlanetScale CLI
+
+Alternatively, you can connect to your PlanetScale database server using the [PlanetScale CLI](https://planetscale.com/docs/concepts/planetscale-environment-setup), and use a local connection URL. In this case the connection URL will look like this:
+
+```bash file=.env
+DATABASE_URL="mysql://root@localhost:PORT/mydb"
+```
+
+
+
+We recommend adding `.env` to your `.gitignore` file to prevent committing your environment variables.
+
+
+
+To connect to your branch, use the following command:
+
+```terminal
+pscale connect prisma-test branchname --port PORT
+```
+
+The `--port` flag can be omitted if you are using the default port `3306`.
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-node-postgresql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-node-postgresql.mdx
new file mode 100644
index 0000000000..0ca802e8ae
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-node-postgresql.mdx
@@ -0,0 +1,65 @@
+---
+title: 'Connect your database using JavaScript and PostgreSQL'
+sidebar_label: 'Connect your database'
+metaTitle: 'Connect your database using JavaScript and PostgreSQL'
+metaDescription: 'Connect your database to your project using JavaScript and PostgreSQL'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_class_name: hidden-sidebar
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases-node-postgresql
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-node-postgresql
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-
+---
+
+To connect your database, you need to set the `url` field of the `datasource` block in your Prisma schema to your database [connection URL](/orm/reference/connection-urls):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+```
+
+In this case, the `url` is [set via an environment variable](/orm/more/development-environment/environment-variables) which is defined in `.env`:
+
+```bash file=.env
+DATABASE_URL="postgresql://johndoe:randompassword@localhost:5432/mydb?schema=public"
+```
+
+
+
+We recommend adding `.env` to your `.gitignore` file to prevent committing your environment variables.
+
+
+
+You now need to adjust the connection URL to point to your own database.
+
+The [format of the connection URL](/orm/reference/connection-urls) for your database depends on the database you use. For PostgreSQL, it looks as follows (the parts spelled all-uppercased are _placeholders_ for your specific connection details):
+
+```no-lines
+postgresql://USER:PASSWORD@HOST:PORT/DATABASE?schema=SCHEMA
+```
+
+Here's a short explanation of each component:
+
+- `USER`: The name of your database user
+- `PASSWORD`: The password for your database user
+- `HOST`: The name of your host name (for the local environment, it is `localhost`)
+- `PORT`: The port where your database server is running (typically `5432` for PostgreSQL)
+- `DATABASE`: The name of the [database](https://www.postgresql.org/docs/12/manage-ag-overview.html)
+- `SCHEMA`: The name of the [schema](https://www.postgresql.org/docs/12/ddl-schemas.html) inside the database
+
+If you're unsure what to provide for the `schema` parameter for a PostgreSQL connection URL, you can probably omit it. In that case, the default schema name `public` will be used.
+
+As an example, for a PostgreSQL database hosted on Heroku, the [connection URL](/orm/reference/connection-urls) might look similar to this:
+
+```bash file=.env
+DATABASE_URL="postgresql://opnmyfngbknppm:XXX@ec2-46-137-91-216.eu-west-1.compute.amazonaws.com:5432/d50rgmkqi2ipus?schema=hello-prisma"
+```
+
+When running PostgreSQL locally on macOS, your user and password as well as the database name _typically_ correspond to the current _user_ of your OS, e.g. assuming the user is called `janedoe`:
+
+```bash file=.env
+DATABASE_URL="postgresql://janedoe:janedoe@localhost:5432/janedoe?schema=hello-prisma"
+```
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-node-sqlserver.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-node-sqlserver.mdx
new file mode 100644
index 0000000000..56115cd142
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-node-sqlserver.mdx
@@ -0,0 +1,40 @@
+---
+title: 'Connect your database using JavaScript and SQL Server'
+sidebar_label: 'Connect your database'
+metaTitle: 'Connect your database using JavaScript and SQL Server'
+metaDescription: 'Connect your database to your project using JavaScript and SQL Server'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_class_name: hidden-sidebar
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases-node-sqlserver
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-node-sqlserver
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-
+---
+
+To connect your database, you need to set the `url` field of the `datasource` block in your Prisma schema to your database [connection URL](/orm/reference/connection-urls):
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "sqlserver"
+ url = env("DATABASE_URL")
+}
+```
+
+In this case, the `url` is [set via an environment variable](/orm/prisma-schema/overview#accessing-environment-variables-from-the-schema) which is defined in `.env`:
+
+The following example connection URL [uses SQL authentication](/orm/overview/databases/sql-server), but there are [other ways to format your connection URL](/orm/overview/databases/sql-server)
+
+```bash file=.env
+ DATABASE_URL="sqlserver://localhost:1433;database=mydb;user=sa;password=r@ndomP@$$w0rd;trustServerCertificate=true"
+```
+
+
+
+We recommend adding `.env` to your `.gitignore` file to prevent committing your environment variables.
+
+
+
+Adjust the connection URL to match your setup - see [Microsoft SQL Server connection URL](/orm/overview/databases/sql-server) for more information.
+
+> Make sure TCP/IP connections are enabled via [SQL Server Configuration Manager](https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-configuration-manager?view=sql-server-ver16&viewFallbackFrom=sql-server-ver16) to avoid `No connection could be made because the target machine actively refused it. (os error 10061)`
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-typescript-cockroachdb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-typescript-cockroachdb.mdx
new file mode 100644
index 0000000000..f8f76a1f3d
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-typescript-cockroachdb.mdx
@@ -0,0 +1,54 @@
+---
+title: 'Connect your database using TypeScript and CockroachDB'
+sidebar_label: 'Connect your database'
+metaTitle: 'Connect your database using TypeScript and CockroachDB'
+metaDescription: 'Connect your database to your project using TypeScript and CockroachDB'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+sidebar_class_name: 'hidden-sidebar tech-switch'
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases-typescript-cockroachdb
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-typescript-cockroachdb
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-
+---
+
+To connect your database, you need to set the `url` field of the `datasource` block in your Prisma schema to your database [connection URL](/orm/reference/connection-urls):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+```
+
+The `url` is [set via an environment variable](/orm/more/development-environment/environment-variables) which is defined in `.env`. You now need to adjust the connection URL to point to your own database.
+
+The [format of the connection URL](/orm/reference/connection-urls) for your database depends on the database you use. CockroachDB uses the PostgreSQL connection URL format, which has the following structure (the parts spelled all-uppercased are _placeholders_ for your specific connection details):
+
+```no-lines
+postgresql://USER:PASSWORD@HOST:PORT/DATABASE?PARAMETERS
+```
+
+Here's a short explanation of each component:
+
+- `USER`: The name of your database user
+- `PASSWORD`: The password for your database user
+- `PORT`: The port where your database server is running. The default for CockroachDB is `26257`.
+- `DATABASE`: The name of the database
+- `PARAMETERS`: Any additional connection parameters. See the CockroachDB documentation [here](https://www.cockroachlabs.com/docs/stable/connection-parameters.html#additional-connection-parameters).
+
+For a [CockroachDB Serverless](https://www.cockroachlabs.com/docs/cockroachcloud/quickstart.html) or [Cockroach Dedicated](https://www.cockroachlabs.com/docs/cockroachcloud/quickstart-trial-cluster) database hosted on [CockroachDB Cloud](https://www.cockroachlabs.com/docs/cockroachcloud/quickstart/), the [connection URL](/orm/reference/connection-urls) looks similar to this:
+
+```bash file=.env
+DATABASE_URL="postgresql://:@..cockroachlabs.cloud:26257/defaultdb?sslmode=verify-full&sslrootcert=$HOME/.postgresql/root.crt&options=--"
+```
+
+To find your connection string on CockroachDB Cloud, click the 'Connect' button on the overview page for your database cluster, and select the 'Connection string' tab.
+
+For a [CockroachDB database hosted locally](https://www.cockroachlabs.com/docs/stable/secure-a-cluster.html), the [connection URL](/orm/reference/connection-urls) looks similar to this:
+
+```bash file=.env
+DATABASE_URL="postgresql://root@localhost:26257?sslmode=disable"
+```
+
+Your connection string is displayed as part of the welcome text when starting CockroachDB from the command line.
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-typescript-mysql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-typescript-mysql.mdx
new file mode 100644
index 0000000000..9b8f5ae7f6
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-typescript-mysql.mdx
@@ -0,0 +1,61 @@
+---
+title: 'Connect your database using TypeScript and MySQL'
+sidebar_label: 'Connect your database'
+metaTitle: 'Connect your database using TypeScript and MySQL'
+metaDescription: 'Connect your database to your project using TypeScript and MySQL'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+sidebar_class_name: hidden-sidebar
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases-typescript-mysql
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-typescript-mysql
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-
+---
+
+To connect your database, you need to set the `url` field of the `datasource` block in your Prisma schema to your database [connection URL](/orm/reference/connection-urls):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "mysql"
+ url = env("DATABASE_URL")
+}
+```
+
+In this case, the `url` is [set via an environment variable](/orm/prisma-schema/overview#accessing-environment-variables-from-the-schema) which is defined in `.env`:
+
+```bash file=.env
+DATABASE_URL="mysql://johndoe:randompassword@localhost:3306/mydb"
+```
+
+
+
+We recommend adding `.env` to your `.gitignore` file to prevent committing your environment variables.
+
+
+
+You now need to adjust the connection URL to point to your own database.
+
+The [format of the connection URL](/orm/reference/connection-urls) for your database typically depends on the database you use. For MySQL, it looks as follows (the parts spelled all-uppercased are _placeholders_ for your specific connection details):
+
+```no-lines
+mysql://USER:PASSWORD@HOST:PORT/DATABASE
+```
+
+Here's a short explanation of each component:
+
+- `USER`: The name of your database user
+- `PASSWORD`: The password for your database user
+- `PORT`: The port where your database server is running (typically `3306` for MySQL)
+- `DATABASE`: The name of the [database](https://dev.mysql.com/doc/refman/8.0/en/creating-database.html)
+
+As an example, for a MySQL database hosted on AWS RDS, the [connection URL](/orm/reference/connection-urls) might look similar to this:
+
+```bash file=.env
+DATABASE_URL="mysql://johndoe:XXX@mysql–instance1.123456789012.us-east-1.rds.amazonaws.com:3306/mydb"
+```
+
+When running MySQL locally, your connection URL typically looks similar to this:
+
+```bash file=.env
+DATABASE_URL="mysql://root:randompassword@localhost:3306/mydb"
+```
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-typescript-planetscale.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-typescript-planetscale.mdx
new file mode 100644
index 0000000000..408d02ba82
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-typescript-planetscale.mdx
@@ -0,0 +1,89 @@
+---
+title: 'Connect your database using TypeScript and PlanetScale'
+sidebar_label: 'Connect your database'
+metaTitle: 'Connect your database using TypeScript and PlanetScale'
+metaDescription: 'Connect your database to your project using TypeScript and PlanetScale'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+sidebar_class_name: hidden-sidebar
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases-typescript-planetscale
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-typescript-planetscale
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-
+---
+
+To connect your database, you need to set the `url` field of the `datasource` block in your Prisma schema to your database [connection URL](/orm/reference/connection-urls):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+```
+
+You will also need to set the relation mode type to `prisma` in order to [emulate foreign key constraints](/orm/overview/databases/planetscale#option-1-emulate-relations-in-prisma-client) in the `datasource` block:
+
+```prisma file=schema.prisma highlight=4;add showLineNumbers
+datasource db {
+ provider = "mysql"
+ url = env("DATABASE_URL")
+ //add-next-line
+ relationMode = "prisma"
+}
+```
+
+> **Note**: Since February 2024, you can alternatively [use foreign key constraints on a database-level in PlanetScale](/orm/overview/databases/planetscale#option-2-enable-foreign-key-constraints-in-the-planetscale-database-settings), which omits the need for setting `relationMode = "prisma"`.
+
+The `url` is [set via an environment variable](/orm/prisma-schema/overview#accessing-environment-variables-from-the-schema) which is defined in `.env`:
+
+```bash file=.env
+DATABASE_URL="mysql://janedoe:mypassword@server.us-east-2.psdb.cloud/mydb?sslaccept=strict"
+```
+
+You now need to adjust the connection URL to point to your own database.
+
+The [format of the connection URL](/orm/reference/connection-urls) for your database typically depends on the database you use. PlanetScale uses the MySQL connection URL format, which has the following structure (the parts spelled all-uppercased are _placeholders_ for your specific connection details):
+
+```no-lines
+mysql://USER:PASSWORD@HOST:PORT/DATABASE
+```
+
+Here's a short explanation of each component:
+
+- `USER`: The name of your database user
+- `PASSWORD`: The password for your database user
+- `PORT`: The port where your database server is running (typically `3306` for MySQL)
+- `DATABASE`: The name of the [database](https://dev.mysql.com/doc/refman/8.0/en/creating-database.html)
+
+For a database hosted with PlanetScale, the [connection URL](/orm/reference/connection-urls) looks similar to this:
+
+```bash file=.env
+DATABASE_URL="mysql://myusername:mypassword@server.us-east-2.psdb.cloud/mydb?sslaccept=strict"
+```
+
+The connection URL for a given database branch can be found from your PlanetScale account by going to the overview page for the branch and selecting the 'Connect' dropdown. In the 'Passwords' section, generate a new password and select 'Prisma' to get the Prisma format for the connection URL.
+
+
+Alternative method: connecting using the PlanetScale CLI
+
+Alternatively, you can connect to your PlanetScale database server using the [PlanetScale CLI](https://planetscale.com/docs/concepts/planetscale-environment-setup), and use a local connection URL. In this case the connection URL will look like this:
+
+```bash file=.env
+DATABASE_URL="mysql://root@localhost:PORT/mydb"
+```
+
+
+
+We recommend adding `.env` to your `.gitignore` file to prevent committing your environment variables.
+
+
+
+To connect to your branch, use the following command:
+
+```terminal
+pscale connect prisma-test branchname --port PORT
+```
+
+The `--port` flag can be omitted if you are using the default port `3306`.
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-typescript-postgresql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-typescript-postgresql.mdx
new file mode 100644
index 0000000000..82703b7c19
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-typescript-postgresql.mdx
@@ -0,0 +1,64 @@
+---
+title: 'Connect your database using TypeScript and PostgreSQL'
+sidebar_label: 'Connect your database'
+metaTitle: 'Connect your database using TypeScript and PostgreSQL'
+metaDescription: 'Connect your database to your project using TypeScript and PostgreSQL'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases-typescript-postgresql
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-typescript-postgresql
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-
+---
+
+To connect your database, you need to set the `url` field of the `datasource` block in your Prisma schema to your database [connection URL](/orm/reference/connection-urls):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+```
+
+In this case, the `url` is [set via an environment variable](/orm/more/development-environment/environment-variables) which is defined in `.env`:
+
+```bash file=.env
+DATABASE_URL="postgresql://johndoe:randompassword@localhost:5432/mydb?schema=public"
+```
+
+
+
+We recommend adding `.env` to your `.gitignore` file to prevent committing your environment variables.
+
+
+
+You now need to adjust the connection URL to point to your own database.
+
+The [format of the connection URL](/orm/reference/connection-urls) for your database depends on the database you use. For PostgreSQL, it looks as follows (the parts spelled all-uppercased are _placeholders_ for your specific connection details):
+
+```no-lines
+postgresql://USER:PASSWORD@HOST:PORT/DATABASE?schema=SCHEMA
+```
+
+Here's a short explanation of each component:
+
+- `USER`: The name of your database user
+- `PASSWORD`: The password for your database user
+- `HOST`: The name of your host name (for the local environment, it is `localhost`)
+- `PORT`: The port where your database server is running (typically `5432` for PostgreSQL)
+- `DATABASE`: The name of the [database](https://www.postgresql.org/docs/12/manage-ag-overview.html)
+- `SCHEMA`: The name of the [schema](https://www.postgresql.org/docs/12/ddl-schemas.html) inside the database
+
+If you're unsure what to provide for the `schema` parameter for a PostgreSQL connection URL, you can probably omit it. In that case, the default schema name `public` will be used.
+
+As an example, for a PostgreSQL database hosted on Heroku, the [connection URL](/orm/reference/connection-urls) might look similar to this:
+
+```bash file=.env
+DATABASE_URL="postgresql://opnmyfngbknppm:XXX@ec2-46-137-91-216.eu-west-1.compute.amazonaws.com:5432/d50rgmkqi2ipus?schema=hello-prisma"
+```
+
+When running PostgreSQL locally on macOS, your user and password as well as the database name _typically_ correspond to the current _user_ of your OS, e.g. assuming the user is called `janedoe`:
+
+```bash file=.env
+DATABASE_URL="postgresql://janedoe:janedoe@localhost:5432/janedoe?schema=hello-prisma"
+```
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-typescript-prismaPostgres.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-typescript-prismaPostgres.mdx
new file mode 100644
index 0000000000..cb0fe2f5b5
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-typescript-prismaPostgres.mdx
@@ -0,0 +1,50 @@
+---
+title: 'Connect your database using TypeScript and Prisma Postgres'
+sidebar_label: 'Connect your database'
+metaTitle: 'Connect your database using TypeScript and Prisma Postgres'
+metaDescription: 'Connect your database to your project using TypeScript and Prisma Postgres'
+langSwitcher: ['typescript']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+sidebar_class_name: 'hidden-sidebar tech-switch'
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases-typescript-prismaPostgres
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-typescript-prismaPostgres
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-
+---
+
+## Set up a Prisma Postgres database in the PDP Console
+
+Follow these steps to create your Prisma Postgres database:
+
+1. Log in to [PDP Console](https://console.prisma.io/).
+1. In a [workspace](/platform/about#workspace) of your choice, click the **New project** button.
+1. Type a name for your project in the **Name** field, e.g. **hello-ppg**.
+1. In the **Prisma Postgres** section, click the **Get started** button.
+1. In the **Region** dropdown, select the region that's closest to your current location, e.g. **US East (N. Virginia)**.
+1. Click the **Create project** button.
+
+At this point, you'll be redirected to the **Dashboard** where you will need to wait for a few seconds while the status of your database changes from **`PROVISIONING`**, to **`ACTIVATING`** to **`CONNECTED`**.
+
+Once the green **`CONNECTED`** label appears, your database is ready to use.
+
+In the Console UI, you'll see a code snippet for a `.env` file with two environment variables defined.
+
+## Set environment variables in your local project
+
+Copy the `DATABASE_URL` environment variable from the Console UI and paste it into your `.env` file. Your `.env` file should look similar to this:
+
+```bash file=.env no-copy
+DATABASE_URL="prisma+postgres://accelerate.prisma-data.net/?api_key=ey..."
+```
+
+By setting the `DATABASE_URL` in the `.env` file, you're ensuring that Prisma ORM can connect to your database. The `DATABASE_URL` is used in the `datasource` block in your Prisma schema:
+
+```prisma file=prisma/schema.prisma
+datasource db {
+ provider = "postgresql"
+ // highlight-next-line
+ url = env("DATABASE_URL")
+}
+```
+
+That's it! You can now start using the Prisma CLI to interact with your Prisma Postgres database. In the next section, you'll learn how to use the Prisma CLI to create and run migrations against your database to update its schema.
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-typescript-sqlserver.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-typescript-sqlserver.mdx
new file mode 100644
index 0000000000..2ef9848ae4
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/100-connect-your-database-typescript-sqlserver.mdx
@@ -0,0 +1,41 @@
+---
+title: 'Connect your database using TypeScript and SQL Server'
+sidebar_label: 'Connect your database'
+metaTitle: 'Connect your database using TypeScript and SQL Server'
+metaDescription: 'Connect your database to your project using TypeScript and SQL Server'
+langSwitcher: ['typescript', 'node']
+sidebar_class_name: hidden-sidebar
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases-typescript-sqlserver
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-typescript-sqlserver
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-
+---
+
+To connect your database, you need to set the `url` field of the `datasource` block in your Prisma schema to your database [connection URL](/orm/reference/connection-urls):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "sqlserver"
+ url = env("DATABASE_URL")
+}
+```
+
+In this case, the `url` is [set via an environment variable](/orm/prisma-schema/overview#accessing-environment-variables-from-the-schema) which is defined in `.env`:
+
+The following example connection URL [uses SQL authentication](/orm/overview/databases/sql-server), but there are [other ways to format your connection URL](/orm/overview/databases/sql-server)
+
+```bash file=.env
+ DATABASE_URL="sqlserver://localhost:1433;database=mydb;user=sa;password=r@ndomP@$$w0rd;trustServerCertificate=true"
+```
+
+
+
+We recommend adding `.env` to your `.gitignore` file to prevent committing your environment variables.
+
+
+
+Adjust the connection URL to match your setup - see [Microsoft SQL Server connection URL](/orm/overview/databases/sql-server) for more information.
+
+> Make sure TCP/IP connections are enabled via [SQL Server Configuration Manager](https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-configuration-manager?view=sql-server-ver16&viewFallbackFrom=sql-server-ver16) to avoid `No connection could be made because the target machine actively refused it. (os error 10061)`
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-node-cockroachdb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-node-cockroachdb.mdx
new file mode 100644
index 0000000000..f39fe32418
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-node-cockroachdb.mdx
@@ -0,0 +1,62 @@
+---
+title: 'Using Prisma Migrate with JavaScript and CockroachDB'
+sidebar_label: 'Using Prisma Migrate'
+metaTitle: 'Using Prisma Migrate with JavaScript and CockroachDB'
+metaDescription: 'Create database tables with Prisma Migrate using JavaScript and CockroachDB'
+langSwitcher: ['typescript', 'node']
+sidebar_class_name: hidden-sidebar
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-node-cockroachdb
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-node-cockroachdb
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-
+---
+
+## Creating the database schema
+
+In this guide, you'll use [Prisma Migrate](/orm/prisma-migrate) to create the tables in your database. Add the following Prisma data model to your Prisma schema in `prisma/schema.prisma`:
+
+```prisma file=prisma/schema.prisma copy showLineNumbers
+model Post {
+ id BigInt @id @default(sequence())
+ createdAt DateTime @default(now())
+ updatedAt DateTime @updatedAt
+ title String
+ content String?
+ published Boolean @default(false)
+ author User @relation(fields: [authorId], references: [id])
+ authorId BigInt
+}
+
+model Profile {
+ id BigInt @id @default(sequence())
+ bio String?
+ user User @relation(fields: [userId], references: [id])
+ userId BigInt @unique
+}
+
+model User {
+ id BigInt @id @default(sequence())
+ email String @unique
+ name String?
+ posts Post[]
+ profile Profile?
+}
+```
+
+To map your data model to the database schema, you need to use the `prisma migrate` CLI commands:
+
+```terminal
+npx prisma migrate dev --name init
+```
+
+This 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
+
+:::note
+`generate` is called under the hood by default, after running `prisma migrate dev`. If the `prisma-client-js` generator is defined in your schema, this will check if `@prisma/client` is installed and install it if it's missing.
+:::
+
+Great, you now created three tables in your database with Prisma Migrate 🚀
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-node-mysql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-node-mysql.mdx
new file mode 100644
index 0000000000..4d95269b0a
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-node-mysql.mdx
@@ -0,0 +1,61 @@
+---
+title: 'Using Prisma Migrate with JavaScript and MySQL'
+sidebar_label: 'Using Prisma Migrate'
+metaTitle: 'Using Prisma Migrate with JavaScript and MySQL'
+metaDescription: 'Create database tables with Prisma Migrate using JavaScript and MySQL'
+langSwitcher: ['typescript', 'node']
+sidebar_class_name: hidden-sidebar
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-node-mysql
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-node-mysql
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-
+---
+
+## Creating the database schema
+
+
+In this guide, you'll use [Prisma Migrate](/orm/prisma-migrate) to create the tables in your database. Add the following Prisma data model to your Prisma schema in `prisma/schema.prisma`:
+
+```prisma file=prisma/schema.prisma copy showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ createdAt DateTime @default(now())
+ updatedAt DateTime @updatedAt
+ title String @db.VarChar(255)
+ content String?
+ published Boolean @default(false)
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ user User @relation(fields: [userId], references: [id])
+ userId Int @unique
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ posts Post[]
+ profile Profile?
+}
+```
+
+To map your data model to the database schema, you need to use the `prisma migrate` CLI commands:
+
+```terminal
+npx prisma migrate dev --name init
+```
+
+This 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
+
+> **Note**: `generate` is called under the hood by default, after running `prisma migrate dev`. If the `prisma-client-js` generator is defined in your schema, this will check if `@prisma/client` is installed and install it if it's missing.
+
+Great, you now created three tables in your database with Prisma Migrate 🚀
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-node-planetscale.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-node-planetscale.mdx
new file mode 100644
index 0000000000..d583dd3b63
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-node-planetscale.mdx
@@ -0,0 +1,59 @@
+---
+title: 'Using Prisma Migrate with JavaScript and PlanetScale'
+sidebar_label: 'Using Prisma Migrate'
+metaTitle: 'Using Prisma Migrate with JavaScript and PlanetScale'
+metaDescription: 'Create database tables with Prisma Migrate using JavaScript and PlanetScale'
+langSwitcher: ['typescript', 'node']
+sidebar_class_name: hidden-sidebar
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-node-planetscale
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-node-planetscale
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-
+---
+
+## Creating the database schema
+
+In this guide, you'll use Prisma's [`db push` command](/orm/prisma-migrate/workflows/prototyping-your-schema) to create the tables in your database. Add the following Prisma data model to your Prisma schema in `prisma/schema.prisma`:
+
+```prisma file=prisma/schema.prisma copy showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ createdAt DateTime @default(now())
+ updatedAt DateTime @updatedAt
+ title String @db.VarChar(255)
+ content String?
+ published Boolean @default(false)
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+
+ @@index(authorId)
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ user User @relation(fields: [userId], references: [id])
+ userId Int @unique
+
+ @@index(userId)
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ posts Post[]
+ profile Profile?
+}
+```
+
+You are now ready to push your new schema to your database. Connect to your `main` branch using the instructions in [Connect your database](/getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-typescript-planetscale).
+
+Now use the `db push` CLI command to push to the `main` branch:
+
+```terminal
+npx prisma db push
+```
+
+Great, you now created three tables in your database with Prisma's `db push` command 🚀
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-node-postgresql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-node-postgresql.mdx
new file mode 100644
index 0000000000..3a5db8a0df
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-node-postgresql.mdx
@@ -0,0 +1,62 @@
+---
+title: 'Using Prisma Migrate with JavaScript and PostgreSQL'
+sidebar_label: 'Using Prisma Migrate'
+metaTitle: 'Using Prisma Migrate with JavaScript and PostgreSQL'
+metaDescription: 'Create database tables with Prisma Migrate using JavaScript and PostgreSQL'
+langSwitcher: ['typescript', 'node']
+sidebar_class_name: hidden-sidebar
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-node-postgresql
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-node-postgresql
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-
+---
+
+## Creating the database schema
+
+In this guide, you'll use [Prisma Migrate](/orm/prisma-migrate) to create the tables in your database. Add the following data model to your [Prisma schema](/orm/prisma-schema) in `prisma/schema.prisma`:
+
+```prisma file=prisma/schema.prisma showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ createdAt DateTime @default(now())
+ updatedAt DateTime @updatedAt
+ title String @db.VarChar(255)
+ content String?
+ published Boolean @default(false)
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ user User @relation(fields: [userId], references: [id])
+ userId Int @unique
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ posts Post[]
+ profile Profile?
+}
+```
+
+To map your data model to the database schema, you need to use the `prisma migrate` CLI commands:
+
+```terminal
+npx prisma migrate dev --name init
+```
+
+This 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
+
+:::note
+`generate` is called under the hood by default, after running `prisma migrate dev`. If the `prisma-client-js` generator is defined in your schema, this will check if `@prisma/client` is installed and install it if it's missing.
+:::
+
+Great, you now created three tables in your database with Prisma Migrate 🚀
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-node-sqlserver.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-node-sqlserver.mdx
new file mode 100644
index 0000000000..a7446e5dd0
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-node-sqlserver.mdx
@@ -0,0 +1,60 @@
+---
+title: 'Using Prisma Migrate with JavaScript and SQL Server'
+sidebar_label: 'Using Prisma Migrate'
+metaTitle: 'Using Prisma Migrate with JavaScript and SQL Server'
+metaDescription: 'Create database tables with Prisma Migrate using JavaScript and SQL Server'
+langSwitcher: ['typescript', 'node']
+sidebar_class_name: hidden-sidebar
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-node-sqlserver
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-node-sqlserver
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-
+---
+
+## Creating the database schema
+
+In this guide, you'll use [Prisma Migrate](/orm/prisma-migrate) to create the tables in your database. Add the following Prisma data model to your Prisma schema in `prisma/schema.prisma`:
+
+```prisma file=prisma/schema.prisma copy showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ createdAt DateTime @default(now())
+ updatedAt DateTime @updatedAt
+ title String @db.VarChar(255)
+ content String?
+ published Boolean @default(false)
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ user User @relation(fields: [userId], references: [id])
+ userId Int @unique
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ posts Post[]
+ profile Profile?
+}
+```
+
+To map your data model to the database schema, you need to use the `prisma migrate` CLI commands:
+
+```terminal
+npx prisma migrate dev --name init
+```
+
+This 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
+
+> **Note**: `generate` is called under the hood by default, after running `prisma migrate dev`. If the `prisma-client-js` generator is defined in your schema, this will check if `@prisma/client` is installed and install it if it's missing.
+
+Great, you now created three tables in your database with Prisma Migrate 🚀
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-typescript-cockroachdb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-typescript-cockroachdb.mdx
new file mode 100644
index 0000000000..8afec9807f
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-typescript-cockroachdb.mdx
@@ -0,0 +1,62 @@
+---
+title: 'Using Prisma Migrate with TypeScript and CockroachDB'
+sidebar_label: 'Using Prisma Migrate'
+metaTitle: 'Using Prisma Migrate with TypeScript and CockroachDB'
+metaDescription: 'Create database tables with Prisma Migrate using TypeScript and CockroachDB'
+langSwitcher: ['typescript', 'node']
+sidebar_class_name: hidden-sidebar
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-typescript-cockroachdb
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-typescript-cockroachdb
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-
+---
+
+## Creating the database schema
+
+In this guide, you'll use [Prisma Migrate](/orm/prisma-migrate) to create the tables in your database. Add the following Prisma data model to your Prisma schema in `prisma/schema.prisma`:
+
+```prisma file=prisma/schema.prisma copy showLineNumbers
+model Post {
+ id BigInt @id @default(sequence())
+ createdAt DateTime @default(now())
+ updatedAt DateTime @updatedAt
+ title String
+ content String?
+ published Boolean @default(false)
+ author User @relation(fields: [authorId], references: [id])
+ authorId BigInt
+}
+
+model Profile {
+ id BigInt @id @default(sequence())
+ bio String?
+ user User @relation(fields: [userId], references: [id])
+ userId BigInt @unique
+}
+
+model User {
+ id BigInt @id @default(sequence())
+ email String @unique
+ name String?
+ posts Post[]
+ profile Profile?
+}
+```
+
+To map your data model to the database schema, you need to use the `prisma migrate` CLI commands:
+
+```terminal
+npx prisma migrate dev --name init
+```
+
+This 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
+
+:::note
+`generate` is called under the hood by default, after running `prisma migrate dev`. If the `prisma-client-js` generator is defined in your schema, this will check if `@prisma/client` is installed and install it if it's missing.
+:::
+
+Great, you now created three tables in your database with Prisma Migrate 🚀
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-typescript-mysql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-typescript-mysql.mdx
new file mode 100644
index 0000000000..c7081afe43
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-typescript-mysql.mdx
@@ -0,0 +1,60 @@
+---
+title: 'Using Prisma Migrate with TypeScript and MySQL'
+sidebar_label: 'Using Prisma Migrate'
+metaTitle: 'Using Prisma Migrate with TypeScript and MySQL'
+metaDescription: 'Create database tables with Prisma Migrate using TypeScript and MySQL'
+langSwitcher: ['typescript', 'node']
+sidebar_class_name: hidden-sidebar
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-typescript-mysql
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-typescript-mysql
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-
+---
+
+## Creating the database schema
+
+In this guide, you'll use [Prisma Migrate](/orm/prisma-migrate) to create the tables in your database. Add the following Prisma data model to your Prisma schema in `prisma/schema.prisma`:
+
+```prisma file=prisma/schema.prisma copy showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ createdAt DateTime @default(now())
+ updatedAt DateTime @updatedAt
+ title String @db.VarChar(255)
+ content String?
+ published Boolean @default(false)
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ user User @relation(fields: [userId], references: [id])
+ userId Int @unique
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ posts Post[]
+ profile Profile?
+}
+```
+
+To map your data model to the database schema, you need to use the `prisma migrate` CLI commands:
+
+```terminal
+npx prisma migrate dev --name init
+```
+
+This 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
+
+> **Note**: `generate` is called under the hood by default, after running `prisma migrate dev`. If the `prisma-client-js` generator is defined in your schema, this will check if `@prisma/client` is installed and install it if it's missing.
+
+Great, you now created three tables in your database with Prisma Migrate 🚀
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-typescript-planetscale.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-typescript-planetscale.mdx
new file mode 100644
index 0000000000..14af90d1ee
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-typescript-planetscale.mdx
@@ -0,0 +1,59 @@
+---
+title: 'Using Prisma Migrate with TypeScript and PlanetScale'
+sidebar_label: 'Using Prisma Migrate'
+metaTitle: 'Using Prisma Migrate with TypeScript and PlanetScale'
+metaDescription: 'Create database tables with Prisma Migrate using TypeScript and PlanetScale'
+langSwitcher: ['typescript', 'node']
+sidebar_class_name: hidden-sidebar
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-typescript-planetscale
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-typescript-planetscale
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-
+---
+
+## Creating the database schema
+
+In this guide, you'll use Prisma's [`db push` command](/orm/prisma-migrate/workflows/prototyping-your-schema) to create the tables in your database. Add the following Prisma data model to your Prisma schema in `prisma/schema.prisma`:
+
+```prisma file=prisma/schema.prisma copy showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ createdAt DateTime @default(now())
+ updatedAt DateTime @updatedAt
+ title String @db.VarChar(255)
+ content String?
+ published Boolean @default(false)
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+
+ @@index(authorId)
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ user User @relation(fields: [userId], references: [id])
+ userId Int @unique
+
+ @@index(userId)
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ posts Post[]
+ profile Profile?
+}
+```
+
+You are now ready to push your new schema to your database. Connect to your `main` branch using the instructions in [Connect your database](/getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-typescript-planetscale).
+
+Now use the `db push` CLI command to push to the `main` branch:
+
+```terminal
+npx prisma db push
+```
+
+Great, you now created three tables in your database with Prisma's `db push` command 🚀
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-typescript-postgresql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-typescript-postgresql.mdx
new file mode 100644
index 0000000000..9591d0517e
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-typescript-postgresql.mdx
@@ -0,0 +1,61 @@
+---
+title: 'Using Prisma Migrate with TypeScript and PostgreSQL'
+sidebar_label: 'Using Prisma Migrate'
+metaTitle: 'Using Prisma Migrate with TypeScript and PostgreSQL'
+metaDescription: 'Create database tables with Prisma Migrate using TypeScript and PostgreSQL'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-typescript-postgresql
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-typescript-postgresql
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-
+---
+
+## Creating the database schema
+
+In this guide, you'll use [Prisma Migrate](/orm/prisma-migrate) to create the tables in your database. Add the following data model to your [Prisma schema](/orm/prisma-schema) in `prisma/schema.prisma`:
+
+```prisma file=prisma/schema.prisma showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ createdAt DateTime @default(now())
+ updatedAt DateTime @updatedAt
+ title String @db.VarChar(255)
+ content String?
+ published Boolean @default(false)
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ user User @relation(fields: [userId], references: [id])
+ userId Int @unique
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ posts Post[]
+ profile Profile?
+}
+```
+
+To map your data model to the database schema, you need to use the `prisma migrate` CLI commands:
+
+```terminal
+npx prisma migrate dev --name init
+```
+
+This 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
+
+:::note
+`generate` is called under the hood by default, after running `prisma migrate dev`. If the `prisma-client-js` generator is defined in your schema, this will check if `@prisma/client` is installed and install it if it's missing.
+:::
+
+Great, you now created three tables in your database with Prisma Migrate 🚀
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-typescript-prismaPostgres.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-typescript-prismaPostgres.mdx
new file mode 100644
index 0000000000..350b89cfdb
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-typescript-prismaPostgres.mdx
@@ -0,0 +1,83 @@
+---
+title: 'Using Prisma Migrate with TypeScript and Prisma Postgres'
+sidebar_label: 'Using Prisma Migrate'
+metaTitle: 'Using Prisma Migrate with TypeScript and Prisma Postgres'
+metaDescription: 'Create database tables with Prisma Migrate using TypeScript and Prisma Postgres'
+langSwitcher: ['typescript']
+sidebar_class_name: hidden-sidebar
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-typescript-prismaPostgres
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-typescript-prismaPostgres
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-
+---
+
+## Creating the database schema
+
+In this guide, you'll use [Prisma Migrate](/orm/prisma-migrate) to create the tables in your database.
+
+To do so, first add the following Prisma data model to your Prisma schema in `prisma/schema.prisma`:
+
+```prisma file=prisma/schema.prisma copy
+model Post {
+ id Int @id @default(autoincrement())
+ createdAt DateTime @default(now())
+ updatedAt DateTime @updatedAt
+ title String
+ content String?
+ published Boolean @default(false)
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ user User @relation(fields: [userId], references: [id])
+ userId Int @unique
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ posts Post[]
+ profile Profile?
+}
+```
+
+This data model defines three [models](/orm/prisma-schema/data-model/models) (which will be mapped to _tables_ in the underlying database):
+- `Post`
+- `Profile`
+- `User`
+
+It also defines two [relations](/orm/prisma-schema/data-model/relations):
+- A one-to-many relation between `User` and `Post` (i.e. "_one_ user can have _many_ posts")
+- A one-to-one relation between `User` and `Profile` (i.e. "_one_ user can have _one_ profile")
+
+To map your data model to the database schema, you need to use the `prisma migrate` CLI commands:
+
+```terminal
+npx prisma migrate dev --name init
+```
+
+This command did two things:
+
+1. It generated a new SQL migration file for this migration
+1. It ran the SQL migration file against the database
+
+You can inspect the generated SQL migration file in the newly created `prisma/migrations` directory.
+
+:::tip Explore your database in Prisma Studio
+
+[Prisma Studio](/orm/tools/prisma-studio) is a visual editor for your database. You can open it with the following command in your terminal:
+
+```
+npx prisma studio
+```
+
+Since you just created the database, you won't see any records but you can take a look at the empty `User`, `Post` and `Profile` tables.
+
+:::
+
+Great, you now created three tables in your database with Prisma Migrate. In the next section, you'll learn how to install Prisma Client which lets you send queries to your database from your TypeScript app.
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-typescript-sqlserver.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-typescript-sqlserver.mdx
new file mode 100644
index 0000000000..ee06eeffae
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/150-using-prisma-migrate-typescript-sqlserver.mdx
@@ -0,0 +1,60 @@
+---
+title: 'Using Prisma Migrate with TypeScript and SQL Server'
+sidebar_label: 'Using Prisma Migrate'
+metaTitle: 'Using Prisma Migrate with TypeScript and SQL Server'
+metaDescription: 'Create database tables with Prisma Migrate using TypeScript and SQL Server'
+langSwitcher: ['typescript', 'node']
+sidebar_class_name: hidden-sidebar
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-typescript-sqlserver
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-typescript-sqlserver
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-
+---
+
+## Creating the database schema
+
+In this guide, you'll use [Prisma Migrate](/orm/prisma-migrate) to create the tables in your database. Add the following Prisma data model to your Prisma schema in `prisma/schema.prisma`:
+
+```prisma file=prisma/schema.prisma copy showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ createdAt DateTime @default(now())
+ updatedAt DateTime @updatedAt
+ title String @db.VarChar(255)
+ content String?
+ published Boolean @default(false)
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ user User @relation(fields: [userId], references: [id])
+ userId Int @unique
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ posts Post[]
+ profile Profile?
+}
+```
+
+To map your data model to the database schema, you need to use the `prisma migrate` CLI commands:
+
+```terminal
+npx prisma migrate dev --name init
+```
+
+This 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
+
+> **Note**: `generate` is called under the hood by default, after running `prisma migrate dev`. If the `prisma-client-js` generator is defined in your schema, this will check if `@prisma/client` is installed and install it if it's missing.
+
+Great, you now created three tables in your database with Prisma Migrate 🚀
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-node-cockroachdb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-node-cockroachdb.mdx
new file mode 100644
index 0000000000..751ae30729
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-node-cockroachdb.mdx
@@ -0,0 +1,17 @@
+---
+title: 'Install Prisma Client (JavaScript and CockroachDB)'
+sidebar_label: 'Install Prisma Client'
+metaTitle: 'Install Prisma Client: JavaScript and CockroachDB'
+metaDescription: 'Install and generate Prisma Client in your project using JavaScript and CockroachDB'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_class_name: hidden-sidebar
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-node-cockroachdb
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/querying-the-database-node-cockroachdb
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-
+---
+
+import InstallPrismaClient from './_install-prisma-client-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-node-mysql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-node-mysql.mdx
new file mode 100644
index 0000000000..2de9870bd7
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-node-mysql.mdx
@@ -0,0 +1,17 @@
+---
+title: 'Install Prisma Client (JavaScript and MySQL)'
+sidebar_label: 'Install Prisma Client'
+metaTitle: 'Install Prisma Client: JavaScript and MySQL'
+metaDescription: 'Install and generate Prisma Client in your project using JavaScript and MySQL'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_class_name: hidden-sidebar
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-node-mysql
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/querying-the-database-node-mysql
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-
+---
+
+import InstallPrismaClient from './_install-prisma-client-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-node-planetscale.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-node-planetscale.mdx
new file mode 100644
index 0000000000..5caaba1e29
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-node-planetscale.mdx
@@ -0,0 +1,17 @@
+---
+title: 'Install Prisma Client (JavaScript and PlanetScale)'
+sidebar_label: 'Install Prisma Client'
+metaTitle: 'Install Prisma Client: JavaScript and PlanetScale'
+metaDescription: 'Install and generate Prisma Client in your project using JavaScript and PlanetScale'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_class_name: hidden-sidebar
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-node-planetscale
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/querying-the-database-node-planetscale
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-
+---
+
+import InstallPrismaClient from './_install-prisma-client-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-node-postgresql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-node-postgresql.mdx
new file mode 100644
index 0000000000..8be8bd1b6a
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-node-postgresql.mdx
@@ -0,0 +1,17 @@
+---
+title: 'Install Prisma Client (JavaScript and PostgreSQL)'
+sidebar_label: 'Install Prisma Client'
+metaTitle: 'Install Prisma Client: JavaScript and PostgreSQL'
+metaDescription: 'Install and generate Prisma Client in your project using JavaScript and PostgreSQL'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_class_name: hidden-sidebar
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-node-postgresql
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/querying-the-database-node-postgresql
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-
+---
+
+import InstallPrismaClient from './_install-prisma-client-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-node-sqlserver.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-node-sqlserver.mdx
new file mode 100644
index 0000000000..f68348bd8e
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-node-sqlserver.mdx
@@ -0,0 +1,17 @@
+---
+title: 'Install Prisma Client (JavaScript and SQL Server)'
+sidebar_label: 'Install Prisma Client'
+metaTitle: 'Install Prisma Client: JavaScript and SQL Server'
+metaDescription: 'Install and generate Prisma Client in your project using JavaScript and SQL Server'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_class_name: hidden-sidebar
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-node-sqlserver
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/querying-the-database-node-sqlserver
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-
+---
+
+import InstallPrismaClient from './_install-prisma-client-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-typescript-cockroachdb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-typescript-cockroachdb.mdx
new file mode 100644
index 0000000000..ee8904442b
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-typescript-cockroachdb.mdx
@@ -0,0 +1,17 @@
+---
+title: 'Install Prisma Client (TypeScript and CockroachDB)'
+sidebar_label: 'Install Prisma Client'
+metaTitle: 'Install Prisma Client: TypeScript and CockroachDB'
+metaDescription: 'Install and generate Prisma Client in your project using TypeScript and CockroachDB'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+sidebar_class_name: hidden-sidebar
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-typescript-cockroachdb
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/querying-the-database-typescript-cockroachdb
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-
+---
+
+import InstallPrismaClient from './_install-prisma-client-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-typescript-mysql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-typescript-mysql.mdx
new file mode 100644
index 0000000000..9f4f57e82e
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-typescript-mysql.mdx
@@ -0,0 +1,17 @@
+---
+title: 'Install Prisma Client (TypeScript and MySQL)'
+sidebar_label: 'Install Prisma Client'
+metaTitle: 'Install Prisma Client: TypeScript and MySQL'
+metaDescription: 'Install and generate Prisma Client in your project using TypeScript and MySQL'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+sidebar_class_name: hidden-sidebar
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-typescript-mysql
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/querying-the-database-typescript-mysql
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-
+---
+
+import InstallPrismaClient from './_install-prisma-client-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-typescript-planetscale.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-typescript-planetscale.mdx
new file mode 100644
index 0000000000..cc8361c41b
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-typescript-planetscale.mdx
@@ -0,0 +1,17 @@
+---
+title: 'Install Prisma Client (TypeScript and PlanetScale)'
+sidebar_label: 'Install Prisma Client'
+metaTitle: 'Install Prisma Client: TypeScript and PlanetScale'
+metaDescription: 'Install and generate Prisma Client in your project using TypeScript and PlanetScale'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+sidebar_class_name: hidden-sidebar
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-typescript-planetscale
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/querying-the-database-typescript-planetscale
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-
+---
+
+import InstallPrismaClient from './_install-prisma-client-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-typescript-postgresql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-typescript-postgresql.mdx
new file mode 100644
index 0000000000..a8b37611ee
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-typescript-postgresql.mdx
@@ -0,0 +1,32 @@
+---
+title: 'Install Prisma Client (TypeScript and PostgreSQL)'
+sidebar_label: 'Install Prisma Client'
+metaTitle: 'Install Prisma Client: TypeScript and PostgreSQL'
+metaDescription: 'Install and generate Prisma Client in your project using TypeScript and PostgreSQL'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-typescript-postgresql
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/querying-the-database-typescript-postgresql
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-
+---
+
+import InstallPrismaClient from './_install-prisma-client-partial.mdx'
+
+
+
+These commands serve different purposes in managing your database schema with Prisma. Here’s a breakdown of when and why to use each:
+
+#### `npx prisma migrate dev`
+
+- **Purpose:** This command generates and applies a new migration based on your Prisma schema changes. It creates migration files that keep a history of changes.
+- **Use Case:** Use this when you want to maintain a record of database changes, which is essential for production environments or when working in teams. It allows for version control of your database schema.
+- **Benefits:** This command also includes checks for applying migrations in a controlled manner, ensuring data integrity.
+
+
+#### `npx prisma db push`
+
+- **Purpose:** This command is used to push your current Prisma schema to the database directly. It applies any changes you've made to your schema without creating migration files.
+- **Use Case:** It’s particularly useful during the development phase when you want to quickly sync your database schema with your Prisma schema without worrying about migration history.
+- **Caution:** It can overwrite data if your schema changes affect existing tables or columns, so it’s best for early-stage development or prototyping.
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-typescript-prismaPostgres.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-typescript-prismaPostgres.mdx
new file mode 100644
index 0000000000..cd152cec57
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-typescript-prismaPostgres.mdx
@@ -0,0 +1,28 @@
+---
+title: 'Install Prisma Client (TypeScript and Prisma Postgres)'
+sidebar_label: 'Install Prisma Client'
+metaTitle: 'Install Prisma Client: TypeScript and Prisma Postgres'
+metaDescription: 'Install and generate Prisma Client in your project using TypeScript and Prisma Postgres'
+langSwitcher: ['typescript']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+sidebar_class_name: hidden-sidebar
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-typescript-prismaPostgres
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/querying-the-database-typescript-prismaPostgres
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-
+---
+
+import InstallPrismaClient from './_install-prisma-client-partial.mdx'
+
+
+
+## Install the Prisma Accelerate extension
+
+Since Prisma Postgres provides a connection pool and (optional) caching layer with Prisma Accelerate, you need to install the Accelerate [Client extension](/orm/prisma-client/client-extensions) in your project as well:
+
+```
+npm install @prisma/extension-accelerate
+```
+
+With that you're all set to read and write data in your database. Move on to the next page to start querying your Prisma Postgres database using Prisma Client.
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-typescript-sqlserver.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-typescript-sqlserver.mdx
new file mode 100644
index 0000000000..c92dbcf171
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/200-install-prisma-client-typescript-sqlserver.mdx
@@ -0,0 +1,17 @@
+---
+title: 'Install Prisma Client (TypeScript and SQL Server)'
+sidebar_label: 'Install Prisma Client'
+metaTitle: 'Install Prisma Client: TypeScript and SQL Server'
+metaDescription: 'Install and generate Prisma Client in your project using TypeScript and SQL Server'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+sidebar_class_name: hidden-sidebar
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-typescript-sqlserver
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/querying-the-database-typescript-sqlserver
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-
+---
+
+import InstallPrismaClient from './_install-prisma-client-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-node-cockroachdb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-node-cockroachdb.mdx
new file mode 100644
index 0000000000..da47ee46b7
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-node-cockroachdb.mdx
@@ -0,0 +1,205 @@
+---
+title: 'Querying the database using JavaScript and CockroachDB'
+sidebar_label: 'Querying the database'
+metaTitle: 'Querying the database using JavaScript and CockroachDB'
+metaDescription: 'Write data to and query the database using JavaScript and CockroachDB'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-node-cockroachdb
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/next-steps
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/querying-the-database-
+---
+
+## Write your first query with Prisma Client
+
+Now that you have generated [Prisma Client](/orm/prisma-client), you can start writing queries to read and write data in your database. For the purpose of this guide, you'll use a plain Node.js script to explore some basic features of Prisma Client.
+
+Create a new file named `index.js` and add the following code to it:
+
+```js file=index.js copy showLineNumbers
+const { PrismaClient } = require('./generated/prisma')
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // ... you will write your Prisma Client queries here
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Here's a quick overview of the different parts of the code snippet:
+
+1. Import the `PrismaClient` constructor from the `@prisma/client` node module
+1. Instantiate `PrismaClient`
+1. Define an `async` function named `main` to send queries to the database
+1. Call the `main` function
+1. Close the database connections when the script terminates
+
+Inside the `main` function, add the following query to read all `User` records from the database and print the result:
+
+```js file=index.js highlight=2;delete|3,4;add showLineNumbers
+async function main() {
+ //delete-next-line
+ // ... you will write your Prisma Client queries here
+ //add-start
+ const allUsers = await prisma.user.findMany()
+ console.log(allUsers)
+ //add-end
+}
+```
+
+Now run the code with this command:
+
+```terminal copy
+node index.js
+```
+
+This should print an empty array because there are no `User` records in the database yet:
+
+```json no-lines
+[]
+```
+
+## Write data into the database
+
+The `findMany` query you used in the previous section only _reads_ data from the database (although it was still empty). In this section, you'll learn how to write a query to _write_ new records into the `Post` and `User` tables.
+
+Adjust the `main` function to send a `create` query to the database:
+
+```js file=index.js highlight=2-21;add copy showLineNumbers
+async function main() {
+ //add-start
+ await prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ posts: {
+ create: { title: 'Hello World' },
+ },
+ profile: {
+ create: { bio: 'I like turtles' },
+ },
+ },
+ })
+
+ const allUsers = await prisma.user.findMany({
+ include: {
+ posts: true,
+ profile: true,
+ },
+ })
+ console.dir(allUsers, { depth: null })
+ //add-end
+}
+```
+
+This code creates a new `User` record together with new `Post` and `Profile` records using a [nested write](/orm/prisma-client/queries/relation-queries#nested-writes) query. The `User` record is connected to the two other ones via the `Post.author` ↔ `User.posts` and `Profile.user` ↔ `User.profile` [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) respectively.
+
+Notice that you're passing the [`include`](/orm/prisma-client/queries/select-fields#return-nested-objects-by-selecting-relation-fields) option to `findMany` which tells Prisma Client to include the `posts` and `profile` relations on the returned `User` objects.
+
+Run the code with this command:
+
+```terminal copy
+node index.js
+```
+
+The output should look similar to this:
+
+```js no-lines
+[
+ {
+ email: 'alice@prisma.io',
+ id: 1,
+ name: 'Alice',
+ posts: [
+ {
+ content: null,
+ createdAt: 2020-03-21T16:45:01.246Z,
+ updatedAt: 2020-03-21T16:45:01.246Z,
+ id: 1,
+ published: false,
+ title: 'Hello World',
+ authorId: 1,
+ }
+ ],
+ profile: {
+ bio: 'I like turtles',
+ id: 1,
+ userId: 1,
+ }
+ }
+]
+```
+
+The query added new records to the `User` and the `Post` tables:
+
+**User**
+
+| **id** | **email** | **name** |
+| :----- | :------------------ | :-------- |
+| `1` | `"alice@prisma.io"` | `"Alice"` |
+
+**Post**
+
+| **id** | **createdAt** | **updatedAt** | **title** | **content** | **published** | **authorId** |
+| :----- | :------------------------- | :------------------------: | :-------------- | :---------- | :------------ | :----------- |
+| `1` | `2020-03-21T16:45:01.246Z` | `2020-03-21T16:45:01.246Z` | `"Hello World"` | `null` | `false` | `1` |
+
+**Profile**
+
+| **id** | **bio** | **userId** |
+| :----- | :----------------- | :--------- |
+| `1` | `"I like turtles"` | `1` |
+
+> **Note**: The numbers in the `authorId` column on `Post` and `userId` column on `Profile` both reference the `id` column of the `User` table, meaning the `id` value `1` column therefore refers to the first (and only) `User` record in the database.
+
+Before moving on to the next section, you'll "publish" the `Post` record you just created using an `update` query. Adjust the `main` function as follows:
+
+```js file=index.js copy showLineNumbers
+async function main() {
+ const post = await prisma.post.update({
+ where: { id: 1 },
+ data: { published: true },
+ })
+ console.log(post)
+}
+```
+
+Now run the code using the same command as before:
+
+```terminal copy
+node index.js
+```
+
+You will see the following output:
+
+```js no-lines
+{
+ id: 1,
+ title: 'Hello World',
+ content: null,
+ published: true,
+ authorId: 1
+}
+```
+
+The `Post` record with an `id` of `1` now got updated in the database:
+
+**Post**
+
+| **id** | **title** | **content** | **published** | **authorId** |
+| :----- | :-------------- | :---------- | :------------ | :----------- |
+| `1` | `"Hello World"` | `null` | `true` | `1` |
+
+Fantastic, you just wrote new data into your database for the first time using Prisma Client 🚀
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-node-mysql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-node-mysql.mdx
new file mode 100644
index 0000000000..93e81725bc
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-node-mysql.mdx
@@ -0,0 +1,205 @@
+---
+title: 'Querying the database using JavaScript and MySQL'
+sidebar_label: 'Querying the database'
+metaTitle: 'Querying the database using JavaScript and MySQL'
+metaDescription: 'Write data to and query the database using JavaScript and MySQL'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-node-mysql
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/next-steps
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/querying-the-database-
+---
+
+## Write your first query with Prisma Client
+
+Now that you have generated [Prisma Client](/orm/prisma-client), you can start writing queries to read and write data in your database. For the purpose of this guide, you'll use a plain Node.js script to explore some basic features of Prisma Client.
+
+Create a new file named `index.js` and add the following code to it:
+
+```js file=index.js copy showLineNumbers
+const { PrismaClient } = require('./generated/prisma')
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // ... you will write your Prisma Client queries here
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Here's a quick overview of the different parts of the code snippet:
+
+1. Import the `PrismaClient` constructor from the `@prisma/client` node module
+1. Instantiate `PrismaClient`
+1. Define an `async` function named `main` to send queries to the database
+1. Call the `main` function
+1. Close the database connections when the script terminates
+
+Inside the `main` function, add the following query to read all `User` records from the database and print the result:
+
+```js file=index.js highlight=2;delete|3,4; showLineNumbers
+async function main() {
+ //delete-next-line
+ // ... you will write your Prisma Client queries here
+ //add-start
+ const allUsers = await prisma.user.findMany()
+ console.log(allUsers)
+ //add-end
+}
+```
+
+Now run the code with this command:
+
+```terminal copy
+node index.js
+```
+
+This should print an empty array because there are no `User` records in the database yet:
+
+```json no-lines
+[]
+```
+
+## Write data into the database
+
+The `findMany` query you used in the previous section only _reads_ data from the database (although it was still empty). In this section, you'll learn how to write a query to _write_ new records into the `Post` and `User` tables.
+
+Adjust the `main` function to send a `create` query to the database:
+
+```js file=index.js highlight=2-21;add copy showLineNumbers
+async function main() {
+ //add-start
+ await prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ posts: {
+ create: { title: 'Hello World' },
+ },
+ profile: {
+ create: { bio: 'I like turtles' },
+ },
+ },
+ })
+
+ const allUsers = await prisma.user.findMany({
+ include: {
+ posts: true,
+ profile: true,
+ },
+ })
+ console.dir(allUsers, { depth: null })
+ //add-end
+}
+```
+
+This code creates a new `User` record together with new `Post` and `Profile` records using a [nested write](/orm/prisma-client/queries/relation-queries#nested-writes) query. The `User` record is connected to the two other ones via the `Post.author` ↔ `User.posts` and `Profile.user` ↔ `User.profile` [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) respectively.
+
+Notice that you're passing the [`include`](/orm/prisma-client/queries/select-fields#return-nested-objects-by-selecting-relation-fields) option to `findMany` which tells Prisma Client to include the `posts` and `profile` relations on the returned `User` objects.
+
+Run the code with this command:
+
+```terminal copy
+node index.js
+```
+
+The output should look similar to this:
+
+```js no-lines
+[
+ {
+ email: 'alice@prisma.io',
+ id: 1,
+ name: 'Alice',
+ posts: [
+ {
+ content: null,
+ createdAt: 2020-03-21T16:45:01.246Z,
+ updatedAt: 2020-03-21T16:45:01.246Z,
+ id: 1,
+ published: false,
+ title: 'Hello World',
+ authorId: 1,
+ }
+ ],
+ profile: {
+ bio: 'I like turtles',
+ id: 1,
+ userId: 1,
+ }
+ }
+]
+```
+
+The query added new records to the `User` and the `Post` tables:
+
+**User**
+
+| **id** | **email** | **name** |
+| :----- | :------------------ | :-------- |
+| `1` | `"alice@prisma.io"` | `"Alice"` |
+
+**Post**
+
+| **id** | **createdAt** | **updatedAt** | **title** | **content** | **published** | **authorId** |
+| :----- | :------------------------- | :------------------------: | :-------------- | :---------- | :------------ | :----------- |
+| `1` | `2020-03-21T16:45:01.246Z` | `2020-03-21T16:45:01.246Z` | `"Hello World"` | `null` | `false` | `1` |
+
+**Profile**
+
+| **id** | **bio** | **userId** |
+| :----- | :----------------- | :--------- |
+| `1` | `"I like turtles"` | `1` |
+
+> **Note**: The numbers in the `authorId` column on `Post` and `userId` column on `Profile` both reference the `id` column of the `User` table, meaning the `id` value `1` column therefore refers to the first (and only) `User` record in the database.
+
+Before moving on to the next section, you'll "publish" the `Post` record you just created using an `update` query. Adjust the `main` function as follows:
+
+```js file=index.js copy showLineNumbers
+async function main() {
+ const post = await prisma.post.update({
+ where: { id: 1 },
+ data: { published: true },
+ })
+ console.log(post)
+}
+```
+
+Now run the code using the same command as before:
+
+```terminal copy
+node index.js
+```
+
+You will see the following output:
+
+```js no-lines
+{
+ id: 1,
+ title: 'Hello World',
+ content: null,
+ published: true,
+ authorId: 1
+}
+```
+
+The `Post` record with an `id` of `1` now got updated in the database:
+
+**Post**
+
+| **id** | **title** | **content** | **published** | **authorId** |
+| :----- | :-------------- | :---------- | :------------ | :----------- |
+| `1` | `"Hello World"` | `null` | `true` | `1` |
+
+Fantastic, you just wrote new data into your database for the first time using Prisma Client 🚀
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-node-planetscale.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-node-planetscale.mdx
new file mode 100644
index 0000000000..6a8bec5c58
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-node-planetscale.mdx
@@ -0,0 +1,206 @@
+---
+title: 'Querying the database using JavaScript and PlanetScale'
+sidebar_label: 'Querying the database'
+metaTitle: 'Querying the database using JavaScript and PlanetScale'
+metaDescription: 'Write data to and query the database using JavaScript and PlanetScale'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-node-planetscale
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/next-steps
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/querying-the-database-
+---
+
+## Write your first query with Prisma Client
+
+Now that you have generated [Prisma Client](/orm/prisma-client), you can start writing queries to read and write data in your database. For the purpose of this guide, you'll use a plain Node.js script to explore some basic features of Prisma Client.
+
+Create a new file named `index.js` and add the following code to it:
+
+```js file=index.js copy showLineNumbers
+const { PrismaClient } = require('./generated/prisma')
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // ... you will write your Prisma Client queries here
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Here's a quick overview of the different parts of the code snippet:
+
+1. Import the `PrismaClient` constructor from the `@prisma/client` node module
+1. Instantiate `PrismaClient`
+1. Define an `async` function named `main` to send queries to the database
+1. Call the `main` function
+1. Close the database connections when the script terminates
+
+Inside the `main` function, add the following query to read all `User` records from the database and print the result:
+
+```js file=index.js highlight=2;delete|3,4;add showLineNumbers
+async function main() {
+ //delete-next-line
+ // ... you will write your Prisma Client queries here
+ //add-start
+ const allUsers = await prisma.user.findMany()
+ console.log(allUsers)
+ //add-end
+}
+```
+
+Now run the code with this command:
+
+```terminal copy
+node index.js
+```
+
+This should print an empty array because there are no `User` records in the database yet:
+
+```json no-lines
+[]
+```
+
+## Write data into the database
+
+The `findMany` query you used in the previous section only _reads_ data from the database (although it was still empty). In this section, you'll learn how to write a query to _write_ new records into the `Post` and `User` tables.
+
+Adjust the `main` function to send a `create` query to the database:
+
+```js file=index.js highlight=2-21;add copy showLineNumbers
+async function main() {
+ //add-start
+ await prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ posts: {
+ create: { title: 'Hello World' },
+ },
+ profile: {
+ create: { bio: 'I like turtles' },
+ },
+ },
+ })
+
+ const allUsers = await prisma.user.findMany({
+ include: {
+ posts: true,
+ profile: true,
+ },
+ })
+ console.dir(allUsers, { depth: null })
+ //add-end
+}
+```
+
+This code creates a new `User` record together with new `Post` and `Profile` records using a [nested write](/orm/prisma-client/queries/relation-queries#nested-writes) query. The `User` record is connected to the two other ones via the `Post.author` ↔ `User.posts` and `Profile.user` ↔ `User.profile` [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) respectively.
+
+Notice that you're passing the [`include`](/orm/prisma-client/queries/select-fields#return-nested-objects-by-selecting-relation-fields) option to `findMany` which tells Prisma Client to include the `posts` and `profile` relations on the returned `User` objects.
+
+Run the code with this command:
+
+```terminal copy
+node index.js
+```
+
+The output should look similar to this:
+
+```js no-lines
+[
+ {
+ email: 'alice@prisma.io',
+ id: 1,
+ name: 'Alice',
+ posts: [
+ {
+ content: null,
+ createdAt: 2020-03-21T16:45:01.246Z,
+ updatedAt: 2020-03-21T16:45:01.246Z,
+ id: 1,
+ published: false,
+ title: 'Hello World',
+ authorId: 1,
+ }
+ ],
+ profile: {
+ bio: 'I like turtles',
+ id: 1,
+ userId: 1,
+ }
+ }
+]
+```
+
+The query added new records to the `User` and the `Post` tables:
+
+**User**
+
+| **id** | **email** | **name** |
+| :----- | :------------------ | :-------- |
+| `1` | `"alice@prisma.io"` | `"Alice"` |
+
+**Post**
+
+| **id** | **createdAt** | **updatedAt** | **title** | **content** | **published** | **authorId** |
+| :----- | :------------------------- | :------------------------: | :-------------- | :---------- | :------------ | :----------- |
+| `1` | `2020-03-21T16:45:01.246Z` | `2020-03-21T16:45:01.246Z` | `"Hello World"` | `null` | `false` | `1` |
+
+**Profile**
+
+| **id** | **bio** | **userId** |
+| :----- | :----------------- | :--------- |
+| `1` | `"I like turtles"` | `1` |
+
+> **Note**: The numbers in the `authorId` column on `Post` and `userId` column on `Profile` both reference the `id` column of the `User` table, meaning the `id` value `1` column therefore refers to the first (and only) `User` record in the database.
+
+Before moving on to the next section, you'll "publish" the `Post` record you just created using an `update` query. Adjust the `main` function as follows:
+
+
+```js file=index.js copy showLineNumbers
+async function main() {
+ const post = await prisma.post.update({
+ where: { id: 1 },
+ data: { published: true },
+ })
+ console.log(post)
+}
+```
+
+Now run the code using the same command as before:
+
+```terminal copy
+node index.js
+```
+
+You will see the following output:
+
+```js no-lines
+{
+ id: 1,
+ title: 'Hello World',
+ content: null,
+ published: true,
+ authorId: 1
+}
+```
+
+The `Post` record with an `id` of `1` now got updated in the database:
+
+**Post**
+
+| **id** | **title** | **content** | **published** | **authorId** |
+| :----- | :-------------- | :---------- | :------------ | :----------- |
+| `1` | `"Hello World"` | `null` | `true` | `1` |
+
+Fantastic, you just wrote new data into your database for the first time using Prisma Client 🚀
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-node-postgresql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-node-postgresql.mdx
new file mode 100644
index 0000000000..5f16c8481c
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-node-postgresql.mdx
@@ -0,0 +1,206 @@
+---
+title: 'Querying the database using JavaScript and PostgreSQL'
+sidebar_label: 'Querying the database'
+metaTitle: 'Querying the database using JavaScript and PostgreSQL'
+metaDescription: 'Write data to and query the database using JavaScript and PostgreSQL'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-node-postgresql
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/next-steps
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/querying-the-database-
+---
+
+## Write your first query with Prisma Client
+
+Now that you have generated [Prisma Client](/orm/prisma-client), you can start writing queries to read and write data in your database. For the purpose of this guide, you'll use a plain Node.js script to explore some basic features of Prisma Client.
+
+Create a new file named `index.js` and add the following code to it:
+
+```js file=index.js copy showLineNumbers
+const { PrismaClient } = require('./generated/prisma')
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // ... you will write your Prisma Client queries here
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Here's a quick overview of the different parts of the code snippet:
+
+1. Import `PrismaClient` from the `output` directory specified in the `prisma init` command.
+1. Instantiate `PrismaClient`
+1. Define an `async` function named `main` to send queries to the database
+1. Call the `main` function
+1. Close the database connections when the script terminates
+
+Inside the `main` function, add the following query to read all `User` records from the database and print the result:
+
+
+```js file=index.js highlight=2;delete|3,4;add showLineNumbers
+async function main() {
+ //delete-next-line
+ // ... you will write your Prisma Client queries here
+ //add-start
+ const allUsers = await prisma.user.findMany()
+ console.log(allUsers)
+ //add-end
+}
+```
+
+Now run the code with this command:
+
+```terminal copy
+node index.js
+```
+
+This should print an empty array because there are no `User` records in the database yet:
+
+```json no-lines
+[]
+```
+
+## Write data into the database
+
+The `findMany` query you used in the previous section only _reads_ data from the database (although it was still empty). In this section, you'll learn how to write a query to _write_ new records into the `Post` and `User` tables.
+
+Adjust the `main` function to send a `create` query to the database:
+
+```js file=index.js highlight=2-21;add copy showLineNumbers
+async function main() {
+ //add-start
+ await prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ posts: {
+ create: { title: 'Hello World' },
+ },
+ profile: {
+ create: { bio: 'I like turtles' },
+ },
+ },
+ })
+
+ const allUsers = await prisma.user.findMany({
+ include: {
+ posts: true,
+ profile: true,
+ },
+ })
+ console.dir(allUsers, { depth: null })
+ //add-end
+}
+```
+
+This code creates a new `User` record together with new `Post` and `Profile` records using a [nested write](/orm/prisma-client/queries/relation-queries#nested-writes) query. The `User` record is connected to the two other ones via the `Post.author` ↔ `User.posts` and `Profile.user` ↔ `User.profile` [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) respectively.
+
+Notice that you're passing the [`include`](/orm/prisma-client/queries/select-fields#return-nested-objects-by-selecting-relation-fields) option to `findMany` which tells Prisma Client to include the `posts` and `profile` relations on the returned `User` objects.
+
+Run the code with this command:
+
+```terminal copy
+node index.js
+```
+
+The output should look similar to this:
+
+```js no-lines
+[
+ {
+ email: 'alice@prisma.io',
+ id: 1,
+ name: 'Alice',
+ posts: [
+ {
+ content: null,
+ createdAt: 2020-03-21T16:45:01.246Z,
+ updatedAt: 2020-03-21T16:45:01.246Z,
+ id: 1,
+ published: false,
+ title: 'Hello World',
+ authorId: 1,
+ }
+ ],
+ profile: {
+ bio: 'I like turtles',
+ id: 1,
+ userId: 1,
+ }
+ }
+]
+```
+
+The query added new records to the `User` and the `Post` tables:
+
+**User**
+
+| **id** | **email** | **name** |
+| :----- | :------------------ | :-------- |
+| `1` | `"alice@prisma.io"` | `"Alice"` |
+
+**Post**
+
+| **id** | **createdAt** | **updatedAt** | **title** | **content** | **published** | **authorId** |
+| :----- | :------------------------- | :------------------------: | :-------------- | :---------- | :------------ | :----------- |
+| `1` | `2020-03-21T16:45:01.246Z` | `2020-03-21T16:45:01.246Z` | `"Hello World"` | `null` | `false` | `1` |
+
+**Profile**
+
+| **id** | **bio** | **userId** |
+| :----- | :----------------- | :--------- |
+| `1` | `"I like turtles"` | `1` |
+
+> **Note**: The numbers in the `authorId` column on `Post` and `userId` column on `Profile` both reference the `id` column of the `User` table, meaning the `id` value `1` column therefore refers to the first (and only) `User` record in the database.
+
+Before moving on to the next section, you'll "publish" the `Post` record you just created using an `update` query. Adjust the `main` function as follows:
+
+```js file=index.js copy showLineNumbers
+async function main() {
+ const post = await prisma.post.update({
+ where: { id: 1 },
+ data: { published: true },
+ })
+ console.log(post)
+}
+```
+
+Now run the code using the same command as before:
+
+```terminal copy
+node index.js
+```
+
+You will see the following output:
+
+```js no-lines
+{
+ id: 1,
+ title: 'Hello World',
+ content: null,
+ published: true,
+ authorId: 1
+}
+```
+
+The `Post` record with an `id` of `1` now got updated in the database:
+
+**Post**
+
+| **id** | **title** | **content** | **published** | **authorId** |
+| :----- | :-------------- | :---------- | :------------ | :----------- |
+| `1` | `"Hello World"` | `null` | `true` | `1` |
+
+Fantastic, you just wrote new data into your database for the first time using Prisma Client 🚀
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-node-sqlserver.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-node-sqlserver.mdx
new file mode 100644
index 0000000000..1fe0350537
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-node-sqlserver.mdx
@@ -0,0 +1,205 @@
+---
+title: 'Querying the database using JavaScript and SQL Server'
+sidebar_label: 'Querying the database'
+metaTitle: 'Querying the database using JavaScript and SQL Server'
+metaDescription: 'Write data to and query the database using JavaScript and SQL Server'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-node-sqlserver
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/next-steps
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/querying-the-database-
+---
+
+## Write your first query with Prisma Client
+
+Now that you have generated [Prisma Client](/orm/prisma-client), you can start writing queries to read and write data in your database. For the purpose of this guide, you'll use a plain Node.js script to explore some basic features of Prisma Client.
+
+Create a new file named `index.js` and add the following code to it:
+
+```js file=index.js copy showLineNumbers
+const { PrismaClient } = require('./generated/prisma')
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // ... you will write your Prisma Client queries here
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Here's a quick overview of the different parts of the code snippet:
+
+1. Import the `PrismaClient` constructor from the `@prisma/client` node module
+1. Instantiate `PrismaClient`
+1. Define an `async` function named `main` to send queries to the database
+1. Call the `main` function
+1. Close the database connections when the script terminates
+
+Inside the `main` function, add the following query to read all `User` records from the database and print the result:
+
+```js file=index.js highlight=2;delete|3,4;add showLineNumbers
+async function main() {
+ //delete-next-line
+ // ... you will write your Prisma Client queries here
+ //add-start
+ const allUsers = await prisma.user.findMany()
+ console.log(allUsers)
+ //add-end
+}
+```
+
+Now run the code with this command:
+
+```terminal copy
+node index.js
+```
+
+This should print an empty array because there are no `User` records in the database yet:
+
+```json no-lines
+[]
+```
+
+## Write data into the database
+
+The `findMany` query you used in the previous section only _reads_ data from the database (although it was still empty). In this section, you'll learn how to write a query to _write_ new records into the `Post` and `User` tables.
+
+Adjust the `main` function to send a `create` query to the database:
+
+```js file=index.js highlight=2-21;add copy showLineNumbers
+async function main() {
+ //add-start
+ await prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ posts: {
+ create: { title: 'Hello World' },
+ },
+ profile: {
+ create: { bio: 'I like turtles' },
+ },
+ },
+ })
+
+ const allUsers = await prisma.user.findMany({
+ include: {
+ posts: true,
+ profile: true,
+ },
+ })
+ console.dir(allUsers, { depth: null })
+ //add-end
+}
+```
+
+This code creates a new `User` record together with new `Post` and `Profile` records using a [nested write](/orm/prisma-client/queries/relation-queries#nested-writes) query. The `User` record is connected to the two other ones via the `Post.author` ↔ `User.posts` and `Profile.user` ↔ `User.profile` [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) respectively.
+
+Notice that you're passing the [`include`](/orm/prisma-client/queries/select-fields#return-nested-objects-by-selecting-relation-fields) option to `findMany` which tells Prisma Client to include the `posts` and `profile` relations on the returned `User` objects.
+
+Run the code with this command:
+
+```terminal copy
+node index.js
+```
+
+The output should look similar to this:
+
+```js no-lines
+[
+ {
+ email: 'alice@prisma.io',
+ id: 1,
+ name: 'Alice',
+ posts: [
+ {
+ content: null,
+ createdAt: 2020-03-21T16:45:01.246Z,
+ updatedAt: 2020-03-21T16:45:01.246Z,
+ id: 1,
+ published: false,
+ title: 'Hello World',
+ authorId: 1,
+ }
+ ],
+ profile: {
+ bio: 'I like turtles',
+ id: 1,
+ userId: 1,
+ }
+ }
+]
+```
+
+The query added new records to the `User` and the `Post` tables:
+
+**User**
+
+| **id** | **email** | **name** |
+| :----- | :------------------ | :-------- |
+| `1` | `"alice@prisma.io"` | `"Alice"` |
+
+**Post**
+
+| **id** | **createdAt** | **updatedAt** | **title** | **content** | **published** | **authorId** |
+| :----- | :------------------------- | :------------------------: | :-------------- | :---------- | :------------ | :----------- |
+| `1` | `2020-03-21T16:45:01.246Z` | `2020-03-21T16:45:01.246Z` | `"Hello World"` | `null` | `false` | `1` |
+
+**Profile**
+
+| **id** | **bio** | **userId** |
+| :----- | :----------------- | :--------- |
+| `1` | `"I like turtles"` | `1` |
+
+> **Note**: The numbers in the `authorId` column on `Post` and `userId` column on `Profile` both reference the `id` column of the `User` table, meaning the `id` value `1` column therefore refers to the first (and only) `User` record in the database.
+
+Before moving on to the next section, you'll "publish" the `Post` record you just created using an `update` query. Adjust the `main` function as follows:
+
+```js file=index.js copy showLineNumbers
+async function main() {
+ const post = await prisma.post.update({
+ where: { id: 1 },
+ data: { published: true },
+ })
+ console.log(post)
+}
+```
+
+Now run the code using the same command as before:
+
+```terminal copy
+node index.js
+```
+
+You will see the following output:
+
+```js no-lines
+{
+ id: 1,
+ title: 'Hello World',
+ content: null,
+ published: true,
+ authorId: 1
+}
+```
+
+The `Post` record with an `id` of `1` now got updated in the database:
+
+**Post**
+
+| **id** | **title** | **content** | **published** | **authorId** |
+| :----- | :-------------- | :---------- | :------------ | :----------- |
+| `1` | `"Hello World"` | `null` | `true` | `1` |
+
+Fantastic, you just wrote new data into your database for the first time using Prisma Client 🚀
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-typescript-cockroachdb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-typescript-cockroachdb.mdx
new file mode 100644
index 0000000000..381a3319f1
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-typescript-cockroachdb.mdx
@@ -0,0 +1,220 @@
+---
+title: 'Querying the database using TypeScript and CockroachDB'
+sidebar_label: 'Querying the database'
+metaTitle: 'Querying the database using TypeScript and CockroachDB'
+metaDescription: 'Write data to and query the database using TypeScript and CockroachDB'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-typescript-cockroachdb
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/next-steps
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/querying-the-database-
+---
+
+## Write your first query with Prisma Client
+
+Now that you have generated [Prisma Client](/orm/prisma-client), you can start writing queries to read and write data in your database. For the purpose of this guide, you'll use a plain Node.js script to explore some basic features of Prisma Client.
+
+Create a new file named `index.ts` and add the following code to it:
+
+```js file=index.ts copy showLineNumbers
+import { PrismaClient } from './generated/prisma'
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // ... you will write your Prisma Client queries here
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Here's a quick overview of the different parts of the code snippet:
+
+1. Import the `PrismaClient` constructor from the `@prisma/client` node module
+1. Instantiate `PrismaClient`
+1. Define an `async` function named `main` to send queries to the database
+1. Call the `main` function
+1. Close the database connections when the script terminates
+
+Inside the `main` function, add the following query to read all `User` records from the database and print the result:
+
+```ts file=index.ts highlight=3,4;add showLineNumbers
+async function main() {
+ // ... you will write your Prisma Client queries here
+ //add-start
+ const allUsers = await prisma.user.findMany()
+ console.log(allUsers)
+ //add-end
+}
+```
+
+Now run the code with this command:
+
+```terminal copy
+npx tsx index.ts
+```
+
+This should print an empty array because there are no `User` records in the database yet:
+
+```json no-lines
+[]
+```
+
+## Write data into the database
+
+The `findMany` query you used in the previous section only _reads_ data from the database (although it was still empty). In this section, you'll learn how to write a query to _write_ new records into the `Post` and `User` tables.
+
+Adjust the `main` function to send a `create` query to the database:
+
+```ts file=index.ts highlight=2-21;add copy showLineNumbers
+async function main() {
+ //add-start
+ await prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ posts: {
+ create: { title: 'Hello World' },
+ },
+ profile: {
+ create: { bio: 'I like turtles' },
+ },
+ },
+ })
+
+ const allUsers = await prisma.user.findMany({
+ include: {
+ posts: true,
+ profile: true,
+ },
+ })
+ console.dir(allUsers, { depth: null })
+ //add-end
+}
+```
+
+This code creates a new `User` record together with new `Post` and `Profile` records using a [nested write](/orm/prisma-client/queries/relation-queries#nested-writes) query. The `User` record is connected to the two other ones via the `Post.author` ↔ `User.posts` and `Profile.user` ↔ `User.profile` [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) respectively.
+
+Notice that you're passing the [`include`](/orm/prisma-client/queries/select-fields#return-nested-objects-by-selecting-relation-fields) option to `findMany` which tells Prisma Client to include the `posts` and `profile` relations on the returned `User` objects.
+
+Run the code with this command:
+
+```terminal copy
+npx tsx index.ts
+```
+
+The output should look similar to this:
+
+```js no-lines
+[
+ {
+ email: 'alice@prisma.io',
+ id: 1,
+ name: 'Alice',
+ posts: [
+ {
+ content: null,
+ createdAt: 2020-03-21T16:45:01.246Z,
+ updatedAt: 2020-03-21T16:45:01.246Z,
+ id: 1,
+ published: false,
+ title: 'Hello World',
+ authorId: 1,
+ }
+ ],
+ profile: {
+ bio: 'I like turtles',
+ id: 1,
+ userId: 1,
+ }
+ }
+]
+```
+
+Also note that `allUsers` is _statically typed_ thanks to [Prisma Client's generated types](/orm/prisma-client/type-safety/operating-against-partial-structures-of-model-types). You can observe the type by hovering over the `allUsers` variable in your editor. It should be typed as follows:
+
+```ts no-lines
+const allUsers: (User & {
+ posts: Post[]
+})[]
+
+export type Post = {
+ id: number
+ title: string
+ content: string | null
+ published: boolean
+ authorId: number | null
+}
+```
+
+The query added new records to the `User` and the `Post` tables:
+
+**User**
+
+| **id** | **email** | **name** |
+| :----- | :------------------ | :-------- |
+| `1` | `"alice@prisma.io"` | `"Alice"` |
+
+**Post**
+
+| **id** | **createdAt** | **updatedAt** | **title** | **content** | **published** | **authorId** |
+| :----- | :------------------------- | :------------------------: | :-------------- | :---------- | :------------ | :----------- |
+| `1` | `2020-03-21T16:45:01.246Z` | `2020-03-21T16:45:01.246Z` | `"Hello World"` | `null` | `false` | `1` |
+
+**Profile**
+
+| **id** | **bio** | **userId** |
+| :----- | :----------------- | :--------- |
+| `1` | `"I like turtles"` | `1` |
+
+> **Note**: The numbers in the `authorId` column on `Post` and `userId` column on `Profile` both reference the `id` column of the `User` table, meaning the `id` value `1` column therefore refers to the first (and only) `User` record in the database.
+
+Before moving on to the next section, you'll "publish" the `Post` record you just created using an `update` query. Adjust the `main` function as follows:
+
+```ts file=index.ts copy showLineNumbers
+async function main() {
+ const post = await prisma.post.update({
+ where: { id: 1 },
+ data: { published: true },
+ })
+ console.log(post)
+}
+```
+
+Now run the code using the same command as before:
+
+```terminal copy
+npx tsx index.ts
+```
+
+You will see the following output:
+
+```js no-lines
+{
+ id: 1,
+ title: 'Hello World',
+ content: null,
+ published: true,
+ authorId: 1
+}
+```
+
+The `Post` record with an `id` of `1` now got updated in the database:
+
+**Post**
+
+| **id** | **title** | **content** | **published** | **authorId** |
+| :----- | :-------------- | :---------- | :------------ | :----------- |
+| `1` | `"Hello World"` | `null` | `true` | `1` |
+
+Fantastic, you just wrote new data into your database for the first time using Prisma Client 🚀
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-typescript-mysql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-typescript-mysql.mdx
new file mode 100644
index 0000000000..ee929e9772
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-typescript-mysql.mdx
@@ -0,0 +1,220 @@
+---
+title: 'Querying the database using TypeScript and MySQL'
+sidebar_label: 'Querying the database'
+metaTitle: 'Querying the database using TypeScript and MySQL'
+metaDescription: 'Write data to and query the database using TypeScript and MySQL'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-typescript-mysql
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/next-steps
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/querying-the-database-
+---
+
+## Write your first query with Prisma Client
+
+Now that you have generated [Prisma Client](/orm/prisma-client), you can start writing queries to read and write data in your database. For the purpose of this guide, you'll use a plain Node.js script to explore some basic features of Prisma Client.
+
+Create a new file named `index.ts` and add the following code to it:
+
+```js file=index.ts copy showLineNumbers
+import { PrismaClient } from './generated/prisma'
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // ... you will write your Prisma Client queries here
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Here's a quick overview of the different parts of the code snippet:
+
+1. Import the `PrismaClient` constructor from the `@prisma/client` node module
+1. Instantiate `PrismaClient`
+1. Define an `async` function named `main` to send queries to the database
+1. Call the `main` function
+1. Close the database connections when the script terminates
+
+Inside the `main` function, add the following query to read all `User` records from the database and print the result:
+
+```ts file=index.ts highlight=3,4;add showLineNumbers
+async function main() {
+ // ... you will write your Prisma Client queries here
+ //add-start
+ const allUsers = await prisma.user.findMany()
+ console.log(allUsers)
+ //add-end
+}
+```
+
+Now run the code with this command:
+
+```terminal copy
+npx tsx index.ts
+```
+
+This should print an empty array because there are no `User` records in the database yet:
+
+```json no-lines
+[]
+```
+
+## Write data into the database
+
+The `findMany` query you used in the previous section only _reads_ data from the database (although it was still empty). In this section, you'll learn how to write a query to _write_ new records into the `Post` and `User` tables.
+
+Adjust the `main` function to send a `create` query to the database:
+
+```ts file=index.ts highlight=2-21;add copy showLineNumbers
+async function main() {
+ //add-start
+ await prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ posts: {
+ create: { title: 'Hello World' },
+ },
+ profile: {
+ create: { bio: 'I like turtles' },
+ },
+ },
+ })
+
+ const allUsers = await prisma.user.findMany({
+ include: {
+ posts: true,
+ profile: true,
+ },
+ })
+ console.dir(allUsers, { depth: null })
+ //add-end
+}
+```
+
+This code creates a new `User` record together with new `Post` and `Profile` records using a [nested write](/orm/prisma-client/queries/relation-queries#nested-writes) query. The `User` record is connected to the two other ones via the `Post.author` ↔ `User.posts` and `Profile.user` ↔ `User.profile` [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) respectively.
+
+Notice that you're passing the [`include`](/orm/prisma-client/queries/select-fields#return-nested-objects-by-selecting-relation-fields) option to `findMany` which tells Prisma Client to include the `posts` and `profile` relations on the returned `User` objects.
+
+Run the code with this command:
+
+```terminal copy
+npx tsx index.ts
+```
+
+The output should look similar to this:
+
+```js no-lines
+[
+ {
+ email: 'alice@prisma.io',
+ id: 1,
+ name: 'Alice',
+ posts: [
+ {
+ content: null,
+ createdAt: 2020-03-21T16:45:01.246Z,
+ updatedAt: 2020-03-21T16:45:01.246Z,
+ id: 1,
+ published: false,
+ title: 'Hello World',
+ authorId: 1,
+ }
+ ],
+ profile: {
+ bio: 'I like turtles',
+ id: 1,
+ userId: 1,
+ }
+ }
+]
+```
+
+Also note that `allUsers` is _statically typed_ thanks to [Prisma Client's generated types](/orm/prisma-client/type-safety/operating-against-partial-structures-of-model-types). You can observe the type by hovering over the `allUsers` variable in your editor. It should be typed as follows:
+
+```ts no-lines
+const allUsers: (User & {
+ posts: Post[]
+})[]
+
+export type Post = {
+ id: number
+ title: string
+ content: string | null
+ published: boolean
+ authorId: number | null
+}
+```
+
+The query added new records to the `User` and the `Post` tables:
+
+**User**
+
+| **id** | **email** | **name** |
+| :----- | :------------------ | :-------- |
+| `1` | `"alice@prisma.io"` | `"Alice"` |
+
+**Post**
+
+| **id** | **createdAt** | **updatedAt** | **title** | **content** | **published** | **authorId** |
+| :----- | :------------------------- | :------------------------: | :-------------- | :---------- | :------------ | :----------- |
+| `1` | `2020-03-21T16:45:01.246Z` | `2020-03-21T16:45:01.246Z` | `"Hello World"` | `null` | `false` | `1` |
+
+**Profile**
+
+| **id** | **bio** | **userId** |
+| :----- | :----------------- | :--------- |
+| `1` | `"I like turtles"` | `1` |
+
+> **Note**: The numbers in the `authorId` column on `Post` and `userId` column on `Profile` both reference the `id` column of the `User` table, meaning the `id` value `1` column therefore refers to the first (and only) `User` record in the database.
+
+Before moving on to the next section, you'll "publish" the `Post` record you just created using an `update` query. Adjust the `main` function as follows:
+
+```ts file=index.ts copy showLineNumbers
+async function main() {
+ const post = await prisma.post.update({
+ where: { id: 1 },
+ data: { published: true },
+ })
+ console.log(post)
+}
+```
+
+Now run the code using the same command as before:
+
+```terminal copy
+npx tsx index.ts
+```
+
+You will see the following output:
+
+```js no-lines
+{
+ id: 1,
+ title: 'Hello World',
+ content: null,
+ published: true,
+ authorId: 1
+}
+```
+
+The `Post` record with an `id` of `1` now got updated in the database:
+
+**Post**
+
+| **id** | **title** | **content** | **published** | **authorId** |
+| :----- | :-------------- | :---------- | :------------ | :----------- |
+| `1` | `"Hello World"` | `null` | `true` | `1` |
+
+Fantastic, you just wrote new data into your database for the first time using Prisma Client 🚀
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-typescript-planetscale.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-typescript-planetscale.mdx
new file mode 100644
index 0000000000..b28afc292d
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-typescript-planetscale.mdx
@@ -0,0 +1,221 @@
+---
+title: 'Querying the database using TypeScript and PlanetScale'
+sidebar_label: 'Querying the database'
+metaTitle: 'Querying the database using TypeScript and PlanetScale'
+metaDescription: 'Write data to and query the database using TypeScript and PlanetScale'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-typescript-planetscale
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/next-steps
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/querying-the-database-
+---
+
+## Write your first query with Prisma Client
+
+Now that you have generated [Prisma Client](/orm/prisma-client), you can start writing queries to read and write data in your database. For the purpose of this guide, you'll use a plain Node.js script to explore some basic features of Prisma Client.
+
+Create a new file named `index.ts` and add the following code to it:
+
+```js file=index.ts copy showLineNumbers
+import { PrismaClient } from './generated/prisma'
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // ... you will write your Prisma Client queries here
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Here's a quick overview of the different parts of the code snippet:
+
+1. Import the `PrismaClient` constructor from the `@prisma/client` node module
+1. Instantiate `PrismaClient`
+1. Define an `async` function named `main` to send queries to the database
+1. Call the `main` function
+1. Close the database connections when the script terminates
+
+Inside the `main` function, add the following query to read all `User` records from the database and print the result:
+
+```ts file=index.ts highlight=3,4;add showLineNumbers
+async function main() {
+ // ... you will write your Prisma Client queries here
+ //add-start
+ const allUsers = await prisma.user.findMany()
+ console.log(allUsers)
+ //add-end
+}
+```
+
+Now run the code with this command:
+
+```terminal copy
+npx tsx index.ts
+```
+
+This should print an empty array because there are no `User` records in the database yet:
+
+```json no-lines
+[]
+```
+
+## Write data into the database
+
+The `findMany` query you used in the previous section only _reads_ data from the database (although it was still empty). In this section, you'll learn how to write a query to _write_ new records into the `Post` and `User` tables.
+
+Adjust the `main` function to send a `create` query to the database:
+
+```ts file=index.ts highlight=2-21;add copy showLineNumbers
+async function main() {
+ //add-start
+ await prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ posts: {
+ create: { title: 'Hello World' },
+ },
+ profile: {
+ create: { bio: 'I like turtles' },
+ },
+ },
+ })
+
+ const allUsers = await prisma.user.findMany({
+ include: {
+ posts: true,
+ profile: true,
+ },
+ })
+ console.dir(allUsers, { depth: null })
+ //add-end
+}
+```
+
+This code creates a new `User` record together with new `Post` and `Profile` records using a [nested write](/orm/prisma-client/queries/relation-queries#nested-writes) query. The `User` record is connected to the two other ones via the `Post.author` ↔ `User.posts` and `Profile.user` ↔ `User.profile` [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) respectively.
+
+Notice that you're passing the [`include`](/orm/prisma-client/queries/select-fields#return-nested-objects-by-selecting-relation-fields) option to `findMany` which tells Prisma Client to include the `posts` and `profile` relations on the returned `User` objects.
+
+Run the code with this command:
+
+```terminal copy
+npx tsx index.ts
+```
+
+The output should look similar to this:
+
+```js no-lines
+[
+ {
+ email: 'alice@prisma.io',
+ id: 1,
+ name: 'Alice',
+ posts: [
+ {
+ content: null,
+ createdAt: 2020-03-21T16:45:01.246Z,
+ updatedAt: 2020-03-21T16:45:01.246Z,
+ id: 1,
+ published: false,
+ title: 'Hello World',
+ authorId: 1,
+ }
+ ],
+ profile: {
+ bio: 'I like turtles',
+ id: 1,
+ userId: 1,
+ }
+ }
+]
+```
+
+Also note that `allUsers` is _statically typed_ thanks to [Prisma Client's generated types](/orm/prisma-client/type-safety/operating-against-partial-structures-of-model-types). You can observe the type by hovering over the `allUsers` variable in your editor. It should be typed as follows:
+
+```ts no-lines
+const allUsers: (User & {
+ posts: Post[]
+})[]
+
+export type Post = {
+ id: number
+ title: string
+ content: string | null
+ published: boolean
+ authorId: number | null
+}
+```
+
+The query added new records to the `User` and the `Post` tables:
+
+**User**
+
+| **id** | **email** | **name** |
+| :----- | :------------------ | :-------- |
+| `1` | `"alice@prisma.io"` | `"Alice"` |
+
+**Post**
+
+| **id** | **createdAt** | **updatedAt** | **title** | **content** | **published** | **authorId** |
+| :----- | :------------------------- | :------------------------: | :-------------- | :---------- | :------------ | :----------- |
+| `1` | `2020-03-21T16:45:01.246Z` | `2020-03-21T16:45:01.246Z` | `"Hello World"` | `null` | `false` | `1` |
+
+**Profile**
+
+| **id** | **bio** | **userId** |
+| :----- | :----------------- | :--------- |
+| `1` | `"I like turtles"` | `1` |
+
+> **Note**: The numbers in the `authorId` column on `Post` and `userId` column on `Profile` both reference the `id` column of the `User` table, meaning the `id` value `1` column therefore refers to the first (and only) `User` record in the database.
+
+Before moving on to the next section, you'll "publish" the `Post` record you just created using an `update` query. Adjust the `main` function as follows:
+
+```ts file=index.ts copy showLineNumbers
+async function main() {
+ const post = await prisma.post.update({
+ where: { id: 1 },
+ data: { published: true },
+ })
+ console.log(post)
+}
+```
+
+Now run the code using the same command as before:
+
+```terminal copy
+npx tsx index.ts
+```
+
+You will see the following output:
+
+```js no-lines
+{
+ id: 1,
+ title: 'Hello World',
+ content: null,
+ published: true,
+ authorId: 1
+}
+```
+
+The `Post` record with an `id` of `1` now got updated in the database:
+
+**Post**
+
+| **id** | **title** | **content** | **published** | **authorId** |
+| :----- | :-------------- | :---------- | :------------ | :----------- |
+| `1` | `"Hello World"` | `null` | `true` | `1` |
+
+Fantastic, you just wrote new data into your database for the first time using Prisma Client 🚀
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-typescript-postgresql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-typescript-postgresql.mdx
new file mode 100644
index 0000000000..2765dd3411
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-typescript-postgresql.mdx
@@ -0,0 +1,219 @@
+---
+title: 'Querying the database using TypeScript and PostgreSQL'
+sidebar_label: 'Querying the database'
+metaTitle: 'Querying the database using TypeScript and PostgreSQL'
+metaDescription: 'Write data to and query the database using TypeScript and PostgreSQL'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-typescript-postgresql
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/next-steps
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/querying-the-database-
+---
+
+## Write your first query with Prisma Client
+
+Now that you have generated [Prisma Client](/orm/prisma-client), you can start writing queries to read and write data in your database. For the purpose of this guide, you'll use a plain Node.js script to explore some basic features of Prisma Client.
+
+Create a new file named `index.ts` and add the following code to it:
+
+```js file=index.ts copy showLineNumbers
+import { PrismaClient } from './generated/prisma'
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // ... you will write your Prisma Client queries here
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Here's a quick overview of the different parts of the code snippet:
+
+1. Import PrismaClient from output folder specified in [`prisma init`](/getting-started/setup-prisma/start-from-scratch/relational-databases-typescript-prismaPostgres) command.
+1. Instantiate `PrismaClient`
+1. Define an `async` function named `main` to send queries to the database
+1. Call the `main` function
+1. Close the database connections when the script terminates
+
+Inside the `main` function, add the following query to read all `User` records from the database and print the result:
+
+```ts file=index.ts highlight=3,4;add showLineNumbers
+async function main() {
+ // ... you will write your Prisma Client queries here
+ //add-start
+ const allUsers = await prisma.user.findMany()
+ console.log(allUsers)
+ //add-end
+}
+```
+
+Now run the code with this command:
+
+```terminal copy
+npx tsx index.ts
+```
+
+This should print an empty array because there are no `User` records in the database yet:
+
+```json no-lines
+[]
+```
+
+## Write data into the database
+
+The `findMany` query you used in the previous section only _reads_ data from the database (although it was still empty). In this section, you'll learn how to write a query to _write_ new records into the `Post` and `User` tables.
+
+Adjust the `main` function to send a `create` query to the database:
+
+```ts file=index.ts highlight=2-21;add copy showLineNumbers
+async function main() {
+ //add-start
+ await prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ posts: {
+ create: { title: 'Hello World' },
+ },
+ profile: {
+ create: { bio: 'I like turtles' },
+ },
+ },
+ })
+
+ const allUsers = await prisma.user.findMany({
+ include: {
+ posts: true,
+ profile: true,
+ },
+ })
+ console.dir(allUsers, { depth: null })
+ //add-end
+}
+```
+
+This code creates a new `User` record together with new `Post` and `Profile` records using a [nested write](/orm/prisma-client/queries/relation-queries#nested-writes) query. The `User` record is connected to the two other ones via the `Post.author` ↔ `User.posts` and `Profile.user` ↔ `User.profile` [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) respectively.
+
+Notice that you're passing the [`include`](/orm/prisma-client/queries/select-fields#return-nested-objects-by-selecting-relation-fields) option to `findMany` which tells Prisma Client to include the `posts` and `profile` relations on the returned `User` objects.
+
+Run the code with this command:
+
+```terminal copy
+npx tsx index.ts
+```
+
+The output should look similar to this:
+
+```js no-lines
+[
+ {
+ email: 'alice@prisma.io',
+ id: 1,
+ name: 'Alice',
+ posts: [
+ {
+ content: null,
+ createdAt: 2020-03-21T16:45:01.246Z,
+ updatedAt: 2020-03-21T16:45:01.246Z,
+ id: 1,
+ published: false,
+ title: 'Hello World',
+ authorId: 1,
+ }
+ ],
+ profile: {
+ bio: 'I like turtles',
+ id: 1,
+ userId: 1,
+ }
+ }
+]
+```
+
+Also note that `allUsers` is _statically typed_ thanks to [Prisma Client's generated types](/orm/prisma-client/type-safety/operating-against-partial-structures-of-model-types). You can observe the type by hovering over the `allUsers` variable in your editor. It should be typed as follows:
+
+```ts no-lines
+const allUsers: (User & {
+ posts: Post[]
+})[]
+
+export type Post = {
+ id: number
+ title: string
+ content: string | null
+ published: boolean
+ authorId: number | null
+}
+```
+
+The query added new records to the `User` and the `Post` tables:
+
+**User**
+
+| **id** | **email** | **name** |
+| :----- | :------------------ | :-------- |
+| `1` | `"alice@prisma.io"` | `"Alice"` |
+
+**Post**
+
+| **id** | **createdAt** | **updatedAt** | **title** | **content** | **published** | **authorId** |
+| :----- | :------------------------- | :------------------------: | :-------------- | :---------- | :------------ | :----------- |
+| `1` | `2020-03-21T16:45:01.246Z` | `2020-03-21T16:45:01.246Z` | `"Hello World"` | `null` | `false` | `1` |
+
+**Profile**
+
+| **id** | **bio** | **userId** |
+| :----- | :----------------- | :--------- |
+| `1` | `"I like turtles"` | `1` |
+
+> **Note**: The numbers in the `authorId` column on `Post` and `userId` column on `Profile` both reference the `id` column of the `User` table, meaning the `id` value `1` column therefore refers to the first (and only) `User` record in the database.
+
+Before moving on to the next section, you'll "publish" the `Post` record you just created using an `update` query. Adjust the `main` function as follows:
+
+```ts file=index.ts copy showLineNumbers
+async function main() {
+ const post = await prisma.post.update({
+ where: { id: 1 },
+ data: { published: true },
+ })
+ console.log(post)
+}
+```
+
+Now run the code using the same command as before:
+
+```terminal copy
+npx tsx index.ts
+```
+
+You will see the following output:
+
+```js no-lines
+{
+ id: 1,
+ title: 'Hello World',
+ content: null,
+ published: true,
+ authorId: 1
+}
+```
+
+The `Post` record with an `id` of `1` now got updated in the database:
+
+**Post**
+
+| **id** | **title** | **content** | **published** | **authorId** |
+| :----- | :-------------- | :---------- | :------------ | :----------- |
+| `1` | `"Hello World"` | `null` | `true` | `1` |
+
+Fantastic, you just wrote new data into your database for the first time using Prisma Client 🚀
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-typescript-prismaPostgres.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-typescript-prismaPostgres.mdx
new file mode 100644
index 0000000000..cd0f4852f5
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-typescript-prismaPostgres.mdx
@@ -0,0 +1,243 @@
+---
+title: 'Querying the database using TypeScript and Prisma Postgres'
+sidebar_label: 'Querying the database'
+metaTitle: 'Querying the database using TypeScript and Prisma Postgres'
+metaDescription: 'Write data to and query the database using TypeScript and Prisma Postgres'
+langSwitcher: ['typescript']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-typescript-prismaPostgres
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/next-steps
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/querying-the-database-
+---
+
+## Write your first query with Prisma Client
+
+Now that you have generated [Prisma Client](/orm/prisma-client), you can start writing queries to read and write data in your database. For the purpose of this guide, you'll use a plain TypeScript script to explore some basic features of Prisma Client.
+
+Create a new file named `queries.ts` and add the following code to it:
+
+```js file=queries.ts copy
+// 1
+import { PrismaClient } from './generated/prisma'
+import { withAccelerate } from '@prisma/extension-accelerate'
+
+// 2
+const prisma = new PrismaClient()
+ .$extends(withAccelerate())
+
+// 3
+async function main() {
+ // ... you will write your Prisma Client queries here
+}
+
+// 4
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ // 5
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Here's a quick overview of the different parts of the code snippet:
+
+1. Import the `PrismaClient` constructor and the `withAccelerate` extension.
+1. Instantiate `PrismaClient` and add the Accelerate extension.
+1. Define an `async` function named `main` to send queries to the database.
+1. Call the `main` function.
+1. Close the database connections when the script terminates.
+
+Inside the `main` function, add the following query to read all `User` records from the database and log the result:
+
+```ts file=queries.ts
+async function main() {
+ //add-start
+ const allUsers = await prisma.user.findMany()
+ console.log(allUsers)
+ //add-end
+}
+```
+
+Now run the code with this command:
+
+```terminal copy
+npx tsx queries.ts
+```
+
+This should print an empty array because there are no `User` records in the database yet:
+
+```json no-lines
+[]
+```
+
+## Write data into the database
+
+The `findMany` query you used in the previous section only _reads_ data from the database (although it was still empty).
+
+In this section, you'll learn how to write a query to _write_ new records into the `Post`, `User` and `Profile` tables all at once.
+
+Adjust the `main` function by removing the code from before and adding the following:
+
+```ts file=queries.ts highlight=2-21;add copy
+async function main() {
+ //add-start
+ await prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ posts: {
+ create: { title: 'Hello World' },
+ },
+ profile: {
+ create: { bio: 'I like turtles' },
+ },
+ },
+ })
+
+ const allUsers = await prisma.user.findMany({
+ include: {
+ posts: true,
+ profile: true,
+ },
+ })
+ console.dir(allUsers, { depth: null })
+ //add-end
+}
+```
+
+This code creates a new `User` record together with new `Post` and `Profile` records using a [nested write](/orm/prisma-client/queries/relation-queries#nested-writes) query.
+
+The records are connected via the [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) that you defined in your Prisma schema.
+
+Notice that you're also passing the [`include`](/orm/prisma-client/queries/select-fields#return-nested-objects-by-selecting-relation-fields) option to `findMany` which tells Prisma Client to include the `posts` and `profile` relations on the returned `User` objects.
+
+Run the code with this command:
+
+```terminal copy
+npx tsx queries.ts
+```
+
+The output should look similar to this:
+
+```js no-copy showLineNumbers
+[
+ {
+ email: 'alice@prisma.io',
+ id: 1,
+ name: 'Alice',
+ posts: [
+ {
+ content: null,
+ createdAt: 2020-03-21T16:45:01.246Z,
+ updatedAt: 2020-03-21T16:45:01.246Z,
+ id: 1,
+ published: false,
+ title: 'Hello World',
+ authorId: 1,
+ }
+ ],
+ profile: {
+ bio: 'I like turtles',
+ id: 1,
+ userId: 1,
+ }
+ }
+]
+```
+
+Also note that the `allUsers` variable is _statically typed_ thanks to [Prisma Client's generated types](/orm/prisma-client/type-safety/operating-against-partial-structures-of-model-types). You can observe the type by hovering over the `allUsers` variable in your editor. It should be typed as follows:
+
+```ts no-copy showLineNumbers
+const allUsers: ({
+ posts: {
+ id: number;
+ createdAt: Date;
+ updatedAt: Date;
+ title: string;
+ content: string | null;
+ published: boolean;
+ authorId: number;
+ }[];
+ profile: {
+ id: number;
+ bio: string | null;
+ userId: number;
+ } | null;
+} & {
+ ...;
+})[]
+```
+
+
+Expand for a visual view of the records that have been created
+
+
+The query added new records to the `User`, `Post`, and `Profile` tables:
+
+**User**
+
+| **id** | **email** | **name** |
+| :----- | :------------------ | :-------- |
+| `1` | `"alice@prisma.io"` | `"Alice"` |
+
+**Post**
+
+| **id** | **createdAt** | **updatedAt** | **title** | **content** | **published** | **authorId** |
+| :----- | :------------------------- | :------------------------: | :-------------- | :---------- | :------------ | :----------- |
+| `1` | `2020-03-21T16:45:01.246Z` | `2020-03-21T16:45:01.246Z` | `"Hello World"` | `null` | `false` | `1` |
+
+**Profile**
+
+| **id** | **bio** | **userId** |
+| :----- | :----------------- | :--------- |
+| `1` | `"I like turtles"` | `1` |
+
+The numbers in the `authorId` column on `Post` and `userId` column on `Profile` both reference the `id` column of the `User` table, meaning the `id` value `1` column therefore refers to the first (and only) `User` record in the database.
+
+
+
+Before moving on to the next section, you'll "publish" the `Post` record you just created using an `update` query. Adjust the `main` function as follows:
+
+```ts file=queries.ts copy
+async function main() {
+ const post = await prisma.post.update({
+ where: { id: 1 },
+ data: { published: true },
+ })
+ console.log(post)
+}
+```
+
+Now run the code using the same command as before:
+
+```terminal copy
+npx tsx queries.ts
+```
+
+You will see the following output:
+
+```js no-lines
+{
+ id: 1,
+ title: 'Hello World',
+ content: null,
+ published: true,
+ authorId: 1
+}
+```
+
+The `Post` record with an `id` of `1` now got updated in the database:
+
+**Post**
+
+| **id** | **title** | **content** | **published** | **authorId** |
+| :----- | :-------------- | :---------- | :------------ | :----------- |
+| `1` | `"Hello World"` | `null` | `true` | `1` |
+
+Congratulations! You've now learned how to query a Prisma Postgres database with Prisma Client in your application. If you got lost along the way, want to learn about more queries or explore the caching feature of Prisma Accelerate, check out the comprehensive [Prisma starter template](https://github.com/prisma/prisma-examples/tree/latest/databases/prisma-postgres).
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-typescript-sqlserver.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-typescript-sqlserver.mdx
new file mode 100644
index 0000000000..3fd7f12046
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/250-querying-the-database-typescript-sqlserver.mdx
@@ -0,0 +1,222 @@
+---
+title: 'Querying the database using TypeScript and SQL Server'
+sidebar_label: 'Querying the database'
+metaTitle: 'Querying the database using TypeScript and SQL Server'
+metaDescription: 'Write data to and query the database using TypeScript and SQL Server'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb', 'prismaPostgres']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/start-from-scratch/relational-databases/install-prisma-client-typescript-sqlserver
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/next-steps
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/querying-the-database-
+---
+
+## Write your first query with Prisma Client
+
+Now that you have generated [Prisma Client](/orm/prisma-client), you can start writing queries to read and write data in your database. For the purpose of this guide, you'll use a plain Node.js script to explore some basic features of Prisma Client.
+
+Create a new file named `index.ts` and add the following code to it:
+
+```js file=index.ts copy showLineNumbers
+import { PrismaClient } from './generated/prisma'
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // ... you will write your Prisma Client queries here
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Here's a quick overview of the different parts of the code snippet:
+
+1. Import the `PrismaClient` constructor from the `@prisma/client` node module
+1. Instantiate `PrismaClient`
+1. Define an `async` function named `main` to send queries to the database
+1. Call the `main` function
+1. Close the database connections when the script terminates
+
+Inside the `main` function, add the following query to read all `User` records from the database and print the result:
+
+```ts file=index.ts highlight=3,4;add showLineNumbers
+async function main() {
+ // ... you will write your Prisma Client queries here
+ //add-start
+ const allUsers = await prisma.user.findMany()
+ console.log(allUsers)
+ //add-end
+}
+```
+
+Now run the code with this command:
+
+```terminal copy
+npx tsx index.ts
+```
+
+This should print an empty array because there are no `User` records in the database yet:
+
+```json no-lines
+[]
+```
+
+## Write data into the database
+
+The `findMany` query you used in the previous section only _reads_ data from the database (although it was still empty). In this section, you'll learn how to write a query to _write_ new records into the `Post` and `User` tables.
+
+Adjust the `main` function to send a `create` query to the database:
+
+```ts file=index.ts highlight=2-21;add copy showLineNumbers
+async function main() {
+ //add-start
+ await prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ posts: {
+ create: { title: 'Hello World' },
+ },
+ profile: {
+ create: { bio: 'I like turtles' },
+ },
+ },
+ })
+
+ const allUsers = await prisma.user.findMany({
+ include: {
+ posts: true,
+ profile: true,
+ },
+ })
+ console.dir(allUsers, { depth: null })
+ //add-end
+}
+```
+
+This code creates a new `User` record together with new `Post` and `Profile` records using a [nested write](/orm/prisma-client/queries/relation-queries#nested-writes) query. The `User` record is connected to the two other ones via the `Post.author` ↔ `User.posts` and `Profile.user` ↔ `User.profile` [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) respectively.
+
+Notice that you're passing the [`include`](/orm/prisma-client/queries/select-fields#return-nested-objects-by-selecting-relation-fields) option to `findMany` which tells Prisma Client to include the `posts` and `profile` relations on the returned `User` objects.
+
+Run the code with this command:
+
+```terminal copy
+npx tsx index.ts
+```
+
+The output should look similar to this:
+
+```js no-lines
+[
+ {
+ email: 'alice@prisma.io',
+ id: 1,
+ name: 'Alice',
+ posts: [
+ {
+ content: null,
+ createdAt: 2020-03-21T16:45:01.246Z,
+ updatedAt: 2020-03-21T16:45:01.246Z,
+ id: 1,
+ published: false,
+ title: 'Hello World',
+ authorId: 1,
+ }
+ ],
+ profile: {
+ bio: 'I like turtles',
+ id: 1,
+ userId: 1,
+ }
+ }
+]
+```
+
+Also note that `allUsers` is _statically typed_ thanks to [Prisma Client's generated types](/orm/prisma-client/type-safety/operating-against-partial-structures-of-model-types). You can observe the type by hovering over the `allUsers` variable in your editor. It should be typed as follows:
+
+```ts no-lines
+const allUsers: (User & {
+ posts: Post[]
+})[]
+
+export type Post = {
+ id: number
+ title: string
+ content: string | null
+ published: boolean
+ authorId: number | null
+}
+```
+
+The query added new records to the `User` and the `Post` tables:
+
+**User**
+
+| **id** | **email** | **name** |
+| :----- | :------------------ | :-------- |
+| `1` | `"alice@prisma.io"` | `"Alice"` |
+
+**Post**
+
+| **id** | **createdAt** | **updatedAt** | **title** | **content** | **published** | **authorId** |
+| :----- | :------------------------- | :------------------------: | :-------------- | :---------- | :------------ | :----------- |
+| `1` | `2020-03-21T16:45:01.246Z` | `2020-03-21T16:45:01.246Z` | `"Hello World"` | `null` | `false` | `1` |
+
+**Profile**
+
+| **id** | **bio** | **userId** |
+| :----- | :----------------- | :--------- |
+| `1` | `"I like turtles"` | `1` |
+
+> **Note**: The numbers in the `authorId` column on `Post` and `userId` column on `Profile` both reference the `id` column of the `User` table, meaning the `id` value `1` column therefore refers to the first (and only) `User` record in the database.
+
+Before moving on to the next section, you'll "publish" the `Post` record you just created using an `update` query. Adjust the `main` function as follows:
+
+```ts file=index.ts copy showLineNumbers
+async function main() {
+ const post = await prisma.post.update({
+ where: { id: 1 },
+ data: { published: true },
+ })
+ console.log(post)
+}
+```
+
+Now run the code using the same command as before:
+
+```terminal copy
+npx tsx index.ts
+```
+
+You will see the following output:
+
+```js no-lines
+{
+ id: 1,
+ title: 'Hello World',
+ content: null,
+ published: true,
+ authorId: 1
+}
+```
+
+The `Post` record with an `id` of `1` now got updated in the database:
+
+**Post**
+
+| **id** | **title** | **content** | **published** | **authorId** |
+| :----- | :-------------- | :---------- | :------------ | :----------- |
+| `1` | `"Hello World"` | `null` | `true` | `1` |
+
+Fantastic, you just wrote new data into your database for the first time using Prisma Client 🚀
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/300-next-steps.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/300-next-steps.mdx
new file mode 100644
index 0000000000..a8cae6ef57
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/300-next-steps.mdx
@@ -0,0 +1,100 @@
+---
+title: 'Next steps with Prisma ORM and your relational database'
+sidebar_label: 'Next steps'
+metaTitle: 'Next steps after setting up Prisma ORM with your relational database'
+metaDescription: 'Next steps to take now that you have successfully added Prisma ORM to your new TypeScript or JavaScript project'
+hide_table_of_contents: true
+---
+
+This section lists a number of potential next steps you can now take from here. Feel free to explore these or read the [Introduction](/orm/overview/introduction/what-is-prisma) page to get a high-level overview of Prisma ORM.
+
+### Continue exploring the Prisma Client API
+
+You can send a variety of queries with the Prisma Client API. Check out the [API reference](/orm/prisma-client) and use your existing database setup from this guide to try them out.
+
+:::tip
+
+You can use your editor's auto-completion feature to learn about the different API calls and the arguments it takes. Auto-completion is commonly invoked by hitting CTRL+SPACE on your keyboard.
+
+:::
+
+
+Expand for more Prisma Client API examples
+
+Here are a few suggestions for a number of more queries you can send with Prisma Client:
+
+**Filter all `Post` records that contain `"hello"`**
+
+```js
+const filteredPosts = await prisma.post.findMany({
+ where: {
+ OR: [{ title: { contains: 'hello' } }, { content: { contains: 'hello' } }],
+ },
+})
+```
+
+**Create a new `Post` record and connect it to an existing `User` record**
+
+```js
+const post = await prisma.post.create({
+ data: {
+ title: 'Join us for Prisma Day 2020',
+ author: {
+ connect: { email: 'alice@prisma.io' },
+ },
+ },
+})
+```
+
+**Use the fluent relations API to retrieve the `Post` records of a `User` by traversing the relations**
+
+```js
+const posts = await prisma.profile
+ .findUnique({
+ where: { id: 1 },
+ })
+ .user()
+ .posts()
+```
+
+**Delete a `User` record**
+
+```js
+const deletedUser = await prisma.user.delete({
+ where: { email: 'sarah@prisma.io' },
+})
+```
+
+
+
+### Build an app with Prisma ORM
+
+The Prisma blog features comprehensive tutorials about Prisma ORM, check out our latest ones:
+
+- [Build a fullstack app with Next.js](https://www.youtube.com/watch?v=QXxy8Uv1LnQ&ab_channel=ByteGrad)
+- [Build a fullstack app with Remix](https://www.prisma.io/blog/fullstack-remix-prisma-mongodb-1-7D0BfTXBmB6r) (5 parts, including videos)
+- [Build a REST API with NestJS](https://www.prisma.io/blog/nestjs-prisma-rest-api-7D056s1BmOL0)
+
+### Explore the data in Prisma Studio
+
+Prisma Studio is a visual editor for the data in your database. Run `npx prisma studio` in your terminal.
+
+If you are using [Prisma Postgres](https://www.prisma.io/postgres), you can also directly use Prisma Studio inside the [Console](https://console.prisma.io) by selecting the **Studio** tab in your project.
+
+### Get query insights and analytics with Prisma Optimize
+
+[Prisma Optimize](/optimize) helps you generate insights and provides recommendations that can help you make your database queries faster. [Try it out now!](/optimize/getting-started)
+
+Optimize aims to help developers of all skill levels write efficient database queries, reducing database load and making applications more responsive.
+
+### Try a Prisma ORM example
+
+The [`prisma-examples`](https://github.com/prisma/prisma-examples/) repository contains a number of ready-to-run examples:
+
+| Demo | Stack | Description |
+| :------------------------------------------------------------------------------------------------------------------ | :----------- | --------------------------------------------------------------------------------------------------- |
+| [`nextjs`](https://pris.ly/e/orm/nextjs) | Fullstack | Simple [Next.js](https://nextjs.org/) app |
+| [`nextjs-graphql`](https://pris.ly/e/ts/graphql-nextjs) | Fullstack | Simple [Next.js](https://nextjs.org/) app (React) with a GraphQL API |
+| [`graphql-nexus`](https://pris.ly/e/ts/graphql-nexus) | Backend only | GraphQL server based on [`@apollo/server`](https://www.apollographql.com/docs/apollo-server) |
+| [`express`](https://pris.ly/e/ts/rest-express) | Backend only | Simple REST API with Express.JS |
+| [`grpc`](https://pris.ly/e/ts/grpc) | Backend only | Simple gRPC API |
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/_install-prisma-client-partial.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/_install-prisma-client-partial.mdx
new file mode 100644
index 0000000000..2bf6ab6d15
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/110-relational-databases/_install-prisma-client-partial.mdx
@@ -0,0 +1,25 @@
+## Install and generate Prisma Client
+
+To get started with Prisma Client, first install the `@prisma/client` package:
+
+```terminal copy
+npm install @prisma/client
+```
+
+Then, run `prisma generate` which reads your Prisma schema and generates the Prisma Client.
+
+```terminal copy
+npx prisma generate
+```
+
+You can now import the `PrismaClient` constructor from the `@prisma/client` package to create an instance of Prisma Client to send queries to your database. You'll learn how to do that in the next section.
+
+:::note Good to know
+
+When you run `prisma generate`, you are actually creating code (TypeScript types, methods, queries, ...) that is tailored to _your_ Prisma schema file or files in the `prisma` directory. This means, that whenever you make changes to your Prisma schema file, you also need to update the Prisma Client. You can do this by running the `prisma generate` command.
+
+
+
+Whenever you update your Prisma schema, you will have to update your database schema using either `prisma migrate dev` or `prisma db push`. This will keep your database schema in sync with your Prisma schema. These commands will also run `prisma generate` under the hood to re-generate your Prisma Client.
+
+:::
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb-node-mongodb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb-node-mongodb.mdx
new file mode 100644
index 0000000000..13a23e4d08
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb-node-mongodb.mdx
@@ -0,0 +1,54 @@
+---
+title: 'Start from scratch with Prisma ORM using MongoDB and JavaScript'
+sidebar_label: 'MongoDB'
+metaTitle: 'Start from scratch with Prisma ORM using MongoDB and JavaScript (15 min)'
+metaDescription: 'Learn how to create a new Node.js project from scratch by connecting Prisma ORM to your MongoDB database and generating a Prisma Client for database access.'
+hide_table_of_contents: true
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['mongodb']
+sidebar_custom_props: { badge: '15 min' }
+sidebar_class_name: hidden-sidebar
+pagination_next: getting-started/setup-prisma/start-from-scratch/mongodb/connect-your-database-node-mongodb
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/mongodb-
+---
+
+Learn how to create a new Node.js or TypeScript project from scratch by connecting Prisma ORM to your MongoDB database and generating a Prisma Client for database access. The following tutorial introduces you to the [Prisma CLI](/orm/tools/prisma-cli) and [Prisma Client](/orm/prisma-client).
+
+## Prerequisites
+
+In order to successfully complete this guide, you need:
+
+- [Node.js](https://nodejs.org/en/) installed on your machine (see [system requirements](/orm/reference/system-requirements) for officially supported versions)
+- Access to a MongoDB 4.2+ server with a replica set deployment. We recommend using [MongoDB Atlas](https://www.mongodb.com/cloud/atlas).
+
+
+
+ The MongoDB database connector uses transactions to support nested writes. Transactions **require** a [replica set](https://www.mongodb.com/docs/manual/tutorial/deploy-replica-set/) deployment. The easiest way to deploy a replica set is with [Atlas](https://www.mongodb.com/docs/atlas/getting-started/). It's free to get started.
+
+
+
+Make sure you have your database [connection URL](/orm/reference/connection-urls) at hand. If you don't have a database server running and just want to explore Prisma ORM, check out the [Quickstart](/getting-started/quickstart-sqlite).
+
+> See [System requirements](/orm/reference/system-requirements) for exact version requirements.
+
+## Create project setup
+
+As a first step, create a project directory and navigate into it:
+
+```terminal copy
+mkdir hello-prisma
+cd hello-prisma
+```
+
+Next, initialize a Node.js project and add the Prisma CLI as a development dependency to it:
+
+```terminal copy
+npm init -y
+npm install prisma --save-dev
+```
+
+This creates a `package.json` with an initial setup for a Node.js app.
+
+import PrismaInitPartial from './_prisma-init-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb-typescript-mongodb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb-typescript-mongodb.mdx
new file mode 100644
index 0000000000..ed401e69f4
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb-typescript-mongodb.mdx
@@ -0,0 +1,59 @@
+---
+title: 'Start from scratch with Prisma ORM using MongoDB and TypeScript'
+sidebar_label: 'MongoDB'
+metaTitle: 'Start from scratch with Prisma ORM using MongoDB and TypeScript (15 min)'
+metaDescription: 'Learn how to create a new TypeScript project from scratch by connecting Prisma ORM to your MongoDB database and generating a Prisma Client for database access.'
+hide_table_of_contents: true
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['mongodb']
+sidebar_custom_props: { badge: '15 min' }
+pagination_next: getting-started/setup-prisma/start-from-scratch/mongodb/connect-your-database-typescript-mongodb
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/mongodb-
+---
+
+Learn how to create a new Node.js or TypeScript project from scratch by connecting Prisma ORM to your MongoDB database and generating a Prisma Client for database access. The following tutorial introduces you to the [Prisma CLI](/orm/tools/prisma-cli) and [Prisma Client](/orm/prisma-client).
+
+## Prerequisites
+
+In order to successfully complete this guide, you need:
+
+- [Node.js](https://nodejs.org/en/) installed on your machine (see [system requirements](/orm/reference/system-requirements) for officially supported versions)
+- Access to a MongoDB 4.2+ server with a replica set deployment. We recommend using [MongoDB Atlas](https://www.mongodb.com/cloud/atlas).
+
+
+
+ The MongoDB database connector uses transactions to support nested writes. Transactions **require** a [replica set](https://www.mongodb.com/docs/manual/tutorial/deploy-replica-set/) deployment. The easiest way to deploy a replica set is with [Atlas](https://www.mongodb.com/docs/atlas/getting-started/). It's free to get started.
+
+
+
+Make sure you have your database [connection URL](/orm/reference/connection-urls) at hand. If you don't have a database server running and just want to explore Prisma ORM, check out the [Quickstart](/getting-started/quickstart-sqlite).
+
+> See [System requirements](/orm/reference/system-requirements) for exact version requirements.
+
+## Create project setup
+
+As a first step, create a project directory and navigate into it:
+
+```terminal copy
+mkdir hello-prisma
+cd hello-prisma
+```
+
+Next, initialize a TypeScript project and add the Prisma CLI as a development dependency to it:
+
+```terminal copy
+npm init -y
+npm install prisma typescript tsx @types/node --save-dev
+```
+
+This creates a `package.json` with an initial setup for your TypeScript app.
+
+Next, initialize TypeScript:
+
+```terminal copy
+npx tsc --init
+```
+
+import PrismaInitPartial from './_prisma-init-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb/100-connect-your-database-node-mongodb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb/100-connect-your-database-node-mongodb.mdx
new file mode 100644
index 0000000000..c0af956fcc
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb/100-connect-your-database-node-mongodb.mdx
@@ -0,0 +1,55 @@
+---
+title: 'Connect your database using JavaScript and MongoDB'
+sidebar_label: 'Connect your database (MongoDB)'
+metaTitle: 'Connect your database using JavaScript and MongoDB'
+metaDescription: 'Connect your database to your project using JavaScript and MongoDB'
+langSwitcher: ['typescript', 'node']
+sidebar_class_name: hidden-sidebar
+dbSwitcher: ['mongodb']
+hide_table_of_contents: true
+toc: false
+pagination_prev: getting-started/setup-prisma/start-from-scratch/mongodb-node-mongodb
+pagination_next: getting-started/setup-prisma/start-from-scratch/mongodb/creating-the-prisma-schema-node-mongodb
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/mongodb/connect-your-database-
+---
+
+To connect your database, you need to set the `url` field of the `datasource` block in your Prisma schema to your database [connection URL](/orm/reference/connection-urls):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "mongodb"
+ url = env("DATABASE_URL")
+}
+```
+
+In this case, the `url` is [set via an environment variable](/orm/more/development-environment/environment-variables) which is defined in `.env` (the example uses a [MongoDB Atlas](https://www.mongodb.com/cloud/atlas) URL):
+
+```bash file=.env showLineNumbers
+DATABASE_URL="mongodb+srv://test:test@cluster0.ns1yp.mongodb.net/myFirstDatabase"
+```
+
+You now need to adjust the connection URL to point to your own database.
+
+The [format of the connection URL](/orm/reference/connection-urls) for your database depends on the database you use. For MongoDB, it looks as follows (the parts spelled all-uppercased are _placeholders_ for your specific connection details):
+
+```no-lines
+mongodb://USERNAME:PASSWORD@HOST:PORT/DATABASE
+```
+
+Here's a short explanation of each component:
+
+- `USERNAME`: The name of your database user
+- `PASSWORD`: The password for your database user
+- `HOST`: The host where a [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod/#mongodb-binary-bin.mongod) (or [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos/#mongodb-binary-bin.mongos)) instance is running
+- `PORT`: The port where your database server is running (typically `27017` for MongoDB)
+- `DATABASE`: The name of the database. Note that if you're using MongoDB Atlas, you need to manually append the database name to the connection URL because the environment link from MongoDB Atlas doesn't contain it.
+
+## Troubleshooting
+
+### `Error in connector: SCRAM failure: Authentication failed.`
+
+If you see the `Error in connector: SCRAM failure: Authentication failed.` error message, you can specify the source database for the authentication by [adding](https://github.com/prisma/prisma/discussions/9994#discussioncomment-1562283) `?authSource=admin` to the end of the connection string.
+
+### `Raw query failed. Error code 8000 (AtlasError): empty database name not allowed.`
+
+If you see the `Raw query failed. Code: unknown. Message: Kind: Command failed: Error code 8000 (AtlasError): empty database name not allowed.` error message, be sure to append the database name to the database URL. You can find more info in this [GitHub issue](https://github.com/prisma/docs/issues/5562).
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb/100-connect-your-database-typescript-mongodb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb/100-connect-your-database-typescript-mongodb.mdx
new file mode 100644
index 0000000000..82c326862a
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb/100-connect-your-database-typescript-mongodb.mdx
@@ -0,0 +1,53 @@
+---
+title: 'Connect your database using TypeScript and MongoDB'
+sidebar_label: 'Connect your database (MongoDB)'
+metaTitle: 'Connect your database using TypeScript and MongoDB'
+metaDescription: 'Connect your database to your project using TypeScript and MongoDB'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['mongodb']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/mongodb-typescript-mongodb
+pagination_next: getting-started/setup-prisma/start-from-scratch/mongodb/creating-the-prisma-schema-typescript-mongodb
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/mongodb/connect-your-database-
+---
+
+To connect your database, you need to set the `url` field of the `datasource` block in your Prisma schema to your database [connection URL](/orm/reference/connection-urls):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "mongodb"
+ url = env("DATABASE_URL")
+}
+```
+
+In this case, the `url` is [set via an environment variable](/orm/more/development-environment/environment-variables) which is defined in `.env` (the example uses a [MongoDB Atlas](https://www.mongodb.com/cloud/atlas) URL):
+
+```bash file=.env showLineNumbers
+DATABASE_URL="mongodb+srv://test:test@cluster0.ns1yp.mongodb.net/myFirstDatabase"
+```
+
+You now need to adjust the connection URL to point to your own database.
+
+The [format of the connection URL](/orm/reference/connection-urls) for your database depends on the database you use. For MongoDB, it looks as follows (the parts spelled all-uppercased are _placeholders_ for your specific connection details):
+
+```no-lines
+mongodb://USERNAME:PASSWORD@HOST:PORT/DATABASE
+```
+
+Here's a short explanation of each component:
+
+- `USERNAME`: The name of your database user
+- `PASSWORD`: The password for your database user
+- `HOST`: The host where a [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod/#mongodb-binary-bin.mongod) (or [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos/#mongodb-binary-bin.mongos)) instance is running
+- `PORT`: The port where your database server is running (typically `27017` for MongoDB)
+- `DATABASE`: The name of the database. Note that if you're using MongoDB Atlas, you need to manually append the database name to the connection URL because the environment link from MongoDB Atlas doesn't contain it.
+
+## Troubleshooting
+
+### `Error in connector: SCRAM failure: Authentication failed.`
+
+If you see the `Error in connector: SCRAM failure: Authentication failed.` error message, you can specify the source database for the authentication by [adding](https://github.com/prisma/prisma/discussions/9994#discussioncomment-1562283) `?authSource=admin` to the end of the connection string.
+
+### `Raw query failed. Error code 8000 (AtlasError): empty database name not allowed.`
+
+If you see the `Raw query failed. Code: unknown. Message: Kind: Command failed: Error code 8000 (AtlasError): empty database name not allowed.` error message, be sure to append the database name to the database URL. You can find more info in this [GitHub issue](https://github.com/prisma/docs/issues/5562).
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb/125-creating-the-prisma-schema-node-mongodb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb/125-creating-the-prisma-schema-node-mongodb.mdx
new file mode 100644
index 0000000000..a2bd0d3782
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb/125-creating-the-prisma-schema-node-mongodb.mdx
@@ -0,0 +1,68 @@
+---
+title: 'Creating the Prisma schema using JavaScript and MongoDB'
+sidebar_label: 'Creating the Prisma schema'
+metaTitle: 'Creating the Prisma schema using JavaScript and MongoDB'
+metaDescription: 'Update the Prisma schema for MongoDB with JavaScript'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['mongodb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/start-from-scratch/mongodb/connect-your-database-node-mongodb
+pagination_next: getting-started/setup-prisma/start-from-scratch/mongodb/install-prisma-client-node-mongodb
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/mongodb/creating-the-prisma-schema-
+---
+
+
+## Update the Prisma schema
+
+Open the `prisma/schema.prisma` file and replace the default contents with the following:
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "mongodb"
+ url = env("DATABASE_URL")
+}
+
+generator client {
+ provider = "prisma-client-js"
+}
+
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ slug String @unique
+ title String
+ body String
+ author User @relation(fields: [authorId], references: [id])
+ authorId String @db.ObjectId
+ comments Comment[]
+}
+
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ email String @unique
+ name String?
+ address Address?
+ posts Post[]
+}
+
+model Comment {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ comment String
+ post Post @relation(fields: [postId], references: [id])
+ postId String @db.ObjectId
+}
+
+// Address is an embedded document
+type Address {
+ street String
+ city String
+ state String
+ zip String
+}
+```
+
+There are also a number of subtle differences in how the schema is setup when compared to relational databases like PostgreSQL.
+
+For example, the underlying `ID` field name is always `_id` and must be mapped with `@map("_id")`.
+
+For more information check out the [MongoDB schema reference](/orm/reference/prisma-schema-reference#mongodb-2).
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb/125-creating-the-prisma-schema-typescript-mongodb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb/125-creating-the-prisma-schema-typescript-mongodb.mdx
new file mode 100644
index 0000000000..fc255f746b
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb/125-creating-the-prisma-schema-typescript-mongodb.mdx
@@ -0,0 +1,67 @@
+---
+title: 'Creating the Prisma schema using TypeScript and MongoDB'
+sidebar_label: 'Creating the Prisma schema'
+metaTitle: 'Creating the Prisma schema using TypeScript and MongoDB'
+metaDescription: 'Update the Prisma schema for MongoDB with TypeScript'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['mongodb']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/mongodb/connect-your-database-typescript-mongodb
+pagination_next: getting-started/setup-prisma/start-from-scratch/mongodb/install-prisma-client-typescript-mongodb
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/mongodb/creating-the-prisma-schema-
+---
+
+## Update the Prisma schema
+
+Open the `prisma/schema.prisma` file and replace the default contents with the following:
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "mongodb"
+ url = env("DATABASE_URL")
+}
+
+generator client {
+ provider = "prisma-client-js"
+}
+
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ slug String @unique
+ title String
+ body String
+ author User @relation(fields: [authorId], references: [id])
+ authorId String @db.ObjectId
+ comments Comment[]
+}
+
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ email String @unique
+ name String?
+ address Address?
+ posts Post[]
+}
+
+model Comment {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ comment String
+ post Post @relation(fields: [postId], references: [id])
+ postId String @db.ObjectId
+}
+
+// Address is an embedded document
+type Address {
+ street String
+ city String
+ state String
+ zip String
+}
+```
+
+There are also a number of subtle differences in how the schema is setup when compared to relational databases like PostgreSQL.
+
+For example, the underlying `ID` field name is always `_id` and must be mapped with `@map("_id")`.
+
+For more information check out the [MongoDB schema reference](/orm/reference/prisma-schema-reference#mongodb-2).
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb/200-install-prisma-client-node-mongodb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb/200-install-prisma-client-node-mongodb.mdx
new file mode 100644
index 0000000000..85dd430ade
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb/200-install-prisma-client-node-mongodb.mdx
@@ -0,0 +1,31 @@
+---
+title: 'Install Prisma Client (JavaScript and MongoDB)'
+sidebar_label: 'Install Prisma Client'
+metaTitle: 'Install Prisma Client: JavaScript and MongoDB'
+metaDescription: 'Install and generate Prisma Client in your project using JavaScript and MongoDB'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['mongodb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/start-from-scratch/mongodb/creating-the-prisma-schema-node-mongodb
+pagination_next: getting-started/setup-prisma/start-from-scratch/mongodb/querying-the-database-node-mongodb
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/mongodb/install-prisma-client-
+---
+
+## Install and generate Prisma Client
+
+To get started with Prisma Client, you need to install the `@prisma/client` package:
+
+```terminal copy
+npm install @prisma/client
+```
+
+Then, run `prisma generate` which reads your Prisma schema and generates the Prisma Client.
+
+```terminal copy
+npx prisma generate
+```
+
+
+
+Whenever you update your Prisma schema, you will need to run the `prisma db push` command to create new indexes and regenerate Prisma Client.
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb/200-install-prisma-client-typescript-mongodb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb/200-install-prisma-client-typescript-mongodb.mdx
new file mode 100644
index 0000000000..1d1217095c
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb/200-install-prisma-client-typescript-mongodb.mdx
@@ -0,0 +1,30 @@
+---
+title: 'Install Prisma Client (TypeScript and MongoDB)'
+sidebar_label: 'Install Prisma Client'
+metaTitle: 'Install Prisma Client: TypeScript and MongoDB'
+metaDescription: 'Install and generate Prisma Client in your project using TypeScript and MongoDB'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['mongodb']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/mongodb/creating-the-prisma-schema-typescript-mongodb
+pagination_next: getting-started/setup-prisma/start-from-scratch/mongodb/querying-the-database-typescript-mongodb
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/mongodb/install-prisma-client-
+---
+
+## Install and generate Prisma Client
+
+To get started with Prisma Client, you need to install the `@prisma/client` package:
+
+```terminal copy
+npm install @prisma/client
+```
+
+Then, run `prisma generate` which reads your Prisma schema and generates the Prisma Client.
+
+```terminal copy
+npx prisma generate
+```
+
+
+
+Whenever you update your Prisma schema, you will need to run the `prisma db push` command to create new indexes and regenerate Prisma Client.
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb/250-querying-the-database-node-mongodb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb/250-querying-the-database-node-mongodb.mdx
new file mode 100644
index 0000000000..3e3afcb5db
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb/250-querying-the-database-node-mongodb.mdx
@@ -0,0 +1,217 @@
+---
+title: 'Querying the database using JavaScript and MongoDB'
+sidebar_label: 'Querying the database'
+metaTitle: 'Querying the database with JavaScript and MongoDB'
+metaDescription: 'Write data to and query the database using JavaScript and MongoDB'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['mongodb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/start-from-scratch/mongodb/install-prisma-client-node-mongodb
+pagination_next: getting-started/setup-prisma/start-from-scratch/mongodb/next-steps
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/mongodb/querying-the-database-
+---
+
+## Write your first query with Prisma Client
+
+Now that you have generated Prisma Client, you can start writing queries to read and write data in your database. For the purpose of this guide, you'll use a plain Node.js script to explore some basic features of Prisma Client.
+
+Create a new file named `index.js` and add the following code to it:
+
+```js file=index.js copy showLineNumbers
+const { PrismaClient } = require('@prisma/client')
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // ... you will write your Prisma Client queries here
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Here's a quick overview of the different parts of the code snippet:
+
+1. Import the `PrismaClient` constructor from the `@prisma/client` node module
+1. Instantiate `PrismaClient`
+1. Define an `async` function named `main` to send queries to the database
+1. Connect to the database
+1. Call the `main` function
+1. Close the database connections when the script terminates
+
+Inside the `main` function, add the following query to read all `User` records from the database and print the result:
+
+```js file=index.js
+async function main() {
+ //delete-next-line
+- // ... you will write your Prisma Client queries here
+//add-start
++ const allUsers = await prisma.user.findMany()
++ console.log(allUsers)
+//add-end
+}
+```
+
+Now run the code with this command:
+
+```terminal copy
+node index.js
+```
+
+This should print an empty array because there are no `User` records in the database yet:
+
+```json no-lines
+[]
+```
+
+## Write data into the database
+
+The `findMany` query you used in the previous section only _reads_ data from the database (although it was still empty). In this section, you'll learn how to write a query to _write_ new records into the `Post`, `User` and `Comment` tables.
+
+Adjust the `main` function to send a `create` query to the database:
+
+```js file=index.js highlight=2-21;add copy showLineNumbers
+async function main() {
+ //add-start
+ await prisma.user.create({
+ data: {
+ name: 'Rich',
+ email: 'hello@prisma.com',
+ posts: {
+ create: {
+ title: 'My first post',
+ body: 'Lots of really interesting stuff',
+ slug: 'my-first-post',
+ },
+ },
+ },
+ })
+
+ const allUsers = await prisma.user.findMany({
+ include: {
+ posts: true,
+ },
+ })
+ console.dir(allUsers, { depth: null })
+ //add-end
+}
+```
+
+This code creates a new `User` record together with a new `Post` using a [nested write](/orm/prisma-client/queries/relation-queries#nested-writes) query. The `User` record is connected to the other one via the `Post.author` ↔ `User.posts` [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) respectively.
+
+Notice that you're passing the [`include`](/orm/prisma-client/queries/select-fields#return-nested-objects-by-selecting-relation-fields) option to `findMany` which tells Prisma Client to include the `posts` relations on the returned `User` objects.
+
+Run the code with this command:
+
+```terminal copy
+node index.js
+```
+
+The output should look similar to this:
+
+```json no-lines
+[
+ {
+ id: '60cc9b0e001e3bfd00a6eddf',
+ email: 'hello@prisma.com',
+ name: 'Rich',
+ address: null,
+ posts: [
+ {
+ id: '60cc9bad005059d6007f45dd',
+ slug: 'my-first-post',
+ title: 'My first post',
+ body: 'Lots of really interesting stuff',
+ userId: '60cc9b0e001e3bfd00a6eddf',
+ },
+ ],
+ },
+]
+```
+
+The query added new records to the `User` and the `Post` tables:
+
+**User**
+
+| **id** | **email** | **name** |
+| :------------------------- | :------------------- | :------- |
+| `60cc9b0e001e3bfd00a6eddf` | `"hello@prisma.com"` | `"Rich"` |
+
+**Post**
+
+| **id** | **createdAt** | **title** | **content** | **published** | **authorId** |
+| :------------------------- | :------------------------- | :---------------- | :--------------------------------- | :------------ | :------------------------- |
+| `60cc9bad005059d6007f45dd` | `2020-03-21T16:45:01.246Z` | `"My first post"` | `Lots of really interesting stuff` | `false` | `60cc9b0e001e3bfd00a6eddf` |
+
+> **Note**: The unique IDs in the `authorId` column on `Post` reference the `id` column of the `User` table, meaning the `id` value `60cc9b0e001e3bfd00a6eddf` column therefore refers to the first (and only) `User` record in the database.
+
+Before moving on to the next section, you'll add a couple of comments to the `Post` record you just created using an `update` query. Adjust the `main` function as follows:
+
+```js file=index.js copy showLineNumbers
+async function main() {
+ await prisma.post.update({
+ where: {
+ slug: 'my-first-post',
+ },
+ data: {
+ comments: {
+ createMany: {
+ data: [
+ { comment: 'Great post!' },
+ { comment: "Can't wait to read more!" },
+ ],
+ },
+ },
+ },
+ })
+ const posts = await prisma.post.findMany({
+ include: {
+ comments: true,
+ },
+ })
+
+ console.dir(posts, { depth: Infinity })
+}
+```
+
+Now run the code using the same command as before:
+
+```terminal copy
+node index.js
+```
+
+You will see the following output:
+
+```json no-lines
+[
+ {
+ id: '60cc9bad005059d6007f45dd',
+ slug: 'my-first-post',
+ title: 'My first post',
+ body: 'Lots of really interesting stuff',
+ userId: '60cc9b0e001e3bfd00a6eddf',
+ comments: [
+ {
+ id: '60cca420008a21d800578793',
+ postId: '60cca40300af8bf000f6ca99',
+ comment: 'Great post!',
+ },
+ {
+ id: '60cca420008a21d800578794',
+ postId: '60cca40300af8bf000f6ca99',
+ comment: "Can't wait to try this!",
+ },
+ ],
+ },
+]
+```
+
+Fantastic, you just wrote new data into your database for the first time using Prisma Client 🚀
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb/250-querying-the-database-typescript-mongodb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb/250-querying-the-database-typescript-mongodb.mdx
new file mode 100644
index 0000000000..d0e5efac14
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb/250-querying-the-database-typescript-mongodb.mdx
@@ -0,0 +1,230 @@
+---
+title: 'Querying the database using TypeScript and MongoDB'
+sidebar_label: 'Querying the database'
+metaTitle: 'Querying the database with TypeScript and MongoDB'
+metaDescription: 'Write data to and query the database using TypeScript and MongoDB'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['mongodb']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/start-from-scratch/mongodb/install-prisma-client-typescript-mongodb
+pagination_next: getting-started/setup-prisma/start-from-scratch/mongodb/next-steps
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/mongodb/querying-the-database-
+---
+
+## Write your first query with Prisma Client
+
+Now that you have generated Prisma Client, you can start writing queries to read and write data in your database. For the purpose of this guide, you'll use a plain Node.js script to explore some basic features of Prisma Client.
+
+Create a new file named `index.ts` and add the following code to it:
+
+```js file=index.ts copy showLineNumbers
+import { PrismaClient } from './generated/prisma'
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // ... you will write your Prisma Client queries here
+}
+
+main()
+ .catch(async (e) => {
+ console.error(e)
+ process.exit(1)
+ })
+ .finally(async () => {
+ await prisma.$disconnect()
+ })
+```
+
+Here's a quick overview of the different parts of the code snippet:
+
+1. Import the `PrismaClient` constructor from the `@prisma/client` node module
+1. Instantiate `PrismaClient`
+1. Define an `async` function named `main` to send queries to the database
+1. Connect to the database
+1. Call the `main` function
+1. Close the database connections when the script terminates
+
+Inside the `main` function, add the following query to read all `User` records from the database and print the result:
+
+```ts file=index.ts showLineNumbers
+async function main() {
+ // ... you will write your Prisma Client queries here
+//add-start
++ const allUsers = await prisma.user.findMany()
++ console.log(allUsers)
+//add-end
+}
+```
+
+Now run the code with this command:
+
+```terminal copy
+npx tsx index.ts
+```
+
+This should print an empty array because there are no `User` records in the database yet:
+
+```json no-lines
+[]
+```
+
+## Write data into the database
+
+The `findMany` query you used in the previous section only _reads_ data from the database (although it was still empty). In this section, you'll learn how to write a query to _write_ new records into the `Post`, `User` and `Comment` tables.
+
+Adjust the `main` function to send a `create` query to the database:
+
+```ts file=index.ts highlight=2-21;add copy showLineNumbers
+async function main() {
+ //add-start
+ await prisma.user.create({
+ data: {
+ name: 'Rich',
+ email: 'hello@prisma.com',
+ posts: {
+ create: {
+ title: 'My first post',
+ body: 'Lots of really interesting stuff',
+ slug: 'my-first-post',
+ },
+ },
+ },
+ })
+
+ const allUsers = await prisma.user.findMany({
+ include: {
+ posts: true,
+ },
+ })
+ console.dir(allUsers, { depth: null })
+ //add-end
+}
+```
+
+This code creates a new `User` record together with a new `Post` using a [nested write](/orm/prisma-client/queries/relation-queries#nested-writes) query. The `User` record is connected to the other one via the `Post.author` ↔ `User.posts` [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) respectively.
+
+Notice that you're passing the [`include`](/orm/prisma-client/queries/select-fields#return-nested-objects-by-selecting-relation-fields) option to `findMany` which tells Prisma Client to include the `posts` relations on the returned `User` objects.
+
+Run the code with this command:
+
+```terminal copy
+npx tsx index.ts
+```
+
+The output should look similar to this:
+
+```json no-lines
+[
+ {
+ id: '60cc9b0e001e3bfd00a6eddf',
+ email: 'hello@prisma.com',
+ name: 'Rich',
+ address: null,
+ posts: [
+ {
+ id: '60cc9bad005059d6007f45dd',
+ slug: 'my-first-post',
+ title: 'My first post',
+ body: 'Lots of really interesting stuff',
+ userId: '60cc9b0e001e3bfd00a6eddf',
+ },
+ ],
+ },
+]
+```
+
+Also note that `allUsers` is _statically typed_ thanks to [Prisma Client's generated types](/orm/prisma-client/type-safety/operating-against-partial-structures-of-model-types). You can observe the type by hovering over the `allUsers` variable in your editor. It should be typed as follows:
+
+```ts no-lines
+const allUsers: (User & {
+ posts: Post[]
+})[]
+
+export type Post = {
+ id: number
+ title: string
+ body: string | null
+ published: boolean
+ authorId: number | null
+}
+```
+
+The query added new records to the `User` and the `Post` tables:
+
+**User**
+
+| **id** | **email** | **name** |
+| :------------------------- | :------------------- | :------- |
+| `60cc9b0e001e3bfd00a6eddf` | `"hello@prisma.com"` | `"Rich"` |
+
+**Post**
+
+| **id** | **createdAt** | **title** | **content** | **published** | **authorId** |
+| :------------------------- | :------------------------- | :---------------- | :--------------------------------- | :------------ | :------------------------- |
+| `60cc9bad005059d6007f45dd` | `2020-03-21T16:45:01.246Z` | `"My first post"` | `Lots of really interesting stuff` | `false` | `60cc9b0e001e3bfd00a6eddf` |
+
+> **Note**: The unique IDs in the `authorId` column on `Post` reference the `id` column of the `User` table, meaning the `id` value `60cc9b0e001e3bfd00a6eddf` column therefore refers to the first (and only) `User` record in the database.
+
+Before moving on to the next section, you'll add a couple of comments to the `Post` record you just created using an `update` query. Adjust the `main` function as follows:
+
+```ts file=index.ts copy showLineNumbers
+async function main() {
+ await prisma.post.update({
+ where: {
+ slug: 'my-first-post',
+ },
+ data: {
+ comments: {
+ createMany: {
+ data: [
+ { comment: 'Great post!' },
+ { comment: "Can't wait to read more!" },
+ ],
+ },
+ },
+ },
+ })
+ const posts = await prisma.post.findMany({
+ include: {
+ comments: true,
+ },
+ })
+
+ console.dir(posts, { depth: Infinity })
+}
+```
+
+Now run the code using the same command as before:
+
+```terminal copy
+npx tsx index.ts
+```
+
+You will see the following output:
+
+```json no-lines
+[
+ {
+ id: '60cc9bad005059d6007f45dd',
+ slug: 'my-first-post',
+ title: 'My first post',
+ body: 'Lots of really interesting stuff',
+ userId: '60cc9b0e001e3bfd00a6eddf',
+ comments: [
+ {
+ id: '60cca420008a21d800578793',
+ postId: '60cca40300af8bf000f6ca99',
+ comment: 'Great post!',
+ },
+ {
+ id: '60cca420008a21d800578794',
+ postId: '60cca40300af8bf000f6ca99',
+ comment: "Can't wait to try this!",
+ },
+ ],
+ },
+]
+```
+
+Fantastic, you just wrote new data into your database for the first time using Prisma Client 🚀
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb/300-next-steps.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb/300-next-steps.mdx
new file mode 100644
index 0000000000..37b3d5384d
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/120-mongodb/300-next-steps.mdx
@@ -0,0 +1,94 @@
+---
+title: 'Next steps after setting up Prisma ORM with MongoDB'
+sidebar_label: 'Next steps'
+metaTitle: 'Next steps after setting up Prisma ORM with MongoDB'
+metaDescription: 'Next steps to take now that you have successfully added Prisma ORM to your new JavaScript or TypeScript project'
+hide_table_of_contents: true
+---
+
+This section lists a number of potential next steps you can now take from here. Feel free to explore these or read the [Introduction](/orm/overview/introduction/what-is-prisma) page to get a high-level overview of Prisma ORM.
+
+### Continue exploring the Prisma Client API
+
+You can send a variety of queries with the Prisma Client API. Check out the [API reference](/orm/prisma-client) and use your existing database setup from this guide to try them out.
+
+:::tip
+
+You can use your editor's auto-completion feature to learn about the different API calls and the arguments it takes. Auto-completion is commonly invoked by hitting CTRL+SPACE on your keyboard.
+
+:::
+
+
+Expand for more Prisma Client API examples
+
+Here are a few suggestions for a number of more queries you can send with Prisma Client:
+
+**Filter all `Post` records that contain `"hello"`**
+
+```js
+const filteredPosts = await prisma.post.findMany({
+ where: {
+ OR: [{ title: { contains: 'hello' } }, { body: { contains: 'hello' } }],
+ },
+})
+```
+
+**Create a new `Post` record and connect it to an existing `User` record**
+
+```js
+const post = await prisma.post.create({
+ data: {
+ title: 'Join us for Prisma Day 2020',
+ slug: 'prisma-day-2020',
+ body: 'A conference on modern application development and databases.',
+ user: {
+ connect: { email: 'hello@prisma.com' },
+ },
+ },
+})
+```
+
+**Use the fluent relations API to retrieve the `Post` records of a `User` by traversing the relations**
+
+```js
+const user = await prisma.comment
+ .findUnique({
+ where: { id: '60ff4e9500acc65700ebf470' },
+ })
+ .post()
+ .user()
+```
+
+**Delete a `User` record**
+
+```js
+const deletedUser = await prisma.user.delete({
+ where: { email: 'sarah@prisma.io' },
+})
+```
+
+
+
+### Build an app with Prisma ORM
+
+The Prisma blog features comprehensive tutorials about Prisma ORM, check out our latest ones:
+
+- [Build a fullstack app with Next.js](https://www.youtube.com/watch?v=QXxy8Uv1LnQ&ab_channel=ByteGrad)
+- [Build a fullstack app with Remix](https://www.prisma.io/blog/fullstack-remix-prisma-mongodb-1-7D0BfTXBmB6r) (5 parts, including videos)
+- [Build a REST API with NestJS](https://www.prisma.io/blog/nestjs-prisma-rest-api-7D056s1BmOL0)
+
+### Explore the data in Prisma Studio
+
+Prisma Studio is a visual editor for the data in your database. Run `npx prisma studio` in your terminal.
+
+### Try a Prisma ORM example
+
+The [`prisma-examples`](https://github.com/prisma/prisma-examples/) repository contains a number of ready-to-run examples:
+
+| Demo | Stack | Description |
+| :------------------------------------------------------------------------------------------------------------------ | :----------- | --------------------------------------------------------------------------------------------------- |
+| [`nextjs`](https://pris.ly/e/orm/nextjs) | Fullstack | Simple [Next.js](https://nextjs.org/) app |
+| [`nextjs-graphql`](https://pris.ly/e/ts/graphql-nextjs) | Fullstack | Simple [Next.js](https://nextjs.org/) app (React) with a GraphQL API |
+| [`graphql-nexus`](https://pris.ly/e/ts/graphql-nexus) | Backend only | GraphQL server based on [`@apollo/server`](https://www.apollographql.com/docs/apollo-server) |
+| [`express`](https://pris.ly/e/ts/rest-express) | Backend only | Simple REST API with Express.JS |
+| [`grpc`](https://pris.ly/e/ts/grpc) | Backend only | Simple gRPC API |
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/_prisma-init-partial.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/_prisma-init-partial.mdx
new file mode 100644
index 0000000000..a77182b411
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/_prisma-init-partial.mdx
@@ -0,0 +1,27 @@
+import CodeBlock from '@theme/CodeBlock';
+
+You can now invoke the Prisma CLI by prefixing it with `npx`:
+
+```terminal
+npx prisma
+```
+
+Next, set up your Prisma ORM project by creating your [Prisma Schema](/orm/prisma-schema) file with the following command:
+
+{`npx prisma init --datasource-provider ${props.datasource.toLowerCase()} --output ../generated/prisma`}
+
+This command does a few things:
+
+- Creates a new directory called `prisma` that contains a file called `schema.prisma`, which contains the Prisma Schema with your database connection variable and schema models.
+- Sets the `datasource` to {props.datasource} and the output to a custom location, respectively.
+- Creates the [`.env` file](/orm/more/development-environment/environment-variables) in the root directory of the project, which is used for defining environment variables (such as your database connection)
+
+Note that the default schema created by `prisma init` uses PostgreSQL as the `provider`. If you didn't specify a provider with the `datasource-provider` option, you need to edit the `datasource` block to use the {props.datasource.toLowerCase()} provider instead:
+
+
+{`datasource db {
+ //edit-next-line
+ provider = "${props.datasource.toLowerCase()}"
+ url = env("DATABASE_URL")
+}`}
+
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/index.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/index.mdx
new file mode 100644
index 0000000000..455593e360
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/100-start-from-scratch/index.mdx
@@ -0,0 +1,16 @@
+---
+title: 'Start from scratch'
+metaTitle: 'Start from scratch with Prisma ORM'
+metaDescription: 'Learn how to create a new Node.js or TypeScript project from scratch by connecting Prisma ORM to your database of choice and generating a Prisma Client for database access.'
+hide_table_of_contents: true
+---
+
+
+
+Start a fresh project from scratch with the following tutorials as they introduce you to the [Prisma CLI](/orm/tools/prisma-cli), [Prisma Client](/orm/prisma-client), and [Prisma Migrate](/orm/prisma-migrate).
+
+
+
+## In this section
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-node-cockroachdb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-node-cockroachdb.mdx
new file mode 100644
index 0000000000..8faa0c838f
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-node-cockroachdb.mdx
@@ -0,0 +1,57 @@
+---
+title: 'Add Prisma ORM to an existing project (JavaScript and CockroachDB)'
+sidebar_label: 'Relational databases'
+metaTitle: 'Add Prisma ORM to an existing project using JavaScript and CockroachDB (15 min)'
+metaDescription: 'Learn how to add Prisma ORM to an existing Node.js project by connecting it to your CockroachDB database and generating a Prisma Client for database access.'
+hide_table_of_contents: true
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_custom_props: { badge: '15 min' }
+sidebar_class_name: hidden-sidebar
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-node-cockroachdb
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases-
+---
+
+
+
+Learn how to add Prisma ORM to an existing Node.js or TypeScript project by connecting it to your database and generating a Prisma Client for database access. The following tutorial introduces you to the [Prisma CLI](/orm/tools/prisma-cli), [Prisma Client](/orm/prisma-client), and [Prisma Introspection](/orm/prisma-schema/introspection).
+
+
+
+:::tip
+
+If you're migrating to Prisma ORM from another ORM, see our [Migrate from TypeORM](/guides/migrate-from-typeorm) or [Migrate from Sequelize](/guides/migrate-from-sequelize) migration guides.
+
+:::
+
+## Prerequisites
+
+In order to successfully complete this guide, you need:
+
+- an existing Node.js project with a `package.json`
+- [Node.js](https://nodejs.org/en/) installed on your machine (see [system requirements](/orm/reference/system-requirements) for officially supported versions)
+- a [CockroachDB](https://www.cockroachlabs.com) database server running and a database with at least one table
+
+> See [System requirements](/orm/reference/system-requirements) for exact version requirements.
+
+Make sure you have your database [connection URL](/orm/reference/connection-urls) (that includes your authentication credentials) at hand! If you don't have a database server running and just want to explore Prisma ORM, check out the [Quickstart](/getting-started/quickstart-sqlite).
+
+## Set up Prisma ORM
+
+As a first step, navigate into your project directory that contains the `package.json` file.
+
+Next, add the Prisma CLI as a development dependency to your project:
+
+```terminal copy
+npm install prisma --save-dev
+```
+
+:::note
+
+If your project contains multiple directories with `package.json` files (e.g., `frontend`, `backend`, etc.), note that Prisma ORM is specifically designed for use in the API/backend layer. To set up Prisma, navigate to the appropriate backend directory containing the relevant `package.json` file and configure Prisma there.
+
+:::
+
+import PrismaInitPartial from './_prisma-init-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-node-mysql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-node-mysql.mdx
new file mode 100644
index 0000000000..27577e96cf
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-node-mysql.mdx
@@ -0,0 +1,58 @@
+---
+title: 'Add Prisma ORM to an existing JavaScript project (MySQL)'
+sidebar_label: 'Relational databases'
+metaTitle: 'Add Prisma ORM to an existing project using JavaScript and MySQL (15 min)'
+metaDescription: 'Learn how to add Prisma ORM to an existing Node.js project by connecting it to your MySQL database and generating a Prisma Client for database access.'
+hide_table_of_contents: true
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_custom_props: { badge: '15 min' }
+sidebar_class_name: hidden-sidebar
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-node-mysql
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases-
+---
+
+
+
+Learn how to add Prisma ORM to an existing Node.js or TypeScript project by connecting it to your database and generating a Prisma Client for database access. The following tutorial introduces you to the [Prisma CLI](/orm/tools/prisma-cli), [Prisma Client](/orm/prisma-client), and [Prisma Introspection](/orm/prisma-schema/introspection).
+
+
+
+:::tip
+
+If you're migrating to Prisma ORM from another ORM, see our [Migrate from TypeORM](/guides/migrate-from-typeorm) or [Migrate from Sequelize](/guides/migrate-from-sequelize) migration guides.
+
+:::
+
+## Prerequisites
+
+In order to successfully complete this guide, you need:
+
+- an existing Node.js project with a `package.json`
+- [Node.js](https://nodejs.org/en/) installed on your machine (see [system requirements](/orm/reference/system-requirements) for officially supported versions)
+- a [MySQL](https://www.mysql.com/) database server running and a database with at least one table
+
+
+> See [System requirements](/orm/reference/system-requirements) for exact version requirements.
+
+Make sure you have your database [connection URL](/orm/reference/connection-urls) (that includes your authentication credentials) at hand! If you don't have a database server running and just want to explore Prisma ORM, check out the [Quickstart](/getting-started/quickstart-sqlite).
+
+## Set up Prisma ORM
+
+As a first step, navigate into your project directory that contains the `package.json` file.
+
+Next, add the Prisma CLI as a development dependency to your project:
+
+```terminal copy
+npm install prisma --save-dev
+```
+
+:::note
+
+If your project contains multiple directories with `package.json` files (e.g., `frontend`, `backend`, etc.), note that Prisma ORM is specifically designed for use in the API/backend layer. To set up Prisma, navigate to the appropriate backend directory containing the relevant `package.json` file and configure Prisma there.
+
+:::
+
+import PrismaInitPartial from './_prisma-init-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-node-planetscale.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-node-planetscale.mdx
new file mode 100644
index 0000000000..d1f687604e
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-node-planetscale.mdx
@@ -0,0 +1,57 @@
+---
+title: 'Add Prisma ORM to an existing JavaScript project (PlanetScale)'
+sidebar_label: 'Relational databases'
+metaTitle: 'Add Prisma ORM to an existing project using JavaScript and PlanetScale (15 min)'
+metaDescription: 'Learn how to add Prisma ORM to an existing Node.js project by connecting it to your PlanetScale database and generating a Prisma Client for database access.'
+hide_table_of_contents: true
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_custom_props: { badge: '15 min' }
+sidebar_class_name: hidden-sidebar
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-node-planetscale
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases-
+---
+
+
+
+Learn how to add Prisma ORM to an existing Node.js or TypeScript project by connecting it to your database and generating a Prisma Client for database access. The following tutorial introduces you to the [Prisma CLI](/orm/tools/prisma-cli), [Prisma Client](/orm/prisma-client), and [Prisma Introspection](/orm/prisma-schema/introspection).
+
+
+
+:::tip
+
+If you're migrating to Prisma ORM from another ORM, see our [Migrate from TypeORM](/guides/migrate-from-typeorm) or [Migrate from Sequelize](/guides/migrate-from-sequelize) migration guides.
+
+:::
+
+## Prerequisites
+
+In order to successfully complete this guide, you need:
+
+- an existing Node.js project with a `package.json`
+- [Node.js](https://nodejs.org/en/) installed on your machine (see [system requirements](/orm/reference/system-requirements) for officially supported versions)
+- a [PlanetScale](https://planetscale.com/) database server running and a database with at least one table
+
+> See [System requirements](/orm/reference/system-requirements) for exact version requirements.
+
+Make sure you have your database [connection URL](/orm/reference/connection-urls) (that includes your authentication credentials) at hand! If you don't have a database server running and just want to explore Prisma ORM, check out the [Quickstart](/getting-started/quickstart-sqlite).
+
+## Set up Prisma ORM
+
+As a first step, navigate into your project directory that contains the `package.json` file.
+
+Next, add the Prisma CLI as a development dependency to your project:
+
+```terminal copy
+npm install prisma --save-dev
+```
+
+:::note
+
+If your project contains multiple directories with `package.json` files (e.g., `frontend`, `backend`, etc.), note that Prisma ORM is specifically designed for use in the API/backend layer. To set up Prisma, navigate to the appropriate backend directory containing the relevant `package.json` file and configure Prisma there.
+
+:::
+
+import PrismaInitPartial from './_prisma-init-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-node-postgresql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-node-postgresql.mdx
new file mode 100644
index 0000000000..73e178c8c5
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-node-postgresql.mdx
@@ -0,0 +1,58 @@
+---
+title: 'Add Prisma ORM to an existing JavaScript project (PostgreSQL)'
+sidebar_label: 'Relational databases'
+metaTitle: 'Add Prisma ORM to an existing project that using JavaScript and PostgreSQL(15 min)'
+metaDescription: 'Learn how to add Prisma ORM to an existing Node.js project by connecting it to your PostgreSQL database and generating a Prisma Client for database access.'
+hide_table_of_contents: true
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_custom_props: { badge: '15 min' }
+sidebar_class_name: hidden-sidebar
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-node-postgresql
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases-
+---
+
+
+
+
+Learn how to add Prisma ORM to an existing Node.js or TypeScript project by connecting it to your database and generating a Prisma Client for database access. The following tutorial introduces you to the [Prisma CLI](/orm/tools/prisma-cli), [Prisma Client](/orm/prisma-client), and [Prisma Introspection](/orm/prisma-schema/introspection).
+
+
+
+:::tip
+
+If you're migrating to Prisma ORM from another ORM, see our [Migrate from TypeORM](/guides/migrate-from-typeorm) or [Migrate from Sequelize](/guides/migrate-from-sequelize) migration guides.
+
+:::
+
+## Prerequisites
+
+In order to successfully complete this guide, you need:
+
+- an existing Node.js project with a `package.json`
+- [Node.js](https://nodejs.org/en/) installed on your machine (see [system requirements](/orm/reference/system-requirements) for officially supported versions)
+- a [PostgreSQL](https://www.postgresql.org/) database server running and a database with at least one table
+
+> See [System requirements](/orm/reference/system-requirements) for exact version requirements.
+
+Make sure you have your database [connection URL](/orm/reference/connection-urls) (that includes your authentication credentials) at hand! If you don't have a database server running and just want to explore Prisma ORM, check out the [Quickstart](/getting-started/quickstart-sqlite).
+
+## Set up Prisma ORM
+
+As a first step, navigate into your project directory that contains the `package.json` file.
+
+Next, add the Prisma CLI as a development dependency to your project:
+
+```terminal copy
+npm install prisma --save-dev
+```
+
+:::note
+
+If your project contains multiple directories with `package.json` files (e.g., `frontend`, `backend`, etc.), note that Prisma ORM is specifically designed for use in the API/backend layer. To set up Prisma, navigate to the appropriate backend directory containing the relevant `package.json` file and configure Prisma there.
+
+:::
+
+import PrismaInitPartial from './_prisma-init-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-node-sqlserver.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-node-sqlserver.mdx
new file mode 100644
index 0000000000..872be668d2
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-node-sqlserver.mdx
@@ -0,0 +1,58 @@
+---
+title: 'Add Prisma ORM to an existing project (JavaScript and SQL Server)'
+sidebar_label: 'Relational databases'
+metaTitle: 'Add Prisma to an existing project using JavaScript and SQL Server (15 min)'
+metaDescription: 'Learn how to add Prisma to an existing Node.js project by connecting it to your SQL Server database and generating a Prisma Client for database access.'
+hide_table_of_contents: true
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_custom_props: { badge: '15 min' }
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-node-sqlserver
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases-
+---
+
+
+
+Learn how to add Prisma ORM to an existing Node.js or TypeScript project by connecting it to your database and generating a Prisma Client for database access. The following tutorial introduces you to the [Prisma CLI](/orm/tools/prisma-cli), [Prisma Client](/orm/prisma-client), and [Prisma Introspection](/orm/prisma-schema/introspection).
+
+
+
+:::tip
+
+
+If you're migrating to Prisma ORM from another ORM, see our [Migrate from TypeORM](/guides/migrate-from-typeorm) or [Migrate from Sequelize](/guides/migrate-from-sequelize) migration guides.
+
+:::
+
+## Prerequisites
+
+In order to successfully complete this guide, you need:
+
+- [Node.js](https://nodejs.org/en/) installed on your machine (see [system requirements](/orm/reference/system-requirements) for officially supported versions)
+- A [Microsoft SQL Server](https://learn.microsoft.com/en-us/sql/?view=sql-server-ver16) database
+ - [Microsoft SQL Server on Linux for Docker](/orm/overview/databases/sql-server/sql-server-docker)
+ - [Microsoft SQL Server on Windows (local)](/orm/overview/databases/sql-server/sql-server-local)
+
+> See [System requirements](/orm/reference/system-requirements) for exact version requirements.
+
+Make sure you have your database [connection URL](/orm/reference/connection-urls) (that includes your authentication credentials) at hand! If you don't have a database server running and just want to explore Prisma ORM, check out the [Quickstart](/getting-started/quickstart-sqlite).
+
+## Set up Prisma ORM
+
+As a first step, navigate into your project directory that contains the `package.json` file.
+
+Next, add the Prisma CLI as a development dependency to your project:
+
+```terminal copy
+npm install prisma --save-dev
+```
+
+:::note
+
+If your project contains multiple directories with `package.json` files (e.g., `frontend`, `backend`, etc.), note that Prisma ORM is specifically designed for use in the API/backend layer. To set up Prisma, navigate to the appropriate backend directory containing the relevant `package.json` file and configure Prisma there.
+
+:::
+
+import PrismaInitPartial from './_prisma-init-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-typescript-cockroachdb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-typescript-cockroachdb.mdx
new file mode 100644
index 0000000000..adbdc5f8ae
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-typescript-cockroachdb.mdx
@@ -0,0 +1,58 @@
+---
+title: 'Add Prisma ORM to an existing project (TypeScript and CockroachDB)'
+sidebar_label: 'Relational databases'
+metaTitle: 'Add Prisma ORM to an existing project using TypeScript and CockroachDB (15 min)'
+metaDescription: 'Learn how to add Prisma ORM to an existing TypeScript project by connecting it to your CockroachDB database and generating a Prisma Client for database access.'
+hide_table_of_contents: true
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_custom_props: { badge: '15 min' }
+sidebar_class_name: hidden-sidebar
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-typescript-cockroachdb
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases-
+---
+
+
+
+
+Learn how to add Prisma ORM to an existing Node.js or TypeScript project by connecting it to your database and generating a Prisma Client for database access. The following tutorial introduces you to the [Prisma CLI](/orm/tools/prisma-cli), [Prisma Client](/orm/prisma-client), and [Prisma Introspection](/orm/prisma-schema/introspection).
+
+
+
+:::tip
+
+If you're migrating to Prisma ORM from another ORM, see our [Migrate from TypeORM](/guides/migrate-from-typeorm) or [Migrate from Sequelize](/guides/migrate-from-sequelize) migration guides.
+
+:::
+
+## Prerequisites
+
+In order to successfully complete this guide, you need:
+
+- an existing Node.js project with a `package.json`
+- [Node.js](https://nodejs.org/en/) installed on your machine (see [system requirements](/orm/reference/system-requirements) for officially supported versions)
+- a [CockroachDB](https://www.cockroachlabs.com) database server running and a database with at least one table
+
+> See [System requirements](/orm/reference/system-requirements) for exact version requirements.
+
+Make sure you have your database [connection URL](/orm/reference/connection-urls) (that includes your authentication credentials) at hand! If you don't have a database server running and just want to explore Prisma ORM, check out the [Quickstart](/getting-started/quickstart-sqlite).
+
+## Set up Prisma ORM
+
+As a first step, navigate into your project directory that contains the `package.json` file.
+
+Next, add the Prisma CLI as a development dependency to your project:
+
+```terminal copy
+npm install prisma --save-dev
+```
+
+:::note
+
+If your project contains multiple directories with `package.json` files (e.g., `frontend`, `backend`, etc.), note that Prisma ORM is specifically designed for use in the API/backend layer. To set up Prisma, navigate to the appropriate backend directory containing the relevant `package.json` file and configure Prisma there.
+
+:::
+
+import PrismaInitPartial from './_prisma-init-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-typescript-mysql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-typescript-mysql.mdx
new file mode 100644
index 0000000000..1c89468762
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-typescript-mysql.mdx
@@ -0,0 +1,47 @@
+---
+title: 'Add Prisma ORM to an existing project (TypeScript and MySQL)'
+sidebar_label: 'Relational databases'
+metaTitle: 'Integrate Prisma into a TypeScript Project with MySQL (15 min)'
+metaDescription: 'Step-by-step guide to connecting a MySQL database to an existing TypeScript project using Prisma and generating a Prisma Client.'
+hide_table_of_contents: true
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_custom_props: { badge: '15 min' }
+sidebar_class_name: hidden-sidebar
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-typescript-mysql
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases-
+---
+
+## Overview
+
+This guide walks you through integrating Prisma ORM into an existing Node.js or TypeScript project. You'll learn how to:
+
+- Connect Prisma to your MySQL database
+- Use the [Prisma CLI](/orm/tools/prisma-cli)
+- Generate a [Prisma Client](/orm/prisma-client) for database access
+- Introspect your existing database schema using [Prisma Introspection](/orm/prisma-schema/introspection)
+
+:::tip
+Migrating from another ORM? Check out our dedicated guides for [TypeORM](/guides/migrate-from-typeorm) and [Sequelize](/guides/migrate-from-sequelize).
+:::
+
+## Prerequisites
+
+Before you begin, ensure you have:
+
+- An existing Node.js project with a `package.json` file
+- [Node.js](https://nodejs.org/en/) installed (see [system requirements](/orm/reference/system-requirements))
+- A running [MySQL](https://www.mysql.com/) database with at least one table
+
+> 📌 You'll need your [database connection URL](/orm/reference/connection-urls), including credentials.
+
+> 💡 Don’t have a database yet? Try our [Quickstart guide](/getting-started/quickstart-sqlite) with SQLite to explore Prisma ORM.
+
+## Step 1: Set Up Prisma
+
+1. Open your terminal and navigate to the project directory containing your `package.json`.
+
+2. Install Prisma CLI as a development dependency:
+
+```bash
+npm install prisma --save-dev
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-typescript-planetscale.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-typescript-planetscale.mdx
new file mode 100644
index 0000000000..b25b8800ab
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-typescript-planetscale.mdx
@@ -0,0 +1,57 @@
+---
+title: 'Add Prisma ORM to an existing project (TypeScript and PlanetScale)'
+sidebar_label: 'Relational databases'
+metaTitle: 'Add Prisma ORM to an existing project using TypeScript and PlanetScale (15 min)'
+metaDescription: 'Learn how to add Prisma ORM to an existing TypeScript project by connecting it to your PlanetScale database and generating a Prisma Client for database access.'
+hide_table_of_contents: true
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_custom_props: { badge: '15 min' }
+sidebar_class_name: hidden-sidebar
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-typescript-planetscale
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases-
+---
+
+
+
+Learn how to add Prisma ORM to an existing Node.js or TypeScript project by connecting it to your database and generating a Prisma Client for database access. The following tutorial introduces you to the [Prisma CLI](/orm/tools/prisma-cli), [Prisma Client](/orm/prisma-client), and [Prisma Introspection](/orm/prisma-schema/introspection).
+
+
+
+:::tip
+
+If you're migrating to Prisma ORM from another ORM, see our [Migrate from TypeORM](/guides/migrate-from-typeorm) or [Migrate from Sequelize](/guides/migrate-from-sequelize) migration guides.
+
+:::
+
+## Prerequisites
+
+In order to successfully complete this guide, you need:
+
+- an existing Node.js project with a `package.json`
+- [Node.js](https://nodejs.org/en/) installed on your machine (see [system requirements](/orm/reference/system-requirements) for officially supported versions)
+- a [PlanetScale](https://planetscale.com/) database server running and a database with at least one table
+
+> See [System requirements](/orm/reference/system-requirements) for exact version requirements.
+
+Make sure you have your database [connection URL](/orm/reference/connection-urls) (that includes your authentication credentials) at hand! If you don't have a database server running and just want to explore Prisma ORM, check out the [Quickstart](/getting-started/quickstart-sqlite).
+
+## Set up Prisma ORM
+
+As a first step, navigate into your project directory that contains the `package.json` file.
+
+Next, add the Prisma CLI as a development dependency to your project:
+
+```terminal copy
+npm install prisma --save-dev
+```
+
+:::note
+
+If your project contains multiple directories with `package.json` files (e.g., `frontend`, `backend`, etc.), note that Prisma ORM is specifically designed for use in the API/backend layer. To set up Prisma, navigate to the appropriate backend directory containing the relevant `package.json` file and configure Prisma there.
+
+:::
+
+import PrismaInitPartial from './_prisma-init-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-typescript-postgresql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-typescript-postgresql.mdx
new file mode 100644
index 0000000000..1fd554d7e4
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-typescript-postgresql.mdx
@@ -0,0 +1,57 @@
+---
+title: 'Add Prisma ORM to an existing project (TypeScript and PostgreSQL)'
+sidebar_label: 'Relational databases'
+metaTitle: 'Add Prisma ORM to an existing project using TypeScript and PostgreSQL (15 min)'
+metaDescription: 'Learn how to add Prisma ORM to an existing TypeScript project by connecting it to your PostgreSQL database and generating a Prisma Client for database access.'
+hide_table_of_contents: true
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_custom_props: { badge: '15 min' }
+sidebar_class_name: hidden-sidebar
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-typescript-postgresql
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases-
+---
+
+
+
+Learn how to add Prisma ORM to an existing Node.js or TypeScript project by connecting it to your database and generating a Prisma Client for database access. The following tutorial introduces you to the [Prisma CLI](/orm/tools/prisma-cli), [Prisma Client](/orm/prisma-client), and [Prisma Introspection](/orm/prisma-schema/introspection).
+
+
+
+:::tip
+
+If you're migrating to Prisma ORM from another ORM, see our [Migrate from TypeORM](/guides/migrate-from-typeorm) or [Migrate from Sequelize](/guides/migrate-from-sequelize) migration guides.
+
+:::
+
+## Prerequisites
+
+In order to successfully complete this guide, you need:
+
+- an existing Node.js project with a `package.json`
+- [Node.js](https://nodejs.org/en/) installed on your machine (see [system requirements](/orm/reference/system-requirements) for officially supported versions)
+- a [PostgreSQL](https://www.postgresql.org/) database server running and a database with at least one table
+
+> See [System requirements](/orm/reference/system-requirements) for exact version requirements.
+
+Make sure you have your database [connection URL](/orm/reference/connection-urls) (that includes your authentication credentials) at hand! If you don't have a database server running and just want to explore Prisma ORM, check out the [Quickstart](/getting-started/quickstart-sqlite).
+
+## Set up Prisma ORM
+
+As a first step, navigate into your project directory that contains the `package.json` file.
+
+Next, add the Prisma CLI as a development dependency to your project:
+
+```terminal copy
+npm install prisma --save-dev
+```
+
+:::note
+
+If your project contains multiple directories with `package.json` files (e.g., `frontend`, `backend`, etc.), note that Prisma ORM is specifically designed for use in the API/backend layer. To set up Prisma, navigate to the appropriate backend directory containing the relevant `package.json` file and configure Prisma there.
+
+:::
+
+import PrismaInitPartial from './_prisma-init-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-typescript-sqlserver.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-typescript-sqlserver.mdx
new file mode 100644
index 0000000000..a563f5dccc
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases-typescript-sqlserver.mdx
@@ -0,0 +1,58 @@
+---
+title: 'Add Prisma ORM to an existing project (TypeScript and SQL Server)'
+sidebar_label: 'Relational databases'
+metaTitle: 'Add Prisma ORM to an existing project using TypeScript and SQL Server (15 min)'
+metaDescription: 'Learn how to add Prisma ORM to an existing TypeScript project by connecting it to your SQL Server database and generating a Prisma Client for database access.'
+hide_table_of_contents: true
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_custom_props: { badge: '15 min' }
+sidebar_class_name: hidden-sidebar
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-typescript-sqlserver
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases-
+---
+
+
+
+Learn how to add Prisma ORM to an existing Node.js or TypeScript project by connecting it to your database and generating a Prisma Client for database access. The following tutorial introduces you to the [Prisma CLI](/orm/tools/prisma-cli), [Prisma Client](/orm/prisma-client), and [Prisma Introspection](/orm/prisma-schema/introspection).
+
+
+
+:::tip
+
+If you're migrating to Prisma ORM from another ORM, see our [Migrate from TypeORM](/guides/migrate-from-typeorm) or [Migrate from Sequelize](/guides/migrate-from-sequelize) migration guides.
+
+:::
+
+## Prerequisites
+
+In order to successfully complete this guide, you need:
+
+- [Node.js](https://nodejs.org/en/) installed on your machine (see [system requirements](/orm/reference/system-requirements) for officially supported versions)
+- A [Microsoft SQL Server](https://learn.microsoft.com/en-us/sql/?view=sql-server-ver16) database
+ - [Microsoft SQL Server on Linux for Docker](/orm/overview/databases/sql-server/sql-server-docker)
+ - [Microsoft SQL Server on Windows (local)](/orm/overview/databases/sql-server/sql-server-local)
+
+> See [System requirements](/orm/reference/system-requirements) for exact version requirements.
+
+Make sure you have your database [connection URL](/orm/reference/connection-urls) (that includes your authentication credentials) at hand! If you don't have a database server running and just want to explore Prisma ORM, check out the [Quickstart](/getting-started/quickstart-sqlite).
+
+## Set up Prisma ORM
+
+As a first step, navigate into your project directory that contains the `package.json` file.
+
+Next, add the Prisma CLI as a development dependency to your project:
+
+```terminal copy
+npm install prisma --save-dev
+```
+
+:::note
+
+If your project contains multiple directories with `package.json` files (e.g., `frontend`, `backend`, etc.), note that Prisma ORM is specifically designed for use in the API/backend layer. To set up Prisma, navigate to the appropriate backend directory containing the relevant `package.json` file and configure Prisma there.
+
+:::
+
+import PrismaInitPartial from './_prisma-init-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-node-cockroachdb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-node-cockroachdb.mdx
new file mode 100644
index 0000000000..3ce1f6f2d0
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-node-cockroachdb.mdx
@@ -0,0 +1,59 @@
+---
+title: 'Connect your existing database using JavaScript and CockroachDB'
+sidebar_label: 'Connect your database'
+metaTitle: 'Connect your existing database using JavaScript and CockroachDB'
+metaDescription: 'Connect your database to your existing project using JavaScript and CockroachDB'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+toc: false
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases-node-cockroachdb
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-node-cockroachdb
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-
+---
+
+## Connecting your database
+
+To connect your database, you need to set the `url` field of the `datasource` block in your Prisma schema to your database [connection URL](/orm/reference/connection-urls):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+```
+
+The `url` is [set via an environment variable](/orm/more/development-environment/environment-variables) which is defined in `.env`. You now need to adjust the connection URL to point to your own database.
+
+
Connection URL
+
+The [format of the connection URL](/orm/reference/connection-urls) for your database depends on the database you use. CockroachDB uses the PostgreSQL connection URL format, which has the following structure (the parts spelled all-uppercased are _placeholders_ for your specific connection details):
+
+```no-lines
+postgresql://USER:PASSWORD@HOST:PORT/DATABASE?PARAMETERS
+```
+
+Here's a short explanation of each component:
+
+- `USER`: The name of your database user
+- `PASSWORD`: The password for your database user
+- `PORT`: The port where your database server is running. The default for CockroachDB is `26257`.
+- `DATABASE`: The name of the database
+- `PARAMETERS`: Any additional connection parameters. See the CockroachDB documentation [here](https://www.cockroachlabs.com/docs/stable/connection-parameters.html#additional-connection-parameters).
+
+For a [CockroachDB Serverless](https://www.cockroachlabs.com/docs/cockroachcloud/quickstart.html) or [Cockroach Dedicated](https://www.cockroachlabs.com/docs/cockroachcloud/quickstart-trial-cluster) database hosted on [CockroachDB Cloud](https://www.cockroachlabs.com/docs/cockroachcloud/quickstart/), the [connection URL](/orm/reference/connection-urls) looks similar to this:
+
+```bash file=.env
+DATABASE_URL="postgresql://:@..cockroachlabs.cloud:26257/defaultdb?sslmode=verify-full&sslrootcert=$HOME/.postgresql/root.crt&options=--"
+```
+
+To find your connection string on CockroachDB Cloud, click the 'Connect' button on the overview page for your database cluster, and select the 'Connection string' tab.
+
+For a [CockroachDB database hosted locally](https://www.cockroachlabs.com/docs/stable/secure-a-cluster.html), the [connection URL](/orm/reference/connection-urls) looks similar to this:
+
+```bash file=.env
+DATABASE_URL="postgresql://root@localhost:26257?sslmode=disable"
+```
+
+Your connection string is displayed as part of the welcome text when starting CockroachDB from the command line.
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-node-mysql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-node-mysql.mdx
new file mode 100644
index 0000000000..6f9b36cfb5
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-node-mysql.mdx
@@ -0,0 +1,60 @@
+---
+title: 'Connect your existing database using JavaScript and MySQL'
+sidebar_label: 'Connect your database'
+metaTitle: 'Connect your existing database using JavaScript and MySQL'
+metaDescription: 'Connect your database to your existing project using JavaScript and MySQL'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_class_name: hidden-sidebar
+hide_table_of_contents: true
+toc: false
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases-node-mysql
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-node-mysql
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-
+---
+
+## Connecting your database
+
+To connect your database, you need to set the `url` field of the `datasource` block in your Prisma schema to your database [connection URL](/orm/reference/connection-urls):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "mysql"
+ url = env("DATABASE_URL")
+}
+```
+
+In this case, the `url` is [set via an environment variable](/orm/prisma-schema/overview#accessing-environment-variables-from-the-schema) which is defined in `.env`:
+
+```bash file=.env
+DATABASE_URL="mysql://johndoe:randompassword@localhost:3306/mydb"
+```
+
+You now need to adjust the connection URL to point to your own database.
+
+
Connection URL
+
+The [format of the connection URL](/orm/reference/connection-urls) for your database typically depends on the database you use. For MySQL, it looks as follows (the parts spelled all-uppercased are _placeholders_ for your specific connection details):
+
+```no-lines
+mysql://USER:PASSWORD@HOST:PORT/DATABASE
+```
+
+Here's a short explanation of each component:
+
+- `USER`: The name of your database user
+- `PASSWORD`: The password for your database user
+- `PORT`: The port where your database server is running (typically `3306` for MySQL)
+- `DATABASE`: The name of the [database](https://dev.mysql.com/doc/refman/8.0/en/creating-database.html)
+
+As an example, for a MySQL database hosted on AWS RDS, the [connection URL](/orm/reference/connection-urls) might look similar to this:
+
+```bash file=.env
+DATABASE_URL="mysql://johndoe:XXX@mysql–instance1.123456789012.us-east-1.rds.amazonaws.com:3306/mydb"
+```
+
+When running MySQL locally, your connection URL typically looks similar to this:
+
+```bash file=.env
+DATABASE_URL="mysql://root:randompassword@localhost:3306/mydb"
+```
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-node-planetscale.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-node-planetscale.mdx
new file mode 100644
index 0000000000..5e59471d9b
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-node-planetscale.mdx
@@ -0,0 +1,89 @@
+---
+title: 'Connect your existing database using JavaScript and PlanetScale'
+sidebar_label: 'Connect your database'
+metaTitle: 'Connect your existing database using JavaScript and PlanetScale'
+metaDescription: 'Connect your database to your existing project using JavaScript and PlanetScale'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_class_name: hidden-sidebar
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases-node-planetscale
+pagination_next: getting-started/setup-prisma/start-from-scratch/relational-databases/using-prisma-migrate-node-planetscale
+slugSwitch: /getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-
+---
+
+To connect your database, you need to set the `url` field of the `datasource` block in your Prisma schema to your database [connection URL](/orm/reference/connection-urls):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+```
+
+You will also need to set the relation mode type to `prisma` in order to [emulate foreign key constraints](/orm/overview/databases/planetscale#option-1-emulate-relations-in-prisma-client) in the `datasource` block:
+
+```prisma file=schema.prisma highlight=4;add showLineNumbers
+datasource db {
+ provider = "mysql"
+ url = env("DATABASE_URL")
+ //add-next-line
+ relationMode = "prisma"
+}
+```
+
+> **Note**: Since February 2024, you can alternatively [use foreign key constraints on a database-level in PlanetScale](/orm/overview/databases/planetscale#option-2-enable-foreign-key-constraints-in-the-planetscale-database-settings), which omits the need for setting `relationMode = "prisma"`.
+
+The `url` is [set via an environment variable](/orm/prisma-schema/overview#accessing-environment-variables-from-the-schema) which is defined in `.env`:
+
+```bash file=.env
+DATABASE_URL="mysql://janedoe:mypassword@server.us-east-2.psdb.cloud/mydb?sslaccept=strict"
+```
+
+You now need to adjust the connection URL to point to your own database.
+
+The [format of the connection URL](/orm/reference/connection-urls) for your database typically depends on the database you use. PlanetScale uses the MySQL connection URL format, which has the following structure (the parts spelled all-uppercased are _placeholders_ for your specific connection details):
+
+```no-lines
+mysql://USER:PASSWORD@HOST:PORT/DATABASE
+```
+
+Here's a short explanation of each component:
+
+- `USER`: The name of your database user
+- `PASSWORD`: The password for your database user
+- `PORT`: The port where your database server is running (typically `3306` for MySQL)
+- `DATABASE`: The name of the [database](https://dev.mysql.com/doc/refman/8.0/en/creating-database.html)
+
+For a database hosted with PlanetScale, the [connection URL](/orm/reference/connection-urls) looks similar to this:
+
+```bash file=.env
+DATABASE_URL="mysql://myusername:mypassword@server.us-east-2.psdb.cloud/mydb?sslaccept=strict"
+```
+
+The connection URL for a given database branch can be found from your PlanetScale account by going to the overview page for the branch and selecting the 'Connect' dropdown. In the 'Passwords' section, generate a new password and select 'Prisma' to get the Prisma format for the connection URL.
+
+
+Alternative method: connecting using the PlanetScale CLI
+
+Alternatively, you can connect to your PlanetScale database server using the [PlanetScale CLI](https://planetscale.com/docs/concepts/planetscale-environment-setup), and use a local connection URL. In this case the connection URL will look like this:
+
+```bash file=.env
+DATABASE_URL="mysql://root@localhost:PORT/mydb"
+```
+
+
+
+We recommend adding `.env` to your `.gitignore` file to prevent committing your environment variables.
+
+
+
+To connect to your branch, use the following command:
+
+```terminal
+pscale connect prisma-test branchname --port PORT
+```
+
+The `--port` flag can be omitted if you are using the default port `3306`.
+
+
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-node-postgresql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-node-postgresql.mdx
new file mode 100644
index 0000000000..33a3055f80
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-node-postgresql.mdx
@@ -0,0 +1,57 @@
+---
+title: 'Connect your existing database using JavaScript and PostgreSQL'
+sidebar_label: 'Connect your database'
+metaTitle: 'Connect your existing database using JavaScript and PostgreSQL'
+metaDescription: 'Connect your database to your existing project using JavaScript and PostgreSQL'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_class_name: hidden-sidebar
+hide_table_of_contents: true
+toc: false
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases-node-postgresql
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-node-postgresql
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-
+---
+
+## Connecting your database
+
+To connect your database, you need to set the `url` field of the `datasource` block in your Prisma schema to your database [connection URL](/orm/reference/connection-urls):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+```
+
+In this case, the `url` is [set via an environment variable](/orm/more/development-environment/environment-variables) which is defined in `.env`:
+
+```bash file=.env
+DATABASE_URL="postgresql://johndoe:randompassword@localhost:5432/mydb?schema=public"
+```
+
+You now need to adjust the connection URL to point to your own database.
+
+
Connection URL
+
+The [format of the connection URL](/orm/reference/connection-urls) for your database depends on the database you use. For PostgreSQL, it looks as follows (the parts spelled all-uppercased are _placeholders_ for your specific connection details):
+
+```no-lines
+postgresql://USER:PASSWORD@HOST:PORT/DATABASE?schema=SCHEMA
+```
+
+> **Note**: In most cases, you can use the [`postgres://` and `postgresql:// URI scheme designators interchangeably`](https://www.postgresql.org/docs/10/libpq-connect.html#id-1.7.3.8.3.6) - however, depending on how your database is hosted, you might need to be specific.
+
+If you're unsure what to provide for the `schema` parameter for a PostgreSQL connection URL, you can probably omit it. In that case, the default schema name `public` will be used.
+
+As an example, for a PostgreSQL database hosted on Heroku, the connection URL might look similar to this:
+
+```bash file=.env
+DATABASE_URL="postgresql://opnmyfngbknppm:XXX@ec2-46-137-91-216.eu-west-1.compute.amazonaws.com:5432/d50rgmkqi2ipus?schema=hello-prisma"
+```
+
+When running PostgreSQL locally on macOS, your user and password as well as the database name _typically_ correspond to the current _user_ of your OS, e.g. assuming the user is called `janedoe`:
+
+```bash file=.env
+DATABASE_URL="postgresql://janedoe:janedoe@localhost:5432/janedoe?schema=hello-prisma"
+```
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-node-sqlserver.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-node-sqlserver.mdx
new file mode 100644
index 0000000000..57fa9a847d
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-node-sqlserver.mdx
@@ -0,0 +1,35 @@
+---
+title: 'Connect your existing database using JavaScript and SQL Server'
+sidebar_label: 'Connect your database'
+metaTitle: 'Connect your existing database using JavaScript and SQL Server'
+metaDescription: 'Connect your existing database to your project using JavaScript and SQL Server'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_class_name: hidden-sidebar
+hide_table_of_contents: true
+toc: false
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases-node-sqlserver
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-node-sqlserver
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-
+---
+
+## Connecting your database
+
+To connect your database, you need to set the `url` field of the `datasource` block in your Prisma schema to your database [connection URL](/orm/reference/connection-urls):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "sqlserver"
+ url = env("DATABASE_URL")
+}
+```
+
+The `url` is [set via an environment variable](/orm/prisma-schema/overview#accessing-environment-variables-from-the-schema), the following example connection URL [uses SQL authentication](/orm/overview/databases/sql-server), but there are [other ways to format your connection URL](/orm/overview/databases/sql-server)
+
+```bash file=.env
+DATABASE_URL="sqlserver://localhost:1433;database=mydb;user=sa;password=r@ndomP@$$w0rd;trustServerCertificate=true"
+```
+
+Adjust the connection URL to match your setup - see [Microsoft SQL Server connection URL](/orm/overview/databases/sql-server) for more information.
+
+> Make sure TCP/IP connections are enabled via [SQL Server Configuration Manager](https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-configuration-manager?view=sql-server-ver16&viewFallbackFrom=sql-server-ver16) to avoid `No connection could be made because the target machine actively refused it. (os error 10061)`
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-typescript-cockroachdb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-typescript-cockroachdb.mdx
new file mode 100644
index 0000000000..2a80965129
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-typescript-cockroachdb.mdx
@@ -0,0 +1,59 @@
+---
+title: 'Connect your existing database using TypeScript and CockroachDB'
+sidebar_label: 'Connect your database'
+metaTitle: 'Connect your existing database using TypeScript and CockroachDB'
+metaDescription: 'Connect your existing database to your project using TypeScript and CockroachDB'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_class_name: 'hidden-sidebar tech-switch'
+hide_table_of_contents: true
+toc: false
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases-typescript-cockroachdb
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-typescript-cockroachdb
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-
+---
+
+## Connecting your database
+
+To connect your database, you need to set the `url` field of the `datasource` block in your Prisma schema to your database [connection URL](/orm/reference/connection-urls):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+```
+
+The `url` is [set via an environment variable](/orm/more/development-environment/environment-variables) which is defined in `.env`. You now need to adjust the connection URL to point to your own database.
+
+
Connection URL
+
+The [format of the connection URL](/orm/reference/connection-urls) for your database depends on the database you use. CockroachDB uses the PostgreSQL connection URL format, which has the following structure (the parts spelled all-uppercased are _placeholders_ for your specific connection details):
+
+```no-lines
+postgresql://USER:PASSWORD@HOST:PORT/DATABASE?PARAMETERS
+```
+
+Here's a short explanation of each component:
+
+- `USER`: The name of your database user
+- `PASSWORD`: The password for your database user
+- `PORT`: The port where your database server is running. The default for CockroachDB is `26257`.
+- `DATABASE`: The name of the database
+- `PARAMETERS`: Any additional connection parameters. See the CockroachDB documentation [here](https://www.cockroachlabs.com/docs/stable/connection-parameters.html#additional-connection-parameters).
+
+For a [CockroachDB Serverless](https://www.cockroachlabs.com/docs/cockroachcloud/quickstart.html) or [Cockroach Dedicated](https://www.cockroachlabs.com/docs/cockroachcloud/quickstart-trial-cluster) database hosted on [CockroachDB Cloud](https://www.cockroachlabs.com/docs/cockroachcloud/quickstart/), the [connection URL](/orm/reference/connection-urls) looks similar to this:
+
+```bash file=.env
+DATABASE_URL="postgresql://:@..cockroachlabs.cloud:26257/defaultdb?sslmode=verify-full&sslrootcert=$HOME/.postgresql/root.crt&options=--"
+```
+
+To find your connection string on CockroachDB Cloud, click the 'Connect' button on the overview page for your database cluster, and select the 'Connection string' tab.
+
+For a [CockroachDB database hosted locally](https://www.cockroachlabs.com/docs/stable/secure-a-cluster.html), the [connection URL](/orm/reference/connection-urls) looks similar to this:
+
+```bash file=.env
+DATABASE_URL="postgresql://root@localhost:26257?sslmode=disable"
+```
+
+Your connection string is displayed as part of the welcome text when starting CockroachDB from the command line.
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-typescript-mysql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-typescript-mysql.mdx
new file mode 100644
index 0000000000..412a150be7
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-typescript-mysql.mdx
@@ -0,0 +1,60 @@
+---
+title: 'Connect your existing database using TypeScript and MySQL'
+sidebar_label: 'Connect your database'
+metaTitle: 'Connect your existing database using TypeScript and MySQL'
+metaDescription: 'Connect your existing database to your project using TypeScript and MySQL'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_class_name: hidden-sidebar
+hide_table_of_contents: true
+toc: false
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases-typescript-mysql
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-typescript-mysql
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-
+---
+
+## Connecting your database
+
+To connect your database, you need to set the `url` field of the `datasource` block in your Prisma schema to your database [connection URL](/orm/reference/connection-urls):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "mysql"
+ url = env("DATABASE_URL")
+}
+```
+
+In this case, the `url` is [set via an environment variable](/orm/prisma-schema/overview#accessing-environment-variables-from-the-schema) which is defined in `.env`:
+
+```bash file=.env
+DATABASE_URL="mysql://johndoe:randompassword@localhost:3306/mydb"
+```
+
+You now need to adjust the connection URL to point to your own database.
+
+
Connection URL
+
+The [format of the connection URL](/orm/reference/connection-urls) for your database typically depends on the database you use. For MySQL, it looks as follows (the parts spelled all-uppercased are _placeholders_ for your specific connection details):
+
+```no-lines
+mysql://USER:PASSWORD@HOST:PORT/DATABASE
+```
+
+Here's a short explanation of each component:
+
+- `USER`: The name of your database user
+- `PASSWORD`: The password for your database user
+- `PORT`: The port where your database server is running (typically `3306` for MySQL)
+- `DATABASE`: The name of the [database](https://dev.mysql.com/doc/refman/8.0/en/creating-database.html)
+
+As an example, for a MySQL database hosted on AWS RDS, the [connection URL](/orm/reference/connection-urls) might look similar to this:
+
+```bash file=.env
+DATABASE_URL="mysql://johndoe:XXX@mysql–instance1.123456789012.us-east-1.rds.amazonaws.com:3306/mydb"
+```
+
+When running MySQL locally, your connection URL typically looks similar to this:
+
+```bash file=.env
+DATABASE_URL="mysql://root:randompassword@localhost:3306/mydb"
+```
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-typescript-planetscale.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-typescript-planetscale.mdx
new file mode 100644
index 0000000000..3dfe674538
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-typescript-planetscale.mdx
@@ -0,0 +1,86 @@
+---
+title: 'Connect your existing database using TypeScript and PlanetScale'
+sidebar_label: 'Connect your database'
+metaTitle: 'Connect your existing database using TypeScript and PlanetScale'
+metaDescription: 'Connect your existing database to your project using TypeScript and PlanetScale'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+sidebar_class_name: hidden-sidebar
+hide_table_of_contents: true
+toc: false
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases-typescript-planetscale
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-typescript-planetscale
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-
+---
+
+## Connecting your database
+
+To connect your database, you need to set the `url` field of the `datasource` block in your Prisma schema to your database [connection URL](/orm/reference/connection-urls):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+```
+
+You will also need to [set the relation mode type to `prisma`](/orm/prisma-schema/data-model/relations/relation-mode#emulate-relations-in-prisma-orm-with-the-prisma-relation-mode) in the `datasource` block:
+
+```prisma file=schema.prisma highlight=4;add showLineNumbers
+datasource db {
+ provider = "mysql"
+ url = env("DATABASE_URL")
+ //add-next-line
+ relationMode = "prisma"
+}
+```
+
+The `url` is [set via an environment variable](/orm/prisma-schema/overview#accessing-environment-variables-from-the-schema) which is defined in `.env`:
+
+```bash file=.env
+DATABASE_URL="mysql://janedoe:mypassword@server.us-east-2.psdb.cloud/mydb?sslaccept=strict"
+```
+
+You now need to adjust the connection URL to point to your own database.
+
+
Connection URL
+
+The [format of the connection URL](/orm/reference/connection-urls) for your database typically depends on the database you use. PlanetScale uses the MySQL connection URL format, which has the following structure (the parts spelled all-uppercased are _placeholders_ for your specific connection details):
+
+```no-lines
+mysql://USER:PASSWORD@HOST:PORT/DATABASE
+```
+
+Here's a short explanation of each component:
+
+- `USER`: The name of your database user
+- `PASSWORD`: The password for your database user
+- `PORT`: The port where your database server is running (typically `3306` for MySQL)
+- `DATABASE`: The name of the [database](https://dev.mysql.com/doc/refman/8.0/en/creating-database.html)
+
+For a database hosted with PlanetScale, the [connection URL](/orm/reference/connection-urls) looks similar to this:
+
+```bash file=.env
+DATABASE_URL="mysql://myusername:mypassword@server.us-east-2.psdb.cloud/mydb?sslaccept=strict"
+```
+
+The connection URL for a given database branch can be found from your PlanetScale account by going to the overview page for the branch and selecting the 'Connect' dropdown. In the 'Passwords' section, generate a new password and select 'Prisma' to get the Prisma format for the connection URL.
+
+
+Alternative method: connecting using the PlanetScale CLI
+
+Alternatively, you can connect to your PlanetScale database server using the [PlanetScale CLI](https://planetscale.com/docs/concepts/planetscale-environment-setup), and use a local connection URL. In this case the connection URL will look like this:
+
+```bash file=.env
+DATABASE_URL="mysql://root@localhost:PORT/mydb"
+```
+
+To connect to your branch, use the following command:
+
+```terminal
+pscale connect prisma-test branchname --port PORT
+```
+
+The `--port` flag can be omitted if you are using the default port `3306`.
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-typescript-postgresql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-typescript-postgresql.mdx
new file mode 100644
index 0000000000..6035f3ee0f
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-typescript-postgresql.mdx
@@ -0,0 +1,56 @@
+---
+title: 'Connect your existing database using TypeScript and PostgresSQL'
+sidebar_label: 'Connect your database'
+metaTitle: 'Connect your existing database using TypeScript and PostgresSQL'
+metaDescription: 'Connect your existing database to your project using TypeScript and PostgresSQL'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+toc: false
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases-typescript-postgresql
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-typescript-postgresql
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-
+---
+
+## Connecting your database
+
+To connect your database, you need to set the `url` field of the `datasource` block in your Prisma schema to your database [connection URL](/orm/reference/connection-urls):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+```
+
+In this case, the `url` is [set via an environment variable](/orm/more/development-environment/environment-variables) which is defined in `.env`:
+
+```bash file=.env
+DATABASE_URL="postgresql://johndoe:randompassword@localhost:5432/mydb?schema=public"
+```
+
+You now need to adjust the connection URL to point to your own database.
+
+
Connection URL
+
+The [format of the connection URL](/orm/reference/connection-urls) for your database depends on the database you use. For PostgreSQL, it looks as follows (the parts spelled all-uppercased are _placeholders_ for your specific connection details):
+
+```no-lines
+postgresql://USER:PASSWORD@HOST:PORT/DATABASE?schema=SCHEMA
+```
+
+> **Note**: In most cases, you can use the [`postgres://` and `postgresql:// URI scheme designators interchangeably`](https://www.postgresql.org/docs/10/libpq-connect.html#id-1.7.3.8.3.6) - however, depending on how your database is hosted, you might need to be specific.
+
+If you're unsure what to provide for the `schema` parameter for a PostgreSQL connection URL, you can probably omit it. In that case, the default schema name `public` will be used.
+
+As an example, for a PostgreSQL database hosted on Heroku, the connection URL might look similar to this:
+
+```bash file=.env
+DATABASE_URL="postgresql://opnmyfngbknppm:XXX@ec2-46-137-91-216.eu-west-1.compute.amazonaws.com:5432/d50rgmkqi2ipus?schema=hello-prisma"
+```
+
+When running PostgreSQL locally on macOS, your user and password as well as the database name _typically_ correspond to the current _user_ of your OS, e.g. assuming the user is called `janedoe`:
+
+```bash file=.env
+DATABASE_URL="postgresql://janedoe:janedoe@localhost:5432/janedoe?schema=hello-prisma"
+```
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-typescript-sqlserver.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-typescript-sqlserver.mdx
new file mode 100644
index 0000000000..e898b23b12
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/100-connect-your-database-typescript-sqlserver.mdx
@@ -0,0 +1,35 @@
+---
+title: 'Connect your existing database using TypeScript and SQL Server'
+sidebar_label: 'Connect your database'
+metaTitle: 'Connect your existing database using TypeScript and SQL Server'
+metaDescription: 'Connect your existing database to your project using TypeScript and SQL Server'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+toc: false
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases-typescript-sqlserver
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-typescript-sqlserver
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-
+---
+
+## Connecting your database
+
+To connect your database, you need to set the `url` field of the `datasource` block in your Prisma schema to your database [connection URL](/orm/reference/connection-urls):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "sqlserver"
+ url = env("DATABASE_URL")
+}
+```
+
+The `url` is [set via an environment variable](/orm/prisma-schema/overview#accessing-environment-variables-from-the-schema), the following example connection URL [uses SQL authentication](/orm/overview/databases/sql-server), but there are [other ways to format your connection URL](/orm/overview/databases/sql-server)
+
+```bash file=.env
+DATABASE_URL="sqlserver://localhost:1433;database=mydb;user=sa;password=r@ndomP@$$w0rd;trustServerCertificate=true"
+```
+
+Adjust the connection URL to match your setup - see [Microsoft SQL Server connection URL](/orm/overview/databases/sql-server) for more information.
+
+> Make sure TCP/IP connections are enabled via [SQL Server Configuration Manager](https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-configuration-manager?view=sql-server-ver16&viewFallbackFrom=sql-server-ver16) to avoid `No connection could be made because the target machine actively refused it. (os error 10061)`
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-node-cockroachdb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-node-cockroachdb.mdx
new file mode 100644
index 0000000000..d7d5f1cda4
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-node-cockroachdb.mdx
@@ -0,0 +1,217 @@
+---
+title: 'Introspection for CockroachDB in a JavaScript project'
+sidebar_label: 'Introspection'
+metaTitle: 'Introspection with Prisma ORM, JavaScript, and CockroachDB'
+metaDescription: 'Introspect your existing project with Prisma ORM, JavaScript, and CockroachDB'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-node-cockroachdb
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/baseline-your-database-node-cockroachdb
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-
+---
+
+## Introspect your database with Prisma ORM
+
+For the purpose of this guide, we'll use a demo SQL schema with three tables:
+
+```sql no-lines
+CREATE TABLE "User" (
+ id INT8 PRIMARY KEY DEFAULT unique_rowid(),
+ name STRING(255),
+ email STRING(255) UNIQUE NOT NULL
+);
+
+CREATE TABLE "Post" (
+ id INT8 PRIMARY KEY DEFAULT unique_rowid(),
+ title STRING(255) UNIQUE NOT NULL,
+ "createdAt" TIMESTAMP NOT NULL DEFAULT now(),
+ content STRING,
+ published BOOLEAN NOT NULL DEFAULT false,
+ "authorId" INT8 NOT NULL,
+ FOREIGN KEY ("authorId") REFERENCES "User"(id)
+);
+
+CREATE TABLE "Profile" (
+ id INT8 PRIMARY KEY DEFAULT unique_rowid(),
+ bio STRING,
+ "userId" INT8 UNIQUE NOT NULL,
+ FOREIGN KEY ("userId") REFERENCES "User"(id)
+);
+```
+
+> **Note**: Some fields are written in double quotes to ensure CockroachDB uses proper casing. If no double-quotes were used, CockroachDB would just read everything as _lowercase_ characters.
+
+
+Expand for a graphical overview of the tables
+
+**User**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :------------ | :---------- | :---------- | :------- | :----------------- |
+| `id` | `INT8` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `name` | `STRING(255)` | No | No | No | - |
+| `email` | `STRING(255)` | No | No | **✔️** | - |
+
+**Post**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :------------ | :---------- | :---------- | :------- | :----------------- |
+| `id` | `INT8` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `createdAt` | `TIMESTAMP` | No | No | **✔️** | `now()` |
+| `title` | `STRING(255)` | No | No | **✔️** | - |
+| `content` | `STRING` | No | No | No | - |
+| `published` | `BOOLEAN` | No | No | **✔️** | `false` |
+| `authorId` | `INT8` | No | **✔️** | **✔️** | - |
+
+**Profile**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :------- | :---------- | :---------- | :------- | :----------------- |
+| `id` | `INT8` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `bio` | `STRING` | No | No | No | - |
+| `userId` | `INT8` | No | **✔️** | **✔️** | - |
+
+
+
+As a next step, you will introspect your database. The result of the introspection will be a [data model](/orm/prisma-schema/data-model/models) inside your Prisma schema.
+
+Run the following command to introspect your database:
+
+```terminal copy
+npx prisma db pull
+```
+
+This command reads the environment variable used to define the `url` in your `schema.prisma`, `DATABASE_URL`, that in our case is set in `.env` and connects to your database. Once the connection is established, it introspects the database (i.e. it _reads the database schema_). It then translates the database schema from SQL into a Prisma data model.
+
+After the introspection is complete, your Prisma schema is updated:
+
+
+
+The data model now looks similar to this:
+
+```prisma file=prisma/schema.prisma showLineNumbers
+model Post {
+ id BigInt @id @default(autoincrement())
+ title String @unique @db.String(255)
+ createdAt DateTime @default(now()) @db.Timestamp(6)
+ content String?
+ published Boolean @default(false)
+ authorId BigInt
+ User User @relation(fields: [authorId], references: [id], onDelete: NoAction, onUpdate: NoAction)
+}
+
+model Profile {
+ id BigInt @id @default(autoincrement())
+ bio String?
+ userId BigInt @unique
+ User User @relation(fields: [userId], references: [id], onDelete: NoAction, onUpdate: NoAction)
+}
+
+model User {
+ id BigInt @id @default(autoincrement())
+ name String? @db.String(255)
+ email String @unique @db.String(255)
+ Post Post[]
+ Profile Profile?
+}
+```
+
+Prisma ORM's data model is a declarative representation of your database schema and serves as the foundation for the generated Prisma Client library. Your Prisma Client instance will expose queries that are _tailored_ to these models.
+
+Right now, there's a few minor "issues" with the data model:
+
+- The `User` relation field is uppercased and therefore doesn't adhere to Prisma's [naming conventions](/orm/reference/prisma-schema-reference#naming-conventions-1) . To express more "semantics", it would also be nice if this field was called `author` to _describe_ the relationship between `User` and `Post` better.
+- The `Post` and `Profile` relation fields on `User` as well as the `User` relation field on `Profile` are all uppercased. To adhere to Prisma's [naming conventions](/orm/reference/prisma-schema-reference#naming-conventions-1) , both fields should be lowercased to `post`, `profile` and `user`.
+- Even after lowercasing, the `post` field on `User` is still slightly misnamed. That's because it actually refers to a [list](/orm/prisma-schema/data-model/models#type-modifiers) of posts – a better name therefore would be the plural form: `posts`.
+
+These changes are relevant for the generated Prisma Client API where using lowercased relation fields `author`, `posts`, `profile` and `user` will feel more natural and idiomatic to JavaScript/TypeScript developers. You can therefore [configure your Prisma Client API](/orm/prisma-client/setup-and-configuration/custom-model-and-field-names).
+
+Because [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) are _virtual_ (i.e. they _do not directly manifest in the database_), you can manually rename them in your Prisma schema without touching the database:
+
+```prisma file=prisma/schema.prisma highlight=8,15,22,23;edit showLineNumbers
+model Post {
+ id BigInt @id @default(autoincrement())
+ title String @unique @db.String(255)
+ createdAt DateTime @default(now()) @db.Timestamp(6)
+ content String?
+ published Boolean @default(false)
+ authorId BigInt
+ //edit-next-line
+ author User @relation(fields: [authorId], references: [id], onDelete: NoAction, onUpdate: NoAction)
+}
+
+model Profile {
+ id BigInt @id @default(autoincrement())
+ bio String?
+ userId BigInt @unique
+ //edit-next-line
+ user User @relation(fields: [userId], references: [id], onDelete: NoAction, onUpdate: NoAction)
+}
+
+model User {
+ id BigInt @id @default(autoincrement())
+ name String? @db.String(255)
+ email String @unique @db.String(255)
+ //edit-start
+ posts Post[]
+ profile Profile?
+ //edit-end
+}
+```
+
+In this example, the database schema did follow the [naming conventions](/orm/reference/prisma-schema-reference#naming-conventions) for Prisma ORM models (only the virtual relation fields that were generated from introspection did not adhere to them and needed adjustment). This optimizes the ergonomics of the generated Prisma Client API.
+
+
+ Using custom model and field names
+
+Sometimes though, you may want to make additional changes to the names of the columns and tables that are exposed in the Prisma Client API. A common example is to translate _snake_case_ notation which is often used in database schemas into _PascalCase_ and _camelCase_ notations which feel more natural for JavaScript/TypeScript developers.
+
+Assume you obtained the following model from introspection that's based on _snake_case_ notation:
+
+```prisma no-lines
+model my_user {
+ user_id Int @id @default(sequence())
+ first_name String?
+ last_name String @unique
+}
+```
+
+If you generated a Prisma Client API for this model, it would pick up the _snake_case_ notation in its API:
+
+```ts no-lines
+const user = await prisma.my_user.create({
+ data: {
+ first_name: 'Alice',
+ last_name: 'Smith',
+ },
+})
+```
+
+If you don't want to use the table and column names from your database in your Prisma Client API, you can configure them with [`@map` and `@@map`](/orm/prisma-schema/data-model/models#mapping-model-names-to-tables-or-collections):
+
+```prisma no-lines
+model MyUser {
+ userId Int @id @default(sequence()) @map("user_id")
+ firstName String? @map("first_name")
+ lastName String @unique @map("last_name")
+
+ @@map("my_user")
+}
+```
+
+With this approach, you can name your model and its fields whatever you like and use the `@map` (for field names) and `@@map` (for models names) to point to the underlying tables and columns. Your Prisma Client API now looks as follows:
+
+```ts no-lines
+const user = await prisma.myUser.create({
+ data: {
+ firstName: 'Alice',
+ lastName: 'Smith',
+ },
+})
+```
+
+Learn more about this on the [Configuring your Prisma Client API](/orm/prisma-client/setup-and-configuration/custom-model-and-field-names) page.
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-node-mysql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-node-mysql.mdx
new file mode 100644
index 0000000000..64ab5fdfd6
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-node-mysql.mdx
@@ -0,0 +1,220 @@
+---
+title: 'Introspection for MySQL in a JavaScript project'
+sidebar_label: 'Introspection'
+metaTitle: 'Introspection with Prisma ORM, JavaScript, and MySQL'
+metaDescription: 'Introspect your existing project with Prisma ORM, JavaScript, and MySQL'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-node-mysql
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/baseline-your-database-node-mysql
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-
+---
+
+## Introspect your database with Prisma ORM
+
+For the purpose of this guide, we'll use a demo SQL schema with three tables:
+
+```sql no-lines
+CREATE TABLE User (
+ id INTEGER PRIMARY KEY AUTO_INCREMENT NOT NULL,
+ name VARCHAR(255),
+ email VARCHAR(255) UNIQUE NOT NULL
+);
+
+CREATE TABLE Post (
+ id INTEGER PRIMARY KEY AUTO_INCREMENT NOT NULL,
+ title VARCHAR(255) NOT NULL,
+ createdAt TIMESTAMP NOT NULL DEFAULT now(),
+ content TEXT,
+ published BOOLEAN NOT NULL DEFAULT false,
+ authorId INTEGER NOT NULL,
+ FOREIGN KEY (authorId) REFERENCES User(id)
+);
+
+CREATE TABLE Profile (
+ id INTEGER PRIMARY KEY AUTO_INCREMENT NOT NULL,
+ bio TEXT,
+ userId INTEGER UNIQUE NOT NULL,
+ FOREIGN KEY (userId) REFERENCES User(id)
+);
+```
+
+
+Expand for a graphical overview of the tables
+
+**User**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :------------- | :---------- | :---------- | :------- | :----------------- |
+| `id` | `INTEGER` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `name` | `VARCHAR(255)` | No | No | No | - |
+| `email` | `VARCHAR(255)` | No | No | **✔️** | - |
+
+**Post**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :------------- | :---------- | :---------- | :------- | :----------------- |
+| `id` | `INTEGER` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `createdAt` | `DATETIME(3)` | No | No | **✔️** | `now()` |
+| `title` | `VARCHAR(255)` | No | No | **✔️** | - |
+| `content` | `TEXT` | No | No | No | - |
+| `published` | `BOOLEAN` | No | No | **✔️** | `false` |
+| `authorId` | `INTEGER` | No | **✔️** | **✔️** | `false` |
+
+**Profile**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :-------- | :---------- | :---------- | :------- | :----------------- |
+| `id` | `INTEGER` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `bio` | `TEXT` | No | No | No | - |
+| `userId` | `INTEGER` | No | **✔️** | **✔️** | - |
+
+
+
+As a next step, you will introspect your database. The result of the introspection will be a [data model](/orm/prisma-schema/data-model/models) inside your Prisma schema.
+
+Run the following command to introspect your database:
+
+```terminal copy
+npx prisma db pull
+```
+
+This command reads the `DATABASE_URL` environment variable that's defined in `.env` and connects to your database. Once the connection is established, it introspects the database (i.e. it _reads the database schema_). It then translates the database schema from SQL into a Prisma data model.
+
+After the introspection is complete, your Prisma schema is updated:
+
+
+
+The data model now looks similar to this (note that the fields on the models have been reordered for better readability):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String @db.VarChar(255)
+ createdAt DateTime @default(now()) @db.Timestamp(0)
+ content String? @db.Text
+ published Boolean @default(false)
+ authorId Int
+ User User @relation(fields: [authorId], references: [id], onDelete: NoAction, onUpdate: NoAction, map: "Post_ibfk_1")
+
+ @@index([authorId], map: "authorId")
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String? @db.Text
+ userId Int @unique(map: "userId")
+ User User @relation(fields: [userId], references: [id], onDelete: NoAction, onUpdate: NoAction, map: "Profile_ibfk_1")
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ name String? @db.VarChar(255)
+ email String @unique(map: "email") @db.VarChar(255)
+ Post Post[]
+ Profile Profile?
+}
+```
+
+:::info
+
+Refer to the [Prisma schema reference](/orm/reference/prisma-schema-reference) for detailed information about the schema definition.
+
+:::
+
+Prisma ORM's data model is a declarative representation of your database schema and serves as the foundation for the generated Prisma Client library. Your Prisma Client instance will expose queries that are _tailored_ to these models.
+
+Right now, there's a few minor "issues" with the data model:
+
+- The `User` relation field is uppercased and therefore doesn't adhere to Prisma's [naming conventions](/orm/reference/prisma-schema-reference#naming-conventions-1) . To express more "semantics", it would also be nice if this field was called `author` to _describe_ the relationship between `User` and `Post` better.
+- The `Post` and `Profile` relation fields on `User` as well as the `User` relation field on `Profile` are all uppercased. To adhere to Prisma's [naming conventions](/orm/reference/prisma-schema-reference#naming-conventions-1) , both fields should be lowercased to `post`, `profile` and `user`.
+- Even after lowercasing, the `post` field on `User` is still slightly misnamed. That's because it actually refers to a [list](/orm/prisma-schema/data-model/models#type-modifiers) of posts – a better name therefore would be the plural form: `posts`.
+
+These changes are relevant for the generated Prisma Client API where using lowercased relation fields `author`, `posts`, `profile` and `user` will feel more natural and idiomatic to JavaScript/TypeScript developers. You can therefore [configure your Prisma Client API](/orm/prisma-client/setup-and-configuration/custom-model-and-field-names).
+
+Because [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) are _virtual_ (i.e. they _do not directly manifest in the database_), you can manually rename them in your Prisma schema without touching the database:
+
+```prisma file=prisma/schema.prisma highlight=8,17,24,25;edit showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String @db.VarChar(255)
+ createdAt DateTime @default(now()) @db.Timestamp(0)
+ content String? @db.Text
+ published Boolean @default(false)
+ authorId Int
+ //edit-next-line
+ author User @relation(fields: [authorId], references: [id], onDelete: NoAction, onUpdate: NoAction, map: "Post_ibfk_1")
+
+ @@index([authorId], map: "authorId")
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String? @db.Text
+ userId Int @unique(map: "userId")
+ //edit-next-line
+ user User @relation(fields: [userId], references: [id], onDelete: NoAction, onUpdate: NoAction, map: "Profile_ibfk_1")
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ name String? @db.VarChar(255)
+ email String @unique(map: "email") @db.VarChar(255)
+ //edit-start
+ posts Post[]
+ profile Profile?
+ //edit-end
+}
+```
+
+In this example, the database schema did follow the [naming conventions](/orm/reference/prisma-schema-reference#naming-conventions) for Prisma ORM models (only the virtual relation fields that were generated from introspection did not adhere to them and needed adjustment). This optimizes the ergonomics of the generated Prisma Client API.
+
+Sometimes though, you may want to make additional changes to the names of the columns and tables that are exposed in the Prisma Client API. A common example is to translate _snake_case_ notation which is often used in database schemas into _PascalCase_ and _camelCase_ notations which feel more natural for JavaScript/TypeScript developers.
+
+Assume you obtained the following model from introspection that's based on _snake_case_ notation:
+
+```prisma no-lines
+model my_user {
+ user_id Int @id @default(autoincrement())
+ first_name String?
+ last_name String @unique
+}
+```
+
+If you generated a Prisma Client API for this model, it would pick up the _snake_case_ notation in its API:
+
+```ts no-lines
+const user = await prisma.my_user.create({
+ data: {
+ first_name: 'Alice',
+ last_name: 'Smith',
+ },
+})
+```
+
+If you don't want to use the table and column names from your database in your Prisma Client API, you can configure them with [`@map` and `@@map`](/orm/prisma-schema/data-model/models#mapping-model-names-to-tables-or-collections):
+
+```prisma no-lines
+model MyUser {
+ userId Int @id @default(autoincrement()) @map("user_id")
+ firstName String? @map("first_name")
+ lastName String @unique @map("last_name")
+
+ @@map("my_user")
+}
+```
+
+With this approach, you can name your model and its fields whatever you like and use the `@map` (for field names) and `@@map` (for models names) to point to the underlying tables and columns. Your Prisma Client API now looks as follows:
+
+```ts no-lines
+const user = await prisma.myUser.create({
+ data: {
+ firstName: 'Alice',
+ lastName: 'Smith',
+ },
+})
+```
+
+Learn more about this on the [Configuring your Prisma Client API](/orm/prisma-client/setup-and-configuration/custom-model-and-field-names) page.
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-node-planetscale.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-node-planetscale.mdx
new file mode 100644
index 0000000000..453a978732
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-node-planetscale.mdx
@@ -0,0 +1,237 @@
+---
+title: 'Introspection for PlanetScale in a JavaScript project'
+sidebar_label: 'Introspection'
+metaTitle: 'Introspection with Prisma ORM, JavaScript, and PlanetScale'
+metaDescription: 'Introspect your existing project with Prisma ORM, JavaScript, and PlanetScale'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-node-postgresql
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/baseline-your-database-node-postgresql
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-
+---
+
+
+## Introspect your database with Prisma ORM
+
+For the purpose of this guide, we'll use a demo SQL schema with three tables:
+
+```sql no-lines
+CREATE TABLE `Post` (
+ `id` int NOT NULL AUTO_INCREMENT,
+ `createdAt` datetime(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3),
+ `updatedAt` datetime(3) NOT NULL,
+ `title` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
+ `content` varchar(191) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
+ `published` tinyint(1) NOT NULL DEFAULT '0',
+ `authorId` int NOT NULL,
+ PRIMARY KEY (`id`),
+ KEY `Post_authorId_idx` (`authorId`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
+
+CREATE TABLE `Profile` (
+ `id` int NOT NULL AUTO_INCREMENT,
+ `bio` varchar(191) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
+ `userId` int NOT NULL,
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `Profile_userId_key` (`userId`),
+ KEY `Profile_userId_idx` (`userId`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
+
+CREATE TABLE `User` (
+ `id` int NOT NULL AUTO_INCREMENT,
+ `email` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL,
+ `name` varchar(191) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `User_email_key` (`email`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
+```
+
+
+Expand for a graphical overview of the tables
+
+**Post**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :------------- | :---------- | :---------- | :------- | :----------------- |
+| `id` | `int` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `createdAt` | `datetime(3)` | No | No | **✔️** | `now()` |
+| `updatedAt` | `datetime(3)` | No | No | **✔️** | |
+| `title` | `varchar(255)` | No | No | **✔️** | - |
+| `content` | `varchar(191)` | No | No | No | - |
+| `published` | `tinyint(1)` | No | No | **✔️** | `false` |
+| `authorId` | `int` | No | No | **✔️** | - |
+
+**Profile**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :------------- | :---------- | :---------- | :------- | :----------------- |
+| `id` | `int` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `bio` | `varchar(191)` | No | No | No | - |
+| `userId` | `int` | No | No | **✔️** | - |
+
+**User**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :------------- | :---------- | :---------- | :------- | :----------------- |
+| `id` | `int` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `name` | `varchar(191)` | No | No | No | - |
+| `email` | `varchar(191)` | No | No | **✔️** | - |
+
+
+
+As a next step, you will introspect your database. The result of the introspection will be a [data model](/orm/prisma-schema/data-model/models) inside your Prisma schema.
+
+Run the following command to introspect your database:
+
+```terminal copy
+npx prisma db pull
+```
+
+This command reads the `DATABASE_URL` environment variable that's defined in `.env` and connects to your database. Once the connection is established, it introspects the database (i.e. it _reads the database schema_). It then translates the database schema from SQL into a Prisma data model.
+
+After the introspection is complete, your Prisma schema is updated:
+
+
+
+The data model now looks similar to this:
+
+```prisma file=prisma/schema.prisma showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ createdAt DateTime @default(now())
+ updatedAt DateTime
+ title String @db.VarChar(255)
+ content String?
+ published Boolean @default(false)
+ authorId Int
+
+ @@index([authorId])
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ userId Int @unique
+
+ @@index([userId])
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+}
+```
+
+:::info
+
+Refer to the [Prisma schema reference](/orm/reference/prisma-schema-reference) for detailed information about the schema definition.
+
+:::
+
+Prisma's data model is a declarative representation of your database schema and serves as the foundation for the generated Prisma Client library. Your Prisma Client instance will expose queries that are _tailored_ to these models.
+
+You will then need to add in any missing relations between your data using [relation fields](/orm/prisma-schema/data-model/relations#relation-fields):
+
+```prisma file=prisma/schema.prisma highlight=8,17,27,28;add showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ createdAt DateTime @default(now())
+ updatedAt DateTime
+ title String @db.VarChar(255)
+ content String?
+ published Boolean @default(false)
+ //add-next-line
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+
+ @@index([authorId])
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ //add-next-line
+ user User @relation(fields: [userId], references: [id])
+ userId Int @unique
+
+ @@index([userId])
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ //add-start
+ posts Post[]
+ profile Profile?
+ //add-end
+}
+```
+
+After this, run introspection on your database for a second time:
+
+```terminal copy
+npx prisma db pull
+```
+
+Prisma Migrate will now keep the manually added relation fields.
+
+Because relation fields are _virtual_ (i.e. they _do not directly manifest in the database_), you can manually rename them in your Prisma schema without touching the database.
+
+In this example, the database schema follows the [naming conventions](/orm/reference/prisma-schema-reference#naming-conventions) for Prisma ORM models. This optimizes the ergonomics of the generated Prisma Client API.
+
+
+ Using custom model and field names
+
+Sometimes though, you may want to make additional changes to the names of the columns and tables that are exposed in the Prisma Client API. A common example is to translate _snake_case_ notation which is often used in database schemas into _PascalCase_ and _camelCase_ notations which feel more natural for JavaScript/TypeScript developers.
+
+Assume you obtained the following model from introspection that's based on _snake_case_ notation:
+
+```prisma no-lines
+model my_user {
+ user_id Int @id @default(autoincrement())
+ first_name String?
+ last_name String @unique
+}
+```
+
+If you generated a Prisma Client API for this model, it would pick up the _snake_case_ notation in its API:
+
+```ts no-lines
+const user = await prisma.my_user.create({
+ data: {
+ first_name: 'Alice',
+ last_name: 'Smith',
+ },
+})
+```
+
+If you don't want to use the table and column names from your database in your Prisma Client API, you can configure them with [`@map` and `@@map`](/orm/prisma-schema/data-model/models#mapping-model-names-to-tables-or-collections):
+
+```prisma no-lines
+model MyUser {
+ userId Int @id @default(autoincrement()) @map("user_id")
+ firstName String? @map("first_name")
+ lastName String @unique @map("last_name")
+
+ @@map("my_user")
+}
+```
+
+With this approach, you can name your model and its fields whatever you like and use the `@map` (for field names) and `@@map` (for models names) to point to the underlying tables and columns. Your Prisma Client API now looks as follows:
+
+```ts no-lines
+const user = await prisma.myUser.create({
+ data: {
+ firstName: 'Alice',
+ lastName: 'Smith',
+ },
+})
+```
+
+Learn more about this on the [Configuring your Prisma Client API](/orm/prisma-client/setup-and-configuration/custom-model-and-field-names) page.
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-node-postgresql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-node-postgresql.mdx
new file mode 100644
index 0000000000..6231b4a6f5
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-node-postgresql.mdx
@@ -0,0 +1,218 @@
+---
+title: 'Introspection for PostgreSQL in a JavaScript project'
+sidebar_label: 'Introspection'
+metaTitle: 'Introspection with Prisma ORM, JavaScript, and PostgreSQL'
+metaDescription: 'Introspect your existing project with Prisma ORM, JavaScript, and PostgreSQL'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-node-postgresql
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/baseline-your-database-node-postgresql
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-
+---
+
+
+## Introspect your database with Prisma ORM
+
+For the purpose of this guide, we'll use a demo SQL schema with three tables:
+
+```sql no-lines
+CREATE TABLE "public"."User" (
+ id SERIAL PRIMARY KEY NOT NULL,
+ name VARCHAR(255),
+ email VARCHAR(255) UNIQUE NOT NULL
+);
+
+CREATE TABLE "public"."Post" (
+ id SERIAL PRIMARY KEY NOT NULL,
+ title VARCHAR(255) NOT NULL,
+ "createdAt" TIMESTAMP NOT NULL DEFAULT now(),
+ content TEXT,
+ published BOOLEAN NOT NULL DEFAULT false,
+ "authorId" INTEGER NOT NULL,
+ FOREIGN KEY ("authorId") REFERENCES "public"."User"(id)
+);
+
+CREATE TABLE "public"."Profile" (
+ id SERIAL PRIMARY KEY NOT NULL,
+ bio TEXT,
+ "userId" INTEGER UNIQUE NOT NULL,
+ FOREIGN KEY ("userId") REFERENCES "public"."User"(id)
+);
+```
+
+> **Note**: Some fields are written in double-quotes to ensure PostgreSQL uses proper casing. If no double-quotes were used, PostgreSQL would just read everything as _lowercase_ characters.
+
+
+Expand for a graphical overview of the tables
+
+**User**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :------------- | :---------- | :---------- | :------- | :----------------- |
+| `id` | `SERIAL` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `name` | `VARCHAR(255)` | No | No | No | - |
+| `email` | `VARCHAR(255)` | No | No | **✔️** | - |
+
+**Post**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :------------- | :---------- | :---------- | :------- | :----------------- |
+| `id` | `SERIAL` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `createdAt` | `TIMESTAMP` | No | No | **✔️** | `now()` |
+| `title` | `VARCHAR(255)` | No | No | **✔️** | - |
+| `content` | `TEXT` | No | No | No | - |
+| `published` | `BOOLEAN` | No | No | **✔️** | `false` |
+| `authorId` | `INTEGER` | No | **✔️** | **✔️** | - |
+
+**Profile**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :-------- | :---------- | :---------- | :------- | :----------------- |
+| `id` | `SERIAL` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `bio` | `TEXT` | No | No | No | - |
+| `userId` | `INTEGER` | No | **✔️** | **✔️** | - |
+
+
+
+As a next step, you will introspect your database. The result of the introspection will be a [data model](/orm/prisma-schema/data-model/models) inside your Prisma schema.
+
+Run the following command to introspect your database:
+
+```terminal copy
+npx prisma db pull
+```
+
+This command reads the `DATABASE_URL` environment variable that's defined in `.env` and connects to your database. Once the connection is established, it introspects the database (i.e. it _reads the database schema_). It then translates the database schema from SQL into a data model in your Prisma schema.
+
+After the introspection is complete, your Prisma schema is updated:
+
+
+
+The data model now looks similar to this (note that the fields on the models have been reordered for better readability):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String @db.VarChar(255)
+ createdAt DateTime @default(now()) @db.Timestamp(6)
+ content String?
+ published Boolean @default(false)
+ authorId Int
+ User User @relation(fields: [authorId], references: [id], onDelete: NoAction, onUpdate: NoAction)
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ userId Int @unique
+ User User @relation(fields: [userId], references: [id], onDelete: NoAction, onUpdate: NoAction)
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ name String? @db.VarChar(255)
+ email String @unique @db.VarChar(255)
+ Post Post[]
+ Profile Profile?
+}
+```
+
+Prisma ORM's data model is a declarative representation of your database schema and serves as the foundation for the generated Prisma Client library. Your Prisma Client instance will expose queries that are _tailored_ to these models.
+
+Right now, there's a few minor "issues" with the data model:
+
+- The `User` relation field is uppercased and therefore doesn't adhere to Prisma's [naming conventions](/orm/reference/prisma-schema-reference#naming-conventions-1) . To express more "semantics", it would also be nice if this field was called `author` to _describe_ the relationship between `User` and `Post` better.
+- The `Post` and `Profile` relation fields on `User` as well as the `User` relation field on `Profile` are all uppercased. To adhere to Prisma's [naming conventions](/orm/reference/prisma-schema-reference#naming-conventions-1) , both fields should be lowercased to `post`, `profile` and `user`.
+- Even after lowercasing, the `post` field on `User` is still slightly misnamed. That's because it actually refers to a [list](/orm/prisma-schema/data-model/models#type-modifiers) of posts – a better name therefore would be the plural form: `posts`.
+
+These changes are relevant for the generated Prisma Client API where using lowercased relation fields `author`, `posts`, `profile` and `user` will feel more natural and idiomatic to JavaScript/TypeScript developers. You can therefore [configure your Prisma Client API](/orm/prisma-client/setup-and-configuration/custom-model-and-field-names).
+
+Because [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) are _virtual_ (i.e. they _do not directly manifest in the database_), you can manually rename them in your Prisma schema without touching the database:
+
+```prisma file=prisma/schema.prisma highlight=8,15,22,23;edit showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String @db.VarChar(255)
+ createdAt DateTime @default(now()) @db.Timestamp(6)
+ content String?
+ published Boolean @default(false)
+ authorId Int
+ //edit-next-line
+ author User @relation(fields: [authorId], references: [id], onDelete: NoAction, onUpdate: NoAction)
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ userId Int @unique
+ //edit-next-line
+ user User @relation(fields: [userId], references: [id], onDelete: NoAction, onUpdate: NoAction)
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ name String? @db.VarChar(255)
+ email String @unique @db.VarChar(255)
+ //edit-start
+ posts Post[]
+ profile Profile?
+ //edit-end
+}
+```
+
+In this example, the database schema did follow the [naming conventions](/orm/reference/prisma-schema-reference#naming-conventions) for Prisma ORM models (only the virtual relation fields that were generated from introspection did not adhere to them and needed adjustment). This optimizes the ergonomics of the generated Prisma Client API.
+
+
+ Using custom model and field names
+
+Sometimes though, you may want to make additional changes to the names of the columns and tables that are exposed in the Prisma Client API. A common example is to translate _snake_case_ notation which is often used in database schemas into _PascalCase_ and _camelCase_ notations which feel more natural for JavaScript/TypeScript developers.
+
+Assume you obtained the following model from introspection that's based on _snake_case_ notation:
+
+```prisma no-lines
+model my_user {
+ user_id Int @id @default(autoincrement())
+ first_name String?
+ last_name String @unique
+}
+```
+
+If you generated a Prisma Client API for this model, it would pick up the _snake_case_ notation in its API:
+
+```ts no-lines
+const user = await prisma.my_user.create({
+ data: {
+ first_name: 'Alice',
+ last_name: 'Smith',
+ },
+})
+```
+
+If you don't want to use the table and column names from your database in your Prisma Client API, you can configure them with [`@map` and `@@map`](/orm/prisma-schema/data-model/models#mapping-model-names-to-tables-or-collections):
+
+```prisma no-lines
+model MyUser {
+ userId Int @id @default(autoincrement()) @map("user_id")
+ firstName String? @map("first_name")
+ lastName String @unique @map("last_name")
+
+ @@map("my_user")
+}
+```
+
+With this approach, you can name your model and its fields whatever you like and use the `@map` (for field names) and `@@map` (for models names) to point to the underlying tables and columns. Your Prisma Client API now looks as follows:
+
+```ts no-lines
+const user = await prisma.myUser.create({
+ data: {
+ firstName: 'Alice',
+ lastName: 'Smith',
+ },
+})
+```
+
+Learn more about this on the [Configuring your Prisma Client API](/orm/prisma-client/setup-and-configuration/custom-model-and-field-names) page.
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-node-sqlserver.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-node-sqlserver.mdx
new file mode 100644
index 0000000000..983267bd6e
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-node-sqlserver.mdx
@@ -0,0 +1,225 @@
+---
+title: 'Introspection for SQL Server in a JavaScript project'
+sidebar_label: 'Introspection'
+metaTitle: 'Introspection with Prisma ORM, JavaScript, and SQL Server'
+metaDescription: 'Introspect your database with Prisma ORM, JavaScript, and SQL Server'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-node-sqlserver
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/baseline-your-database-node-sqlserver
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-
+---
+
+
+## Introspect your database with Prisma ORM
+
+For the purpose of this guide, we'll use a demo SQL schema with three tables:
+
+```sql no-lines
+CREATE TABLE [dbo].[Post] (
+ [id] INT NOT NULL IDENTITY(1,1),
+ [createdAt] DATETIME2 NOT NULL CONSTRAINT [Post_createdAt_df] DEFAULT CURRENT_TIMESTAMP,
+ [updatedAt] DATETIME2 NOT NULL,
+ [title] VARCHAR(255) NOT NULL,
+ [content] NVARCHAR(1000),
+ [published] BIT NOT NULL CONSTRAINT [Post_published_df] DEFAULT 0,
+ [authorId] INT NOT NULL,
+ CONSTRAINT [Post_pkey] PRIMARY KEY ([id])
+);
+
+CREATE TABLE [dbo].[Profile] (
+ [id] INT NOT NULL IDENTITY(1,1),
+ [bio] NVARCHAR(1000),
+ [userId] INT NOT NULL,
+ CONSTRAINT [Profile_pkey] PRIMARY KEY ([id]),
+ CONSTRAINT [Profile_userId_key] UNIQUE ([userId])
+);
+
+CREATE TABLE [dbo].[User] (
+ [id] INT NOT NULL IDENTITY(1,1),
+ [email] NVARCHAR(1000) NOT NULL,
+ [name] NVARCHAR(1000),
+ CONSTRAINT [User_pkey] PRIMARY KEY ([id]),
+ CONSTRAINT [User_email_key] UNIQUE ([email])
+);
+
+ALTER TABLE [dbo].[Post] ADD CONSTRAINT [Post_authorId_fkey] FOREIGN KEY ([authorId]) REFERENCES [dbo].[User]([id]) ON DELETE NO ACTION ON UPDATE CASCADE;
+
+ALTER TABLE [dbo].[Profile] ADD CONSTRAINT [Profile_userId_fkey] FOREIGN KEY ([userId]) REFERENCES [dbo].[User]([id]) ON DELETE NO ACTION ON UPDATE CASCADE;
+```
+
+
+Expand for a graphical overview of the tables
+
+**User**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :--------------- | :---------- | :---------- | :------- | :----------------- |
+| `id` | `INT` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `name` | `NVARCHAR(1000)` | No | No | No | - |
+| `email` | `NVARCHAR(1000)` | No | No | **✔️** | - |
+
+**Post**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :--------------- | :---------- | :---------- | :------- | :----------------- |
+| `id` | `INT` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `createdAt` | `DATETIME2` | No | No | **✔️** | `now()` |
+| `updatedAt` | `DATETIME2` | No | No | **✔️** | |
+| `title` | `VARCHAR(255)` | No | No | **✔️** | - |
+| `content` | `NVARCHAR(1000)` | No | No | No | - |
+| `published` | `BIT` | No | No | **✔️** | `false` |
+| `authorId` | `INT` | No | **✔️** | **✔️** | - |
+
+**Profile**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :--------------- | :---------- | :---------- | :------- | :----------------- |
+| `id` | `INT` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `bio` | `NVARCHAR(1000)` | No | No | No | - |
+| `userId` | `INT` | No | **✔️** | **✔️** | - |
+
+
+
+As a next step, you will introspect your database. The result of the introspection will be a [data model](/orm/prisma-schema/data-model/models) inside your Prisma schema.
+
+Run the following command to introspect your database:
+
+```terminal copy
+npx prisma db pull
+```
+
+This command reads the `DATABASE_URL` environment variable that's defined in `.env` and connects to your database. Once the connection is established, it introspects the database (i.e. it _reads the database schema_). It then translates the database schema from SQL into a Prisma data model.
+
+After the introspection is complete, your Prisma schema is updated:
+
+
+
+The data model now looks similar to this (note that the fields on the models have been reordered for better readability):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String @db.VarChar(255)
+ createdAt DateTime @default(now()) @db.Timestamp(6)
+ content String?
+ published Boolean @default(false)
+ authorId Int
+ User User @relation(fields: [authorId], references: [id])
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ userId Int @unique
+ User User @relation(fields: [userId], references: [id])
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ name String? @db.VarChar(255)
+ email String @unique @db.VarChar(255)
+ Post Post[]
+ Profile Profile?
+}
+```
+
+Prisma's data model is a declarative representation of your database schema and serves as the foundation for the generated Prisma Client library. Your Prisma Client instance will expose queries that are _tailored_ to these models.
+
+Right now, there's a few minor "issues" with the data model:
+
+- The `User` relation field is uppercased and therefore doesn't adhere to Prisma's [naming conventions](/orm/reference/prisma-schema-reference#naming-conventions-1) . To express more "semantics", it would also be nice if this field was called `author` to _describe_ the relationship between `User` and `Post` better.
+- The `Post` and `Profile` relation fields on `User` as well as the `User` relation field on `Profile` are all uppercased. To adhere to Prisma's [naming conventions](/orm/reference/prisma-schema-reference#naming-conventions-1) , both fields should be lowercased to `post`, `profile` and `user`.
+- Even after lowercasing, the `post` field on `User` is still slightly misnamed. That's because it actually refers to a [list](/orm/prisma-schema/data-model/models#type-modifiers) of posts – a better name therefore would be the plural form: `posts`.
+
+These changes are relevant for the generated Prisma Client API where using lowercased relation fields `author`, `posts`, `profile` and `user` will feel more natural and idiomatic to JavaScript/TypeScript developers. You can therefore [configure your Prisma Client API](/orm/prisma-client/setup-and-configuration/custom-model-and-field-names).
+
+Because [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) are _virtual_ (i.e. they _do not directly manifest in the database_), you can manually rename them in your Prisma schema without touching the database:
+
+```prisma file=prisma/schema.prisma highlight=7,14,22,23;edit showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String @db.VarChar(255)
+ createdAt DateTime @default(now()) @db.Timestamp(6)
+ content String?
+ published Boolean @default(false)
+ //edit-next-line
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ //edit-next-line
+ user User @relation(fields: [userId], references: [id])
+ userId Int @unique
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique @db.VarChar(255)
+ name String? @db.VarChar(255)
+ //edit-start
+ posts Post[]
+ profile Profile?
+ //edit-end
+}
+```
+
+In this example, the database schema did follow the [naming conventions](/orm/reference/prisma-schema-reference#naming-conventions) for Prisma ORM models (only the virtual relation fields that were generated from introspection did not adhere to them and needed adjustment). This optimizes the ergonomics of the generated Prisma Client API.
+
+
+ Using custom model and field names
+
+Sometimes though, you may want to make additional changes to the names of the columns and tables that are exposed in the Prisma Client API. A common example is to translate _snake_case_ notation which is often used in database schemas into _PascalCase_ and _camelCase_ notations which feel more natural for JavaScript/TypeScript developers.
+
+Assume you obtained the following model from introspection that's based on _snake_case_ notation:
+
+```prisma no-lines
+model my_user {
+ user_id Int @id @default(autoincrement())
+ first_name String?
+ last_name String @unique
+}
+```
+
+If you generated a Prisma Client API for this model, it would pick up the _snake_case_ notation in its API:
+
+```ts no-lines
+const user = await prisma.my_user.create({
+ data: {
+ first_name: 'Alice',
+ last_name: 'Smith',
+ },
+})
+```
+
+If you don't want to use the table and column names from your database in your Prisma Client API, you can configure them with [`@map` and `@@map`](/orm/prisma-schema/data-model/models#mapping-model-names-to-tables-or-collections):
+
+```prisma no-lines
+model MyUser {
+ userId Int @id @default(autoincrement()) @map("user_id")
+ firstName String? @map("first_name")
+ lastName String @unique @map("last_name")
+
+ @@map("my_user")
+}
+```
+
+With this approach, you can name your model and its fields whatever you like and use the `@map` (for field names) and `@@map` (for models names) to point to the underlying tables and columns. Your Prisma Client API now looks as follows:
+
+```ts no-lines
+const user = await prisma.myUser.create({
+ data: {
+ firstName: 'Alice',
+ lastName: 'Smith',
+ },
+})
+```
+
+Learn more about this on the [Configuring your Prisma Client API](/orm/prisma-client/setup-and-configuration/custom-model-and-field-names) page.
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-typescript-cockroachdb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-typescript-cockroachdb.mdx
new file mode 100644
index 0000000000..64a55d9a57
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-typescript-cockroachdb.mdx
@@ -0,0 +1,218 @@
+---
+title: 'Introspection for CockroachDB in a TypeScript project'
+sidebar_label: 'Introspection'
+metaTitle: 'Introspection with Prisma ORM, TypeScript, and CockroachDB'
+metaDescription: 'Introspect your database with Prisma ORM, TypeScript, and CockroachDB'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-typescript-cockroachdb
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/baseline-your-database-typescript-cockroachdb
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-
+---
+
+
+## Introspect your database with Prisma ORM
+
+For the purpose of this guide, we'll use a demo SQL schema with three tables:
+
+```sql no-lines
+CREATE TABLE "User" (
+ id INT8 PRIMARY KEY DEFAULT unique_rowid(),
+ name STRING(255),
+ email STRING(255) UNIQUE NOT NULL
+);
+
+CREATE TABLE "Post" (
+ id INT8 PRIMARY KEY DEFAULT unique_rowid(),
+ title STRING(255) UNIQUE NOT NULL,
+ "createdAt" TIMESTAMP NOT NULL DEFAULT now(),
+ content STRING,
+ published BOOLEAN NOT NULL DEFAULT false,
+ "authorId" INT8 NOT NULL,
+ FOREIGN KEY ("authorId") REFERENCES "User"(id)
+);
+
+CREATE TABLE "Profile" (
+ id INT8 PRIMARY KEY DEFAULT unique_rowid(),
+ bio STRING,
+ "userId" INT8 UNIQUE NOT NULL,
+ FOREIGN KEY ("userId") REFERENCES "User"(id)
+);
+```
+
+> **Note**: Some fields are written in double quotes to ensure CockroachDB uses proper casing. If no double-quotes were used, CockroachDB would just read everything as _lowercase_ characters.
+
+
+Expand for a graphical overview of the tables
+
+**User**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :------------ | :---------- | :---------- | :------- | :----------------- |
+| `id` | `INT8` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `name` | `STRING(255)` | No | No | No | - |
+| `email` | `STRING(255)` | No | No | **✔️** | - |
+
+**Post**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :------------ | :---------- | :---------- | :------- | :----------------- |
+| `id` | `INT8` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `createdAt` | `TIMESTAMP` | No | No | **✔️** | `now()` |
+| `title` | `STRING(255)` | No | No | **✔️** | - |
+| `content` | `STRING` | No | No | No | - |
+| `published` | `BOOLEAN` | No | No | **✔️** | `false` |
+| `authorId` | `INT8` | No | **✔️** | **✔️** | - |
+
+**Profile**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :------- | :---------- | :---------- | :------- | :----------------- |
+| `id` | `INT8` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `bio` | `STRING` | No | No | No | - |
+| `userId` | `INT8` | No | **✔️** | **✔️** | - |
+
+
+
+As a next step, you will introspect your database. The result of the introspection will be a [data model](/orm/prisma-schema/data-model/models) inside your Prisma schema.
+
+Run the following command to introspect your database:
+
+```terminal copy
+npx prisma db pull
+```
+
+This command reads the environment variable used to define the `url` in your `schema.prisma`, `DATABASE_URL`, that in our case is set in `.env` and connects to your database. Once the connection is established, it introspects the database (i.e. it _reads the database schema_). It then translates the database schema from SQL into a Prisma data model.
+
+After the introspection is complete, your Prisma schema is updated:
+
+
+
+The data model now looks similar to this:
+
+```prisma file=prisma/schema.prisma showLineNumbers
+model Post {
+ id BigInt @id @default(autoincrement())
+ title String @unique @db.String(255)
+ createdAt DateTime @default(now()) @db.Timestamp(6)
+ content String?
+ published Boolean @default(false)
+ authorId BigInt
+ User User @relation(fields: [authorId], references: [id], onDelete: NoAction, onUpdate: NoAction)
+}
+
+model Profile {
+ id BigInt @id @default(autoincrement())
+ bio String?
+ userId BigInt @unique
+ User User @relation(fields: [userId], references: [id], onDelete: NoAction, onUpdate: NoAction)
+}
+
+model User {
+ id BigInt @id @default(autoincrement())
+ name String? @db.String(255)
+ email String @unique @db.String(255)
+ Post Post[]
+ Profile Profile?
+}
+```
+
+Prisma ORM's data model is a declarative representation of your database schema and serves as the foundation for the generated Prisma Client library. Your Prisma Client instance will expose queries that are _tailored_ to these models.
+
+Right now, there's a few minor "issues" with the data model:
+
+- The `User` relation field is uppercased and therefore doesn't adhere to Prisma's [naming conventions](/orm/reference/prisma-schema-reference#naming-conventions-1) . To express more "semantics", it would also be nice if this field was called `author` to _describe_ the relationship between `User` and `Post` better.
+- The `Post` and `Profile` relation fields on `User` as well as the `User` relation field on `Profile` are all uppercased. To adhere to Prisma's [naming conventions](/orm/reference/prisma-schema-reference#naming-conventions-1) , both fields should be lowercased to `post`, `profile` and `user`.
+- Even after lowercasing, the `post` field on `User` is still slightly misnamed. That's because it actually refers to a [list](/orm/prisma-schema/data-model/models#type-modifiers) of posts – a better name therefore would be the plural form: `posts`.
+
+These changes are relevant for the generated Prisma Client API where using lowercased relation fields `author`, `posts`, `profile` and `user` will feel more natural and idiomatic to JavaScript/TypeScript developers. You can therefore [configure your Prisma Client API](/orm/prisma-client/setup-and-configuration/custom-model-and-field-names).
+
+Because [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) are _virtual_ (i.e. they _do not directly manifest in the database_), you can manually rename them in your Prisma schema without touching the database:
+
+```prisma file=prisma/schema.prisma highlight=8,15,22,23;edit showLineNumbers
+model Post {
+ id BigInt @id @default(autoincrement())
+ title String @unique @db.String(255)
+ createdAt DateTime @default(now()) @db.Timestamp(6)
+ content String?
+ published Boolean @default(false)
+ authorId BigInt
+ //edit-next-line
+ author User @relation(fields: [authorId], references: [id], onDelete: NoAction, onUpdate: NoAction)
+}
+
+model Profile {
+ id BigInt @id @default(autoincrement())
+ bio String?
+ userId BigInt @unique
+ //edit-next-line
+ user User @relation(fields: [userId], references: [id], onDelete: NoAction, onUpdate: NoAction)
+}
+
+model User {
+ id BigInt @id @default(autoincrement())
+ name String? @db.String(255)
+ email String @unique @db.String(255)
+ //edit-start
+ posts Post[]
+ profile Profile?
+ //edit-end
+}
+```
+
+In this example, the database schema did follow the [naming conventions](/orm/reference/prisma-schema-reference#naming-conventions) for Prisma ORM models (only the virtual relation fields that were generated from introspection did not adhere to them and needed adjustment). This optimizes the ergonomics of the generated Prisma Client API.
+
+
+ Using custom model and field names
+
+Sometimes though, you may want to make additional changes to the names of the columns and tables that are exposed in the Prisma Client API. A common example is to translate _snake_case_ notation which is often used in database schemas into _PascalCase_ and _camelCase_ notations which feel more natural for JavaScript/TypeScript developers.
+
+Assume you obtained the following model from introspection that's based on _snake_case_ notation:
+
+```prisma no-lines
+model my_user {
+ user_id Int @id @default(sequence())
+ first_name String?
+ last_name String @unique
+}
+```
+
+If you generated a Prisma Client API for this model, it would pick up the _snake_case_ notation in its API:
+
+```ts no-lines
+const user = await prisma.my_user.create({
+ data: {
+ first_name: 'Alice',
+ last_name: 'Smith',
+ },
+})
+```
+
+If you don't want to use the table and column names from your database in your Prisma Client API, you can configure them with [`@map` and `@@map`](/orm/prisma-schema/data-model/models#mapping-model-names-to-tables-or-collections):
+
+```prisma no-lines
+model MyUser {
+ userId Int @id @default(sequence()) @map("user_id")
+ firstName String? @map("first_name")
+ lastName String @unique @map("last_name")
+
+ @@map("my_user")
+}
+```
+
+With this approach, you can name your model and its fields whatever you like and use the `@map` (for field names) and `@@map` (for models names) to point to the underlying tables and columns. Your Prisma Client API now looks as follows:
+
+```ts no-lines
+const user = await prisma.myUser.create({
+ data: {
+ firstName: 'Alice',
+ lastName: 'Smith',
+ },
+})
+```
+
+Learn more about this on the [Configuring your Prisma Client API](/orm/prisma-client/setup-and-configuration/custom-model-and-field-names) page.
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-typescript-mysql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-typescript-mysql.mdx
new file mode 100644
index 0000000000..7df914b56b
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-typescript-mysql.mdx
@@ -0,0 +1,221 @@
+---
+title: 'Introspection for MySQL in a TypeScript project'
+sidebar_label: 'Introspection'
+metaTitle: 'Introspection with Prisma ORM, TypeScript, and MySQL'
+metaDescription: 'Introspect your existing project with Prisma ORM, TypeScript, and MySQL'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-typescript-mysql
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/baseline-your-database-typescript-mysql
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-
+---
+
+
+## Introspect your database with Prisma ORM
+
+For the purpose of this guide, we'll use a demo SQL schema with three tables:
+
+```sql no-lines
+CREATE TABLE User (
+ id INTEGER PRIMARY KEY AUTO_INCREMENT NOT NULL,
+ name VARCHAR(255),
+ email VARCHAR(255) UNIQUE NOT NULL
+);
+
+CREATE TABLE Post (
+ id INTEGER PRIMARY KEY AUTO_INCREMENT NOT NULL,
+ title VARCHAR(255) NOT NULL,
+ createdAt TIMESTAMP NOT NULL DEFAULT now(),
+ content TEXT,
+ published BOOLEAN NOT NULL DEFAULT false,
+ authorId INTEGER NOT NULL,
+ FOREIGN KEY (authorId) REFERENCES User(id)
+);
+
+CREATE TABLE Profile (
+ id INTEGER PRIMARY KEY AUTO_INCREMENT NOT NULL,
+ bio TEXT,
+ userId INTEGER UNIQUE NOT NULL,
+ FOREIGN KEY (userId) REFERENCES User(id)
+);
+```
+
+
+Expand for a graphical overview of the tables
+
+**User**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :------------- | :---------- | :---------- | :------- | :----------------- |
+| `id` | `INTEGER` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `name` | `VARCHAR(255)` | No | No | No | - |
+| `email` | `VARCHAR(255)` | No | No | **✔️** | - |
+
+**Post**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :------------- | :---------- | :---------- | :------- | :----------------- |
+| `id` | `INTEGER` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `createdAt` | `DATETIME(3)` | No | No | **✔️** | `now()` |
+| `title` | `VARCHAR(255)` | No | No | **✔️** | - |
+| `content` | `TEXT` | No | No | No | - |
+| `published` | `BOOLEAN` | No | No | **✔️** | `false` |
+| `authorId` | `INTEGER` | No | **✔️** | **✔️** | `false` |
+
+**Profile**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :-------- | :---------- | :---------- | :------- | :----------------- |
+| `id` | `INTEGER` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `bio` | `TEXT` | No | No | No | - |
+| `userId` | `INTEGER` | No | **✔️** | **✔️** | - |
+
+
+
+As a next step, you will introspect your database. The result of the introspection will be a [data model](/orm/prisma-schema/data-model/models) inside your Prisma schema.
+
+Run the following command to introspect your database:
+
+```terminal copy
+npx prisma db pull
+```
+
+This command reads the `DATABASE_URL` environment variable that's defined in `.env` and connects to your database. Once the connection is established, it introspects the database (i.e. it _reads the database schema_). It then translates the database schema from SQL into a Prisma data model.
+
+After the introspection is complete, your Prisma schema is updated:
+
+
+
+The data model now looks similar to this (note that the fields on the models have been reordered for better readability):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String @db.VarChar(255)
+ createdAt DateTime @default(now()) @db.Timestamp(0)
+ content String? @db.Text
+ published Boolean @default(false)
+ authorId Int
+ User User @relation(fields: [authorId], references: [id], onDelete: NoAction, onUpdate: NoAction, map: "Post_ibfk_1")
+
+ @@index([authorId], map: "authorId")
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String? @db.Text
+ userId Int @unique(map: "userId")
+ User User @relation(fields: [userId], references: [id], onDelete: NoAction, onUpdate: NoAction, map: "Profile_ibfk_1")
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ name String? @db.VarChar(255)
+ email String @unique(map: "email") @db.VarChar(255)
+ Post Post[]
+ Profile Profile?
+}
+```
+
+:::info
+
+Refer to the [Prisma schema reference](/orm/reference/prisma-schema-reference) for detailed information about the schema definition.
+
+:::
+
+Prisma ORM's data model is a declarative representation of your database schema and serves as the foundation for the generated Prisma Client library. Your Prisma Client instance will expose queries that are _tailored_ to these models.
+
+Right now, there's a few minor "issues" with the data model:
+
+- The `User` relation field is uppercased and therefore doesn't adhere to Prisma's [naming conventions](/orm/reference/prisma-schema-reference#naming-conventions-1) . To express more "semantics", it would also be nice if this field was called `author` to _describe_ the relationship between `User` and `Post` better.
+- The `Post` and `Profile` relation fields on `User` as well as the `User` relation field on `Profile` are all uppercased. To adhere to Prisma's [naming conventions](/orm/reference/prisma-schema-reference#naming-conventions-1) , both fields should be lowercased to `post`, `profile` and `user`.
+- Even after lowercasing, the `post` field on `User` is still slightly misnamed. That's because it actually refers to a [list](/orm/prisma-schema/data-model/models#type-modifiers) of posts – a better name therefore would be the plural form: `posts`.
+
+These changes are relevant for the generated Prisma Client API where using lowercased relation fields `author`, `posts`, `profile` and `user` will feel more natural and idiomatic to JavaScript/TypeScript developers. You can therefore [configure your Prisma Client API](/orm/prisma-client/setup-and-configuration/custom-model-and-field-names).
+
+Because [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) are _virtual_ (i.e. they _do not directly manifest in the database_), you can manually rename them in your Prisma schema without touching the database:
+
+```prisma file=prisma/schema.prisma highlight=8,17,24,25;edit showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String @db.VarChar(255)
+ createdAt DateTime @default(now()) @db.Timestamp(0)
+ content String? @db.Text
+ published Boolean @default(false)
+ authorId Int
+ //edit-next-line
+ author User @relation(fields: [authorId], references: [id], onDelete: NoAction, onUpdate: NoAction, map: "Post_ibfk_1")
+
+ @@index([authorId], map: "authorId")
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String? @db.Text
+ userId Int @unique(map: "userId")
+ //edit-next-line
+ user User @relation(fields: [userId], references: [id], onDelete: NoAction, onUpdate: NoAction, map: "Profile_ibfk_1")
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ name String? @db.VarChar(255)
+ email String @unique(map: "email") @db.VarChar(255)
+ //edit-start
+ posts Post[]
+ profile Profile?
+ //edit-end
+}
+```
+
+In this example, the database schema did follow the [naming conventions](/orm/reference/prisma-schema-reference#naming-conventions) for Prisma ORM models (only the virtual relation fields that were generated from introspection did not adhere to them and needed adjustment). This optimizes the ergonomics of the generated Prisma Client API.
+
+Sometimes though, you may want to make additional changes to the names of the columns and tables that are exposed in the Prisma Client API. A common example is to translate _snake_case_ notation which is often used in database schemas into _PascalCase_ and _camelCase_ notations which feel more natural for JavaScript/TypeScript developers.
+
+Assume you obtained the following model from introspection that's based on _snake_case_ notation:
+
+```prisma no-lines
+model my_user {
+ user_id Int @id @default(autoincrement())
+ first_name String?
+ last_name String @unique
+}
+```
+
+If you generated a Prisma Client API for this model, it would pick up the _snake_case_ notation in its API:
+
+```ts no-lines
+const user = await prisma.my_user.create({
+ data: {
+ first_name: 'Alice',
+ last_name: 'Smith',
+ },
+})
+```
+
+If you don't want to use the table and column names from your database in your Prisma Client API, you can configure them with [`@map` and `@@map`](/orm/prisma-schema/data-model/models#mapping-model-names-to-tables-or-collections):
+
+```prisma no-lines
+model MyUser {
+ userId Int @id @default(autoincrement()) @map("user_id")
+ firstName String? @map("first_name")
+ lastName String @unique @map("last_name")
+
+ @@map("my_user")
+}
+```
+
+With this approach, you can name your model and its fields whatever you like and use the `@map` (for field names) and `@@map` (for models names) to point to the underlying tables and columns. Your Prisma Client API now looks as follows:
+
+```ts no-lines
+const user = await prisma.myUser.create({
+ data: {
+ firstName: 'Alice',
+ lastName: 'Smith',
+ },
+})
+```
+
+Learn more about this on the [Configuring your Prisma Client API](/orm/prisma-client/setup-and-configuration/custom-model-and-field-names) page.
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-typescript-planetscale.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-typescript-planetscale.mdx
new file mode 100644
index 0000000000..07b8f12df8
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-typescript-planetscale.mdx
@@ -0,0 +1,237 @@
+---
+title: 'Introspection for PlanetScale in a TypeScript project'
+sidebar_label: 'Introspection'
+metaTitle: 'Introspection with Prisma ORM, TypeScript, and PlanetScale'
+metaDescription: 'Introspect your existing project with Prisma ORM, TypeScript, and PlanetScale'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-typescript-planetscale
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-typescript-planetscale
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-
+---
+
+
+## Introspect your database with Prisma ORM
+
+For the purpose of this guide, we'll use a demo SQL schema with three tables:
+
+```sql no-lines
+CREATE TABLE `Post` (
+ `id` int NOT NULL AUTO_INCREMENT,
+ `createdAt` datetime(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3),
+ `updatedAt` datetime(3) NOT NULL,
+ `title` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
+ `content` varchar(191) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
+ `published` tinyint(1) NOT NULL DEFAULT '0',
+ `authorId` int NOT NULL,
+ PRIMARY KEY (`id`),
+ KEY `Post_authorId_idx` (`authorId`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
+
+CREATE TABLE `Profile` (
+ `id` int NOT NULL AUTO_INCREMENT,
+ `bio` varchar(191) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
+ `userId` int NOT NULL,
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `Profile_userId_key` (`userId`),
+ KEY `Profile_userId_idx` (`userId`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
+
+CREATE TABLE `User` (
+ `id` int NOT NULL AUTO_INCREMENT,
+ `email` varchar(191) COLLATE utf8mb4_unicode_ci NOT NULL,
+ `name` varchar(191) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `User_email_key` (`email`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
+```
+
+
+Expand for a graphical overview of the tables
+
+**Post**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :------------- | :---------- | :---------- | :------- | :----------------- |
+| `id` | `int` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `createdAt` | `datetime(3)` | No | No | **✔️** | `now()` |
+| `updatedAt` | `datetime(3)` | No | No | **✔️** | |
+| `title` | `varchar(255)` | No | No | **✔️** | - |
+| `content` | `varchar(191)` | No | No | No | - |
+| `published` | `tinyint(1)` | No | No | **✔️** | `false` |
+| `authorId` | `int` | No | No | **✔️** | - |
+
+**Profile**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :------------- | :---------- | :---------- | :------- | :----------------- |
+| `id` | `int` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `bio` | `varchar(191)` | No | No | No | - |
+| `userId` | `int` | No | No | **✔️** | - |
+
+**User**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :------------- | :---------- | :---------- | :------- | :----------------- |
+| `id` | `int` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `name` | `varchar(191)` | No | No | No | - |
+| `email` | `varchar(191)` | No | No | **✔️** | - |
+
+
+
+As a next step, you will introspect your database. The result of the introspection will be a [data model](/orm/prisma-schema/data-model/models) inside your Prisma schema.
+
+Run the following command to introspect your database:
+
+```terminal copy
+npx prisma db pull
+```
+
+This command reads the `DATABASE_URL` environment variable that's defined in `.env` and connects to your database. Once the connection is established, it introspects the database (i.e. it _reads the database schema_). It then translates the database schema from SQL into a Prisma data model.
+
+After the introspection is complete, your Prisma schema is updated:
+
+
+
+The data model now looks similar to this:
+
+```prisma file=prisma/schema.prisma showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ createdAt DateTime @default(now())
+ updatedAt DateTime
+ title String @db.VarChar(255)
+ content String?
+ published Boolean @default(false)
+ authorId Int
+
+ @@index([authorId])
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ userId Int @unique
+
+ @@index([userId])
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+}
+```
+
+:::info
+
+Refer to the [Prisma schema reference](/orm/reference/prisma-schema-reference) for detailed information about the schema definition.
+
+:::
+
+Prisma's data model is a declarative representation of your database schema and serves as the foundation for the generated Prisma Client library. Your Prisma Client instance will expose queries that are _tailored_ to these models.
+
+You will then need to add in any missing relations between your data using [relation fields](/orm/prisma-schema/data-model/relations#relation-fields):
+
+```prisma file=prisma/schema.prisma highlight=8,17,27,28;add showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ createdAt DateTime @default(now())
+ updatedAt DateTime
+ title String @db.VarChar(255)
+ content String?
+ published Boolean @default(false)
+ //add-next-line
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+
+ @@index([authorId])
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ //add-next-line
+ user User @relation(fields: [userId], references: [id])
+ userId Int @unique
+
+ @@index([userId])
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ //add-start
+ posts Post[]
+ profile Profile?
+ //add-end
+}
+```
+
+After this, run introspection on your database for a second time:
+
+```terminal copy
+npx prisma db pull
+```
+
+Prisma Migrate will now keep the manually added relation fields.
+
+Because relation fields are _virtual_ (i.e. they _do not directly manifest in the database_), you can manually rename them in your Prisma schema without touching the database.
+
+In this example, the database schema follows the [naming conventions](/orm/reference/prisma-schema-reference#naming-conventions) for Prisma ORM models. This optimizes the ergonomics of the generated Prisma Client API.
+
+
+ Using custom model and field names
+
+Sometimes though, you may want to make additional changes to the names of the columns and tables that are exposed in the Prisma Client API. A common example is to translate _snake_case_ notation which is often used in database schemas into _PascalCase_ and _camelCase_ notations which feel more natural for JavaScript/TypeScript developers.
+
+Assume you obtained the following model from introspection that's based on _snake_case_ notation:
+
+```prisma no-lines
+model my_user {
+ user_id Int @id @default(autoincrement())
+ first_name String?
+ last_name String @unique
+}
+```
+
+If you generated a Prisma Client API for this model, it would pick up the _snake_case_ notation in its API:
+
+```ts no-lines
+const user = await prisma.my_user.create({
+ data: {
+ first_name: 'Alice',
+ last_name: 'Smith',
+ },
+})
+```
+
+If you don't want to use the table and column names from your database in your Prisma Client API, you can configure them with [`@map` and `@@map`](/orm/prisma-schema/data-model/models#mapping-model-names-to-tables-or-collections):
+
+```prisma no-lines
+model MyUser {
+ userId Int @id @default(autoincrement()) @map("user_id")
+ firstName String? @map("first_name")
+ lastName String @unique @map("last_name")
+
+ @@map("my_user")
+}
+```
+
+With this approach, you can name your model and its fields whatever you like and use the `@map` (for field names) and `@@map` (for models names) to point to the underlying tables and columns. Your Prisma Client API now looks as follows:
+
+```ts no-lines
+const user = await prisma.myUser.create({
+ data: {
+ firstName: 'Alice',
+ lastName: 'Smith',
+ },
+})
+```
+
+Learn more about this on the [Configuring your Prisma Client API](/orm/prisma-client/setup-and-configuration/custom-model-and-field-names) page.
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-typescript-postgresql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-typescript-postgresql.mdx
new file mode 100644
index 0000000000..e87d3f4888
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-typescript-postgresql.mdx
@@ -0,0 +1,217 @@
+---
+title: 'Introspection for PostgreSQL in a TypeScript project'
+sidebar_label: 'Introspection'
+metaTitle: 'Introspection with Prisma ORM, TypeScript, and PostgreSQL'
+metaDescription: 'Introspect your existing project with Prisma ORM, TypeScript, and PostgreSQL'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-typescript-postgresql
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/baseline-your-database-typescript-postgresql
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-
+---
+
+
+## Introspect your database with Prisma ORM
+
+For the purpose of this guide, we'll use a demo SQL schema with three tables:
+
+```sql no-lines
+CREATE TABLE "public"."User" (
+ id SERIAL PRIMARY KEY NOT NULL,
+ name VARCHAR(255),
+ email VARCHAR(255) UNIQUE NOT NULL
+);
+
+CREATE TABLE "public"."Post" (
+ id SERIAL PRIMARY KEY NOT NULL,
+ title VARCHAR(255) NOT NULL,
+ "createdAt" TIMESTAMP NOT NULL DEFAULT now(),
+ content TEXT,
+ published BOOLEAN NOT NULL DEFAULT false,
+ "authorId" INTEGER NOT NULL,
+ FOREIGN KEY ("authorId") REFERENCES "public"."User"(id)
+);
+
+CREATE TABLE "public"."Profile" (
+ id SERIAL PRIMARY KEY NOT NULL,
+ bio TEXT,
+ "userId" INTEGER UNIQUE NOT NULL,
+ FOREIGN KEY ("userId") REFERENCES "public"."User"(id)
+);
+```
+
+> **Note**: Some fields are written in double-quotes to ensure PostgreSQL uses proper casing. If no double-quotes were used, PostgreSQL would just read everything as _lowercase_ characters.
+
+
+Expand for a graphical overview of the tables
+
+**User**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :------------- | :---------- | :---------- | :------- | :----------------- |
+| `id` | `SERIAL` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `name` | `VARCHAR(255)` | No | No | No | - |
+| `email` | `VARCHAR(255)` | No | No | **✔️** | - |
+
+**Post**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :------------- | :---------- | :---------- | :------- | :----------------- |
+| `id` | `SERIAL` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `createdAt` | `TIMESTAMP` | No | No | **✔️** | `now()` |
+| `title` | `VARCHAR(255)` | No | No | **✔️** | - |
+| `content` | `TEXT` | No | No | No | - |
+| `published` | `BOOLEAN` | No | No | **✔️** | `false` |
+| `authorId` | `INTEGER` | No | **✔️** | **✔️** | - |
+
+**Profile**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :-------- | :---------- | :---------- | :------- | :----------------- |
+| `id` | `SERIAL` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `bio` | `TEXT` | No | No | No | - |
+| `userId` | `INTEGER` | No | **✔️** | **✔️** | - |
+
+
+
+As a next step, you will introspect your database. The result of the introspection will be a [data model](/orm/prisma-schema/data-model/models) inside your Prisma schema.
+
+Run the following command to introspect your database:
+
+```terminal copy
+npx prisma db pull
+```
+
+This command reads the `DATABASE_URL` environment variable that's defined in `.env` and connects to your database. Once the connection is established, it introspects the database (i.e. it _reads the database schema_). It then translates the database schema from SQL into a data model in your Prisma schema.
+
+After the introspection is complete, your Prisma schema is updated:
+
+
+
+The data model now looks similar to this (note that the fields on the models have been reordered for better readability):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String @db.VarChar(255)
+ createdAt DateTime @default(now()) @db.Timestamp(6)
+ content String?
+ published Boolean @default(false)
+ authorId Int
+ User User @relation(fields: [authorId], references: [id], onDelete: NoAction, onUpdate: NoAction)
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ userId Int @unique
+ User User @relation(fields: [userId], references: [id], onDelete: NoAction, onUpdate: NoAction)
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ name String? @db.VarChar(255)
+ email String @unique @db.VarChar(255)
+ Post Post[]
+ Profile Profile?
+}
+```
+
+Prisma ORM's data model is a declarative representation of your database schema and serves as the foundation for the generated Prisma Client library. Your Prisma Client instance will expose queries that are _tailored_ to these models.
+
+Right now, there's a few minor "issues" with the data model:
+
+- The `User` relation field is uppercased and therefore doesn't adhere to Prisma's [naming conventions](/orm/reference/prisma-schema-reference#naming-conventions-1) . To express more "semantics", it would also be nice if this field was called `author` to _describe_ the relationship between `User` and `Post` better.
+- The `Post` and `Profile` relation fields on `User` as well as the `User` relation field on `Profile` are all uppercased. To adhere to Prisma's [naming conventions](/orm/reference/prisma-schema-reference#naming-conventions-1) , both fields should be lowercased to `post`, `profile` and `user`.
+- Even after lowercasing, the `post` field on `User` is still slightly misnamed. That's because it actually refers to a [list](/orm/prisma-schema/data-model/models#type-modifiers) of posts – a better name therefore would be the plural form: `posts`.
+
+These changes are relevant for the generated Prisma Client API where using lowercased relation fields `author`, `posts`, `profile` and `user` will feel more natural and idiomatic to JavaScript/TypeScript developers. You can therefore [configure your Prisma Client API](/orm/prisma-client/setup-and-configuration/custom-model-and-field-names).
+
+Because [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) are _virtual_ (i.e. they _do not directly manifest in the database_), you can manually rename them in your Prisma schema without touching the database:
+
+```prisma file=prisma/schema.prisma highlight=8,15,22,23;edit showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String @db.VarChar(255)
+ createdAt DateTime @default(now()) @db.Timestamp(6)
+ content String?
+ published Boolean @default(false)
+ authorId Int
+ //edit-next-line
+ author User @relation(fields: [authorId], references: [id], onDelete: NoAction, onUpdate: NoAction)
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ userId Int @unique
+ //edit-next-line
+ user User @relation(fields: [userId], references: [id], onDelete: NoAction, onUpdate: NoAction)
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ name String? @db.VarChar(255)
+ email String @unique @db.VarChar(255)
+ //edit-start
+ posts Post[]
+ profile Profile?
+ //edit-end
+}
+```
+
+In this example, the database schema did follow the [naming conventions](/orm/reference/prisma-schema-reference#naming-conventions) for Prisma ORM models (only the virtual relation fields that were generated from introspection did not adhere to them and needed adjustment). This optimizes the ergonomics of the generated Prisma Client API.
+
+
+ Using custom model and field names
+
+Sometimes though, you may want to make additional changes to the names of the columns and tables that are exposed in the Prisma Client API. A common example is to translate _snake_case_ notation which is often used in database schemas into _PascalCase_ and _camelCase_ notations which feel more natural for JavaScript/TypeScript developers.
+
+Assume you obtained the following model from introspection that's based on _snake_case_ notation:
+
+```prisma no-lines
+model my_user {
+ user_id Int @id @default(autoincrement())
+ first_name String?
+ last_name String @unique
+}
+```
+
+If you generated a Prisma Client API for this model, it would pick up the _snake_case_ notation in its API:
+
+```ts no-lines
+const user = await prisma.my_user.create({
+ data: {
+ first_name: 'Alice',
+ last_name: 'Smith',
+ },
+})
+```
+
+If you don't want to use the table and column names from your database in your Prisma Client API, you can configure them with [`@map` and `@@map`](/orm/prisma-schema/data-model/models#mapping-model-names-to-tables-or-collections):
+
+```prisma no-lines
+model MyUser {
+ userId Int @id @default(autoincrement()) @map("user_id")
+ firstName String? @map("first_name")
+ lastName String @unique @map("last_name")
+
+ @@map("my_user")
+}
+```
+
+With this approach, you can name your model and its fields whatever you like and use the `@map` (for field names) and `@@map` (for models names) to point to the underlying tables and columns. Your Prisma Client API now looks as follows:
+
+```ts no-lines
+const user = await prisma.myUser.create({
+ data: {
+ firstName: 'Alice',
+ lastName: 'Smith',
+ },
+})
+```
+
+Learn more about this on the [Configuring your Prisma Client API](/orm/prisma-client/setup-and-configuration/custom-model-and-field-names) page.
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-typescript-sqlserver.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-typescript-sqlserver.mdx
new file mode 100644
index 0000000000..811cbef53c
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/150-introspection-typescript-sqlserver.mdx
@@ -0,0 +1,225 @@
+---
+title: 'Introspection for SQL Server in a TypeScript project'
+sidebar_label: 'Introspection'
+metaTitle: 'Introspection with Prisma ORM, TypeScript, and SQL Server'
+metaDescription: 'Introspect your existing project with Prisma ORM, TypeScript, and SQL Server'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/connect-your-database-typescript-sqlserver
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/baseline-your-database-typescript-sqlserver
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-
+---
+
+
+## Introspect your database with Prisma ORM
+
+For the purpose of this guide, we'll use a demo SQL schema with three tables:
+
+```sql no-lines
+CREATE TABLE [dbo].[Post] (
+ [id] INT NOT NULL IDENTITY(1,1),
+ [createdAt] DATETIME2 NOT NULL CONSTRAINT [Post_createdAt_df] DEFAULT CURRENT_TIMESTAMP,
+ [updatedAt] DATETIME2 NOT NULL,
+ [title] VARCHAR(255) NOT NULL,
+ [content] NVARCHAR(1000),
+ [published] BIT NOT NULL CONSTRAINT [Post_published_df] DEFAULT 0,
+ [authorId] INT NOT NULL,
+ CONSTRAINT [Post_pkey] PRIMARY KEY ([id])
+);
+
+CREATE TABLE [dbo].[Profile] (
+ [id] INT NOT NULL IDENTITY(1,1),
+ [bio] NVARCHAR(1000),
+ [userId] INT NOT NULL,
+ CONSTRAINT [Profile_pkey] PRIMARY KEY ([id]),
+ CONSTRAINT [Profile_userId_key] UNIQUE ([userId])
+);
+
+CREATE TABLE [dbo].[User] (
+ [id] INT NOT NULL IDENTITY(1,1),
+ [email] NVARCHAR(1000) NOT NULL,
+ [name] NVARCHAR(1000),
+ CONSTRAINT [User_pkey] PRIMARY KEY ([id]),
+ CONSTRAINT [User_email_key] UNIQUE ([email])
+);
+
+ALTER TABLE [dbo].[Post] ADD CONSTRAINT [Post_authorId_fkey] FOREIGN KEY ([authorId]) REFERENCES [dbo].[User]([id]) ON DELETE NO ACTION ON UPDATE CASCADE;
+
+ALTER TABLE [dbo].[Profile] ADD CONSTRAINT [Profile_userId_fkey] FOREIGN KEY ([userId]) REFERENCES [dbo].[User]([id]) ON DELETE NO ACTION ON UPDATE CASCADE;
+```
+
+
+Expand for a graphical overview of the tables
+
+**User**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :--------------- | :---------- | :---------- | :------- | :----------------- |
+| `id` | `INT` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `name` | `NVARCHAR(1000)` | No | No | No | - |
+| `email` | `NVARCHAR(1000)` | No | No | **✔️** | - |
+
+**Post**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :--------------- | :---------- | :---------- | :------- | :----------------- |
+| `id` | `INT` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `createdAt` | `DATETIME2` | No | No | **✔️** | `now()` |
+| `updatedAt` | `DATETIME2` | No | No | **✔️** | |
+| `title` | `VARCHAR(255)` | No | No | **✔️** | - |
+| `content` | `NVARCHAR(1000)` | No | No | No | - |
+| `published` | `BIT` | No | No | **✔️** | `false` |
+| `authorId` | `INT` | No | **✔️** | **✔️** | - |
+
+**Profile**
+
+| Column name | Type | Primary key | Foreign key | Required | Default |
+| :---------- | :--------------- | :---------- | :---------- | :------- | :----------------- |
+| `id` | `INT` | **✔️** | No | **✔️** | _autoincrementing_ |
+| `bio` | `NVARCHAR(1000)` | No | No | No | - |
+| `userId` | `INT` | No | **✔️** | **✔️** | - |
+
+
+
+As a next step, you will introspect your database. The result of the introspection will be a [data model](/orm/prisma-schema/data-model/models) inside your Prisma schema.
+
+Run the following command to introspect your database:
+
+```terminal copy
+npx prisma db pull
+```
+
+This command reads the `DATABASE_URL` environment variable that's defined in `.env` and connects to your database. Once the connection is established, it introspects the database (i.e. it _reads the database schema_). It then translates the database schema from SQL into a Prisma data model.
+
+After the introspection is complete, your Prisma schema is updated:
+
+
+
+The data model now looks similar to this (note that the fields on the models have been reordered for better readability):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String @db.VarChar(255)
+ createdAt DateTime @default(now()) @db.Timestamp(6)
+ content String?
+ published Boolean @default(false)
+ authorId Int
+ User User @relation(fields: [authorId], references: [id])
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ userId Int @unique
+ User User @relation(fields: [userId], references: [id])
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ name String? @db.VarChar(255)
+ email String @unique @db.VarChar(255)
+ Post Post[]
+ Profile Profile?
+}
+```
+
+Prisma's data model is a declarative representation of your database schema and serves as the foundation for the generated Prisma Client library. Your Prisma Client instance will expose queries that are _tailored_ to these models.
+
+Right now, there's a few minor "issues" with the data model:
+
+- The `User` relation field is uppercased and therefore doesn't adhere to Prisma's [naming conventions](/orm/reference/prisma-schema-reference#naming-conventions-1) . To express more "semantics", it would also be nice if this field was called `author` to _describe_ the relationship between `User` and `Post` better.
+- The `Post` and `Profile` relation fields on `User` as well as the `User` relation field on `Profile` are all uppercased. To adhere to Prisma's [naming conventions](/orm/reference/prisma-schema-reference#naming-conventions-1) , both fields should be lowercased to `post`, `profile` and `user`.
+- Even after lowercasing, the `post` field on `User` is still slightly misnamed. That's because it actually refers to a [list](/orm/prisma-schema/data-model/models#type-modifiers) of posts – a better name therefore would be the plural form: `posts`.
+
+These changes are relevant for the generated Prisma Client API where using lowercased relation fields `author`, `posts`, `profile` and `user` will feel more natural and idiomatic to JavaScript/TypeScript developers. You can therefore [configure your Prisma Client API](/orm/prisma-client/setup-and-configuration/custom-model-and-field-names).
+
+Because [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) are _virtual_ (i.e. they _do not directly manifest in the database_), you can manually rename them in your Prisma schema without touching the database:
+
+```prisma file=prisma/schema.prisma highlight=7,14,22,23;edit showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String @db.VarChar(255)
+ createdAt DateTime @default(now()) @db.Timestamp(6)
+ content String?
+ published Boolean @default(false)
+ //edit-next-line
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ //edit-next-line
+ user User @relation(fields: [userId], references: [id])
+ userId Int @unique
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique @db.VarChar(255)
+ name String? @db.VarChar(255)
+ //edit-start
+ posts Post[]
+ profile Profile?
+ //edit-end
+}
+```
+
+In this example, the database schema did follow the [naming conventions](/orm/reference/prisma-schema-reference#naming-conventions) for Prisma ORM models (only the virtual relation fields that were generated from introspection did not adhere to them and needed adjustment). This optimizes the ergonomics of the generated Prisma Client API.
+
+
+ Using custom model and field names
+
+Sometimes though, you may want to make additional changes to the names of the columns and tables that are exposed in the Prisma Client API. A common example is to translate _snake_case_ notation which is often used in database schemas into _PascalCase_ and _camelCase_ notations which feel more natural for JavaScript/TypeScript developers.
+
+Assume you obtained the following model from introspection that's based on _snake_case_ notation:
+
+```prisma no-lines
+model my_user {
+ user_id Int @id @default(autoincrement())
+ first_name String?
+ last_name String @unique
+}
+```
+
+If you generated a Prisma Client API for this model, it would pick up the _snake_case_ notation in its API:
+
+```ts no-lines
+const user = await prisma.my_user.create({
+ data: {
+ first_name: 'Alice',
+ last_name: 'Smith',
+ },
+})
+```
+
+If you don't want to use the table and column names from your database in your Prisma Client API, you can configure them with [`@map` and `@@map`](/orm/prisma-schema/data-model/models#mapping-model-names-to-tables-or-collections):
+
+```prisma no-lines
+model MyUser {
+ userId Int @id @default(autoincrement()) @map("user_id")
+ firstName String? @map("first_name")
+ lastName String @unique @map("last_name")
+
+ @@map("my_user")
+}
+```
+
+With this approach, you can name your model and its fields whatever you like and use the `@map` (for field names) and `@@map` (for models names) to point to the underlying tables and columns. Your Prisma Client API now looks as follows:
+
+```ts no-lines
+const user = await prisma.myUser.create({
+ data: {
+ firstName: 'Alice',
+ lastName: 'Smith',
+ },
+})
+```
+
+Learn more about this on the [Configuring your Prisma Client API](/orm/prisma-client/setup-and-configuration/custom-model-and-field-names) page.
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/170-baseline-your-database-node-cockroachdb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/170-baseline-your-database-node-cockroachdb.mdx
new file mode 100644
index 0000000000..25c6df618c
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/170-baseline-your-database-node-cockroachdb.mdx
@@ -0,0 +1,85 @@
+---
+title: 'Baseline with Prisma ORM, JavaScript, and CockroachDB'
+sidebar_label: 'Baseline your database'
+metaTitle: 'Baseline with Prisma ORM, JavaScript, and CockroachDB'
+metaDescription: 'Baseline your database with Prisma ORM, JavaScript, and CockroachDB'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-node-cockroachdb
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-node-cockroachdb
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/baseline-your-database-
+---
+
+
+## Create an initial migration
+
+To use Prisma Migrate with the database you introspected in the last section, you will need to [baseline your database](/orm/prisma-migrate/getting-started).
+
+Baselining refers to initializing your migration history for a database that might already contain data and **cannot be reset**, such as your production database. Baselining tells Prisma Migrate to assume that one or more migrations have already been applied to your database.
+
+To baseline your database, use [`prisma migrate diff`](/orm/reference/prisma-cli-reference#migrate-diff) to compare your schema and database, and save the output into a SQL file.
+
+First, create a `migrations` directory and add a directory inside with your preferred name for the migration. In this example, we will use `0_init` as the migration name:
+
+```terminal
+mkdir -p prisma/migrations/0_init
+```
+
+
+
+`-p` will recursively create any missing folders in the path you provide.
+
+
+
+Next, generate the migration file with `prisma migrate diff`. Use the following arguments:
+
+- `--from-empty`: assumes the data model you're migrating from is empty
+- `--to-schema-datamodel`: the current database state using the URL in the `datasource` block
+- `--script`: output a SQL script
+
+```terminal wrap
+npx prisma migrate diff --from-empty --to-schema-datamodel prisma/schema.prisma --script > prisma/migrations/0_init/migration.sql
+```
+
+## Review the migration
+
+The command will generate a migration that should resemble the following script:
+
+```sql file=prisma/migrations/0_init/migration.sql
+CREATE TABLE "User" (
+ id INT8 PRIMARY KEY DEFAULT unique_rowid(),
+ name STRING(255),
+ email STRING(255) UNIQUE NOT NULL
+);
+
+CREATE TABLE "Post" (
+ id INT8 PRIMARY KEY DEFAULT unique_rowid(),
+ title STRING(255) UNIQUE NOT NULL,
+ "createdAt" TIMESTAMP NOT NULL DEFAULT now(),
+ content STRING,
+ published BOOLEAN NOT NULL DEFAULT false,
+ "authorId" INT8 NOT NULL,
+ FOREIGN KEY ("authorId") REFERENCES "User"(id)
+);
+
+CREATE TABLE "Profile" (
+ id INT8 PRIMARY KEY DEFAULT unique_rowid(),
+ bio STRING,
+ "userId" INT8 UNIQUE NOT NULL,
+ FOREIGN KEY ("userId") REFERENCES "User"(id)
+);
+```
+
+Review the SQL migration file to ensure everything is correct.
+
+Next, mark the migration as applied using `prisma migrate resolve` with the `--applied` argument.
+
+```terminal
+npx prisma migrate resolve --applied 0_init
+```
+
+The command will mark `0_init` as applied by adding it to the `_prisma_migrations` table.
+
+You now have a baseline for your current database schema. To make further changes to your database schema, you can update your Prisma schema and use `prisma migrate dev` to apply the changes to your database.
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/170-baseline-your-database-node-mysql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/170-baseline-your-database-node-mysql.mdx
new file mode 100644
index 0000000000..ec112cdc58
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/170-baseline-your-database-node-mysql.mdx
@@ -0,0 +1,101 @@
+---
+title: 'Baseline with Prisma ORM, JavaScript, and MySQL'
+sidebar_label: 'Baseline your database'
+metaTitle: 'Baseline with Prisma ORM, JavaScript, and MySQL'
+metaDescription: 'Baseline your database with Prisma ORM, JavaScript, and MySQL'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-node-mysql
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-node-mysql
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/baseline-your-database-
+---
+
+
+## Create an initial migration
+
+To use Prisma Migrate with the database you introspected in the last section, you will need to [baseline your database](/orm/prisma-migrate/getting-started).
+
+Baselining refers to initializing your migration history for a database that might already contain data and **cannot be reset**, such as your production database. Baselining tells Prisma Migrate to assume that one or more migrations have already been applied to your database.
+
+To baseline your database, use [`prisma migrate diff`](/orm/reference/prisma-cli-reference#migrate-diff) to compare your schema and database, and save the output into a SQL file.
+
+First, create a `migrations` directory and add a directory inside with your preferred name for the migration. In this example, we will use `0_init` as the migration name:
+
+```terminal
+mkdir -p prisma/migrations/0_init
+```
+
+
+
+`-p` will recursively create any missing folders in the path you provide.
+
+
+
+Next, generate the migration file with `prisma migrate diff`. Use the following arguments:
+
+- `--from-empty`: assumes the data model you're migrating from is empty
+- `--to-schema-datamodel`: the current database state using the URL in the `datasource` block
+- `--script`: output a SQL script
+
+```terminal wrap
+npx prisma migrate diff --from-empty --to-schema-datamodel prisma/schema.prisma --script > prisma/migrations/0_init/migration.sql
+```
+
+## Review the migration
+
+The command will generate a migration that should resemble the following script:
+
+```sql file=prisma/migrations/0_init/migration.sql
+-- CreateTable
+CREATE TABLE `Post` (
+ `id` INTEGER NOT NULL AUTO_INCREMENT,
+ `title` VARCHAR(255) NOT NULL,
+ `createdAt` TIMESTAMP(0) NOT NULL DEFAULT CURRENT_TIMESTAMP(0),
+ `content` TEXT NULL,
+ `published` BOOLEAN NOT NULL DEFAULT false,
+ `authorId` INTEGER NOT NULL,
+
+ INDEX `authorId`(`authorId`),
+ PRIMARY KEY (`id`)
+) DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
+
+-- CreateTable
+CREATE TABLE `Profile` (
+ `id` INTEGER NOT NULL AUTO_INCREMENT,
+ `bio` TEXT NULL,
+ `userId` INTEGER NOT NULL,
+
+ UNIQUE INDEX `userId`(`userId`),
+ PRIMARY KEY (`id`)
+) DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
+
+-- CreateTable
+CREATE TABLE `User` (
+ `id` INTEGER NOT NULL AUTO_INCREMENT,
+ `name` VARCHAR(255) NULL,
+ `email` VARCHAR(255) NOT NULL,
+
+ UNIQUE INDEX `email`(`email`),
+ PRIMARY KEY (`id`)
+) DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
+
+-- AddForeignKey
+ALTER TABLE `Post` ADD CONSTRAINT `Post_ibfk_1` FOREIGN KEY (`authorId`) REFERENCES `User`(`id`) ON DELETE RESTRICT ON UPDATE RESTRICT;
+
+-- AddForeignKey
+ALTER TABLE `Profile` ADD CONSTRAINT `Profile_ibfk_1` FOREIGN KEY (`userId`) REFERENCES `User`(`id`) ON DELETE RESTRICT ON UPDATE RESTRICT;
+```
+
+Review the SQL migration file to ensure everything is correct.
+
+Next, mark the migration as applied using `prisma migrate resolve` with the `--applied` argument.
+
+```terminal
+npx prisma migrate resolve --applied 0_init
+```
+
+The command will mark `0_init` as applied by adding it to the `_prisma_migrations` table.
+
+You now have a baseline for your current database schema. To make further changes to your database schema, you can update your Prisma schema and use `prisma migrate dev` to apply the changes to your database.
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/170-baseline-your-database-node-postgresql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/170-baseline-your-database-node-postgresql.mdx
new file mode 100644
index 0000000000..79cbdc4a08
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/170-baseline-your-database-node-postgresql.mdx
@@ -0,0 +1,104 @@
+---
+title: 'Baseline with Prisma ORM, JavaScript, and PostgreSQL'
+sidebar_label: 'Baseline your database'
+metaTitle: 'Baseline with Prisma ORM, JavaScript, and PostgreSQL'
+metaDescription: 'Baseline your database with Prisma ORM, JavaScript, and PostgreSQL'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-node-postgresql
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-node-postgresql
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/baseline-your-database-
+---
+
+
+## Create an initial migration
+
+To use Prisma Migrate with the database you introspected in the last section, you will need to [baseline your database](/orm/prisma-migrate/getting-started).
+
+Baselining refers to initializing your migration history for a database that might already contain data and **cannot be reset**, such as your production database. Baselining tells Prisma Migrate to assume that one or more migrations have already been applied to your database.
+
+To baseline your database, use [`prisma migrate diff`](/orm/reference/prisma-cli-reference#migrate-diff) to compare your schema and database, and save the output into a SQL file.
+
+First, create a `migrations` directory and add a directory inside with your preferred name for the migration. In this example, we will use `0_init` as the migration name:
+
+```terminal
+mkdir -p prisma/migrations/0_init
+```
+
+
+
+`-p` will recursively create any missing folders in the path you provide.
+
+
+
+Next, generate the migration file with `prisma migrate diff`. Use the following arguments:
+
+- `--from-empty`: assumes the data model you're migrating from is empty
+- `--to-schema-datamodel`: the current database state using the URL in the `datasource` block
+- `--script`: output a SQL script
+
+```terminal wrap
+npx prisma migrate diff --from-empty --to-schema-datamodel prisma/schema.prisma --script > prisma/migrations/0_init/migration.sql
+```
+
+## Review the migration
+
+The command will generate a migration that should resemble the following script:
+
+```sql file=prisma/migrations/0_init/migration.sql
+-- CreateTable
+CREATE TABLE "Post" (
+ "id" SERIAL NOT NULL,
+ "title" VARCHAR(255) NOT NULL,
+ "createdAt" TIMESTAMP(6) NOT NULL DEFAULT CURRENT_TIMESTAMP,
+ "content" TEXT,
+ "published" BOOLEAN NOT NULL DEFAULT false,
+ "authorId" INTEGER NOT NULL,
+
+ CONSTRAINT "Post_pkey" PRIMARY KEY ("id")
+);
+
+-- CreateTable
+CREATE TABLE "Profile" (
+ "id" SERIAL NOT NULL,
+ "bio" TEXT,
+ "userId" INTEGER NOT NULL,
+
+ CONSTRAINT "Profile_pkey" PRIMARY KEY ("id")
+);
+
+-- CreateTable
+CREATE TABLE "User" (
+ "id" SERIAL NOT NULL,
+ "name" VARCHAR(255),
+ "email" VARCHAR(255) NOT NULL,
+
+ CONSTRAINT "User_pkey" PRIMARY KEY ("id")
+);
+
+-- CreateIndex
+CREATE UNIQUE INDEX "Profile_userId_key" ON "Profile"("userId");
+
+-- CreateIndex
+CREATE UNIQUE INDEX "User_email_key" ON "User"("email");
+
+-- AddForeignKey
+ALTER TABLE "Post" ADD CONSTRAINT "Post_authorId_fkey" FOREIGN KEY ("authorId") REFERENCES "User"("id") ON DELETE NO ACTION ON UPDATE NO ACTION;
+
+-- AddForeignKey
+ALTER TABLE "Profile" ADD CONSTRAINT "Profile_userId_fkey" FOREIGN KEY ("userId") REFERENCES "User"("id") ON DELETE NO ACTION ON UPDATE NO ACTION;
+```
+
+Review the SQL migration file to ensure everything is correct.
+
+Next, mark the migration as applied using `prisma migrate resolve` with the `--applied` argument.
+
+```terminal
+npx prisma migrate resolve --applied 0_init
+```
+
+The command will mark `0_init` as applied by adding it to the `_prisma_migrations` table.
+
+You now have a baseline for your current database schema. To make further changes to your database schema, you can update your Prisma schema and use `prisma migrate dev` to apply the changes to your database.
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/170-baseline-your-database-node-sqlserver.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/170-baseline-your-database-node-sqlserver.mdx
new file mode 100644
index 0000000000..436408fa9d
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/170-baseline-your-database-node-sqlserver.mdx
@@ -0,0 +1,93 @@
+---
+title: 'Baseline with Prisma ORM, JavaScript, and SQL Server'
+sidebar_label: 'Baseline your database'
+metaTitle: 'Baseline with Prisma ORM, JavaScript, and SQL Server'
+metaDescription: 'Baseline your database with Prisma ORM, JavaScript, and SQL Server'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-node-sqlserver
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-node-sqlserver
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/baseline-your-database-
+---
+
+
+## Create an initial migration
+
+To use Prisma Migrate with the database you introspected in the last section, you will need to [baseline your database](/orm/prisma-migrate/getting-started).
+
+Baselining refers to initializing your migration history for a database that might already contain data and **cannot be reset**, such as your production database. Baselining tells Prisma Migrate to assume that one or more migrations have already been applied to your database.
+
+To baseline your database, use [`prisma migrate diff`](/orm/reference/prisma-cli-reference#migrate-diff) to compare your schema and database, and save the output into a SQL file.
+
+First, create a `migrations` directory and add a directory inside with your preferred name for the migration. In this example, we will use `0_init` as the migration name:
+
+```terminal
+mkdir -p prisma/migrations/0_init
+```
+
+
+
+`-p` will recursively create any missing folders in the path you provide.
+
+
+
+Next, generate the migration file with `prisma migrate diff`. Use the following arguments:
+
+- `--from-empty`: assumes the data model you're migrating from is empty
+- `--to-schema-datamodel`: the current database state using the URL in the `datasource` block
+- `--script`: output a SQL script
+
+```terminal wrap
+npx prisma migrate diff --from-empty --to-schema-datamodel prisma/schema.prisma --script > prisma/migrations/0_init/migration.sql
+```
+
+## Review the migration
+
+The command will generate a migration that should resemble the following script:
+
+```sql file=prisma/migrations/0_init/migration.sql
+CREATE TABLE [dbo].[Post] (
+ [id] INT NOT NULL IDENTITY(1,1),
+ [createdAt] DATETIME2 NOT NULL CONSTRAINT [Post_createdAt_df] DEFAULT CURRENT_TIMESTAMP,
+ [updatedAt] DATETIME2 NOT NULL,
+ [title] VARCHAR(255) NOT NULL,
+ [content] NVARCHAR(1000),
+ [published] BIT NOT NULL CONSTRAINT [Post_published_df] DEFAULT 0,
+ [authorId] INT NOT NULL,
+ CONSTRAINT [Post_pkey] PRIMARY KEY ([id])
+);
+
+CREATE TABLE [dbo].[Profile] (
+ [id] INT NOT NULL IDENTITY(1,1),
+ [bio] NVARCHAR(1000),
+ [userId] INT NOT NULL,
+ CONSTRAINT [Profile_pkey] PRIMARY KEY ([id]),
+ CONSTRAINT [Profile_userId_key] UNIQUE ([userId])
+);
+
+CREATE TABLE [dbo].[User] (
+ [id] INT NOT NULL IDENTITY(1,1),
+ [email] NVARCHAR(1000) NOT NULL,
+ [name] NVARCHAR(1000),
+ CONSTRAINT [User_pkey] PRIMARY KEY ([id]),
+ CONSTRAINT [User_email_key] UNIQUE ([email])
+);
+
+ALTER TABLE [dbo].[Post] ADD CONSTRAINT [Post_authorId_fkey] FOREIGN KEY ([authorId]) REFERENCES [dbo].[User]([id]) ON DELETE NO ACTION ON UPDATE CASCADE;
+
+ALTER TABLE [dbo].[Profile] ADD CONSTRAINT [Profile_userId_fkey] FOREIGN KEY ([userId]) REFERENCES [dbo].[User]([id]) ON DELETE NO ACTION ON UPDATE CASCADE;
+```
+
+Review the SQL migration file to ensure everything is correct.
+
+Next, mark the migration as applied using `prisma migrate resolve` with the `--applied` argument.
+
+```terminal
+npx prisma migrate resolve --applied 0_init
+```
+
+The command will mark `0_init` as applied by adding it to the `_prisma_migrations` table.
+
+You now have a baseline for your current database schema. To make further changes to your database schema, you can update your Prisma schema and use `prisma migrate dev` to apply the changes to your database.
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/170-baseline-your-database-typescript-cockroachdb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/170-baseline-your-database-typescript-cockroachdb.mdx
new file mode 100644
index 0000000000..65e048db8b
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/170-baseline-your-database-typescript-cockroachdb.mdx
@@ -0,0 +1,74 @@
+---
+title: 'Baseline with Prisma ORM, TypeScript, and CockroachDB'
+sidebar_label: 'Baseline your database'
+metaTitle: 'Baseline with Prisma ORM, TypeScript, and CockroachDB'
+metaDescription: 'Baseline your database with Prisma ORM, TypeScript, and CockroachDB'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-typescript-cockroachdb
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-typescript-cockroachdb
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/baseline-your-database-
+---
+
+
+## Create an initial migration
+
+To use Prisma Migrate with the database you introspected in the last section, you will need to [baseline your database](/orm/prisma-migrate/getting-started).
+
+Baselining refers to initializing your migration history for a database that might already contain data and **cannot be reset**, such as your production database. Baselining tells Prisma Migrate to assume that one or more migrations have already been applied to your database.
+
+To baseline your database, use [`prisma migrate diff`](/orm/reference/prisma-cli-reference#migrate-diff) to compare your schema and database, and save the output into a SQL file.
+
+First, create a `migrations` directory and add a directory inside with your preferred name for the migration. In this example, we will use `0_init` as the migration name:
+
+```terminal
+mkdir -p prisma/migrations/0_init
+```
+
+
+
+`-p` will recursively create any missing folders in the path you provide.
+
+
+
+Next, generate the migration file with `prisma migrate diff`. Use the following arguments:
+
+- `--from-empty`: assumes the data model you're migrating from is empty
+- `--to-schema-datamodel`: the current database state using the URL in the `datasource` block
+- `--script`: output a SQL script
+
+```terminal wrap
+npx prisma migrate diff --from-empty --to-schema-datamodel prisma/schema.prisma --script > prisma/migrations/0_init/migration.sql
+```
+
+## Review the migration
+
+The command will generate a migration that should resemble the following script:
+
+
+```sql file=prisma/migrations/0_init/migration.sql
+CREATE TABLE "User" (
+ id INT8 PRIMARY KEY DEFAULT unique_rowid(),
+ name STRING(255),
+ email STRING(255) UNIQUE NOT NULL
+);
+
+CREATE TABLE "Post" (
+ id INT8 PRIMARY KEY DEFAULT unique_rowid(),
+ title STRING(255) UNIQUE NOT NULL,
+ "createdAt" TIMESTAMP NOT NULL DEFAULT now(),
+ content STRING,
+ published BOOLEAN NOT NULL DEFAULT false,
+ "authorId" INT8 NOT NULL,
+ FOREIGN KEY ("authorId") REFERENCES "User"(id)
+);
+
+CREATE TABLE "Profile" (
+ id INT8 PRIMARY KEY DEFAULT unique_rowid(),
+ bio STRING,
+ "userId" INT8 UNIQUE NOT NULL,
+ FOREIGN KEY ("userId") REFERENCES "User"(id)
+);
+```
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/170-baseline-your-database-typescript-mysql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/170-baseline-your-database-typescript-mysql.mdx
new file mode 100644
index 0000000000..f2c4008c40
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/170-baseline-your-database-typescript-mysql.mdx
@@ -0,0 +1,102 @@
+---
+title: 'Baseline with Prisma ORM, TypeScript, and MySQL'
+sidebar_label: 'Baseline your database'
+metaTitle: 'Baseline with Prisma ORM, TypeScript, and MySQL'
+metaDescription: 'Baseline your database with Prisma ORM, TypeScript, and MySQL'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-typescript-mysql
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-typescript-mysql
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/baseline-your-database-
+---
+
+
+## Create an initial migration
+
+To use Prisma Migrate with the database you introspected in the last section, you will need to [baseline your database](/orm/prisma-migrate/getting-started).
+
+Baselining refers to initializing your migration history for a database that might already contain data and **cannot be reset**, such as your production database. Baselining tells Prisma Migrate to assume that one or more migrations have already been applied to your database.
+
+To baseline your database, use [`prisma migrate diff`](/orm/reference/prisma-cli-reference#migrate-diff) to compare your schema and database, and save the output into a SQL file.
+
+First, create a `migrations` directory and add a directory inside with your preferred name for the migration. In this example, we will use `0_init` as the migration name:
+
+```terminal
+mkdir -p prisma/migrations/0_init
+```
+
+
+
+`-p` will recursively create any missing folders in the path you provide.
+
+
+
+Next, generate the migration file with `prisma migrate diff`. Use the following arguments:
+
+- `--from-empty`: assumes the data model you're migrating from is empty
+- `--to-schema-datamodel`: the current database state using the URL in the `datasource` block
+- `--script`: output a SQL script
+
+```terminal wrap
+npx prisma migrate diff --from-empty --to-schema-datamodel prisma/schema.prisma --script > prisma/migrations/0_init/migration.sql
+```
+
+## Review the migration
+
+The command will generate a migration that should resemble the following script:
+
+```sql file=prisma/migrations/0_init/migration.sql
+-- CreateTable
+CREATE TABLE `Post` (
+ `id` INTEGER NOT NULL AUTO_INCREMENT,
+ `title` VARCHAR(255) NOT NULL,
+ `createdAt` TIMESTAMP(0) NOT NULL DEFAULT CURRENT_TIMESTAMP(0),
+ `content` TEXT NULL,
+ `published` BOOLEAN NOT NULL DEFAULT false,
+ `authorId` INTEGER NOT NULL,
+
+ INDEX `authorId`(`authorId`),
+ PRIMARY KEY (`id`)
+) DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
+
+-- CreateTable
+CREATE TABLE `Profile` (
+ `id` INTEGER NOT NULL AUTO_INCREMENT,
+ `bio` TEXT NULL,
+ `userId` INTEGER NOT NULL,
+
+ UNIQUE INDEX `userId`(`userId`),
+ PRIMARY KEY (`id`)
+) DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
+
+-- CreateTable
+CREATE TABLE `User` (
+ `id` INTEGER NOT NULL AUTO_INCREMENT,
+ `name` VARCHAR(255) NULL,
+ `email` VARCHAR(255) NOT NULL,
+
+ UNIQUE INDEX `email`(`email`),
+ PRIMARY KEY (`id`)
+) DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
+
+-- AddForeignKey
+ALTER TABLE `Post` ADD CONSTRAINT `Post_ibfk_1` FOREIGN KEY (`authorId`) REFERENCES `User`(`id`) ON DELETE RESTRICT ON UPDATE RESTRICT;
+
+-- AddForeignKey
+ALTER TABLE `Profile` ADD CONSTRAINT `Profile_ibfk_1` FOREIGN KEY (`userId`) REFERENCES `User`(`id`) ON DELETE RESTRICT ON UPDATE RESTRICT;
+```
+
+
+Review the SQL migration file to ensure everything is correct.
+
+Next, mark the migration as applied using `prisma migrate resolve` with the `--applied` argument.
+
+```terminal
+npx prisma migrate resolve --applied 0_init
+```
+
+The command will mark `0_init` as applied by adding it to the `_prisma_migrations` table.
+
+You now have a baseline for your current database schema. To make further changes to your database schema, you can update your Prisma schema and use `prisma migrate dev` to apply the changes to your database.
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/170-baseline-your-database-typescript-postgresql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/170-baseline-your-database-typescript-postgresql.mdx
new file mode 100644
index 0000000000..7041fe9521
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/170-baseline-your-database-typescript-postgresql.mdx
@@ -0,0 +1,103 @@
+---
+title: 'Baseline with Prisma ORM, TypeScript, and PostgreSQL'
+sidebar_label: 'Baseline your database'
+metaTitle: 'Baseline with Prisma ORM, TypeScript, and PostgreSQL'
+metaDescription: 'Baseline your database with Prisma ORM, TypeScript, and PostgreSQL'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'cockroachdb']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-typescript-postgresql
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-typescript-postgresql
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/baseline-your-database-
+---
+
+
+## Create an initial migration
+
+To use Prisma Migrate with the database you introspected in the last section, you will need to [baseline your database](/orm/prisma-migrate/getting-started).
+
+Baselining refers to initializing your migration history for a database that might already contain data and **cannot be reset**, such as your production database. Baselining tells Prisma Migrate to assume that one or more migrations have already been applied to your database.
+
+To baseline your database, use [`prisma migrate diff`](/orm/reference/prisma-cli-reference#migrate-diff) to compare your schema and database, and save the output into a SQL file.
+
+First, create a `migrations` directory and add a directory inside with your preferred name for the migration. In this example, we will use `0_init` as the migration name:
+
+```terminal
+mkdir -p prisma/migrations/0_init
+```
+
+
+
+`-p` will recursively create any missing folders in the path you provide.
+
+
+
+Next, generate the migration file with `prisma migrate diff`. Use the following arguments:
+
+- `--from-empty`: assumes the data model you're migrating from is empty
+- `--to-schema-datamodel`: the current database state using the URL in the `datasource` block
+- `--script`: output a SQL script
+
+```terminal wrap
+npx prisma migrate diff --from-empty --to-schema-datamodel prisma/schema.prisma --script > prisma/migrations/0_init/migration.sql
+```
+
+## Review the migration
+
+The command will generate a migration that should resemble the following script:
+
+```sql file=prisma/migrations/0_init/migration.sql
+-- CreateTable
+CREATE TABLE "Post" (
+ "id" SERIAL NOT NULL,
+ "title" VARCHAR(255) NOT NULL,
+ "createdAt" TIMESTAMP(6) NOT NULL DEFAULT CURRENT_TIMESTAMP,
+ "content" TEXT,
+ "published" BOOLEAN NOT NULL DEFAULT false,
+ "authorId" INTEGER NOT NULL,
+
+ CONSTRAINT "Post_pkey" PRIMARY KEY ("id")
+);
+
+-- CreateTable
+CREATE TABLE "Profile" (
+ "id" SERIAL NOT NULL,
+ "bio" TEXT,
+ "userId" INTEGER NOT NULL,
+
+ CONSTRAINT "Profile_pkey" PRIMARY KEY ("id")
+);
+
+-- CreateTable
+CREATE TABLE "User" (
+ "id" SERIAL NOT NULL,
+ "name" VARCHAR(255),
+ "email" VARCHAR(255) NOT NULL,
+
+ CONSTRAINT "User_pkey" PRIMARY KEY ("id")
+);
+
+-- CreateIndex
+CREATE UNIQUE INDEX "Profile_userId_key" ON "Profile"("userId");
+
+-- CreateIndex
+CREATE UNIQUE INDEX "User_email_key" ON "User"("email");
+
+-- AddForeignKey
+ALTER TABLE "Post" ADD CONSTRAINT "Post_authorId_fkey" FOREIGN KEY ("authorId") REFERENCES "User"("id") ON DELETE NO ACTION ON UPDATE NO ACTION;
+
+-- AddForeignKey
+ALTER TABLE "Profile" ADD CONSTRAINT "Profile_userId_fkey" FOREIGN KEY ("userId") REFERENCES "User"("id") ON DELETE NO ACTION ON UPDATE NO ACTION;
+```
+
+Review the SQL migration file to ensure everything is correct.
+
+Next, mark the migration as applied using `prisma migrate resolve` with the `--applied` argument.
+
+```terminal
+npx prisma migrate resolve --applied 0_init
+```
+
+The command will mark `0_init` as applied by adding it to the `_prisma_migrations` table.
+
+You now have a baseline for your current database schema. To make further changes to your database schema, you can update your Prisma schema and use `prisma migrate dev` to apply the changes to your database.
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/170-baseline-your-database-typescript-sqlserver.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/170-baseline-your-database-typescript-sqlserver.mdx
new file mode 100644
index 0000000000..61bbb0321a
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/170-baseline-your-database-typescript-sqlserver.mdx
@@ -0,0 +1,93 @@
+---
+title: 'Baseline with Prisma ORM, TypeScript, and SQL Server'
+sidebar_label: 'Baseline your database'
+metaTitle: 'Baseline with Prisma ORM, TypeScript, and SQL Server'
+metaDescription: 'Baseline your database with Prisma ORM, TypeScript, and SQL Server'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-typescript-sqlserver
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-typescript-sqlserver
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/baseline-your-database-
+---
+
+
+## Create an initial migration
+
+To use Prisma Migrate with the database you introspected in the last section, you will need to [baseline your database](/orm/prisma-migrate/getting-started).
+
+Baselining refers to initializing your migration history for a database that might already contain data and **cannot be reset**, such as your production database. Baselining tells Prisma Migrate to assume that one or more migrations have already been applied to your database.
+
+To baseline your database, use [`prisma migrate diff`](/orm/reference/prisma-cli-reference#migrate-diff) to compare your schema and database, and save the output into a SQL file.
+
+First, create a `migrations` directory and add a directory inside with your preferred name for the migration. In this example, we will use `0_init` as the migration name:
+
+```terminal
+mkdir -p prisma/migrations/0_init
+```
+
+
+
+`-p` will recursively create any missing folders in the path you provide.
+
+
+
+Next, generate the migration file with `prisma migrate diff`. Use the following arguments:
+
+- `--from-empty`: assumes the data model you're migrating from is empty
+- `--to-schema-datamodel`: the current database state using the URL in the `datasource` block
+- `--script`: output a SQL script
+
+```terminal wrap
+npx prisma migrate diff --from-empty --to-schema-datamodel prisma/schema.prisma --script > prisma/migrations/0_init/migration.sql
+```
+
+## Review the migration
+
+The command will generate a migration that should resemble the following script:
+
+```sql file=prisma/migrations/0_init/migration.sql
+CREATE TABLE [dbo].[Post] (
+ [id] INT NOT NULL IDENTITY(1,1),
+ [createdAt] DATETIME2 NOT NULL CONSTRAINT [Post_createdAt_df] DEFAULT CURRENT_TIMESTAMP,
+ [updatedAt] DATETIME2 NOT NULL,
+ [title] VARCHAR(255) NOT NULL,
+ [content] NVARCHAR(1000),
+ [published] BIT NOT NULL CONSTRAINT [Post_published_df] DEFAULT 0,
+ [authorId] INT NOT NULL,
+ CONSTRAINT [Post_pkey] PRIMARY KEY ([id])
+);
+
+CREATE TABLE [dbo].[Profile] (
+ [id] INT NOT NULL IDENTITY(1,1),
+ [bio] NVARCHAR(1000),
+ [userId] INT NOT NULL,
+ CONSTRAINT [Profile_pkey] PRIMARY KEY ([id]),
+ CONSTRAINT [Profile_userId_key] UNIQUE ([userId])
+);
+
+CREATE TABLE [dbo].[User] (
+ [id] INT NOT NULL IDENTITY(1,1),
+ [email] NVARCHAR(1000) NOT NULL,
+ [name] NVARCHAR(1000),
+ CONSTRAINT [User_pkey] PRIMARY KEY ([id]),
+ CONSTRAINT [User_email_key] UNIQUE ([email])
+);
+
+ALTER TABLE [dbo].[Post] ADD CONSTRAINT [Post_authorId_fkey] FOREIGN KEY ([authorId]) REFERENCES [dbo].[User]([id]) ON DELETE NO ACTION ON UPDATE CASCADE;
+
+ALTER TABLE [dbo].[Profile] ADD CONSTRAINT [Profile_userId_fkey] FOREIGN KEY ([userId]) REFERENCES [dbo].[User]([id]) ON DELETE NO ACTION ON UPDATE CASCADE;
+```
+
+Review the SQL migration file to ensure everything is correct.
+
+Next, mark the migration as applied using `prisma migrate resolve` with the `--applied` argument.
+
+```terminal
+npx prisma migrate resolve --applied 0_init
+```
+
+The command will mark `0_init` as applied by adding it to the `_prisma_migrations` table.
+
+You now have a baseline for your current database schema. To make further changes to your database schema, you can update your Prisma schema and use `prisma migrate dev` to apply the changes to your database.
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-node-cockroachdb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-node-cockroachdb.mdx
new file mode 100644
index 0000000000..306e4ebfbb
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-node-cockroachdb.mdx
@@ -0,0 +1,17 @@
+---
+title: 'Install Prisma Client in an existing JavaScript project (CockroachDB)'
+sidebar_label: 'Install Prisma Client'
+metaTitle: 'Install Prisma Client in your existing project using JavaScript and CockroachDB'
+metaDescription: 'Install and generate Prisma Client in your existing JavaScript and CockroachDB project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/baseline-your-database-node-cockroachdb
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-node-cockroachdb
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-
+---
+
+import InstallPrismaClient from './_install-prisma-client-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-node-mysql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-node-mysql.mdx
new file mode 100644
index 0000000000..6e1d802cd7
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-node-mysql.mdx
@@ -0,0 +1,17 @@
+---
+title: 'Install Prisma Client in an existing JavaScript project (MySQL)'
+sidebar_label: 'Install Prisma Client'
+metaTitle: 'Install Prisma Client in your existing project using JavaScript and MySQL'
+metaDescription: 'Install and generate Prisma Client in your existing JavaScript and MySQL project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/baseline-your-database-node-mysql
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-node-mysql
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-
+---
+
+import InstallPrismaClient from './_install-prisma-client-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-node-planetscale.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-node-planetscale.mdx
new file mode 100644
index 0000000000..5e25861d0a
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-node-planetscale.mdx
@@ -0,0 +1,17 @@
+---
+title: 'Install Prisma Client in an existing JavaScript project (PlanetScale)'
+sidebar_label: 'Install Prisma Client'
+metaTitle: 'Install Prisma Client in your existing project using JavaScript and PlanetScale'
+metaDescription: 'Install and generate Prisma Client in your existing JavaScript and PlanetScale project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-node-planetscale
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-node-planetscale
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-
+---
+
+import InstallPrismaClient from './_install-prisma-client-partial.mdx'
+
+
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-node-postgresql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-node-postgresql.mdx
new file mode 100644
index 0000000000..79a60fe467
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-node-postgresql.mdx
@@ -0,0 +1,17 @@
+---
+title: 'Install Prisma Client in an existing JavaScript project (PostgreSQL)'
+sidebar_label: 'Install Prisma Client'
+metaTitle: 'Install Prisma Client in your existing project using JavaScript and PostgreSQL'
+metaDescription: 'Install and generate Prisma Client in your existing JavaScript and PostgreSQL project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/baseline-your-database-node-postgresql
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-node-postgresql
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-
+---
+
+import InstallPrismaClient from './_install-prisma-client-partial.mdx'
+
+
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-node-sqlserver.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-node-sqlserver.mdx
new file mode 100644
index 0000000000..cef9feceb5
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-node-sqlserver.mdx
@@ -0,0 +1,17 @@
+---
+title: 'Install Prisma Client in an existing JavaScript project (SQL Server)'
+sidebar_label: 'Install Prisma Client'
+metaTitle: 'Install Prisma Client in your existing project using JavaScript and SQL Server'
+metaDescription: 'Install and generate Prisma Client in your existing JavaScript and SQL Server project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/baseline-your-database-node-sqlserver
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-node-sqlserver
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-
+---
+
+import InstallPrismaClient from './_install-prisma-client-partial.mdx'
+
+
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-typescript-cockroachdb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-typescript-cockroachdb.mdx
new file mode 100644
index 0000000000..c1f9a4105d
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-typescript-cockroachdb.mdx
@@ -0,0 +1,17 @@
+---
+title: 'Install Prisma Client in an existing TypeScript project (CockroachDB)'
+sidebar_label: 'Install Prisma Client'
+metaTitle: 'Install Prisma Client in your existing project using TypeScript and CockroachDB'
+metaDescription: 'Install and generate Prisma Client in your existing TypeScript and CockroachDB project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/baseline-your-database-typescript-cockroachdb
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-typescript-cockroachdb
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-
+---
+
+import InstallPrismaClient from './_install-prisma-client-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-typescript-mysql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-typescript-mysql.mdx
new file mode 100644
index 0000000000..e970da5f15
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-typescript-mysql.mdx
@@ -0,0 +1,17 @@
+---
+title: 'Install Prisma Client in an existing TypeScript project (MySQL)'
+sidebar_label: 'Install Prisma Client'
+metaTitle: 'Install Prisma Client in your existing project using TypeScript and MySQL'
+metaDescription: 'Install and generate Prisma Client in your existing TypeScript and MySQL project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/baseline-your-database-typescript-mysql
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-typescript-mysql
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-
+---
+
+import InstallPrismaClient from './_install-prisma-client-partial.mdx'
+
+
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-typescript-planetscale.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-typescript-planetscale.mdx
new file mode 100644
index 0000000000..8830aaab55
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-typescript-planetscale.mdx
@@ -0,0 +1,17 @@
+---
+title: 'Install Prisma Client in an existing TypeScript project (PlanetScale)'
+sidebar_label: 'Install Prisma Client'
+metaTitle: 'Install Prisma Client in your existing project using TypeScript and PlanetScale'
+metaDescription: 'Install and generate Prisma Client in your existing TypeScript and PlanetScale project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-typescript-planetscale
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-typescript-planetscale
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-
+---
+
+import InstallPrismaClient from './_install-prisma-client-partial.mdx'
+
+
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-typescript-postgresql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-typescript-postgresql.mdx
new file mode 100644
index 0000000000..c56f64a9f2
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-typescript-postgresql.mdx
@@ -0,0 +1,16 @@
+---
+title: 'Install Prisma Client in an existing TypeScript project (PostgreSQL)'
+sidebar_label: 'Install Prisma Client'
+metaTitle: 'Install Prisma Client in your existing project using TypeScript and PostgreSQL'
+metaDescription: 'Install and generate Prisma Client in your existing TypeScript and PostgreSQL project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/baseline-your-database-typescript-postgresql
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-typescript-postgresql
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-
+---
+
+import InstallPrismaClient from './_install-prisma-client-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-typescript-sqlserver.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-typescript-sqlserver.mdx
new file mode 100644
index 0000000000..cb7201e06a
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/200-install-prisma-client-typescript-sqlserver.mdx
@@ -0,0 +1,17 @@
+---
+title: 'Install Prisma Client in your existing TypeScript project (SQL Server)'
+sidebar_label: 'Install Prisma Client'
+metaTitle: 'Install Prisma Client in your existing project using TypeScript and SQL Server'
+metaDescription: 'Install and generate Prisma Client in your existing TypeScript and SQL Server project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/baseline-your-database-typescript-sqlserver
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-typescript-sqlserver
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-
+---
+
+import InstallPrismaClient from './_install-prisma-client-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-node-cockroachdb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-node-cockroachdb.mdx
new file mode 100644
index 0000000000..a015c01fad
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-node-cockroachdb.mdx
@@ -0,0 +1,123 @@
+---
+title: 'Query your existing CockroachDB database with JavaScript and Prisma ORM'
+sidebar_label: 'Querying the database'
+metaTitle: 'Query your existing CockroachDB database with JavaScript and Prisma ORM'
+metaDescription: 'Write data to and query the CockroachDB database with your JavaScript and Prisma ORM project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-node-cockroachdb
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/evolve-your-schema-node-cockroachdb
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-
+---
+
+
+## Write your first query with Prisma Client
+
+Now that you have generated Prisma Client, you can start writing queries to read and write data in your database.
+
+If you're building a REST API, you can use Prisma Client in your route handlers to read and write data in the database based on incoming HTTP requests. If you're building a GraphQL API, you can use Prisma Client in your resolvers to read and write data in the database based on incoming queries and mutations.
+
+For the purpose of this guide however, you'll just create a plain Node.js script to learn how to send queries to your database using Prisma Client. Once you have an understanding of how the API works, you can start integrating it into your actual application code (e.g. REST route handlers or GraphQL resolvers).
+
+Create a new file named `index.js` and add the following code to it:
+
+```js file=index.js showLineNumbers
+const { PrismaClient } = require('@prisma/client')
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // ... you will write your Prisma Client queries here
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+```js file=index.js
+async function main() {
+ const allUsers = await prisma.user.findMany()
+ console.log(allUsers)
+}
+```
+
+Now run the code with this command:
+
+```terminal copy
+node index.js
+```
+
+If you created a database using the schema from the database introspection step, the query should print an empty array because there are no `User` records in the database yet.
+
+```no-copy
+[]
+```
+
+If you introspected an existing database with records, the query should return an array of JavaScript objects.
+
+## Write data into the database
+
+The `findMany` query you used in the previous section only _reads_ data from the database. In this section, you'll learn how to write a query to _write_ new records into the `Post` and `User` tables.
+
+Adjust the `main` function to send a `create` query to the database:
+
+```js file=index.js showLineNumbers
+async function main() {
+ await prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ posts: {
+ create: { title: 'Hello World' },
+ },
+ profile: {
+ create: { bio: 'I like turtles' },
+ },
+ },
+ })
+
+ const allUsers = await prisma.user.findMany({
+ include: {
+ posts: true,
+ profile: true,
+ },
+ })
+ console.dir(allUsers, { depth: null })
+}
+```
+This code creates a new `User` record together with new `Post` and `Profile` records using a [nested write](/orm/prisma-client/queries/relation-queries#nested-writes) query. The `User` record is connected to the two other ones via the `Post.author` ↔ `User.posts` and `Profile.user` ↔ `User.profile` [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) respectively.
+
+Notice that you're passing the [`include`](/orm/prisma-client/queries/select-fields#return-nested-objects-by-selecting-relation-fields) option to `findMany` which tells Prisma Client to include the `posts` and `profile` relations on the returned `User` objects.
+
+Run the code with this command:
+
+```terminal copy
+node index.js
+```
+
+Before moving on to the next section, you'll "publish" the `Post` record you just created using an `update` query. Adjust the `main` function as follows:
+
+```js file=index.js showLineNumbers
+async function main() {
+ const post = await prisma.post.update({
+ where: { title: 'Hello World' },
+ data: { published: true },
+ })
+ console.log(post)
+}
+```
+
+Now run the code using the same command as before:
+
+```terminal copy
+node index.js
+```
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-node-mysql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-node-mysql.mdx
new file mode 100644
index 0000000000..926e969795
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-node-mysql.mdx
@@ -0,0 +1,125 @@
+---
+title: 'Query your existing MySQL database with JavaScript and Prisma ORM'
+sidebar_label: 'Querying the database'
+metaTitle: 'Query your existing MySQL database with JavaScript and Prisma ORM'
+metaDescription: 'Write data to and query the MySQL database with your JavaScript and Prisma ORM project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-node-mysql
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/evolve-your-schema-node-mysql
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-
+---
+
+
+## Write your first query with Prisma Client
+
+Now that you have generated Prisma Client, you can start writing queries to read and write data in your database.
+
+If you're building a REST API, you can use Prisma Client in your route handlers to read and write data in the database based on incoming HTTP requests. If you're building a GraphQL API, you can use Prisma Client in your resolvers to read and write data in the database based on incoming queries and mutations.
+
+For the purpose of this guide however, you'll just create a plain Node.js script to learn how to send queries to your database using Prisma Client. Once you have an understanding of how the API works, you can start integrating it into your actual application code (e.g. REST route handlers or GraphQL resolvers).
+
+
+Create a new file named `index.js` and add the following code to it:
+
+```js file=index.js showLineNumbers
+const { PrismaClient } = require('@prisma/client')
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // ... you will write your Prisma Client queries here
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+```js file=index.js
+async function main() {
+ const allUsers = await prisma.user.findMany()
+ console.log(allUsers)
+}
+```
+
+Now run the code with this command:
+
+```terminal copy
+node index.js
+```
+
+If you created a database using the schema from the database introspection step, the query should print an empty array because there are no `User` records in the database yet.
+
+```no-copy
+[]
+```
+
+If you introspected an existing database with records, the query should return an array of JavaScript objects.
+
+## Write data into the database
+
+The `findMany` query you used in the previous section only _reads_ data from the database. In this section, you'll learn how to write a query to _write_ new records into the `Post` and `User` tables.
+
+Adjust the `main` function to send a `create` query to the database:
+
+```js file=index.js showLineNumbers
+async function main() {
+ await prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ posts: {
+ create: { title: 'Hello World' },
+ },
+ profile: {
+ create: { bio: 'I like turtles' },
+ },
+ },
+ })
+
+ const allUsers = await prisma.user.findMany({
+ include: {
+ posts: true,
+ profile: true,
+ },
+ })
+ console.dir(allUsers, { depth: null })
+}
+```
+
+This code creates a new `User` record together with new `Post` and `Profile` records using a [nested write](/orm/prisma-client/queries/relation-queries#nested-writes) query. The `User` record is connected to the two other ones via the `Post.author` ↔ `User.posts` and `Profile.user` ↔ `User.profile` [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) respectively.
+
+Notice that you're passing the [`include`](/orm/prisma-client/queries/select-fields#return-nested-objects-by-selecting-relation-fields) option to `findMany` which tells Prisma Client to include the `posts` and `profile` relations on the returned `User` objects.
+
+Run the code with this command:
+
+```terminal copy
+node index.js
+```
+
+Before moving on to the next section, you'll "publish" the `Post` record you just created using an `update` query. Adjust the `main` function as follows:
+
+```js file=index.js showLineNumbers
+async function main() {
+ const post = await prisma.post.update({
+ where: { id: 1 },
+ data: { published: true },
+ })
+ console.log(post)
+}
+```
+
+Now run the code using the same command as before:
+
+```terminal copy
+node index.js
+```
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-node-planetscale.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-node-planetscale.mdx
new file mode 100644
index 0000000000..055441a96d
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-node-planetscale.mdx
@@ -0,0 +1,137 @@
+---
+title: 'Query your existing PlanetScale database with JavaScript and Prisma ORM'
+sidebar_label: 'Querying the database'
+metaTitle: 'Query your existing PlanetScale database with JavaScript and Prisma ORM'
+metaDescription: 'Write data to and query the PlanetScale database with your JavaScript and Prisma ORM project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-node-postgresql
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/evolve-your-schema-node-postgresql
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-
+---
+
+## Write your first query with Prisma Client
+
+Now that you have generated Prisma Client, you can start writing queries to read and write data in your database.
+
+If you're building a REST API, you can use Prisma Client in your route handlers to read and write data in the database based on incoming HTTP requests. If you're building a GraphQL API, you can use Prisma Client in your resolvers to read and write data in the database based on incoming queries and mutations.
+
+For the purpose of this guide however, you'll just create a plain Node.js script to learn how to send queries to your database using Prisma Client. Once you have an understanding of how the API works, you can start integrating it into your actual application code (e.g. REST route handlers or GraphQL resolvers).
+
+Create a new file named `index.js` and add the following code to it:
+
+```js file=index.js showLineNumbers
+const { PrismaClient } = require('@prisma/client')
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // ... you will write your Prisma Client queries here
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Here's a quick overview of the different parts of the code snippet:
+
+1. Import the `PrismaClient` constructor from the `@prisma/client` node module
+1. Instantiate `PrismaClient`
+1. Define an `async` function named `main` to send queries to the database
+1. Call the `main` function
+1. Close the database connections when the script terminates
+
+Depending on what your models look like, the Prisma Client API will look different as well. For example, if you have a `User` model, your `PrismaClient` instance exposes a property called `user` on which you can call [CRUD](/orm/prisma-client/queries/crud) methods like `findMany`, `create` or `update`. The property is named after the model, but the first letter is lowercased (so for the `Post` model it's called `post`, for `Profile` it's called `profile`).
+
+The following examples are all based on the models in the Prisma schema.
+
+Inside the `main` function, add the following query to read all `User` records from the database and print the result:
+
+```js file=index.js showLineNumbers
+async function main() {
+ const allUsers = await prisma.user.findMany()
+ console.log(allUsers)
+}
+```
+
+Now run the code with this command:
+
+```terminal copy
+node index.js
+```
+
+If you created a database using the schema from the database introspection step, the query should print an empty array because there are no `User` records in the database yet.
+
+```no-copy
+[]
+```
+
+If you introspected an existing database with records, the query should return an array of JavaScript objects.
+
+## Write data into the database
+
+The `findMany` query you used in the previous section only _reads_ data from the database. In this section, you'll learn how to write a query to _write_ new records into the `Post` and `User` tables.
+
+Adjust the `main` function to send a `create` query to the database:
+
+```js file=index.js showLineNumbers
+async function main() {
+ await prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ posts: {
+ create: { title: 'Hello World' },
+ },
+ profile: {
+ create: { bio: 'I like turtles' },
+ },
+ },
+ })
+
+ const allUsers = await prisma.user.findMany({
+ include: {
+ posts: true,
+ profile: true,
+ },
+ })
+ console.dir(allUsers, { depth: null })
+}
+```
+
+This code creates a new `User` record together with new `Post` and `Profile` records using a [nested write](/orm/prisma-client/queries/relation-queries#nested-writes) query. The `User` record is connected to the two other ones via the `Post.author` ↔ `User.posts` and `Profile.user` ↔ `User.profile` [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) respectively.
+
+Notice that you're passing the [`include`](/orm/prisma-client/queries/select-fields#return-nested-objects-by-selecting-relation-fields) option to `findMany` which tells Prisma Client to include the `posts` and `profile` relations on the returned `User` objects.
+
+Run the code with this command:
+
+```terminal copy
+node index.js
+```
+
+Before moving on to the next section, you'll "publish" the `Post` record you just created using an `update` query. Adjust the `main` function as follows:
+
+```js file=index.js
+async function main() {
+ const post = await prisma.post.update({
+ where: { id: 1 },
+ data: { published: true },
+ })
+ console.log(post)
+}
+```
+
+Now run the code using the same command as before:
+
+```terminal copy
+node index.js
+```
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-node-postgresql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-node-postgresql.mdx
new file mode 100644
index 0000000000..552155f8ad
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-node-postgresql.mdx
@@ -0,0 +1,124 @@
+---
+title: 'Query your existing PostgreSQL database with JavaScript and Prisma ORM'
+sidebar_label: 'Querying the database'
+metaTitle: 'Query your existing PostgreSQL database with JavaScript and Prisma ORM'
+metaDescription: 'Write data to and query the PostgreSQL database with your JavaScript and Prisma ORM project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-node-postgresql
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/evolve-your-schema-node-postgresql
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-
+---
+
+
+## Write your first query with Prisma Client
+
+Now that you have generated Prisma Client, you can start writing queries to read and write data in your database.
+
+If you're building a REST API, you can use Prisma Client in your route handlers to read and write data in the database based on incoming HTTP requests. If you're building a GraphQL API, you can use Prisma Client in your resolvers to read and write data in the database based on incoming queries and mutations.
+
+For the purpose of this guide however, you'll just create a plain Node.js script to learn how to send queries to your database using Prisma Client. Once you have an understanding of how the API works, you can start integrating it into your actual application code (e.g. REST route handlers or GraphQL resolvers).
+
+Create a new file named `index.js` and add the following code to it:
+
+```js file=index.js showLineNumbers
+const { PrismaClient } = require('@prisma/client')
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // ... you will write your Prisma Client queries here
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+```js file=index.js showLineNumbers
+async function main() {
+ const allUsers = await prisma.user.findMany()
+ console.log(allUsers)
+}
+```
+
+Now run the code with this command:
+
+```terminal copy
+node index.js
+```
+
+If you created a database using the schema from the database introspection step, the query should print an empty array because there are no `User` records in the database yet.
+
+```no-copy
+[]
+```
+
+If you introspected an existing database with records, the query should return an array of JavaScript objects.
+
+## Write data into the database
+
+The `findMany` query you used in the previous section only _reads_ data from the database. In this section, you'll learn how to write a query to _write_ new records into the `Post` and `User` tables.
+
+Adjust the `main` function to send a `create` query to the database:
+
+```js file=index.js showLineNumbers
+async function main() {
+ await prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ posts: {
+ create: { title: 'Hello World' },
+ },
+ profile: {
+ create: { bio: 'I like turtles' },
+ },
+ },
+ })
+
+ const allUsers = await prisma.user.findMany({
+ include: {
+ posts: true,
+ profile: true,
+ },
+ })
+ console.dir(allUsers, { depth: null })
+}
+```
+
+This code creates a new `User` record together with new `Post` and `Profile` records using a [nested write](/orm/prisma-client/queries/relation-queries#nested-writes) query. The `User` record is connected to the two other ones via the `Post.author` ↔ `User.posts` and `Profile.user` ↔ `User.profile` [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) respectively.
+
+Notice that you're passing the [`include`](/orm/prisma-client/queries/select-fields#return-nested-objects-by-selecting-relation-fields) option to `findMany` which tells Prisma Client to include the `posts` and `profile` relations on the returned `User` objects.
+
+Run the code with this command:
+
+```terminal copy
+node index.js
+```
+
+Before moving on to the next section, you'll "publish" the `Post` record you just created using an `update` query. Adjust the `main` function as follows:
+
+```js file=index.js
+async function main() {
+ const post = await prisma.post.update({
+ where: { id: 1 },
+ data: { published: true },
+ })
+ console.log(post)
+}
+```
+
+Now run the code using the same command as before:
+
+```terminal copy
+node index.js
+```
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-node-sqlserver.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-node-sqlserver.mdx
new file mode 100644
index 0000000000..ad979dd368
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-node-sqlserver.mdx
@@ -0,0 +1,132 @@
+---
+title: 'Query your existing SQL Server database with JavaScript and Prisma ORM'
+sidebar_label: 'Querying the database'
+metaTitle: 'Query your existing SQL Server database with JavaScript and Prisma ORM'
+metaDescription: 'Write data to and query the SQL Server database with your JavaScript and Prisma ORM project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-node-sqlserver
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/evolve-your-schema-node-sqlserver
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-
+---
+
+
+## Write your first query with Prisma Client
+
+Now that you have generated Prisma Client, you can start writing queries to read and write data in your database.
+
+If you're building a REST API, you can use Prisma Client in your route handlers to read and write data in the database based on incoming HTTP requests. If you're building a GraphQL API, you can use Prisma Client in your resolvers to read and write data in the database based on incoming queries and mutations.
+
+For the purpose of this guide however, you'll just create a plain Node.js script to learn how to send queries to your database using Prisma Client. Once you have an understanding of how the API works, you can start integrating it into your actual application code (e.g. REST route handlers or GraphQL resolvers).
+
+Create a new file named `index.js` and add the following code to it:
+
+```js file=index.js showLineNumbers
+const { PrismaClient } = require('@prisma/client')
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // ... you will write your Prisma Client queries here
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Here's a quick overview of the different parts of the code snippet:
+
+1. Import the `PrismaClient` constructor from the `@prisma/client` node module
+1. Instantiate `PrismaClient`
+1. Define an `async` function named `main` to send queries to the database
+1. Call the `main` function
+1. Close the database connections when the script terminates
+
+Depending on what your models look like, the Prisma Client API will look different as well. For example, if you have a `User` model, your `PrismaClient` instance exposes a property called `user` on which you can call [CRUD](/orm/prisma-client/queries/crud) methods like `findMany`, `create` or `update`. The property is named after the model, but the first letter is lowercased (so for the `Post` model it's called `post`, for `Profile` it's called `profile`).
+
+The following examples are all based on the models in the Prisma schema.
+
+Inside the `main` function, add the following query to read all `User` records from the database and print the result:
+
+```js file=index.js showLineNumbers
+async function main() {
+ const allUsers = await prisma.user.findMany()
+ console.log(allUsers)
+}
+```
+
+Now run the code with this command:
+
+```terminal copy
+node index.js
+```
+
+If you created a database using the schema from the database introspection step, the query should print an empty array because there are no `User` records in the database yet.
+
+```no-copy
+[]
+```
+
+If you introspected an existing database with records, the query should return an array of JavaScript objects.
+
+## Write data into the database
+
+The `findMany` query you used in the previous section only _reads_ data from the database. In this section, you'll learn how to write a query to _write_ new records into the `Post` and `User` tables.
+
+Adjust the `main` function to send a `create` query to the database:
+
+```js file=index.js showLineNumbers
+async function main() {
+ await prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ posts: {
+ create: { title: 'Hello World' },
+ },
+ profile: {
+ create: { bio: 'I like turtles' },
+ },
+ },
+ })
+
+ const allUsers = await prisma.user.findMany({
+ include: {
+ posts: true,
+ profile: true,
+ },
+ })
+ console.dir(allUsers, { depth: null })
+}
+```
+
+This code creates a new `User` record together with new `Post` and `Profile` records using a [nested write](/orm/prisma-client/queries/relation-queries#nested-writes) query. The `User` record is connected to the two other ones via the `Post.author` ↔ `User.posts` and `Profile.user` ↔ `User.profile` [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) respectively.
+
+Notice that you're passing the [`include`](/orm/prisma-client/queries/select-fields#return-nested-objects-by-selecting-relation-fields) option to `findMany` which tells Prisma Client to include the `posts` and `profile` relations on the returned `User` objects.
+
+Run the code with this command:
+
+```terminal copy
+node index.js
+```
+
+Before moving on to the next section, you'll "publish" the `Post` record you just created using an `update` query. Adjust the `main` function as follows:
+
+```js file=index.js
+async function main() {
+ const post = await prisma.post.update({
+ where: { id: 1 },
+ data: { published: true },
+ })
+ console.log(post)
+}
+```
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-typescript-cockroachdb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-typescript-cockroachdb.mdx
new file mode 100644
index 0000000000..2bec040594
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-typescript-cockroachdb.mdx
@@ -0,0 +1,139 @@
+---
+title: 'Query your existing CockroachDB database with TypeScript and Prisma ORM'
+sidebar_label: 'Querying the database'
+metaTitle: 'Query your existing CockroachDB database with TypeScript and Prisma ORM'
+metaDescription: 'Write data to and query the CockroachDB database with your TypeScript and Prisma ORM project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-typescript-cockroachdb
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/evolve-your-schema-typescript-cockroachdb
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-
+---
+
+
+## Write your first query with Prisma Client
+
+Now that you have generated Prisma Client, you can start writing queries to read and write data in your database.
+
+If you're building a REST API, you can use Prisma Client in your route handlers to read and write data in the database based on incoming HTTP requests. If you're building a GraphQL API, you can use Prisma Client in your resolvers to read and write data in the database based on incoming queries and mutations.
+
+For the purpose of this guide however, you'll just create a plain Node.js script to learn how to send queries to your database using Prisma Client. Once you have an understanding of how the API works, you can start integrating it into your actual application code (e.g. REST route handlers or GraphQL resolvers).
+
+Create a new file named `index.ts` and add the following code to it:
+
+```ts file=index.ts showLineNumbers
+import { PrismaClient } from './generated/prisma'
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // ... you will write your Prisma Client queries here
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Here's a quick overview of the different parts of the code snippet:
+
+1. Import the `PrismaClient` constructor from the `@prisma/client` node module
+1. Instantiate `PrismaClient`
+1. Define an `async` function named `main` to send queries to the database
+1. Call the `main` function
+1. Close the database connections when the script terminates
+
+Depending on what your models look like, the Prisma Client API will look different as well. For example, if you have a `User` model, your `PrismaClient` instance exposes a property called `user` on which you can call [CRUD](/orm/prisma-client/queries/crud) methods like `findMany`, `create` or `update`. The property is named after the model, but the first letter is lowercased (so for the `Post` model it's called `post`, for `Profile` it's called `profile`).
+
+The following examples are all based on the models in the Prisma schema.
+
+Inside the `main` function, add the following query to read all `User` records from the database and print the result:
+
+```ts file=index.ts showLineNumbers
+async function main() {
+ const allUsers = await prisma.user.findMany()
+ console.log(allUsers)
+}
+```
+
+Now run the code with your current TypeScript setup. If you're using `tsx`, you can run it like this:
+
+```terminal copy
+npx tsx index.ts
+```
+
+If you created a database using the schema from the database introspection step, the query should print an empty array because there are no `User` records in the database yet.
+
+```no-copy
+[]
+```
+
+If you introspected an existing database with records, the query should return an array of JavaScript objects.
+
+## Write data into the database
+
+The `findMany` query you used in the previous section only _reads_ data from the database. In this section, you'll learn how to write a query to _write_ new records into the `Post` and `User` tables.
+
+Adjust the `main` function to send a `create` query to the database:
+
+```ts file=index.ts showLineNumbers
+async function main() {
+ await prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ posts: {
+ create: { title: 'Hello World' },
+ },
+ profile: {
+ create: { bio: 'I like turtles' },
+ },
+ },
+ })
+
+ const allUsers = await prisma.user.findMany({
+ include: {
+ posts: true,
+ profile: true,
+ },
+ })
+ console.dir(allUsers, { depth: null })
+}
+```
+
+This code creates a new `User` record together with new `Post` and `Profile` records using a [nested write](/orm/prisma-client/queries/relation-queries#nested-writes) query. The `User` record is connected to the two other ones via the `Post.author` ↔ `User.posts` and `Profile.user` ↔ `User.profile` [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) respectively.
+
+Notice that you're passing the [`include`](/orm/prisma-client/queries/select-fields#return-nested-objects-by-selecting-relation-fields) option to `findMany` which tells Prisma Client to include the `posts` and `profile` relations on the returned `User` objects.
+
+Run the code with your current TypeScript setup. If you're using `tsx`, you can run it like this:
+
+```terminal copy
+npx tsx index.ts
+```
+
+Before moving on to the next section, you'll "publish" the `Post` record you just created using an `update` query. Adjust the `main` function as follows:
+
+```ts file=index.ts showLineNumbers
+async function main() {
+ const post = await prisma.post.update({
+ where: { title: 'Hello World' },
+ data: { published: true },
+ })
+ console.log(post)
+}
+```
+
+Run the code with your current TypeScript setup. If you're using `tsx`, you can run it like this:
+
+```terminal copy
+npx tsx index.ts
+```
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-typescript-mysql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-typescript-mysql.mdx
new file mode 100644
index 0000000000..7379468b73
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-typescript-mysql.mdx
@@ -0,0 +1,138 @@
+---
+title: 'Query your existing MySQL database with TypeScript and Prisma ORM'
+sidebar_label: 'Querying the database'
+metaTitle: 'Query your existing MySQL database with TypeScript and Prisma ORM'
+metaDescription: 'Write data to and query the MySQL database with your TypeScript and Prisma ORM project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-typescript-mysql
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/evolve-your-schema-typescript-mysql
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-
+---
+
+
+## Write your first query with Prisma Client
+
+Now that you have generated Prisma Client, you can start writing queries to read and write data in your database.
+
+If you're building a REST API, you can use Prisma Client in your route handlers to read and write data in the database based on incoming HTTP requests. If you're building a GraphQL API, you can use Prisma Client in your resolvers to read and write data in the database based on incoming queries and mutations.
+
+For the purpose of this guide however, you'll just create a plain Node.js script to learn how to send queries to your database using Prisma Client. Once you have an understanding of how the API works, you can start integrating it into your actual application code (e.g. REST route handlers or GraphQL resolvers).
+
+Create a new file named `index.ts` and add the following code to it:
+
+```ts file=index.ts showLineNumbers
+import { PrismaClient } from './generated/prisma'
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // ... you will write your Prisma Client queries here
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Here's a quick overview of the different parts of the code snippet:
+
+1. Import the `PrismaClient` constructor from the `@prisma/client` node module
+1. Instantiate `PrismaClient`
+1. Define an `async` function named `main` to send queries to the database
+1. Call the `main` function
+1. Close the database connections when the script terminates
+
+Depending on what your models look like, the Prisma Client API will look different as well. For example, if you have a `User` model, your `PrismaClient` instance exposes a property called `user` on which you can call [CRUD](/orm/prisma-client/queries/crud) methods like `findMany`, `create` or `update`. The property is named after the model, but the first letter is lowercased (so for the `Post` model it's called `post`, for `Profile` it's called `profile`).
+
+The following examples are all based on the models in the Prisma schema.
+
+Inside the `main` function, add the following query to read all `User` records from the database and print the result:
+
+```ts file=index.ts showLineNumbers
+async function main() {
+ const allUsers = await prisma.user.findMany()
+ console.log(allUsers)
+}
+```
+
+Now run the code with your current TypeScript setup. If you're using `tsx`, you can run it like this:
+
+```terminal copy
+npx tsx index.ts
+```
+
+If you created a database using the schema from the database introspection step, the query should print an empty array because there are no `User` records in the database yet.
+
+```no-copy
+[]
+```
+
+If you introspected an existing database with records, the query should return an array of JavaScript objects.
+
+## Write data into the database
+
+The `findMany` query you used in the previous section only _reads_ data from the database. In this section, you'll learn how to write a query to _write_ new records into the `Post` and `User` tables.
+
+Adjust the `main` function to send a `create` query to the database:
+
+```ts file=index.ts showLineNumbers
+async function main() {
+ await prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ posts: {
+ create: { title: 'Hello World' },
+ },
+ profile: {
+ create: { bio: 'I like turtles' },
+ },
+ },
+ })
+
+ const allUsers = await prisma.user.findMany({
+ include: {
+ posts: true,
+ profile: true,
+ },
+ })
+ console.dir(allUsers, { depth: null })
+}
+```
+
+This code creates a new `User` record together with new `Post` and `Profile` records using a [nested write](/orm/prisma-client/queries/relation-queries#nested-writes) query. The `User` record is connected to the two other ones via the `Post.author` ↔ `User.posts` and `Profile.user` ↔ `User.profile` [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) respectively.
+
+Notice that you're passing the [`include`](/orm/prisma-client/queries/select-fields#return-nested-objects-by-selecting-relation-fields) option to `findMany` which tells Prisma Client to include the `posts` and `profile` relations on the returned `User` objects.
+
+Run the code with your current TypeScript setup. If you're using `tsx`, you can run it like this:
+
+```terminal copy
+npx tsx index.ts
+```
+
+Before moving on to the next section, you'll "publish" the `Post` record you just created using an `update` query. Adjust the `main` function as follows:
+
+```ts file=index.ts showLineNumbers
+async function main() {
+ const post = await prisma.post.update({
+ where: { id: 1 },
+ data: { published: true },
+ })
+ console.log(post)
+}
+```
+
+Run the code with your current TypeScript setup. If you're using `tsx`, you can run it like this:
+
+```terminal copy
+npx tsx index.ts
+```
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-typescript-planetscale.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-typescript-planetscale.mdx
new file mode 100644
index 0000000000..5339ab4605
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-typescript-planetscale.mdx
@@ -0,0 +1,139 @@
+---
+title: 'Query your existing PlanetScale database with TypeScript and Prisma ORM'
+sidebar_label: 'Querying the database'
+metaTitle: 'Query your existing PlanetScale database with TypeScript and Prisma ORM'
+metaDescription: 'Write data to and query the PlanetScale database with your TypeScript and Prisma ORM project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-typescript-planetscale
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/next-steps
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-
+---
+
+
+## Write your first query with Prisma Client
+
+Now that you have generated Prisma Client, you can start writing queries to read and write data in your database.
+
+If you're building a REST API, you can use Prisma Client in your route handlers to read and write data in the database based on incoming HTTP requests. If you're building a GraphQL API, you can use Prisma Client in your resolvers to read and write data in the database based on incoming queries and mutations.
+
+For the purpose of this guide however, you'll just create a plain Node.js script to learn how to send queries to your database using Prisma Client. Once you have an understanding of how the API works, you can start integrating it into your actual application code (e.g. REST route handlers or GraphQL resolvers).
+
+Create a new file named `index.ts` and add the following code to it:
+
+```ts file=index.ts showLineNumbers
+import { PrismaClient } from './generated/prisma'
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // ... you will write your Prisma Client queries here
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Here's a quick overview of the different parts of the code snippet:
+
+1. Import the `PrismaClient` constructor from the `@prisma/client` node module
+1. Instantiate `PrismaClient`
+1. Define an `async` function named `main` to send queries to the database
+1. Call the `main` function
+1. Close the database connections when the script terminates
+
+Depending on what your models look like, the Prisma Client API will look different as well. For example, if you have a `User` model, your `PrismaClient` instance exposes a property called `user` on which you can call [CRUD](/orm/prisma-client/queries/crud) methods like `findMany`, `create` or `update`. The property is named after the model, but the first letter is lowercased (so for the `Post` model it's called `post`, for `Profile` it's called `profile`).
+
+The following examples are all based on the models in the Prisma schema.
+
+Inside the `main` function, add the following query to read all `User` records from the database and print the result:
+
+```ts file=index.ts showLineNumbers
+async function main() {
+ const allUsers = await prisma.user.findMany()
+ console.log(allUsers)
+}
+```
+
+Now run the code with your current TypeScript setup. If you're using `tsx`, you can run it like this:
+
+```terminal copy
+npx tsx index.ts
+```
+
+
+If you created a database using the schema from the database introspection step, the query should print an empty array because there are no `User` records in the database yet.
+
+```no-copy
+[]
+```
+
+If you introspected an existing database with records, the query should return an array of JavaScript objects.
+
+## Write data into the database
+
+The `findMany` query you used in the previous section only _reads_ data from the database. In this section, you'll learn how to write a query to _write_ new records into the `Post` and `User` tables.
+
+Adjust the `main` function to send a `create` query to the database:
+
+```ts file=index.ts showLineNumbers
+async function main() {
+ await prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ posts: {
+ create: { title: 'Hello World' },
+ },
+ profile: {
+ create: { bio: 'I like turtles' },
+ },
+ },
+ })
+
+ const allUsers = await prisma.user.findMany({
+ include: {
+ posts: true,
+ profile: true,
+ },
+ })
+ console.dir(allUsers, { depth: null })
+}
+```
+
+This code creates a new `User` record together with new `Post` and `Profile` records using a [nested write](/orm/prisma-client/queries/relation-queries#nested-writes) query. The `User` record is connected to the two other ones via the `Post.author` ↔ `User.posts` and `Profile.user` ↔ `User.profile` [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) respectively.
+
+Notice that you're passing the [`include`](/orm/prisma-client/queries/select-fields#return-nested-objects-by-selecting-relation-fields) option to `findMany` which tells Prisma Client to include the `posts` and `profile` relations on the returned `User` objects.
+
+Run the code with your current TypeScript setup. If you're using `tsx`, you can run it like this:
+
+```terminal copy
+npx tsx index.ts
+```
+
+Before moving on to the next section, you'll "publish" the `Post` record you just created using an `update` query. Adjust the `main` function as follows:
+
+```ts file=index.ts showLineNumbers
+async function main() {
+ const post = await prisma.post.update({
+ where: { id: 1 },
+ data: { published: true },
+ })
+ console.log(post)
+}
+```
+
+Run the code with your current TypeScript setup. If you're using `tsx`, you can run it like this:
+
+```terminal copy
+npx tsx index.ts
+```
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-typescript-postgresql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-typescript-postgresql.mdx
new file mode 100644
index 0000000000..7cd5bf286b
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-typescript-postgresql.mdx
@@ -0,0 +1,137 @@
+---
+title: 'Query your existing PostgreSQL database with TypeScript and Prisma ORM'
+sidebar_label: 'Querying the database'
+metaTitle: 'Query your existing PostgreSQL database with TypeScript and Prisma ORM'
+metaDescription: 'Write data to and query the PostgreSQL database with your TypeScript and Prisma ORM project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-typescript-postgresql
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/evolve-your-schema-typescript-postgresql
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-
+---
+
+
+## Write your first query with Prisma Client
+
+Now that you have generated Prisma Client, you can start writing queries to read and write data in your database.
+
+If you're building a REST API, you can use Prisma Client in your route handlers to read and write data in the database based on incoming HTTP requests. If you're building a GraphQL API, you can use Prisma Client in your resolvers to read and write data in the database based on incoming queries and mutations.
+
+For the purpose of this guide however, you'll just create a plain Node.js script to learn how to send queries to your database using Prisma Client. Once you have an understanding of how the API works, you can start integrating it into your actual application code (e.g. REST route handlers or GraphQL resolvers).
+
+Create a new file named `index.ts` and add the following code to it:
+
+```ts file=index.ts showLineNumbers
+import { PrismaClient } from './generated/prisma'
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // ... you will write your Prisma Client queries here
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Here's a quick overview of the different parts of the code snippet:
+
+1. Import the `PrismaClient` constructor from the `@prisma/client` node module
+1. Instantiate `PrismaClient`
+1. Define an `async` function named `main` to send queries to the database
+1. Call the `main` function
+1. Close the database connections when the script terminates
+
+Depending on what your models look like, the Prisma Client API will look different as well. For example, if you have a `User` model, your `PrismaClient` instance exposes a property called `user` on which you can call [CRUD](/orm/prisma-client/queries/crud) methods like `findMany`, `create` or `update`. The property is named after the model, but the first letter is lowercased (so for the `Post` model it's called `post`, for `Profile` it's called `profile`).
+
+The following examples are all based on the models in the Prisma schema.
+
+Inside the `main` function, add the following query to read all `User` records from the database and print the result:
+
+```ts file=index.ts showLineNumbers
+async function main() {
+ const allUsers = await prisma.user.findMany()
+ console.log(allUsers)
+}
+```
+
+Now run the code with your current TypeScript setup. If you're using `tsx`, you can run it like this:
+
+```terminal copy
+npx tsx index.ts
+```
+
+If you created a database using the schema from the database introspection step, the query should print an empty array because there are no `User` records in the database yet.
+
+```no-copy
+[]
+```
+
+If you introspected an existing database with records, the query should return an array of JavaScript objects.
+
+## Write data into the database
+
+The `findMany` query you used in the previous section only _reads_ data from the database. In this section, you'll learn how to write a query to _write_ new records into the `Post` and `User` tables.
+
+Adjust the `main` function to send a `create` query to the database:
+
+```ts file=index.ts showLineNumbers
+async function main() {
+ await prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ posts: {
+ create: { title: 'Hello World' },
+ },
+ profile: {
+ create: { bio: 'I like turtles' },
+ },
+ },
+ })
+
+ const allUsers = await prisma.user.findMany({
+ include: {
+ posts: true,
+ profile: true,
+ },
+ })
+ console.dir(allUsers, { depth: null })
+}
+```
+
+This code creates a new `User` record together with new `Post` and `Profile` records using a [nested write](/orm/prisma-client/queries/relation-queries#nested-writes) query. The `User` record is connected to the two other ones via the `Post.author` ↔ `User.posts` and `Profile.user` ↔ `User.profile` [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) respectively.
+
+Notice that you're passing the [`include`](/orm/prisma-client/queries/select-fields#return-nested-objects-by-selecting-relation-fields) option to `findMany` which tells Prisma Client to include the `posts` and `profile` relations on the returned `User` objects.
+
+Run the code with your current TypeScript setup. If you're using `tsx`, you can run it like this:
+
+```terminal copy
+npx tsx index.ts
+```
+
+Before moving on to the next section, you'll "publish" the `Post` record you just created using an `update` query. Adjust the `main` function as follows:
+
+```ts file=index.ts showLineNumbers
+async function main() {
+ const post = await prisma.post.update({
+ where: { id: 1 },
+ data: { published: true },
+ })
+ console.log(post)
+}
+```
+
+Run the code with your current TypeScript setup. If you're using `tsx`, you can run it like this:
+
+```terminal copy
+npx tsx index.ts
+```
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-typescript-sqlserver.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-typescript-sqlserver.mdx
new file mode 100644
index 0000000000..ef0b41aa99
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/250-querying-the-database-typescript-sqlserver.mdx
@@ -0,0 +1,138 @@
+---
+title: 'Query your existing SQL Server database with TypeScript and Prisma ORM'
+sidebar_label: 'Querying the database'
+metaTitle: 'Query your existing SQL Server database with TypeScript and Prisma ORM'
+metaDescription: 'Write data to and query the SQL Server database with your TypeScript and Prisma ORM project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'planetscale', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/install-prisma-client-typescript-sqlserver
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/evolve-your-schema-typescript-sqlserver
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-
+---
+
+
+## Write your first query with Prisma Client
+
+Now that you have generated Prisma Client, you can start writing queries to read and write data in your database.
+
+If you're building a REST API, you can use Prisma Client in your route handlers to read and write data in the database based on incoming HTTP requests. If you're building a GraphQL API, you can use Prisma Client in your resolvers to read and write data in the database based on incoming queries and mutations.
+
+For the purpose of this guide however, you'll just create a plain Node.js script to learn how to send queries to your database using Prisma Client. Once you have an understanding of how the API works, you can start integrating it into your actual application code (e.g. REST route handlers or GraphQL resolvers).
+
+Create a new file named `index.ts` and add the following code to it:
+
+```ts file=index.ts showLineNumbers
+import { PrismaClient } from './generated/prisma'
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // ... you will write your Prisma Client queries here
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Here's a quick overview of the different parts of the code snippet:
+
+1. Import the `PrismaClient` constructor from the `@prisma/client` node module
+1. Instantiate `PrismaClient`
+1. Define an `async` function named `main` to send queries to the database
+1. Call the `main` function
+1. Close the database connections when the script terminates
+
+Depending on what your models look like, the Prisma Client API will look different as well. For example, if you have a `User` model, your `PrismaClient` instance exposes a property called `user` on which you can call [CRUD](/orm/prisma-client/queries/crud) methods like `findMany`, `create` or `update`. The property is named after the model, but the first letter is lowercased (so for the `Post` model it's called `post`, for `Profile` it's called `profile`).
+
+The following examples are all based on the models in the Prisma schema.
+
+Inside the `main` function, add the following query to read all `User` records from the database and print the result:
+
+```ts file=index.ts showLineNumbers
+async function main() {
+ const allUsers = await prisma.user.findMany()
+ console.log(allUsers)
+}
+```
+
+Now run the code with your current TypeScript setup. If you're using `tsx`, you can run it like this:
+
+```terminal copy
+npx tsx index.ts
+```
+
+If you created a database using the schema from the database introspection step, the query should print an empty array because there are no `User` records in the database yet.
+
+```no-copy
+[]
+```
+
+If you introspected an existing database with records, the query should return an array of JavaScript objects.
+
+## Write data into the database
+
+The `findMany` query you used in the previous section only _reads_ data from the database. In this section, you'll learn how to write a query to _write_ new records into the `Post` and `User` tables.
+
+Adjust the `main` function to send a `create` query to the database:
+
+```ts file=index.ts showLineNumbers
+async function main() {
+ await prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ posts: {
+ create: { title: 'Hello World' },
+ },
+ profile: {
+ create: { bio: 'I like turtles' },
+ },
+ },
+ })
+
+ const allUsers = await prisma.user.findMany({
+ include: {
+ posts: true,
+ profile: true,
+ },
+ })
+ console.dir(allUsers, { depth: null })
+}
+```
+
+This code creates a new `User` record together with new `Post` and `Profile` records using a [nested write](/orm/prisma-client/queries/relation-queries#nested-writes) query. The `User` record is connected to the two other ones via the `Post.author` ↔ `User.posts` and `Profile.user` ↔ `User.profile` [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) respectively.
+
+Notice that you're passing the [`include`](/orm/prisma-client/queries/select-fields#return-nested-objects-by-selecting-relation-fields) option to `findMany` which tells Prisma Client to include the `posts` and `profile` relations on the returned `User` objects.
+
+Run the code with your current TypeScript setup. If you're using `tsx`, you can run it like this:
+
+```terminal copy
+npx tsx index.ts
+```
+
+Before moving on to the next section, you'll "publish" the `Post` record you just created using an `update` query. Adjust the `main` function as follows:
+
+```ts file=index.ts showLineNumbers
+async function main() {
+ const post = await prisma.post.update({
+ where: { id: 1 },
+ data: { published: true },
+ })
+ console.log(post)
+}
+```
+
+Run the code with your current TypeScript setup. If you're using `tsx`, you can run it like this:
+
+```terminal copy
+npx tsx index.ts
+```
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/275-evolve-your-schema-node-cockroachdb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/275-evolve-your-schema-node-cockroachdb.mdx
new file mode 100644
index 0000000000..88aaf399c1
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/275-evolve-your-schema-node-cockroachdb.mdx
@@ -0,0 +1,106 @@
+---
+title: 'Evolve your schema for a CockroachDB database in a Javascript project'
+sidebar_label: 'Evolve your schema'
+metaTitle: 'Evolve your Prisma schema with Prisma Migrate : JavaScript-CockroachDB'
+metaDescription: 'Evolve your Prisma schema with Prisma Migrate inside of your JavaScript and CockroachDB project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-node-cockroachdb
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/next-steps
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/evolve-your-schema-
+---
+
+## Add a `Tag` model to your schema
+
+In this section, you will evolve your Prisma schema and then generate and apply the migration to your database with [`prisma migrate dev`](/orm/reference/prisma-cli-reference#migrate-dev).
+
+For the purpose of this guide, we'll make the following changes to the Prisma schema:
+
+1. Create a new model called `Tag` with the following fields:
+ - `id`: an auto-incrementing integer that will be the primary key for the model
+ - `name`: a non-null `String`
+ - `posts`: an implicit many-to-many relation field that links to the `Post` model
+2. Update the `Post` model with a `tags` field with an implicit many-to-many relation field that links to the `Tag` model
+
+Once you've made the changes to your schema, your schema should resemble the one below:
+
+```prisma file=prisma/schema.prisma highlight=9,27-31;edit showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String @db.VarChar(255)
+ createdAt DateTime @default(now()) @db.Timestamp(6)
+ content String?
+ published Boolean @default(false)
+ authorId Int
+ user User @relation(fields: [authorId], references: [id])
+ //edit-next-line
+ tags Tag[]
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ userId Int @unique
+ user User @relation(fields: [userId], references: [id])
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ name String? @db.VarChar(255)
+ email String @unique @db.VarChar(255)
+ post Post[]
+ profile Profile?
+}
+
+//edit-start
+model Tag {
+ id Int @id @default(autoincrement())
+ name String
+ posts Post[]
+}
+//edit-end
+```
+
+To apply your Prisma schema changes to your database, use the `prisma migrate dev` CLI command:
+
+```terminal copy
+npx prisma migrate dev --name tags-model
+```
+
+This command will:
+
+1. Create a new SQL migration file for the migration
+1. Apply the generated SQL migration to the database
+1. Regenerate Prisma Client
+
+The following migration will be generated and saved in your `prisma/migrations` folder:
+
+```sql file=prisma/migrations/TIMESTAMP_tags_model.sql showLineNumbers
+ -- CreateTable
+CREATE TABLE "Tag" (
+ "id" SERIAL NOT NULL,
+ "name" VARCHAR(255) NOT NULL,
+
+ CONSTRAINT "Tag_pkey" PRIMARY KEY ("id")
+);
+
+-- CreateTable
+CREATE TABLE "_PostToTag" (
+ "A" INTEGER NOT NULL,
+ "B" INTEGER NOT NULL
+);
+
+-- CreateIndex
+CREATE UNIQUE INDEX "_PostToTag_AB_unique" ON "_PostToTag"("A", "B");
+
+-- CreateIndex
+CREATE INDEX "_PostToTag_B_index" ON "_PostToTag"("B");
+
+-- AddForeignKey
+ALTER TABLE "_PostToTag" ADD CONSTRAINT "_PostToTag_A_fkey" FOREIGN KEY ("A") REFERENCES "Post"("id") ON DELETE CASCADE ON UPDATE CASCADE;
+
+-- AddForeignKey
+ALTER TABLE "_PostToTag" ADD CONSTRAINT "_PostToTag_B_fkey" FOREIGN KEY ("B") REFERENCES "Tag"("id") ON DELETE CASCADE ON UPDATE CASCADE;
+```
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/275-evolve-your-schema-node-mysql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/275-evolve-your-schema-node-mysql.mdx
new file mode 100644
index 0000000000..7b3ed655e2
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/275-evolve-your-schema-node-mysql.mdx
@@ -0,0 +1,108 @@
+---
+title: 'Evolve your schema for a MySQL database in a Javascript project'
+sidebar_label: 'Evolve your schema'
+metaTitle: 'Evolve your Prisma schema with Prisma Migrate : JavaScript-MySQL'
+metaDescription: 'Evolve your Prisma schema with Prisma Migrate inside of your JavaScript and MySQL project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-node-mysql
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/next-steps
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/evolve-your-schema-
+---
+
+## Add a `Tag` model to your schema
+
+In this section, you will evolve your Prisma schema and then generate and apply the migration to your database with [`prisma migrate dev`](/orm/reference/prisma-cli-reference#migrate-dev).
+
+For the purpose of this guide, we'll make the following changes to the Prisma schema:
+
+1. Create a new model called `Tag` with the following fields:
+ - `id`: an auto-incrementing integer that will be the primary key for the model
+ - `name`: a non-null `String`
+ - `posts`: an implicit many-to-many relation field that links to the `Post` model
+2. Update the `Post` model with a `tags` field with an implicit many-to-many relation field that links to the `Tag` model
+
+Once you've made the changes to your schema, your schema should resemble the one below:
+
+```prisma file=prisma/schema.prisma highlight=9,27-31;edit showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String @db.VarChar(255)
+ createdAt DateTime @default(now()) @db.Timestamp(6)
+ content String?
+ published Boolean @default(false)
+ authorId Int
+ user User @relation(fields: [authorId], references: [id])
+ //edit-next-line
+ tags Tag[]
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ userId Int @unique
+ user User @relation(fields: [userId], references: [id])
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ name String? @db.VarChar(255)
+ email String @unique @db.VarChar(255)
+ post Post[]
+ profile Profile?
+}
+
+//edit-start
+model Tag {
+ id Int @id @default(autoincrement())
+ name String
+ posts Post[]
+}
+//edit-end
+```
+
+To apply your Prisma schema changes to your database, use the `prisma migrate dev` CLI command:
+
+```terminal copy
+npx prisma migrate dev --name tags-model
+```
+
+This command will:
+
+1. Create a new SQL migration file for the migration
+1. Apply the generated SQL migration to the database
+1. Regenerate Prisma Client
+
+The following migration will be generated and saved in your `prisma/migrations` folder:
+
+```sql file=prisma/migrations/TIMESTAMP_tags_model.sql showLineNumbers
+-- CreateTable
+CREATE TABLE Tag (
+ id SERIAL NOT NULL,
+ name VARCHAR(255) NOT NULL,
+
+ CONSTRAINT Tag_pkey PRIMARY KEY (id)
+);
+
+-- CreateTable
+CREATE TABLE _PostToTag (
+ A INTEGER NOT NULL,
+ B INTEGER NOT NULL
+);
+
+-- CreateIndex
+CREATE UNIQUE INDEX _PostToTag_AB_unique ON _PostToTag(A, B);
+
+-- CreateIndex
+CREATE INDEX _PostToTag_B_index ON _PostToTag(B);
+
+-- AddForeignKey
+ALTER TABLE _PostToTag ADD CONSTRAINT _PostToTag_A_fkey FOREIGN KEY (A) REFERENCES Post(id) ON DELETE CASCADE ON UPDATE CASCADE;
+
+-- AddForeignKey
+ALTER TABLE _PostToTag ADD CONSTRAINT _PostToTag_B_fkey FOREIGN KEY (B) REFERENCES Tag(id) ON DELETE CASCADE ON UPDATE CASCADE;
+```
+
+Congratulations, you just evolved your database with Prisma Migrate 🚀
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/275-evolve-your-schema-node-postgresql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/275-evolve-your-schema-node-postgresql.mdx
new file mode 100644
index 0000000000..c9ac290123
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/275-evolve-your-schema-node-postgresql.mdx
@@ -0,0 +1,107 @@
+---
+title: 'Evolve your schema for a PostgreSQL database in a Javascript project'
+sidebar_label: 'Evolve your schema'
+metaTitle: 'Evolve your Prisma schema with Prisma Migrate : JavaScript-PostgreSQL'
+metaDescription: 'Evolve your Prisma schema with Prisma Migrate inside of your JavaScript and PostgreSQL project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-node-postgresql
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/next-steps
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/evolve-your-schema-
+---
+
+## Add a `Tag` model to your schema
+
+In this section, you will evolve your Prisma schema and then generate and apply the migration to your database with [`prisma migrate dev`](/orm/reference/prisma-cli-reference#migrate-dev).
+
+For the purpose of this guide, we'll make the following changes to the Prisma schema:
+
+1. Create a new model called `Tag` with the following fields:
+ - `id`: an auto-incrementing integer that will be the primary key for the model
+ - `name`: a non-null `String`
+ - `posts`: an implicit many-to-many relation field that links to the `Post` model
+2. Update the `Post` model with a `tags` field with an implicit many-to-many relation field that links to the `Tag` model
+
+Once you've made the changes to your schema, your schema should resemble the one below:
+
+```prisma file=prisma/schema.prisma highlight=9,27-31;edit showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String @db.VarChar(255)
+ createdAt DateTime @default(now()) @db.Timestamp(6)
+ content String?
+ published Boolean @default(false)
+ authorId Int
+ user User @relation(fields: [authorId], references: [id])
+ //edit-next-line
+ tags Tag[]
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ userId Int @unique
+ user User @relation(fields: [userId], references: [id])
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ name String? @db.VarChar(255)
+ email String @unique @db.VarChar(255)
+ post Post[]
+ profile Profile?
+}
+//edit-start
+model Tag {
+ id Int @id @default(autoincrement())
+ name String
+ posts Post[]
+}
+//edit-end
+```
+
+To apply your Prisma schema changes to your database, use the `prisma migrate dev` CLI command:
+
+```terminal copy
+npx prisma migrate dev --name tags-model
+```
+
+This command will:
+
+1. Create a new SQL migration file for the migration
+1. Apply the generated SQL migration to the database
+1. Regenerate Prisma Client
+
+The following migration will be generated and saved in your `prisma/migrations` folder:
+
+```sql file=prisma/migrations/TIMESTAMP_tags_model.sql showLineNumbers
+ -- CreateTable
+CREATE TABLE "Tag" (
+ "id" SERIAL NOT NULL,
+ "name" VARCHAR(255) NOT NULL,
+
+ CONSTRAINT "Tag_pkey" PRIMARY KEY ("id")
+);
+
+-- CreateTable
+CREATE TABLE "_PostToTag" (
+ "A" INTEGER NOT NULL,
+ "B" INTEGER NOT NULL
+);
+
+-- CreateIndex
+CREATE UNIQUE INDEX "_PostToTag_AB_unique" ON "_PostToTag"("A", "B");
+
+-- CreateIndex
+CREATE INDEX "_PostToTag_B_index" ON "_PostToTag"("B");
+
+-- AddForeignKey
+ALTER TABLE "_PostToTag" ADD CONSTRAINT "_PostToTag_A_fkey" FOREIGN KEY ("A") REFERENCES "Post"("id") ON DELETE CASCADE ON UPDATE CASCADE;
+
+-- AddForeignKey
+ALTER TABLE "_PostToTag" ADD CONSTRAINT "_PostToTag_B_fkey" FOREIGN KEY ("B") REFERENCES "Tag"("id") ON DELETE CASCADE ON UPDATE CASCADE;
+```
+
+Congratulations, you just evolved your database with Prisma Migrate 🚀
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/275-evolve-your-schema-node-sqlserver.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/275-evolve-your-schema-node-sqlserver.mdx
new file mode 100644
index 0000000000..93c06b95e2
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/275-evolve-your-schema-node-sqlserver.mdx
@@ -0,0 +1,108 @@
+---
+title: 'Evolve your schema for a SQL Server database in a Javascript project'
+sidebar_label: 'Evolve your schema'
+metaTitle: 'Evolve your Prisma schema with Prisma Migrate : JavaScript-sqlserver'
+metaDescription: 'Evolve your Prisma schema with Prisma Migrate inside of your JavaScript and SQL Server project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-node-sqlserver
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/next-steps
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/evolve-your-schema-
+---
+
+## Add a `Tag` model to your schema
+
+In this section, you will evolve your Prisma schema and then generate and apply the migration to your database with [`prisma migrate dev`](/orm/reference/prisma-cli-reference#migrate-dev).
+
+For the purpose of this guide, we'll make the following changes to the Prisma schema:
+
+1. Create a new model called `Tag` with the following fields:
+ - `id`: an auto-incrementing integer that will be the primary key for the model
+ - `name`: a non-null `String`
+ - `posts`: an implicit many-to-many relation field that links to the `Post` model
+2. Update the `Post` model with a `tags` field with an implicit many-to-many relation field that links to the `Tag` model
+
+Once you've made the changes to your schema, your schema should resemble the one below:
+
+```prisma file=prisma/schema.prisma highlight=9,27-31;edit showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String @db.VarChar(255)
+ createdAt DateTime @default(now()) @db.Timestamp(6)
+ content String?
+ published Boolean @default(false)
+ authorId Int
+ user User @relation(fields: [authorId], references: [id])
+ //edit-next-line
+ tags Tag[]
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ userId Int @unique
+ user User @relation(fields: [userId], references: [id])
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ name String? @db.VarChar(255)
+ email String @unique @db.VarChar(255)
+ post Post[]
+ profile Profile?
+}
+
+//edit-start
+model Tag {
+ id Int @id @default(autoincrement())
+ name String
+ posts Post[]
+}
+//edit-end
+```
+
+To apply your Prisma schema changes to your database, use the `prisma migrate dev` CLI command:
+
+```terminal copy
+npx prisma migrate dev --name tags-model
+```
+
+This command will:
+
+1. Create a new SQL migration file for the migration
+1. Apply the generated SQL migration to the database
+1. Regenerate Prisma Client
+
+The following migration will be generated and saved in your `prisma/migrations` folder:
+
+```sql file=prisma/migrations/TIMESTAMP_tags_model.sql showLineNumbers
+ -- CreateTable
+CREATE TABLE [dbo].[Tag] (
+ [id] SERIAL NOT NULL,
+ [name] VARCHAR(255) NOT NULL,
+
+ CONSTRAINT [Tag_pkey] PRIMARY KEY ([id])
+);
+
+-- CreateTable
+CREATE TABLE [dbo].[_PostToTag] (
+ [A] INTEGER NOT NULL,
+ [B] INTEGER NOT NULL
+);
+
+-- CreateIndex
+CREATE UNIQUE INDEX [_PostToTag_AB_unique] ON _PostToTag([A], [B]);
+
+-- CreateIndex
+CREATE INDEX [_PostToTag_B_index] ON [_PostToTag]([B]);
+
+-- AddForeignKey
+ALTER TABLE [dbo].[_PostToTag] ADD CONSTRAINT [_PostToTag_A_fkey] FOREIGN KEY ([A]) REFERENCES [dbo].[Post]([id]) ON DELETE CASCADE ON UPDATE CASCADE;
+
+-- AddForeignKey
+ALTER TABLE [dbo].[_PostToTag] ADD CONSTRAINT [_PostToTag_B_fkey] FOREIGN KEY ([B]) REFERENCES [dbo].[Tag]([id]) ON DELETE CASCADE ON UPDATE CASCADE;
+```
+
+Congratulations
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/275-evolve-your-schema-typescript-cockroachdb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/275-evolve-your-schema-typescript-cockroachdb.mdx
new file mode 100644
index 0000000000..328f9a3c03
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/275-evolve-your-schema-typescript-cockroachdb.mdx
@@ -0,0 +1,109 @@
+---
+title: 'Evolve your schema for a CockroachDB database in a Typescript project'
+sidebar_label: 'Evolve your schema'
+metaTitle: 'Evolve your Prisma schema with Prisma Migrate : TypeScript-cockroachdb'
+metaDescription: 'Evolve your Prisma schema with Prisma Migrate inside of your TypeScript and CockroachDB project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-typescript-cockroachdb
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/next-steps
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/evolve-your-schema-
+---
+
+## Add a `Tag` model to your schema
+
+In this section, you will evolve your Prisma schema and then generate and apply the migration to your database with [`prisma migrate dev`](/orm/reference/prisma-cli-reference#migrate-dev).
+
+For the purpose of this guide, we'll make the following changes to the Prisma schema:
+
+1. Create a new model called `Tag` with the following fields:
+ - `id`: an auto-incrementing integer that will be the primary key for the model
+ - `name`: a non-null `String`
+ - `posts`: an implicit many-to-many relation field that links to the `Post` model
+2. Update the `Post` model with a `tags` field with an implicit many-to-many relation field that links to the `Tag` model
+
+Once you've made the changes to your schema, your schema should resemble the one below:
+
+```prisma file=prisma/schema.prisma highlight=9,27-31;edit showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String @db.VarChar(255)
+ createdAt DateTime @default(now()) @db.Timestamp(6)
+ content String?
+ published Boolean @default(false)
+ authorId Int
+ user User @relation(fields: [authorId], references: [id])
+ //edit-next-line
+ tags Tag[]
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ userId Int @unique
+ user User @relation(fields: [userId], references: [id])
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ name String? @db.VarChar(255)
+ email String @unique @db.VarChar(255)
+ post Post[]
+ profile Profile?
+}
+
+//edit-start
+model Tag {
+ id Int @id @default(autoincrement())
+ name String
+ posts Post[]
+}
+//edit-end
+```
+
+To apply your Prisma schema changes to your database, use the `prisma migrate dev` CLI command:
+
+```terminal copy
+npx prisma migrate dev --name tags-model
+```
+
+This command will:
+
+1. Create a new SQL migration file for the migration
+1. Apply the generated SQL migration to the database
+1. Regenerate Prisma Client
+
+The following migration will be generated and saved in your `prisma/migrations` folder:
+
+```sql file=prisma/migrations/TIMESTAMP_tags_model.sql showLineNumbers
+ -- CreateTable
+CREATE TABLE "Tag" (
+ "id" SERIAL NOT NULL,
+ "name" VARCHAR(255) NOT NULL,
+
+ CONSTRAINT "Tag_pkey" PRIMARY KEY ("id")
+);
+
+-- CreateTable
+CREATE TABLE "_PostToTag" (
+ "A" INTEGER NOT NULL,
+ "B" INTEGER NOT NULL
+);
+
+-- CreateIndex
+CREATE UNIQUE INDEX "_PostToTag_AB_unique" ON "_PostToTag"("A", "B");
+
+-- CreateIndex
+CREATE INDEX "_PostToTag_B_index" ON "_PostToTag"("B");
+
+-- AddForeignKey
+ALTER TABLE "_PostToTag" ADD CONSTRAINT "_PostToTag_A_fkey" FOREIGN KEY ("A") REFERENCES "Post"("id") ON DELETE CASCADE ON UPDATE CASCADE;
+
+-- AddForeignKey
+ALTER TABLE "_PostToTag" ADD CONSTRAINT "_PostToTag_B_fkey" FOREIGN KEY ("B") REFERENCES "Tag"("id") ON DELETE CASCADE ON UPDATE CASCADE;
+```
+
+Congratulations, you just evolved your database with Prisma Migrate 🚀
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/275-evolve-your-schema-typescript-mysql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/275-evolve-your-schema-typescript-mysql.mdx
new file mode 100644
index 0000000000..d810eddcb6
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/275-evolve-your-schema-typescript-mysql.mdx
@@ -0,0 +1,108 @@
+---
+title: 'Evolve your schema for a MySQL database in a Typescript project'
+sidebar_label: 'Evolve your schema'
+metaTitle: 'Evolve your Prisma schema with Prisma Migrate : TypeScript-mysql'
+metaDescription: 'Evolve your Prisma schema with Prisma Migrate inside of your TypeScript and MySQL project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-typescript-mysql
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/next-steps
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/evolve-your-schema-
+---
+
+## Add a `Tag` model to your schema
+
+In this section, you will evolve your Prisma schema and then generate and apply the migration to your database with [`prisma migrate dev`](/orm/reference/prisma-cli-reference#migrate-dev).
+
+For the purpose of this guide, we'll make the following changes to the Prisma schema:
+
+1. Create a new model called `Tag` with the following fields:
+ - `id`: an auto-incrementing integer that will be the primary key for the model
+ - `name`: a non-null `String`
+ - `posts`: an implicit many-to-many relation field that links to the `Post` model
+2. Update the `Post` model with a `tags` field with an implicit many-to-many relation field that links to the `Tag` model
+
+Once you've made the changes to your schema, your schema should resemble the one below:
+
+```prisma file=prisma/schema.prisma highlight=9,27-31;edit showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String @db.VarChar(255)
+ createdAt DateTime @default(now()) @db.Timestamp(6)
+ content String?
+ published Boolean @default(false)
+ authorId Int
+ user User @relation(fields: [authorId], references: [id])
+ //edit-next-line
+ tags Tag[]
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ userId Int @unique
+ user User @relation(fields: [userId], references: [id])
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ name String? @db.VarChar(255)
+ email String @unique @db.VarChar(255)
+ post Post[]
+ profile Profile?
+}
+
+//edit-start
+model Tag {
+ id Int @id @default(autoincrement())
+ name String
+ posts Post[]
+}
+//edit-end
+```
+
+To apply your Prisma schema changes to your database, use the `prisma migrate dev` CLI command:
+
+```terminal copy
+npx prisma migrate dev --name tags-model
+```
+
+This command will:
+
+1. Create a new SQL migration file for the migration
+1. Apply the generated SQL migration to the database
+1. Regenerate Prisma Client
+
+The following migration will be generated and saved in your `prisma/migrations` folder:
+
+```sql file=prisma/migrations/TIMESTAMP_tags_model.sql showLineNumbers
+-- CreateTable
+CREATE TABLE Tag (
+ id SERIAL NOT NULL,
+ name VARCHAR(255) NOT NULL,
+
+ CONSTRAINT Tag_pkey PRIMARY KEY (id)
+);
+
+-- CreateTable
+CREATE TABLE _PostToTag (
+ A INTEGER NOT NULL,
+ B INTEGER NOT NULL
+);
+
+-- CreateIndex
+CREATE UNIQUE INDEX _PostToTag_AB_unique ON _PostToTag(A, B);
+
+-- CreateIndex
+CREATE INDEX _PostToTag_B_index ON _PostToTag(B);
+
+-- AddForeignKey
+ALTER TABLE _PostToTag ADD CONSTRAINT _PostToTag_A_fkey FOREIGN KEY (A) REFERENCES Post(id) ON DELETE CASCADE ON UPDATE CASCADE;
+
+-- AddForeignKey
+ALTER TABLE _PostToTag ADD CONSTRAINT _PostToTag_B_fkey FOREIGN KEY (B) REFERENCES Tag(id) ON DELETE CASCADE ON UPDATE CASCADE;
+```
+
+Congratulations, you just evolved your database with Prisma Migrate 🚀
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/275-evolve-your-schema-typescript-postgresql.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/275-evolve-your-schema-typescript-postgresql.mdx
new file mode 100644
index 0000000000..9159fff535
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/275-evolve-your-schema-typescript-postgresql.mdx
@@ -0,0 +1,109 @@
+---
+title: 'Evolve your schema for a PostgreSQL database in a Typescript project'
+sidebar_label: 'Evolve your schema'
+metaTitle: 'Evolve your Prisma schema with Prisma Migrate : TypeScript-postgresql'
+metaDescription: 'Evolve your Prisma schema with Prisma Migrate inside of your TypeScript and PostgreSQL project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'cockroachdb']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-typescript-postgresql
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/next-steps
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/evolve-your-schema-
+---
+
+## Add a `Tag` model to your schema
+
+In this section, you will evolve your Prisma schema and then generate and apply the migration to your database with [`prisma migrate dev`](/orm/reference/prisma-cli-reference#migrate-dev).
+
+For the purpose of this guide, we'll make the following changes to the Prisma schema:
+
+1. Create a new model called `Tag` with the following fields:
+ - `id`: an auto-incrementing integer that will be the primary key for the model
+ - `name`: a non-null `String`
+ - `posts`: an implicit many-to-many relation field that links to the `Post` model
+2. Update the `Post` model with a `tags` field with an implicit many-to-many relation field that links to the `Tag` model
+
+Once you've made the changes to your schema, your schema should resemble the one below:
+
+```prisma file=prisma/schema.prisma highlight=9,27-31;edit showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String @db.VarChar(255)
+ createdAt DateTime @default(now()) @db.Timestamp(6)
+ content String?
+ published Boolean @default(false)
+ authorId Int
+ user User @relation(fields: [authorId], references: [id])
+ //edit-next-line
+ tags Tag[]
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ userId Int @unique
+ user User @relation(fields: [userId], references: [id])
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ name String? @db.VarChar(255)
+ email String @unique @db.VarChar(255)
+ post Post[]
+ profile Profile?
+}
+
+//edit-start
+model Tag {
+ id Int @id @default(autoincrement())
+ name String
+ posts Post[]
+}
+//edit-end
+```
+
+To apply your Prisma schema changes to your database, use the `prisma migrate dev` CLI command:
+
+```terminal copy
+npx prisma migrate dev --name tags-model
+```
+
+This command will:
+
+1. Create a new SQL migration file for the migration
+1. Apply the generated SQL migration to the database
+1. Regenerate Prisma Client
+
+The following migration will be generated and saved in your `prisma/migrations` folder:
+
+```sql file=prisma/migrations/TIMESTAMP_tags_model.sql showLineNumbers
+ -- CreateTable
+CREATE TABLE "Tag" (
+ "id" SERIAL NOT NULL,
+ "name" VARCHAR(255) NOT NULL,
+
+ CONSTRAINT "Tag_pkey" PRIMARY KEY ("id")
+);
+
+-- CreateTable
+CREATE TABLE "_PostToTag" (
+ "A" INTEGER NOT NULL,
+ "B" INTEGER NOT NULL
+);
+
+-- CreateIndex
+CREATE UNIQUE INDEX "_PostToTag_AB_unique" ON "_PostToTag"("A", "B");
+
+-- CreateIndex
+CREATE INDEX "_PostToTag_B_index" ON "_PostToTag"("B");
+
+-- AddForeignKey
+ALTER TABLE "_PostToTag" ADD CONSTRAINT "_PostToTag_A_fkey" FOREIGN KEY ("A") REFERENCES "Post"("id") ON DELETE CASCADE ON UPDATE CASCADE;
+
+-- AddForeignKey
+ALTER TABLE "_PostToTag" ADD CONSTRAINT "_PostToTag_B_fkey" FOREIGN KEY ("B") REFERENCES "Tag"("id") ON DELETE CASCADE ON UPDATE CASCADE;
+```
+
+
+
+Congratulations, you just evolved your database with Prisma Migrate 🚀
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/275-evolve-your-schema-typescript-sqlserver.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/275-evolve-your-schema-typescript-sqlserver.mdx
new file mode 100644
index 0000000000..4b98a336f0
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/275-evolve-your-schema-typescript-sqlserver.mdx
@@ -0,0 +1,108 @@
+---
+title: 'Evolve your schema for a SQL Server database in a Typescript project'
+sidebar_label: 'Evolve your schema'
+metaTitle: 'Evolve your Prisma schema with Prisma Migrate : TypeScript-sql-server'
+metaDescription: 'Evolve your Prisma schema with Prisma Migrate inside of your TypeScript and SQL Server project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['postgresql', 'mysql', 'sqlserver', 'cockroachdb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/relational-databases/querying-the-database-typescript-sqlserver
+pagination_next: getting-started/setup-prisma/add-to-existing-project/relational-databases/next-steps
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/relational-databases/evolve-your-schema-
+---
+
+## Add a `Tag` model to your schema
+
+In this section, you will evolve your Prisma schema and then generate and apply the migration to your database with [`prisma migrate dev`](/orm/reference/prisma-cli-reference#migrate-dev).
+
+For the purpose of this guide, we'll make the following changes to the Prisma schema:
+
+1. Create a new model called `Tag` with the following fields:
+ - `id`: an auto-incrementing integer that will be the primary key for the model
+ - `name`: a non-null `String`
+ - `posts`: an implicit many-to-many relation field that links to the `Post` model
+2. Update the `Post` model with a `tags` field with an implicit many-to-many relation field that links to the `Tag` model
+
+Once you've made the changes to your schema, your schema should resemble the one below:
+
+```prisma file=prisma/schema.prisma highlight=9,27-31;edit showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String @db.VarChar(255)
+ createdAt DateTime @default(now()) @db.Timestamp(6)
+ content String?
+ published Boolean @default(false)
+ authorId Int
+ user User @relation(fields: [authorId], references: [id])
+ //edit-next-line
+ tags Tag[]
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String?
+ userId Int @unique
+ user User @relation(fields: [userId], references: [id])
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ name String? @db.VarChar(255)
+ email String @unique @db.VarChar(255)
+ post Post[]
+ profile Profile?
+}
+
+//edit-start
+model Tag {
+ id Int @id @default(autoincrement())
+ name String
+ posts Post[]
+}
+//edit-end
+```
+
+To apply your Prisma schema changes to your database, use the `prisma migrate dev` CLI command:
+
+```terminal copy
+npx prisma migrate dev --name tags-model
+```
+
+This command will:
+
+1. Create a new SQL migration file for the migration
+1. Apply the generated SQL migration to the database
+1. Regenerate Prisma Client
+
+The following migration will be generated and saved in your `prisma/migrations` folder:
+
+```sql file=prisma/migrations/TIMESTAMP_tags_model.sql showLineNumbers
+ -- CreateTable
+CREATE TABLE [dbo].[Tag] (
+ [id] SERIAL NOT NULL,
+ [name] VARCHAR(255) NOT NULL,
+
+ CONSTRAINT [Tag_pkey] PRIMARY KEY ([id])
+);
+
+-- CreateTable
+CREATE TABLE [dbo].[_PostToTag] (
+ [A] INTEGER NOT NULL,
+ [B] INTEGER NOT NULL
+);
+
+-- CreateIndex
+CREATE UNIQUE INDEX [_PostToTag_AB_unique] ON _PostToTag([A], [B]);
+
+-- CreateIndex
+CREATE INDEX [_PostToTag_B_index] ON [_PostToTag]([B]);
+
+-- AddForeignKey
+ALTER TABLE [dbo].[_PostToTag] ADD CONSTRAINT [_PostToTag_A_fkey] FOREIGN KEY ([A]) REFERENCES [dbo].[Post]([id]) ON DELETE CASCADE ON UPDATE CASCADE;
+
+-- AddForeignKey
+ALTER TABLE [dbo].[_PostToTag] ADD CONSTRAINT [_PostToTag_B_fkey] FOREIGN KEY ([B]) REFERENCES [dbo].[Tag]([id]) ON DELETE CASCADE ON UPDATE CASCADE;
+```
+
+Congratulations, you just evolved your database with Prisma Migrate 🚀
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/300-next-steps.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/300-next-steps.mdx
new file mode 100644
index 0000000000..9cbb67caa6
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/300-next-steps.mdx
@@ -0,0 +1,112 @@
+---
+title: 'Next steps after adding Prisma ORM to your existing project'
+sidebar_label: 'Next steps'
+metaTitle: 'Next steps after adding Prisma ORM to your existing project'
+metaDescription: 'Next steps to take now that you have successfully added Prisma ORM to your relational database project'
+hide_table_of_contents: true
+---
+
+This section lists a number of potential next steps you can now take from here. Feel free to explore these or read the [Introduction](/orm/overview/introduction/what-is-prisma) page to get a high-level overview of Prisma ORM.
+
+### Continue exploring the Prisma Client API
+
+You can send a variety of queries with the Prisma Client API. Check out the [API reference](/orm/prisma-client) and use your existing database setup from this guide to try them out.
+
+:::tip
+
+You can use your editor's auto-completion feature to learn about the different API calls and the arguments it takes. Auto-completion is commonly invoked by hitting CTRL+SPACE on your keyboard.
+
+:::
+
+
+Expand for more Prisma Client API examples
+
+Here are a few suggestions for a number of more queries you can send with Prisma Client:
+
+**Filter all `Post` records that contain `"hello"`**
+
+```js
+const filteredPosts = await prisma.post.findMany({
+ where: {
+ OR: [
+ { title: { contains: "hello" },
+ { content: { contains: "hello" },
+ ],
+ },
+})
+```
+
+**Create a new `Post` record and connect it to an existing `User` record**
+
+```js
+const post = await prisma.post.create({
+ data: {
+ title: 'Join us for Prisma Day 2020',
+ author: {
+ connect: { email: 'alice@prisma.io' },
+ },
+ },
+})
+```
+
+**Use the fluent relations API to retrieve the `Post` records of a `User` by traversing the relations**
+
+```js
+const posts = await prisma.profile
+ .findUnique({
+ where: { id: 1 },
+ })
+ .user()
+ .posts()
+```
+
+**Delete a `User` record**
+
+```js
+const deletedUser = await prisma.user.delete({
+ where: { email: 'sarah@prisma.io' },
+})
+```
+
+
+
+### Build an app with Prisma ORM
+
+The Prisma blog features comprehensive tutorials about Prisma ORM, check out our latest ones:
+
+- [Build a fullstack app with Next.js](https://www.youtube.com/watch?v=QXxy8Uv1LnQ&ab_channel=ByteGrad)
+- [Build a fullstack app with Remix](https://www.prisma.io/blog/fullstack-remix-prisma-mongodb-1-7D0BfTXBmB6r) (5 parts, including videos)
+- [Build a REST API with NestJS](https://www.prisma.io/blog/nestjs-prisma-rest-api-7D056s1BmOL0)
+
+### Explore the data in Prisma Studio
+
+Prisma Studio is a visual editor for the data in your database. Run `npx prisma studio` in your terminal.
+
+### Get query insights and analytics with Prisma Optimize
+
+[Prisma Optimize](/optimize) helps you generate insights and provides recommendations that can help you make your database queries faster. [Try it out now!](/optimize/getting-started)
+
+Optimize aims to help developers of all skill levels write efficient database queries, reducing database load and making applications more responsive.
+
+### Change the database schema (e.g. add more tables)
+
+To evolve the app, you need to follow the same flow of the tutorial:
+
+1. Manually adjust your database schema using SQL
+1. Re-introspect your database
+1. Optionally re-configure your Prisma Client API
+1. Re-generate Prisma Client
+
+
+
+### Try a Prisma ORM example
+
+The [`prisma-examples`](https://github.com/prisma/prisma-examples/) repository contains a number of ready-to-run examples:
+
+| Demo | Stack | Description |
+| :------------------------------------------------------------------------------------------------------------------ | :----------- | --------------------------------------------------------------------------------------------------- |
+| [`nextjs`](https://pris.ly/e/orm/nextjs) | Fullstack | Simple [Next.js](https://nextjs.org/) app |
+| [`nextjs-graphql`](https://pris.ly/e/ts/graphql-nextjs) | Fullstack | Simple [Next.js](https://nextjs.org/) app (React) with a GraphQL API |
+| [`graphql-nexus`](https://pris.ly/e/ts/graphql-nexus) | Backend only | GraphQL server based on [`@apollo/server`](https://www.apollographql.com/docs/apollo-server) |
+| [`express`](https://pris.ly/e/ts/rest-express) | Backend only | Simple REST API with Express.JS |
+| [`grpc`](https://pris.ly/e/ts/grpc) | Backend only | Simple gRPC API |
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/_install-prisma-client-partial.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/_install-prisma-client-partial.mdx
new file mode 100644
index 0000000000..2bf6ab6d15
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/110-relational-databases/_install-prisma-client-partial.mdx
@@ -0,0 +1,25 @@
+## Install and generate Prisma Client
+
+To get started with Prisma Client, first install the `@prisma/client` package:
+
+```terminal copy
+npm install @prisma/client
+```
+
+Then, run `prisma generate` which reads your Prisma schema and generates the Prisma Client.
+
+```terminal copy
+npx prisma generate
+```
+
+You can now import the `PrismaClient` constructor from the `@prisma/client` package to create an instance of Prisma Client to send queries to your database. You'll learn how to do that in the next section.
+
+:::note Good to know
+
+When you run `prisma generate`, you are actually creating code (TypeScript types, methods, queries, ...) that is tailored to _your_ Prisma schema file or files in the `prisma` directory. This means, that whenever you make changes to your Prisma schema file, you also need to update the Prisma Client. You can do this by running the `prisma generate` command.
+
+
+
+Whenever you update your Prisma schema, you will have to update your database schema using either `prisma migrate dev` or `prisma db push`. This will keep your database schema in sync with your Prisma schema. These commands will also run `prisma generate` under the hood to re-generate your Prisma Client.
+
+:::
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb-node-mongodb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb-node-mongodb.mdx
new file mode 100644
index 0000000000..92366024f7
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb-node-mongodb.mdx
@@ -0,0 +1,58 @@
+---
+title: 'Add Prisma ORM to an existing MongoDB project using JavaScript'
+sidebar_label: 'MongoDB'
+metaTitle: 'Add Prisma ORM to an existing MongoDB project using JavaScript (15 min)'
+metaDescription: 'Learn how to add Prisma ORM to an existing Node.js project by connecting it to your MongoDB database and generating a Prisma Client for database access.'
+toc: false
+langSwitcher: ['typescript', 'node']
+hide_table_of_contents: true
+dbSwitcher: ['mongodb']
+sidebar_class_name: hidden-sidebar
+pagination_next: getting-started/setup-prisma/add-to-existing-project/mongodb/connect-your-database-node-mongodb
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/mongodb-
+---
+
+Learn how to add Prisma ORM to an existing Node.js or TypeScript project by connecting it to your database and generating a Prisma Client for database access. The following tutorial introduces you to [Prisma CLI](/orm/tools/prisma-cli), [Prisma Client](/orm/prisma-client), and [Prisma Introspection](/orm/prisma-schema/introspection).
+
+
+
+If you're migrating to Prisma ORM from Mongoose, see our [Migrate from Mongoose guide](/guides/migrate-from-mongoose).
+
+
+
+## Prerequisites
+
+In order to successfully complete this guide, you need:
+
+- [Node.js](https://nodejs.org/en/) installed on your machine (see [system requirements](/orm/reference/system-requirements) for officially supported versions)
+- Access to a MongoDB 4.2+ server with a replica set deployment. We recommend using [MongoDB Atlas](https://www.mongodb.com/cloud/atlas).
+
+
+
+ The MongoDB database connector uses transactions to support nested writes. Transactions **requires** a [replica set](https://www.mongodb.com/docs/manual/tutorial/deploy-replica-set/) deployment. The easiest way to deploy a replica set is with [Atlas](https://www.mongodb.com/docs/atlas/getting-started/). It's free to get started.
+
+
+
+Make sure you have your database [connection URL](/orm/reference/connection-urls) (that includes your authentication credentials) at hand! If you don't have a database server running and just want to explore Prisma ORM, check out the [Quickstart](/getting-started/quickstart-sqlite).
+
+> See [System requirements](/orm/reference/system-requirements) for exact version requirements.
+
+## Set up Prisma ORM
+
+As a first step, navigate into it your project directory that contains the `package.json` file.
+
+Next, add the Prisma CLI as a development dependency to your project:
+
+```terminal copy
+npm install prisma --save-dev
+```
+
+:::note
+
+If your project contains multiple directories with `package.json` files (e.g., `frontend`, `backend`, etc.), note that Prisma ORM is specifically designed for use in the API/backend layer. To set up Prisma, navigate to the appropriate backend directory containing the relevant `package.json` file and configure Prisma there.
+
+:::
+
+import PrismaInitPartial from './_prisma-init-partial.mdx'
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb-typescript-mongodb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb-typescript-mongodb.mdx
new file mode 100644
index 0000000000..fec31143a6
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb-typescript-mongodb.mdx
@@ -0,0 +1,59 @@
+---
+title: 'Add Prisma ORM to an existing MongoDB project using TypeScript '
+sidebar_label: 'MongoDB'
+metaTitle: 'Add Prisma ORM to an existing MongoDB project using TypeScript (15 min)'
+metaDescription: 'Learn how to add Prisma ORM to an existing TypeScript project by connecting it to your MongoDB database and generating a Prisma Client for database access.'
+hide_table_of_contents: true
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['mongodb']
+sidebar_custom_props: { badge: '15 min' }
+sidebar_class_name: hidden-sidebar
+pagination_next: getting-started/setup-prisma/add-to-existing-project/mongodb/connect-your-database-typescript-mongodb
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/mongodb-
+---
+
+Learn how to add Prisma ORM to an existing Node.js or TypeScript project by connecting it to your database and generating a Prisma Client for database access. The following tutorial introduces you to [Prisma CLI](/orm/tools/prisma-cli), [Prisma Client](/orm/prisma-client), and [Prisma Introspection](/orm/prisma-schema/introspection).
+
+
+
+If you're migrating to Prisma ORM from Mongoose, see our [Migrate from Mongoose guide](/guides/migrate-from-mongoose).
+
+
+
+## Prerequisites
+
+In order to successfully complete this guide, you need:
+
+- [Node.js](https://nodejs.org/en/) installed on your machine (see [system requirements](/orm/reference/system-requirements) for officially supported versions)
+- Access to a MongoDB 4.2+ server with a replica set deployment. We recommend using [MongoDB Atlas](https://www.mongodb.com/cloud/atlas).
+
+
+
+ The MongoDB database connector uses transactions to support nested writes. Transactions **requires** a [replica set](https://www.mongodb.com/docs/manual/tutorial/deploy-replica-set/) deployment. The easiest way to deploy a replica set is with [Atlas](https://www.mongodb.com/docs/atlas/getting-started/). It's free to get started.
+
+
+
+Make sure you have your database [connection URL](/orm/reference/connection-urls) (that includes your authentication credentials) at hand! If you don't have a database server running and just want to explore Prisma ORM, check out the [Quickstart](/getting-started/quickstart-sqlite).
+
+> See [System requirements](/orm/reference/system-requirements) for exact version requirements.
+
+## Set up Prisma ORM
+
+As a first step, navigate into it your project directory that contains the `package.json` file.
+
+Next, add the Prisma CLI as a development dependency to your project:
+
+```terminal copy
+npm install prisma --save-dev
+```
+
+:::note
+
+If your project contains multiple directories with `package.json` files (e.g., `frontend`, `backend`, etc.), note that Prisma ORM is specifically designed for use in the API/backend layer. To set up Prisma, navigate to the appropriate backend directory containing the relevant `package.json` file and configure Prisma there.
+
+:::
+
+import PrismaInitPartial from './_prisma-init-partial.mdx'
+
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb/100-connect-your-database-node-mongodb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb/100-connect-your-database-node-mongodb.mdx
new file mode 100644
index 0000000000..09e3fd39de
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb/100-connect-your-database-node-mongodb.mdx
@@ -0,0 +1,57 @@
+---
+title: 'Connect MongoDB to your existing Node.js project'
+sidebar_label: 'Connect your database (MongoDB)'
+metaTitle: 'Connect your MongoDB database'
+metaDescription: 'Connect your MongoDB database to your existing Node.js project'
+langSwitcher: ['typescript', 'node']
+sidebar_class_name: hidden-sidebar
+hide_table_of_contents: true
+dbSwitcher: ['mongodb']
+toc: false
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/mongodb-node-mongodb
+pagination_next: getting-started/setup-prisma/add-to-existing-project/mongodb/introspection-node-mongodb
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/mongodb/connect-your-database-
+---
+
+## Connecting your database
+
+To connect your database, you need to set the `url` field of the `datasource` block in your Prisma schema to your database [connection URL](/orm/reference/connection-urls):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "mongodb"
+ url = env("DATABASE_URL")
+}
+```
+
+In this case, the `url` is [set via an environment variable](/orm/more/development-environment/environment-variables) which is defined in `.env`:
+
+```bash file=.env showLineNumbers
+DATABASE_URL="mongodb+srv://test:test@cluster0.ns1yp.mongodb.net/myFirstDatabase"
+```
+
+You now need to adjust the connection URL to point to your own database.
+
+The [format of the connection URL](/orm/reference/connection-urls) for your database depends on the database you use. For MongoDB, it looks as follows (the parts spelled all-uppercased are _placeholders_ for your specific connection details):
+
+```no-lines
+mongodb://USERNAME:PASSWORD@HOST:PORT/DATABASE
+```
+
+Here's a short explanation of each component:
+
+- `USERNAME`: The name of your database user
+- `PASSWORD`: The password for your database user
+- `HOST`: The host where a [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod/#mongodb-binary-bin.mongod) (or [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos/#mongodb-binary-bin.mongos)) instance is running
+- `PORT`: The port where your database server is running (typically `27017` for MongoDB)
+- `DATABASE`: The name of the database. Note that if you're using MongoDB Atlas, you need to manually append the database name to the connection URL because the environment link from MongoDB Atlas doesn't contain it.
+
+## Troubleshooting
+
+### `Error in connector: SCRAM failure: Authentication failed.`
+
+If you see the `Error in connector: SCRAM failure: Authentication failed.` error message, you can specify the source database for the authentication by [adding](https://github.com/prisma/prisma/discussions/9994#discussioncomment-1562283) `?authSource=admin` to the end of the connection string.
+
+### `Raw query failed. Error code 8000 (AtlasError): empty database name not allowed.`
+
+If you see the `Raw query failed. Code: unknown. Message: Kind: Command failed: Error code 8000 (AtlasError): empty database name not allowed.` error message, be sure to append the database name to the database URL. You can find more info in this [GitHub issue](https://github.com/prisma/docs/issues/5562).
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb/100-connect-your-database-typescript-mongodb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb/100-connect-your-database-typescript-mongodb.mdx
new file mode 100644
index 0000000000..f53849a73d
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb/100-connect-your-database-typescript-mongodb.mdx
@@ -0,0 +1,55 @@
+---
+title: 'Connect your MongoDB database to your existing TypeScript project'
+sidebar_label: 'Connect your database (MongoDB)'
+metaTitle: 'Connect your MongoDB database using TypeScript'
+metaDescription: 'Connect your MongoDB database to your existing TypeScript project'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['mongodb']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/mongodb-typescript-mongodb
+pagination_next: getting-started/setup-prisma/add-to-existing-project/mongodb/introspection-typescript-mongodb
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/mongodb/connect-your-database-
+---
+
+## Connecting your database
+
+To connect your database, you need to set the `url` field of the `datasource` block in your Prisma schema to your database [connection URL](/orm/reference/connection-urls):
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "mongodb"
+ url = env("DATABASE_URL")
+}
+```
+
+In this case, the `url` is [set via an environment variable](/orm/more/development-environment/environment-variables) which is defined in `.env`:
+
+```bash file=.env showLineNumbers
+DATABASE_URL="mongodb+srv://test:test@cluster0.ns1yp.mongodb.net/myFirstDatabase"
+```
+
+You now need to adjust the connection URL to point to your own database.
+
+The [format of the connection URL](/orm/reference/connection-urls) for your database depends on the database you use. For MongoDB, it looks as follows (the parts spelled all-uppercased are _placeholders_ for your specific connection details):
+
+```no-lines
+mongodb://USERNAME:PASSWORD@HOST:PORT/DATABASE
+```
+
+Here's a short explanation of each component:
+
+- `USERNAME`: The name of your database user
+- `PASSWORD`: The password for your database user
+- `HOST`: The host where a [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod/#mongodb-binary-bin.mongod) (or [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos/#mongodb-binary-bin.mongos)) instance is running
+- `PORT`: The port where your database server is running (typically `27017` for MongoDB)
+- `DATABASE`: The name of the database. Note that if you're using MongoDB Atlas, you need to manually append the database name to the connection URL because the environment link from MongoDB Atlas doesn't contain it.
+
+## Troubleshooting
+
+### `Error in connector: SCRAM failure: Authentication failed.`
+
+If you see the `Error in connector: SCRAM failure: Authentication failed.` error message, you can specify the source database for the authentication by [adding](https://github.com/prisma/prisma/discussions/9994#discussioncomment-1562283) `?authSource=admin` to the end of the connection string.
+
+### `Raw query failed. Error code 8000 (AtlasError): empty database name not allowed.`
+
+If you see the `Raw query failed. Code: unknown. Message: Kind: Command failed: Error code 8000 (AtlasError): empty database name not allowed.` error message, be sure to append the database name to the database URL. You can find more info in this [GitHub issue](https://github.com/prisma/docs/issues/5562).
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb/125-introspection-node-mongodb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb/125-introspection-node-mongodb.mdx
new file mode 100644
index 0000000000..7d4f30e8f9
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb/125-introspection-node-mongodb.mdx
@@ -0,0 +1,130 @@
+---
+title: 'Introspection for MongoDB in a JavaScript project'
+sidebar_label: 'Introspection'
+metaTitle: 'Introspection: MongoDB and JavaScript'
+metaDescription: 'Introspect your MongoDB database with Prisma ORM'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['mongodb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/mongodb/connect-your-database-node-mongodb
+pagination_next: getting-started/setup-prisma/add-to-existing-project/mongodb/install-prisma-client-node-mongodb
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/mongodb/introspection-
+---
+
+
+Prisma ORM introspects a MongoDB schema by sampling the data stored in the given database and inferring the schema of that data.
+
+For the purposes of illustrating introspection, this guide will help you setup a MongoDB from scratch. But if you have a MongoDB database already, feel free to jump to [Initializing Prisma ORM](#initializing-prisma-orm) in your project.
+
+## Setting up your Database
+
+To see this in action, first create a `blog` database with 2 collections: `User` and `Post`. We recommend [MongoDB Compass](https://www.mongodb.com/products/tools/compass) for setting this up:
+
+
+
+First, add a user to our `User` collection:
+
+
+
+Next, add some posts to our `Post` collection. It's important that the ObjectID in `userId` matches the user you created above.
+
+
+
+## Initializing Prisma ORM
+
+Now that you have a MongoDB database, the next step is to create a new project and initialize Prisma ORM:
+
+```terminal copy
+mkdir blog
+cd blog
+npm init -y
+npm install -D prisma
+npx prisma init --datasource-provider mongodb --output ../generated/prisma
+```
+
+Initializing Prisma ORM will create a `prisma/schema.prisma` file like the following:
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "mongodb"
+ url = env("DATABASE_URL")
+}
+
+generator client {
+ provider = "prisma-client-js"
+}
+```
+
+Next you'll need to adjust your `.env` file to point the `DATABASE_URL` to your MongoDB database
+
+## Introspecting MongoDB with Prisma ORM
+
+You're now ready to introspect. Run the following command to introspect your database:
+
+```terminal copy
+npx prisma db pull
+```
+
+This command introspects our database and writes the inferred schema into your `prisma/schema.prisma` file:
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "mongodb"
+ url = env("DATABASE_URL")
+}
+
+generator client {
+ provider = "prisma-client-js"
+}
+
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ title String
+ userId String @db.ObjectId
+}
+
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ email String
+}
+```
+
+## Tweaking the Schema
+
+To be able to join data using Prisma Client, you can add the [`@relation`](/orm/reference/prisma-schema-reference#relation) attributes to our models:
+
+```prisma file=prisma/schema.prisma highlight=14;add|20;add showLineNumbers
+datasource db {
+ provider = "mongodb"
+ url = env("DATABASE_URL")
+}
+
+generator client {
+ provider = "prisma-client-js"
+}
+
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ title String
+ userId String @db.ObjectId
+ //add-next-line
+ user User @relation(fields: [userId], references: [id])
+}
+
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ email String
+ //add-next-line
+ posts Post[]
+}
+```
+
+:::tip
+
+We're actively working on MongoDB introspection. Provide feedback for this feature in [this issue](https://github.com/prisma/prisma/issues/8241).
+
+:::
+
+And with that, you're ready to generate Prisma Client.
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb/125-introspection-typescript-mongodb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb/125-introspection-typescript-mongodb.mdx
new file mode 100644
index 0000000000..d7f371fc9f
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb/125-introspection-typescript-mongodb.mdx
@@ -0,0 +1,129 @@
+---
+title: 'Introspection for MongoDB in a TypeScript project'
+sidebar_label: 'Introspection'
+metaTitle: 'Introspection: MongoDB and TypeScript'
+metaDescription: 'Introspection your MongoDB database with Prisma ORM'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['mongodb']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/mongodb/connect-your-database-typescript-mongodb
+pagination_next: getting-started/setup-prisma/add-to-existing-project/mongodb/install-prisma-client-typescript-mongodb
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/mongodb/introspection-
+---
+
+# Introspection
+
+Prisma ORM introspects a MongoDB schema by sampling the data stored in the given database and inferring the schema of that data.
+
+For the purposes of illustrating introspection, this guide will help you setup a MongoDB from scratch. But if you have a MongoDB database already, feel free to jump to [Initializing Prisma ORM](#initializing-prisma-orm) in your project.
+
+## Setting up your Database
+
+To see this in action, first create a `blog` database with 2 collections: `User` and `Post`. We recommend [MongoDB Compass](https://www.mongodb.com/products/tools/compass) for setting this up:
+
+
+
+First, add a user to our `User` collection:
+
+
+
+Next, add some posts to our `Post` collection. It's important that the ObjectID in `userId` matches the user you created above.
+
+
+
+## Initializing Prisma ORM
+
+Now that you have a MongoDB database, the next step is to create a new project and initialize Prisma ORM:
+
+```terminal copy
+mkdir blog
+cd blog
+npm init -y
+npm install -D prisma
+npx prisma init --datasource-provider mongodb --output ../generated/prisma
+```
+
+Initializing Prisma ORM will create a `prisma/schema.prisma` file. Edit this file to use MongoDB:
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "mongodb"
+ url = env("DATABASE_URL")
+}
+
+generator client {
+ provider = "prisma-client-js"
+}
+```
+
+Next you'll need to adjust your `.env` file to point the `DATABASE_URL` to your MongoDB database
+
+## Introspecting MongoDB with Prisma ORM
+
+You're now ready to introspect. Run the following command to introspect your database:
+
+```terminal copy
+npx prisma db pull
+```
+
+This command introspects our database and writes the inferred schema into your `prisma/schema.prisma` file:
+
+```prisma file=prisma/schema.prisma showLineNumbers
+datasource db {
+ provider = "mongodb"
+ url = env("DATABASE_URL")
+}
+
+generator client {
+ provider = "prisma-client-js"
+}
+
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ title String
+ userId String @db.ObjectId
+}
+
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ email String
+}
+```
+
+## Tweaking the Schema
+
+To be able to join data using Prisma Client, you can add the [`@relation`](/orm/reference/prisma-schema-reference#relation) attributes to our models:
+
+```prisma file=prisma/schema.prisma highlight=14;add|20;add showLineNumbers
+datasource db {
+ provider = "mongodb"
+ url = env("DATABASE_URL")
+}
+
+generator client {
+ provider = "prisma-client-js"
+}
+
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ title String
+ userId String @db.ObjectId
+ //add-next-line
+ user User @relation(fields: [userId], references: [id])
+}
+
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ email String
+ //add-next-line
+ posts Post[]
+}
+```
+
+:::tip
+
+We're actively working on MongoDB introspection. Provide feedback for this feature in [this issue](https://github.com/prisma/prisma/issues/8241).
+
+:::
+
+And with that, you're ready to generate Prisma Client.
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb/200-install-prisma-client-node-mongodb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb/200-install-prisma-client-node-mongodb.mdx
new file mode 100644
index 0000000000..77bfa807a1
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb/200-install-prisma-client-node-mongodb.mdx
@@ -0,0 +1,28 @@
+---
+title: 'Install Prisma Client in your existing JavaScript project (MongoDB)'
+sidebar_label: 'Install Prisma Client'
+metaTitle: 'Install Prisma Client in your existing project: JavaScript and MongoDB'
+metaDescription: 'Install and generate Prisma Client in your existing project using a MongoDB database and Javascript.'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['mongodb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/mongodb/introspection-node-mongodb
+pagination_next: getting-started/setup-prisma/add-to-existing-project/mongodb/querying-the-database-node-mongodb
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/mongodb/install-prisma-client-
+---
+
+## Install and generate Prisma Client
+
+To get started with Prisma Client, you need to install the `@prisma/client` package:
+
+```terminal copy
+npm install @prisma/client
+```
+
+The install command invokes `prisma generate` for you which reads your Prisma schema and generates a version of Prisma Client that is _tailored_ to your models.
+
+
+
+Whenever you make changes to your Prisma schema in the future, you manually need to invoke `prisma generate` in order to accommodate the changes in your Prisma Client API.
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb/200-install-prisma-client-typescript-mongodb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb/200-install-prisma-client-typescript-mongodb.mdx
new file mode 100644
index 0000000000..a7b90e1c75
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb/200-install-prisma-client-typescript-mongodb.mdx
@@ -0,0 +1,26 @@
+---
+title: 'Install Prisma Client in an existing TypeScript project (MongoDB)'
+sidebar_label: 'Install Prisma Client'
+metaTitle: 'Install Prisma Client in your existing project: TypeScript and MongoDB'
+metaDescription: 'Install and generate Prisma Client in your existing project using a MongoDB database and TypeScript.'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['mongodb']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/mongodb/introspection-typescript-mongodb
+pagination_next: getting-started/setup-prisma/add-to-existing-project/mongodb/querying-the-database-typescript-mongodb
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/mongodb/install-prisma-client-
+---
+
+## Install and generate Prisma Client
+
+To get started with Prisma Client, you need to install the `@prisma/client` package:
+
+```terminal copy
+npm install @prisma/client
+```
+
+The install command invokes `prisma generate` for you which reads your Prisma schema and generates a version of Prisma Client that is _tailored_ to your models.
+
+
+
+Whenever you make changes to your Prisma schema in the future, you manually need to invoke `prisma generate` in order to accommodate the changes in your Prisma Client API.
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb/250-querying-the-database-node-mongodb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb/250-querying-the-database-node-mongodb.mdx
new file mode 100644
index 0000000000..e82d311963
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb/250-querying-the-database-node-mongodb.mdx
@@ -0,0 +1,220 @@
+---
+title: 'Query your existing MongoDB database with JavaScript and Prisma ORM'
+sidebar_label: 'Querying the database'
+metaTitle: 'Querying the database in your existing project: MongoDB and JavaScript'
+metaDescription: 'Write data to and query your MongoDB database in your existing project.'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['mongodb']
+hide_table_of_contents: true
+sidebar_class_name: hidden-sidebar
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/mongodb/install-prisma-client-node-mongodb
+pagination_next: getting-started/setup-prisma/add-to-existing-project/mongodb/next-steps
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/mongodb/querying-the-database-
+---
+
+## Write your first query with Prisma Client
+
+Now that you have generated Prisma Client, you can start writing queries to read and write data in your database. For the purpose of this guide, you'll use a plain Node.js script to explore some basic features of Prisma Client.
+
+If you're building a REST API, you can use Prisma Client in your route handlers to read and write data in the database based on incoming HTTP requests. If you're building a GraphQL API, you can use Prisma Client in your resolvers to read and write data in the database based on incoming queries and mutations.
+
+For the purpose of this guide however, you'll just create a plain Node.js script to learn how to send queries to your database using Prisma Client. Once you have an understanding of how the API works, you can start integrating it into your actual application code (e.g. REST route handlers or GraphQL resolvers).
+
+Create a new file named `index.js` and add the following code to it:
+
+```js file=index.js copy
+const { PrismaClient } = require('@prisma/client')
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // ... you will write your Prisma Client queries here
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Here's a quick overview of the different parts of the code snippet:
+
+1. Import the `PrismaClient` constructor from the `@prisma/client` node module
+1. Instantiate `PrismaClient`
+1. Define an `async` function named `main` to send queries to the database
+1. Connect to the database
+1. Call the `main` function
+1. Close the database connections when the script terminates
+
+Inside the `main` function, add the following query to read all `User` records from the database and print the result:
+
+```js file=index.js showLineNumbers
+async function main() {
+- // ... you will write your Prisma Client queries here
+//add-start
++ const allUsers = await prisma.user.findMany()
++ console.log(allUsers)
+//add-end
+}
+```
+
+Now run the code with this command:
+
+```terminal copy
+node index.js
+```
+
+If you introspected an existing database with records, the query should return an array of JavaScript objects.
+
+## Write data into the database
+
+The `findMany` query you used in the previous section only _reads_ data from the database (although it was still empty). In this section, you'll learn how to write a query to _write_ new records into the `Post`, `User` and `Comment` tables.
+
+Adjust the `main` function to send a `create` query to the database:
+
+```js file=index.js copy showLineNumbers
+async function main() {
+ await prisma.user.create({
+ data: {
+ name: 'Rich',
+ email: 'hello@prisma.com',
+ posts: {
+ create: {
+ title: 'My first post',
+ body: 'Lots of really interesting stuff',
+ slug: 'my-first-post',
+ },
+ },
+ },
+ })
+
+ const allUsers = await prisma.user.findMany({
+ include: {
+ posts: true,
+ },
+ })
+ console.dir(allUsers, { depth: null })
+}
+```
+
+This code creates a new `User` record together with a new `Post` using a [nested write](/orm/prisma-client/queries/relation-queries#nested-writes) query. The `User` record is connected to the other one via the `Post.author` ↔ `User.posts` [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) respectively.
+
+Notice that you're passing the [`include`](/orm/prisma-client/queries/select-fields#return-nested-objects-by-selecting-relation-fields) option to `findMany` which tells Prisma Client to include the `posts` relations on the returned `User` objects.
+
+Run the code with this command:
+
+```terminal copy
+node index.js
+```
+
+The output should look similar to this:
+
+```json no-lines
+[
+ {
+ id: '60cc9b0e001e3bfd00a6eddf',
+ email: 'hello@prisma.com',
+ name: 'Rich',
+ posts: [
+ {
+ id: '60cc9bad005059d6007f45dd',
+ slug: 'my-first-post',
+ title: 'My first post',
+ body: 'Lots of really interesting stuff',
+ userId: '60cc9b0e001e3bfd00a6eddf',
+ },
+ ],
+ },
+]
+```
+
+The query added new records to the `User` and the `Post` collections:
+
+
+
+The `id` field in the Prisma schema maps to `_id` in the underlying MongoDB database.
+
+
+
+**User** collection
+
+| **\_id** | **email** | **name** |
+| :------------------------- | :------------------- | :------- |
+| `60cc9b0e001e3bfd00a6eddf` | `"hello@prisma.com"` | `"Rich"` |
+
+**Post** collection
+
+| **\_id** | **createdAt** | **title** | **content** | **published** | **authorId** |
+| :------------------------- | :------------------------- | :---------------- | :--------------------------------- | :------------ | :------------------------- |
+| `60cc9bad005059d6007f45dd` | `2020-03-21T16:45:01.246Z` | `"My first post"` | `Lots of really interesting stuff` | `false` | `60cc9b0e001e3bfd00a6eddf` |
+
+> **Note**: The unique identifier in the `authorId` document field on `Post` reference the `_id` document field in the `User` collection, meaning the `_id` value `60cc9b0e001e3bfd00a6eddf` column therefore refers to the first (and only) `User` record in the database.
+
+Before moving on to the next section, you'll add a couple of comments to the `Post` record you just created using an `update` query. Adjust the `main` function as follows:
+
+```js file=index.js copy
+async function main() {
+ await prisma.post.update({
+ where: {
+ slug: 'my-first-post',
+ },
+ data: {
+ comments: {
+ createMany: {
+ data: [
+ { comment: 'Great post!' },
+ { comment: "Can't wait to read more!" },
+ ],
+ },
+ },
+ },
+ })
+ const posts = await prisma.post.findMany({
+ include: {
+ comments: true,
+ },
+ })
+
+ console.dir(posts, { depth: Infinity })
+}
+```
+
+Now run the code using the same command as before:
+
+```terminal copy
+node index.js
+```
+
+You will see the following output:
+
+```json no-lines
+[
+ {
+ id: '60cc9bad005059d6007f45dd',
+ slug: 'my-first-post',
+ title: 'My first post',
+ body: 'Lots of really interesting stuff',
+ userId: '60cc9b0e001e3bfd00a6eddf',
+ comments: [
+ {
+ id: '60cca420008a21d800578793',
+ postId: '60cca40300af8bf000f6ca99',
+ comment: 'Great post!',
+ },
+ {
+ id: '60cca420008a21d800578794',
+ postId: '60cca40300af8bf000f6ca99',
+ comment: "Can't wait to try this!",
+ },
+ ],
+ },
+]
+```
+
+Fantastic, you just wrote new data into your database for the first time using Prisma Client 🚀
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb/250-querying-the-database-typescript-mongodb.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb/250-querying-the-database-typescript-mongodb.mdx
new file mode 100644
index 0000000000..08f3d9ec9a
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb/250-querying-the-database-typescript-mongodb.mdx
@@ -0,0 +1,234 @@
+---
+title: 'Query your existing MongoDB database with TypeScript and Prisma ORM'
+sidebar_label: 'Querying the database'
+metaTitle: 'Querying the database in your existing project: MongoDB and TypeScript'
+metaDescription: 'Write data to and query your MongoDB database'
+langSwitcher: ['typescript', 'node']
+dbSwitcher: ['mongodb']
+hide_table_of_contents: true
+pagination_prev: getting-started/setup-prisma/add-to-existing-project/mongodb/install-prisma-client-typescript-mongodb
+pagination_next: getting-started/setup-prisma/add-to-existing-project/mongodb/next-steps
+slugSwitch: /getting-started/setup-prisma/add-to-existing-project/mongodb/querying-the-database-
+---
+
+## Write your first query with Prisma Client
+
+Now that you have generated Prisma Client, you can start writing queries to read and write data in your database. For the purpose of this guide, you'll use a plain Node.js script to explore some basic features of Prisma Client.
+
+If you're building a REST API, you can use Prisma Client in your route handlers to read and write data in the database based on incoming HTTP requests. If you're building a GraphQL API, you can use Prisma Client in your resolvers to read and write data in the database based on incoming queries and mutations.
+
+For the purpose of this guide however, you'll just create a plain Node.js script to learn how to send queries to your database using Prisma Client. Once you have an understanding of how the API works, you can start integrating it into your actual application code (e.g. REST route handlers or GraphQL resolvers).
+
+Create a new file named `index.ts` and add the following code to it:
+
+```js file=index.ts copy
+import { PrismaClient } from './generated/prisma'
+
+const prisma = new PrismaClient()
+
+async function main() {
+ // ... you will write your Prisma Client queries here
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Here's a quick overview of the different parts of the code snippet:
+
+1. Import the `PrismaClient` constructor from the `@prisma/client` node module
+1. Instantiate `PrismaClient`
+1. Define an `async` function named `main` to send queries to the database
+1. Connect to the database
+1. Call the `main` function
+1. Close the database connections when the script terminates
+
+Inside the `main` function, add the following query to read all `User` records from the database and print the result:
+
+```ts file=index.ts showLineNumbers
+async function main() {
+ // ... you will write your Prisma Client queries here
+//add-start
++ const allUsers = await prisma.user.findMany()
++ console.log(allUsers)
+//add-end
+}
+```
+
+Now run the code with this command:
+
+```terminal copy
+npx tsx index.ts
+```
+
+If you introspected an existing database with records, the query should return an array of JavaScript objects.
+
+## Write data into the database
+
+The `findMany` query you used in the previous section only _reads_ data from the database (although it was still empty). In this section, you'll learn how to write a query to _write_ new records into the `Post`, `User` and `Comment` tables.
+
+Adjust the `main` function to send a `create` query to the database:
+
+```ts file=index.ts copy showLineNumbers
+async function main() {
+ await prisma.user.create({
+ data: {
+ name: 'Rich',
+ email: 'hello@prisma.com',
+ posts: {
+ create: {
+ title: 'My first post',
+ body: 'Lots of really interesting stuff',
+ slug: 'my-first-post',
+ },
+ },
+ },
+ })
+
+ const allUsers = await prisma.user.findMany({
+ include: {
+ posts: true,
+ },
+ })
+ console.dir(allUsers, { depth: null })
+}
+```
+
+This code creates a new `User` record together with a new `Post` using a [nested write](/orm/prisma-client/queries/relation-queries#nested-writes) query. The `User` record is connected to the other one via the `Post.author` ↔ `User.posts` [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) respectively.
+
+Notice that you're passing the [`include`](/orm/prisma-client/queries/select-fields#return-nested-objects-by-selecting-relation-fields) option to `findMany` which tells Prisma Client to include the `posts` relations on the returned `User` objects.
+
+Run the code with this command:
+
+```terminal copy
+npx tsx index.ts
+```
+
+The output should look similar to this:
+
+```json no-lines
+[
+ {
+ id: '60cc9b0e001e3bfd00a6eddf',
+ email: 'hello@prisma.com',
+ name: 'Rich',
+ posts: [
+ {
+ id: '60cc9bad005059d6007f45dd',
+ slug: 'my-first-post',
+ title: 'My first post',
+ body: 'Lots of really interesting stuff',
+ userId: '60cc9b0e001e3bfd00a6eddf',
+ },
+ ],
+ },
+]
+```
+
+Also note that `allUsers` is _statically typed_ thanks to [Prisma Client's generated types](/orm/prisma-client/type-safety/operating-against-partial-structures-of-model-types). You can observe the type by hovering over the `allUsers` variable in your editor. It should be typed as follows:
+
+```ts no-lines showLineNumbers
+const allUsers: (User & {
+ posts: Post[]
+})[]
+
+export type Post = {
+ id: number
+ title: string
+ body: string | null
+ published: boolean
+ authorId: number | null
+}
+```
+
+The query added new records to the `User` and the `Post` collections:
+
+
+
+The `id` field in the Prisma schema maps to `_id` in the underlying MongoDB database.
+
+
+
+**User** collection
+
+| **\_id** | **email** | **name** |
+| :------------------------- | :------------------- | :------- |
+| `60cc9b0e001e3bfd00a6eddf` | `"hello@prisma.com"` | `"Rich"` |
+
+**Post** collection
+
+| **\_id** | **createdAt** | **title** | **content** | **published** | **authorId** |
+| :------------------------- | :------------------------- | :---------------- | :--------------------------------- | :------------ | :------------------------- |
+| `60cc9bad005059d6007f45dd` | `2020-03-21T16:45:01.246Z` | `"My first post"` | `Lots of really interesting stuff` | `false` | `60cc9b0e001e3bfd00a6eddf` |
+
+> **Note**: The unique identifier in the `authorId` document field on `Post` reference the `_id` document field in the `User` collection, meaning the `_id` value `60cc9b0e001e3bfd00a6eddf` column therefore refers to the first (and only) `User` record in the database.
+
+Before moving on to the next section, you'll add a couple of comments to the `Post` record you just created using an `update` query. Adjust the `main` function as follows:
+
+```ts file=index.ts copy showLineNumbers
+async function main() {
+ await prisma.post.update({
+ where: {
+ slug: 'my-first-post',
+ },
+ data: {
+ comments: {
+ createMany: {
+ data: [
+ { comment: 'Great post!' },
+ { comment: "Can't wait to read more!" },
+ ],
+ },
+ },
+ },
+ })
+ const posts = await prisma.post.findMany({
+ include: {
+ comments: true,
+ },
+ })
+
+ console.dir(posts, { depth: Infinity })
+}
+```
+
+Now run the code using the same command as before:
+
+```terminal copy
+npx tsx index.ts
+```
+
+You will see the following output:
+
+```json no-lines
+[
+ {
+ id: '60cc9bad005059d6007f45dd',
+ slug: 'my-first-post',
+ title: 'My first post',
+ body: 'Lots of really interesting stuff',
+ userId: '60cc9b0e001e3bfd00a6eddf',
+ comments: [
+ {
+ id: '60cca420008a21d800578793',
+ postId: '60cca40300af8bf000f6ca99',
+ comment: 'Great post!',
+ },
+ {
+ id: '60cca420008a21d800578794',
+ postId: '60cca40300af8bf000f6ca99',
+ comment: "Can't wait to try this!",
+ },
+ ],
+ },
+]
+```
+
+Fantastic, you just wrote new data into your database for the first time using Prisma Client 🚀
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb/300-next-steps.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb/300-next-steps.mdx
new file mode 100644
index 0000000000..a088fcdf0f
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/120-mongodb/300-next-steps.mdx
@@ -0,0 +1,94 @@
+---
+title: 'Next steps after adding Prisma ORM to an existing project using MongoDB'
+sidebar_label: 'Next steps'
+metaTitle: 'Next steps after adding Prisma ORM to an existing project using MongoDB'
+metaDescription: 'Next steps to take now that you have successfully added Prisma ORM to your existing Node.js or TypeScript project.'
+hide_table_of_contents: true
+---
+
+This section lists a number of potential next steps you can now take from here. Feel free to explore these or read the [Introduction](/orm/overview/introduction/what-is-prisma) page to get a high-level overview of Prisma ORM.
+
+### Continue exploring the Prisma Client API
+
+You can send a variety of queries with the Prisma Client API. Check out the [API reference](/orm/prisma-client) and use your existing database setup from this guide to try them out.
+
+:::tip
+
+You can use your editor's auto-completion feature to learn about the different API calls and the arguments it takes. Auto-completion is commonly invoked by hitting CTRL+SPACE on your keyboard.
+
+:::
+
+
+Expand for more Prisma Client API examples
+
+Here are a few suggestions for a number of more queries you can send with Prisma Client:
+
+**Filter all `Post` records that contain `"hello"`**
+
+```js
+const filteredPosts = await prisma.post.findMany({
+ where: {
+ OR: [{ title: { contains: 'hello' } }, { body: { contains: 'hello' } }],
+ },
+})
+```
+
+**Create a new `Post` record and connect it to an existing `User` record**
+
+```js
+const post = await prisma.post.create({
+ data: {
+ title: 'Join us for Prisma Day 2020',
+ slug: 'prisma-day-2020',
+ body: 'A conference on modern application development and databases.',
+ user: {
+ connect: { email: 'hello@prisma.com' },
+ },
+ },
+})
+```
+
+**Use the fluent relations API to retrieve the `Post` records of a `User` by traversing the relations**
+
+```js
+const user = await prisma.comment
+ .findUnique({
+ where: { id: '60ff4e9500acc65700ebf470' },
+ })
+ .post()
+ .user()
+```
+
+**Delete a `User` record**
+
+```js
+const deletedUser = await prisma.user.delete({
+ where: { email: 'sarah@prisma.io' },
+})
+```
+
+
+
+### Build an app with Prisma ORM
+
+The Prisma blog features comprehensive tutorials about Prisma ORM, check out our latest ones:
+
+- [Build a fullstack app with Next.js](https://www.youtube.com/watch?v=QXxy8Uv1LnQ&ab_channel=ByteGrad)
+- [Build a fullstack app with Remix](https://www.prisma.io/blog/fullstack-remix-prisma-mongodb-1-7D0BfTXBmB6r) (5 parts, including videos)
+- [Build a REST API with NestJS](https://www.prisma.io/blog/nestjs-prisma-rest-api-7D056s1BmOL0)
+
+### Explore the data in Prisma Studio
+
+Prisma Studio is a visual editor for the data in your database. Run `npx prisma studio` in your terminal.
+
+### Try a Prisma ORM example
+
+The [`prisma-examples`](https://github.com/prisma/prisma-examples/) repository contains a number of ready-to-run examples:
+
+| Demo | Stack | Description |
+| :------------------------------------------------------------------------------------------------------------------ | :----------- | --------------------------------------------------------------------------------------------------- |
+| [`nextjs`](https://pris.ly/e/orm/nextjs) | Fullstack | Simple [Next.js](https://nextjs.org/) app |
+| [`nextjs-graphql`](https://pris.ly/e/ts/graphql-nextjs) | Fullstack | Simple [Next.js](https://nextjs.org/) app (React) with a GraphQL API |
+| [`graphql-nexus`](https://pris.ly/e/ts/graphql-nexus) | Backend only | GraphQL server based on [`@apollo/server`](https://www.apollographql.com/docs/apollo-server) |
+| [`express`](https://pris.ly/e/ts/rest-express) | Backend only | Simple REST API with Express.JS |
+| [`grpc`](https://pris.ly/e/ts/grpc) | Backend only | Simple gRPC API |
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/_prisma-init-partial.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/_prisma-init-partial.mdx
new file mode 100644
index 0000000000..4fdfa6d8f3
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/_prisma-init-partial.mdx
@@ -0,0 +1,33 @@
+import CodeBlock from '@theme/CodeBlock';
+
+You can now invoke the Prisma CLI by prefixing it with `npx`:
+
+```terminal
+npx prisma
+```
+
+:::info
+
+See [installation instructions](/orm/tools/prisma-cli#installation) to learn how to install Prisma ORM using a different package manager.
+
+:::
+
+Next, set up your Prisma ORM project by creating your [Prisma Schema](/orm/prisma-schema) file with the following command:
+
+{`npx prisma init --datasource-provider ${props.datasource.toLowerCase()} --output ../generated/prisma`}
+
+This command does a few things:
+
+- Creates a new directory called `prisma` that contains a file called `schema.prisma`, which contains the Prisma Schema with your database connection variable and schema models.
+- Sets the `datasource` to {props.datasource} and the output to a custom location, respectively.
+- Creates the [`.env` file](/orm/more/development-environment/environment-variables) in the root directory of the project, which is used for defining environment variables (such as your database connection)
+
+Note that the default schema created by `prisma init` uses PostgreSQL as the `provider`. If you didn't specify a provider with the `datasource-provider` option, you need to edit the `datasource` block to use the {props.datasource.toLowerCase()} provider instead:
+
+
+{`datasource db {
+ //edit-next-line
+ provider = "${props.datasource.toLowerCase()}"
+ url = env("DATABASE_URL")
+}`}
+
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/index.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/index.mdx
new file mode 100644
index 0000000000..142fedb80d
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/200-add-to-existing-project/index.mdx
@@ -0,0 +1,16 @@
+---
+title: 'Add to existing project'
+metaTitle: 'Add Prisma ORM to an existing project'
+metaDescription: 'Learn how to add Prisma ORM to an existing Node.js or TypeScript project by connecting it to your database of choice and generating a Prisma Client for database access.'
+hide_table_of_contents: true
+---
+
+
+
+Include Prisma ORM in an existing project with the following documentation, which explains some core concepts as it guides you through integrating Prisma ORM into your workflow.
+
+
+
+## In this section
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/index.mdx b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/index.mdx
new file mode 100644
index 0000000000..3532293fe7
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/02-setup-prisma/index.mdx
@@ -0,0 +1,13 @@
+---
+title: 'Set up Prisma ORM'
+metaTitle: 'Set up Prisma ORM'
+metaDescription: 'Get started with Prisma ORM and your favorite database. Learn about data modeling, migrations and querying.'
+hide_table_of_contents: true
+staticLink: true
+---
+
+Start from scratch or add Prisma ORM to an existing project. The following tutorials introduce you to the [Prisma CLI](/orm/tools/prisma-cli), [Prisma Client](/orm/prisma-client), and [Prisma Migrate](/orm/prisma-migrate).
+
+## In this section
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/03-prisma-postgres/100-from-the-cli.mdx b/versioned_docs/version-6.0.0/100-getting-started/03-prisma-postgres/100-from-the-cli.mdx
new file mode 100644
index 0000000000..49fad38bf8
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/03-prisma-postgres/100-from-the-cli.mdx
@@ -0,0 +1,472 @@
+---
+title: 'From the CLI'
+metaTitle: 'From the CLI'
+metaDescription: 'Start building a Prisma application with a Prisma Postgres database from the CLI'
+staticLink: true
+tocDepth: 3
+toc: true
+community_section: true
+---
+
+This page provides a step-by-step guide for Prisma Postgres after setting it up with `prisma init --db`:
+
+1. Set up a TypeScript app with Prisma ORM
+1. Migrate the schema of your database
+1. Query your database from TypeScript
+
+## Prerequisites
+
+This guide assumes you set up [Prisma Postgres](/postgres) instance with `prisma init --db`:
+
+
+
+
+
+```terminal
+npx prisma@latest init --db
+```
+
+
+
+
+
+```code no-copy wrap
+Success! Your Prisma Postgres database is ready ✅
+
+We created an initial schema.prisma file and a .env file with your DATABASE_URL environment variable already set.
+
+--- Next steps ---
+
+Go to https://pris.ly/ppg-init for detailed instructions.
+
+1. Define your database schema
+Open the schema.prisma file and define your first models. Check the docs if you need inspiration: https://pris.ly/ppg-init
+
+2. Apply migrations
+Run the following command to create and apply a migration:
+npx prisma migrate dev --name init
+
+3. Manage your data
+View and edit your data locally by running this command:
+npx prisma studio
+
+... or online in Console:
+https://console.prisma.io/cliwxim5p005xqh0g3mvqpyak/cm6kw97t801ijzhvfwz4a0my3/cm6kw97ta01ikzhvf965vresv/studio
+
+4. Send queries from your app
+To access your database from a JavaScript/TypeScript app, you need to use Prisma ORM. Go here for step-by-step instructions: https://pris.ly/ppg-init
+```
+
+
+
+
+
+Once this command terminated:
+
+- You're logged into Prisma Data Platform.
+- A new Prisma Postgres instance was created.
+- The `prisma/` folder was created with an empty `schema.prisma` file.
+- The `DATABASE_URL` env var was set in a `.env` file.
+
+## 1. Organize your project directory
+
+:::note
+
+If you ran the `prisma init --db` command inside a folder where you want your project to live, you can skip this step and [proceed to the next section](/getting-started/prisma-postgres/from-the-cli#2-set-up-your-project).
+
+:::
+
+If you ran the command outside your intended project directory (e.g., in your home folder or another location), you need to move the generated `prisma` folder and the `.env` file into a dedicated project directory.
+
+Create a new folder (e.g. `hello-prisma`) where you want your project to live and move the necessary files into it:
+
+```terminal
+mkdir hello-prisma
+mv .env ./hello-prisma/
+mv prisma ./hello-prisma/
+```
+
+Navigate into your project folder:
+
+```terminal
+cd ./hello-prisma
+```
+
+Now that your project is in the correct location, continue with the setup.
+
+## 2. Set up your project
+
+### 2.1. Set up TypeScript
+
+Initialize a TypeScript project and add the Prisma CLI as a development dependency:
+
+```terminal
+npm init -y
+npm install typescript tsx @types/node --save-dev
+```
+
+This creates a `package.json` file with an initial setup for your TypeScript app.
+
+Next, initialize TypeScript with a `tsconfig.json` file in the project:
+
+```terminal
+npx tsc --init
+```
+
+### 2.2. Set up Prisma ORM
+
+Install the required dependencies to use Prisma Postgres:
+
+```terminal
+npm install prisma --save-dev
+npm install @prisma/extension-accelerate
+```
+
+### 2.3. Create a TypeScript script
+
+Create an `index.ts` file in the root directory, this will be used to query your application with Prisma ORM:
+
+```terminal
+touch index.ts
+```
+
+## 3. Migrate the database schema
+
+Update your `prisma/schema.prisma` file to include a simple `User` model:
+
+```prisma file=prisma/schema.prisma
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ posts Post[]
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ content String?
+ published Boolean @default(false)
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+}
+```
+
+After adding the models, migrate your database using [Prisma Migrate](/orm/prisma-migrate):
+
+```terminal
+npx prisma migrate dev --name init
+```
+
+## 4. Send queries with Prisma ORM
+
+Paste the following boilerplate into `index.ts`:
+
+```ts file=index.ts
+import { PrismaClient } from './generated/prisma'
+import { withAccelerate } from '@prisma/extension-accelerate'
+
+const prisma = new PrismaClient().$extends(withAccelerate())
+
+async function main() {
+ // ... you will write your Prisma ORM queries here
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+This code contains a `main` function that's invoked at the end of the script. It also instantiates `PrismaClient` which you'll use to send queries to your database.
+
+### 4.1. Create a new `User` record
+
+Let's start with a small query to create a new `User` record in the database and log the resulting object to the console. Add the following code to your `index.ts` file:
+
+```ts file=index.ts
+import { PrismaClient } from './generated/prisma'
+import { withAccelerate } from '@prisma/extension-accelerate'
+
+const prisma = new PrismaClient().$extends(withAccelerate())
+
+async function main() {
+ // add-start
+ const user = await prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ },
+ })
+ console.log(user)
+ // add-end
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Next, execute the script with the following command:
+
+
+
+
+
+```terminal
+npx tsx index.ts
+```
+
+
+
+
+```code no-copy
+{ id: 1, email: 'alice@prisma.io', name: 'Alice' }
+```
+
+
+
+
+
+Great job, you just created your first database record with Prisma Postgres! 🎉
+
+### 4.2. Retrieve all `User` records
+
+Prisma ORM offers various queries to read data from your database. In this section, you'll use the `findMany` query that returns _all_ the records in the database for a given model.
+
+Delete the previous Prisma ORM query and add the new `findMany` query instead:
+
+```ts file=index.ts
+import { PrismaClient } from './generated/prisma'
+import { withAccelerate } from '@prisma/extension-accelerate'
+
+const prisma = new PrismaClient().$extends(withAccelerate())
+
+async function main() {
+ // add-start
+ const users = await prisma.user.findMany()
+ console.log(users)
+ // add-end
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Execute the script again:
+
+
+
+
+
+```terminal
+npx tsx index.ts
+```
+
+
+
+
+
+```code no-copy
+[{ id: 1, email: 'alice@prisma.io', name: 'Alice' }]
+```
+
+
+
+
+
+Notice how the single `User` object is now enclosed with square brackets in the console. That's because the `findMany` returned an array with a single object inside.
+
+### 4.3. Explore relation queries
+
+One of the main features of Prisma ORM is the ease of working with [relations](/orm/prisma-schema/data-model/relations). In this section, you'll learn how to create a `User` and a `Post` record in a nested write query. Afterwards, you'll see how you can retrieve the relation from the database using the `include` option.
+
+First, adjust your script to include the nested query:
+
+```ts file=index.ts
+import { PrismaClient } from './generated/prisma'
+import { withAccelerate } from '@prisma/extension-accelerate'
+
+const prisma = new PrismaClient().$extends(withAccelerate())
+
+async function main() {
+ // add-start
+ const user = await prisma.user.create({
+ data: {
+ name: 'Bob',
+ email: 'bob@prisma.io',
+ posts: {
+ create: [
+ {
+ title: 'Hello World',
+ published: true
+ },
+ {
+ title: 'My second post',
+ content: 'This is still a draft'
+ }
+ ],
+ },
+ },
+ })
+ console.log(user)
+ // add-end
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Run the query by executing the script again:
+
+
+
+
+
+```terminal
+npx tsx index.ts
+```
+
+
+
+
+
+```code no-copy
+{ id: 2, email: 'bob@prisma.io', name: 'Bob' }
+```
+
+
+
+
+
+In order to also retrieve the `Post` records that belong to a `User`, you can use the `include` option via the `posts` relation field:
+
+```ts file=index.ts
+import { PrismaClient } from './generated/prisma'
+import { withAccelerate } from '@prisma/extension-accelerate'
+
+const prisma = new PrismaClient().$extends(withAccelerate())
+
+async function main() {
+// add-start
+ const usersWithPosts = await prisma.user.findMany({
+ include: {
+ posts: true,
+ },
+ })
+ console.dir(usersWithPosts, { depth: null })
+ // add-end
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+Run the script again to see the results of the nested read query:
+
+
+
+
+
+```terminal
+npx tsx index.ts
+```
+
+
+
+
+
+```code no-copy
+[
+ { id: 1, email: 'alice@prisma.io', name: 'Alice', posts: [] },
+ {
+ id: 2,
+ email: 'bob@prisma.io',
+ name: 'Bob',
+ posts: [
+ {
+ id: 1,
+ title: 'Hello World',
+ content: null,
+ published: true,
+ authorId: 2
+ },
+ {
+ id: 2,
+ title: 'My second post',
+ content: 'This is still a draft',
+ published: false,
+ authorId: 2
+ }
+ ]
+ }
+]
+```
+
+
+
+
+
+This time, you're seeing two `User` objects being printed. Both of them have a `posts` field (which is empty for `"Alice"` and populated with two `Post` objects for `"Bob"`) that represents the `Post` records associated with them.
+
+
+## Next steps
+
+You just got your feet wet with a basic Prisma Postgres setup. If you want to explore more complex queries, such as adding caching functionality, check out the official [Quickstart](/getting-started/quickstart-prismaPostgres).
+
+### View and edit data in Prisma Studio
+
+Prisma ORM comes with a built-in GUI to view and edit the data in your database. You can open it using the following command:
+
+```terminal
+npx prisma studio
+```
+
+With Prisma Postgres, you can also directly use Prisma Studio inside the [Console](https://console.prisma.io) by selecting the **Studio** tab in your project.
+
+
+### Build a fullstack app with Next.js
+
+Learn how to use Prisma Postgres in a fullstack app:
+
+- [Build a fullstack app with Next.js 15](/guides/nextjs)
+- [Next.js 15 example app](https://github.com/prisma/nextjs-prisma-postgres-demo) (including authentication)
+
+
+### Explore ready-to-run examples
+
+Check out the [`prisma-examples`](https://github.com/prisma/prisma-examples/) repository on GitHub to see how Prisma ORM can be used with your favorite library. The repo contains examples with Express, NestJS, GraphQL as well as fullstack examples with Next.js and Vue.js, and a lot more.
+
+These examples use SQLite by default but you can follow the instructions in the project README to switch to Prisma Postgres in a few simple steps.
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/100-getting-started/03-prisma-postgres/110-import-from-existing-database-postgresql.mdx b/versioned_docs/version-6.0.0/100-getting-started/03-prisma-postgres/110-import-from-existing-database-postgresql.mdx
new file mode 100644
index 0000000000..310401625f
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/03-prisma-postgres/110-import-from-existing-database-postgresql.mdx
@@ -0,0 +1,225 @@
+---
+title: 'Import data from an existing database'
+sidebar_label: 'Import from existing database'
+metaTitle: 'Import from existing Postgres database into Prisma Postgres'
+metaDescription: 'Learn how to import data from an existing database into Prisma Postgres.'
+tocDepth: 3
+toc: true
+search: true
+dbSwitcher: [ "mysql", "postgresql"]
+slugSwitch: /getting-started/prisma-postgres/import-from-existing-database-
+---
+
+This guide provides step-by-step instructions for importing data from an existing PostgreSQL database into Prisma Postgres.
+
+You can accomplish this migration in three steps:
+
+1. Create a new Prisma Postgres database.
+1. Export your existing data via `pg_dump`.
+1. Import the previously exported data into Prisma Postgres via `pg_restore`.
+
+In the third step, you will be using a [direct connection](/postgres/database/direct-connections) to securely connect to your Prisma Postgres database during to run `pg_restore`.
+
+## Prerequisites
+
+- The connection URL to your existing PostgreSQL database
+- A [Prisma Data Platform](https://console.prisma.io) account
+- Node.js 18+ installed
+- PostgreSQL CLI Tools (`pg_dump`, `pg_restore`) for creating and restoring backups
+
+## 1. Create a new Prisma Postgres database
+
+Follow these steps to create a new Prisma Postgres database:
+
+1. Log in to [Prisma Data Platform](https://console.prisma.io/) and open the Console.
+1. In a [workspace](/platform/about#workspace) of your choice, click the **New project** button.
+1. Type a name for your project in the **Name** field, e.g. **hello-ppg**.
+1. In the **Prisma Postgres** section, click the **Get started** button.
+1. In the **Region** dropdown, select the region that's closest to your current location, e.g. **US East (N. Virginia)**.
+1. Click the **Create project** button.
+
+With your Prisma Postgres instance being created, you can move to the next step.
+
+## 2. Export data from your existing database
+
+In this step, you're going to export the data from your existing database and store it in a `.bak` file on your local machine.
+
+Make sure to have the connection URL for your existing database ready, it should be [structured](/orm/overview/databases/postgresql#connection-url) like this:
+
+```no-copy
+postgresql://USER:PASSWORD@HOST:PORT/DATABASE
+```
+
+Expand below for provider-specific instructions that help you determine the right connection string:
+
+
+Neon
+
+
+
+- Make sure to select non-pooled connection string by switching off the **Connection pooling** toggle.
+- The `sslmode` has to be set to `require` and appended to your Neon database url for the command to work.
+- The connection URL should look similar to this:
+ ```no-copy
+ postgresql://USER:PASSWORD@YOUR-NEON-HOST/DATABASE?sslmode=require
+ ```
+
+
+
+
+Supabase
+
+- Use a database connection URL that uses [Supavisor session mode](https://supabase.com/docs/guides/database/connecting-to-postgres#supavisor-session-mode).
+- The connection URL should look similar to this:
+ ```no-copy
+ postgres://postgres.apbkobhfnmcqqzqeeqss:[YOUR-PASSWORD]@aws-0-ca-central-1.pooler.supabase.com:5432/postgres
+ ```
+
+
+
+Next, run the following command to export the data of your PostgreSQL database (replace the `__DATABASE_URL__` placeholder with your actual database connection URL):
+
+```terminal
+pg_dump \
+ -Fc \
+ -v \
+ -d __DATABASE_URL__ \
+ -n public \
+ -f db_dump.bak
+```
+
+Here's a quick overview of the CLI options that were used for this command:
+
+- `-Fc`: Uses the custom format for backups, recommended for `pg_restore`
+- `-v`: Runs `pg_dump` in verbose mode
+- `-d`: Specifies the database connection string
+- `-n`: Specifies the target PostgreSQL schema
+- `-f`: Specifies the output name for the backup file
+
+Running this command will create a backup file named `db_dump.bak` which you will use to restore the data into your Prisma Postgres database in the next step.
+
+## 3. Import data into Prisma Postgres
+
+In this section, you'll use a [TCP Tunnel](/postgres/database/direct-connections#tcp-tunnel) in order to connect to your Prisma Postgres instance and import data via `pg_restore`.
+
+### 3.1. Connecting to the Prisma Postgres Database with `@prisma/ppg-tunnel`
+
+Open a new terminal and set the environment variable for your Prisma Postgres database connection URL.
+
+```bash
+export DATABASE_URL="prisma+postgres://accelerate.prisma-data.net/?api_key=eyJhbGciOiJIUzI..."
+```
+
+Run the tunnel:
+```bash
+npx @prisma/ppg-tunnel --host 127.0.0.1 --port 5432
+```
+
+You should see output similar to:
+
+```cmd
+Prisma Postgres auth proxy listening on 127.0.0.1:52604 🚀
+
+Your connection is authenticated using your Prisma Postgres API key.
+...
+
+==============================
+hostname: 127.0.0.1
+port: 52604
+username:
+password:
+==============================
+```
+
+
+:::note
+Keep this tunnel process running to maintain the connection!
+:::
+
+### 3.2. Restoring the Backup with `pg_restore`
+
+Use the backup file from **Step 2** to restore data into Prisma Postgres database with `pg_restore` by running this command:
+
+```bash
+PGSSLMODE=disable \
+pg_restore \
+ -h 127.0.0.1 \
+ -p 5432 \
+ -v \
+ -d postgres \
+ ./db_dump.bak \
+&& echo "-complete-"
+```
+
+Once the command completes execution, you will have successfully imported the data from your existing PostgreSQL database into Prisma Postgres 🎉
+
+To validate that the import worked, you can use [Prisma Studio](/postgres/integrations/viewing-data#viewing-and-editing-data-in-prisma-studio). Either open it in the [Platform Console](https://console.prisma.io) by clicking the **Studio** tab in the left-hand sidenav in your project or run this command to launch Prisma Studio locally:
+
+```terminal
+npx prisma studio
+```
+
+## 4. Update your application code to query Prisma Postgres
+
+### Scenario A: You are already using Prisma ORM
+
+If you already using Prisma ORM, the only things you need to do are:
+
+- add the Prisma Accelerate extension to your project
+- update the database connection URL and re-generate Prisma Client
+
+#### 4.A.1. Add the Prisma Accelerate extension
+
+Th Prisma Accelerate extension is [required](/postgres/introduction/overview#using-the-client-extension-for-prisma-accelerate-required) when using Prisma Postgres. If you are not currently using Prisma Accelerate with Prisma ORM, go through the following steps to make Prisma ORM work with Prisma Postgres.
+
+First, install the `@prisma/extension-accelerate` package in your project:
+
+```terminal
+npm install @prisma/extension-accelerate
+```
+
+Then, add the extension to your Prisma Client instance:
+
+```ts
+import { withAccelerate } from '@prisma/extension-accelerate'
+
+const prisma = new PrismaClient().$extends(withAccelerate())
+```
+
+#### 4.A.2. Update the database connection URL
+
+The database connection URL is configured via the `url` of the `datasource` block in your `schema.prisma` file. Most commonly, it is set via an environment variable called `DATABASE_URL`:
+
+```prisma file=schema.prisma
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+```
+
+The next steps assumes that you're a `.env` file to set the `DATABASE_URL` environment variable (if that's not the case, you can set the environment variable in your preferred way).
+
+Open `.env` and update the value for the `DATABASE_URL` environment variable to match your Prisma Postgres connection URL, looking similar to this:
+
+```bash
+DATABASE_URL="prisma+postgres://accelerate.prisma-data.net/?api_key=__API_KEY__"
+```
+
+As a last step, you need to re-generate Prisma Client for so that the updated environment variables takes effect and your queries go to Prisma Postgres going forward:
+
+```
+npx prisma generate --no-engine
+```
+
+Once this is done, you can run your application and it should work as before.
+
+### Scenario B: You are not yet using Prisma ORM
+
+If you are not yet using Prisma ORM, you'll need to go through the following steps to use Prisma Postgres from your application:
+
+1. Install the Prisma CLI in your project
+1. Introspect the database to generate a Prisma schema
+1. Generate Prisma Client
+1. Update the queries in your application to use Prisma ORM
+
+You can find the detailed step-by-step instructions for this process in this guide: [Add Prisma ORM to an existing project](/getting-started/setup-prisma/add-to-existing-project/relational-databases-typescript-postgresql).
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/100-getting-started/03-prisma-postgres/115-import-from-existing-database-mysql.mdx b/versioned_docs/version-6.0.0/100-getting-started/03-prisma-postgres/115-import-from-existing-database-mysql.mdx
new file mode 100644
index 0000000000..795c4c8634
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/03-prisma-postgres/115-import-from-existing-database-mysql.mdx
@@ -0,0 +1,211 @@
+---
+title: 'Import data from an existing MySQL database'
+sidebar_label: 'Import from existing database'
+metaTitle: 'Import from existing MySQL database into Prisma Postgres'
+metaDescription: 'Learn how to import data from an existing MySQL database into Prisma Postgres.'
+tocDepth: 3
+toc: true
+search: true
+dbSwitcher: ["mysql", "postgresql"]
+slugSwitch: /getting-started/prisma-postgres/import-from-existing-database-
+---
+
+This guide provides step-by-step instructions for importing data from an existing MySQL database into Prisma Postgres.
+
+You can accomplish this migration in four steps:
+
+1. Create a new Prisma Postgres database.
+1. Connect directly to a Prisma Postgres instance using a [direct connection](/postgres/database/direct-connections).
+1. Migrate your MySQL data to Prisma Postgres using [pgloader](https://pgloader.io/).
+1. Configure your Prisma project for Prisma Postgres.
+
+## Prerequisites
+
+- The connection URL to your existing MySQL database.
+- A [Prisma Data Platform](https://console.prisma.io) account.
+- Node.js 18+ installed.
+- [pgloader](https://pgloader.io/) installed.
+
+We recommend attempting this migration in a separate git development branch.
+
+## 1. Create a new Prisma Postgres database
+
+Follow these steps to create a new Prisma Postgres database:
+
+1. Log in to [Prisma Data Platform](https://console.prisma.io/) and open the Console.
+1. In a [workspace](/platform/about#workspace) of your choice, click the **New project** button.
+1. Type a name for your project in the **Name** field, e.g. **hello-ppg**.
+1. In the **Prisma Postgres** section, click the **Get started** button.
+1. In the **Region** dropdown, select the region that's closest to your current location, e.g. **US East (N. Virginia)**.
+1. Click the **Create project** button.
+
+Once your database was provisioned, find your direct Prisma Postgres connection string:
+
+1. Navigate to your active Prisma Postgres instance.
+1. Click the **API Keys** tab in the project's sidenav.
+1. Click the **Create API key** button.
+1. In the popup, provide a **Name** for the API key and click **Create**.
+1. Copy the connection string starting with `postgres://`, this is your direct connection string.
+
+Save the connection string, you'll need it in the next step.
+
+## 2. Connect directly to a Prisma Postgres instance
+
+In this step, you'll use a [direct connection](/postgres/database/direct-connections) to connect to your Prisma Postgres instance.
+
+You'll need the Prisma Postgres connection URL from [step 1](/getting-started/prisma-postgres/import-from-existing-database-mysql#1-create-a-new-prisma-postgres-database):
+
+```no-copy
+prisma+postgres://accelerate.prisma-data.net/?api_key=ey...
+```
+
+
+## 3. Migrate your MySQL data to Prisma Postgres using pgloader
+
+Now that you have an active connection to your Prisma Postgres instance, you'll use [pgloader](https://pgloader.io/) to export data from your MySQL database to Prisma Postgres.
+
+Open a separate terminal window and create a `config.load` file:
+
+```terminal
+touch config.load
+```
+
+Open the `config.load` file in your preferred text editor and copy-paste the following configuration:
+
+```text file=config.load
+LOAD DATABASE
+ FROM mysql://username:password@host:PORT/database_name
+ INTO postgres://__USER__:__PASSWORD__@db.prisma.io:5432/?sslmode=require
+
+WITH quote identifiers, -- preserve table/column name case by quoting them
+ include drop,
+ create tables,
+ create indexes,
+ reset sequences
+
+ALTER SCHEMA 'database_name' RENAME TO 'public';
+```
+
+Make sure to update the following details in the `config.load` file:
+
+- `FROM` url (MySQL database URL):
+ - Replace `username`, `password`, `host`, `PORT`, and `database_name` with the actual connection details for your MySQL database.
+ - Ensure that your connection string includes `useSSL=true` if SSL is required, for example: `mysql://username:password@host:PORT/database_name?useSSL=true`. Note that when using PlanetScale, appending `sslaccept=strict` will not work.
+- `INTO` url (Postgres database URL):
+ - Update this with your direct connection string from above, replacing the `__USER__` and `__PASSWORD__` placeholders.
+- Update the `database_name` in `ALTER SCHEMA 'database_name' RENAME TO 'public';` to exactly match the `database_name` in your MySQL connection string.
+
+After saving the configuration file with your updated credentials, in the same terminal window, execute the following command:
+
+```terminal
+pgloader config.load
+```
+
+You should see a log similar to this, which confirms the successful migration of your data:
+
+```terminal
+LOG report summary reset
+ table name errors rows bytes total time
+------------------------- --------- --------- --------- --------------
+ fetch meta data 0 9 2.546s
+ Create Schemas 0 0 0.325s
+ Create SQL Types 0 0 0.635s
+ Create tables 0 6 5.695s
+ Set Table OIDs 0 3 0.328s
+------------------------- --------- --------- --------- --------------
+ public.post 0 8 0.5 kB 4.255s
+ public."user" 0 4 0.1 kB 2.775s
+public._prisma_migrations 0 1 0.2 kB 4.278s
+------------------------- --------- --------- --------- --------------
+ COPY Threads Completion 0 4 5.095s
+ Index Build Completion 0 5 9.601s
+ Create Indexes 0 5 4.116s
+ Reset Sequences 0 2 4.540s
+ Primary Keys 0 3 2.917s
+ Create Foreign Keys 0 1 1.121s
+ Create Triggers 0 0 0.651s
+ Install Comments 0 0 0.000s
+------------------------- --------- --------- --------- --------------
+ Total import time ✓ 13 0.8 kB 28.042s
+```
+
+If you see output like this, it means your data has been successfully exported to your Prisma Postgres instance.
+
+:::note
+
+You also can use [Prisma Studio](/postgres/integrations/viewing-data#viewing-and-editing-data-in-prisma-studio) and verify whether the migration was successful:
+
+```terminal
+npx prisma studio
+```
+:::
+
+## 4. Configure your Prisma project for Prisma Postgres
+
+After migrating your data, you need to set up your Prisma project to work with Prisma Postgres. The steps differ depending on whether you were already using Prisma ORM.
+
+### If you **were not** previously using Prisma ORM
+
+Initialize Prisma in your project by running `npx prisma init` in your project directory. This creates a `prisma` folder with a `schema.prisma` file and `.env` file (if not already present).
+
+In the generated `.env` file, update `DATABASE_URL` to match your Prisma Postgres connection string that you received in [step 1](/getting-started/prisma-postgres/import-from-existing-database-mysql#1-create-a-new-prisma-postgres-database):
+
+```terminal file=.env no-copy
+DATABASE_URL="prisma+postgres://accelerate.prisma-data.net/?api_key=__API_KEY__"
+```
+
+[Introspect](/orm/prisma-schema/introspection) your newly migrated database by running:
+
+```terminal
+npx prisma db pull
+```
+
+This command updates your `schema.prisma` file with models representing your migrated tables, so you can start using [Prisma Client](/orm/prisma-client) to query your data or [Prisma Migrate](/orm/prisma-migrate/getting-started) to manage future changes.
+
+
+Congratulations! You've successfully migrated your MySQL database to Prisma Postgres and configured your Prisma project. Your migration tutorial is now complete.
+
+:::note
+
+For a comprehensive guide on getting started with Prisma and Prisma Postgres, see [start from scratch with Prisma and Prisma Postgres](/getting-started/setup-prisma/start-from-scratch/relational-databases-typescript-prismaPostgres).
+
+:::
+
+### If you **were** already using Prisma ORM
+
+In your `schema.prisma` file, change the `provider` in the `datasource` block from `mysql` to `postgresql`:
+
+```prisma file=schema.prisma
+datasource db {
+ // delete-start
+ provider = "mysql"
+ // delete-end
+ // add-start
+ provider = "postgres"
+ // add-end
+ url = env("DATABASE_URL")
+}
+```
+
+In the generated `.env` file, update `DATABASE_URL` to match your new Prisma Postgres connection string that you received in [step 1](/getting-started/prisma-postgres/import-from-existing-database-mysql#1-create-a-new-prisma-postgres-database):
+
+```terminal file=.env no-copy
+DATABASE_URL="prisma+postgres://accelerate.prisma-data.net/?api_key=__API_KEY__"
+```
+
+Introspect your newly migrated Prisma Postgres database and generate Prisma Client:
+
+```terminal
+npx prisma db pull
+```
+
+This command refreshes your Prisma models based on the new database schema.
+
+If you were using [Prisma Migrate](/orm/prisma-migrate/getting-started) before:
+
+- Delete your existing `migrations` folder in the `prisma` directory.
+- [Baseline your database](/orm/prisma-migrate/workflows/baselining#baselining-a-database) to begin creating new migrations.
+
+Congratulations! You've successfully migrated your MySQL database to Prisma Postgres and configured your Prisma project. Your migration tutorial is now complete.
+
+If you encounter any issues during the migration, please don't hesitate to reach out to us on [Discord](https://pris.ly/discord?utm_source=docs&utm_medium=conclusion) or via [X](https://pris.ly/x?utm_source=docs&utm_medium=conclusion).
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/100-getting-started/03-prisma-postgres/120-upgrade-from-early-access.mdx b/versioned_docs/version-6.0.0/100-getting-started/03-prisma-postgres/120-upgrade-from-early-access.mdx
new file mode 100644
index 0000000000..a7ef91194e
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/03-prisma-postgres/120-upgrade-from-early-access.mdx
@@ -0,0 +1,257 @@
+---
+title: 'Upgrade from Early Access'
+metaTitle: 'Upgrade Prisma Postgres from Early Access'
+metaDescription: 'Upgrade your Prisma Postgres database from Early Access database to General Availability database.'
+staticLink: true
+tocDepth: 3
+toc: true
+---
+
+This guide shows you how to migrate your Prisma Postgres Early Access (EA) database to the now official Prisma Postgres General Availability (GA) database. Prisma Postgres Early Access was introduced to allow early adopters to test Prisma’s new managed PostgreSQL service. As we move to GA, it's crucial to safely migrate data from your EA database to the new GA database.
+
+Prisma will _not_ automatically migrate your data to ensure its integrity. Instead, this process must be done manually. You can accomplish this in three main steps:
+
+1. Back up your EA database via `pg_dump`.
+2. Create a new GA database.
+3. Import your backup into the GA database via `pg_restore`.
+
+We will be using the [`@prisma/ppg-tunnel`](https://www.npmjs.com/package/@prisma/ppg-tunnel) package to securely connect to both databases. This tool sets up a secure proxy tunnel, eliminating the need for manual credential handling.
+
+You can learn more about **Prisma Postgres** on [this page](/postgres).
+
+## Prerequisites
+
+Before you begin, make sure you have:
+
+- **Node.js** installed (version 16 or higher).
+- **PostgreSQL CLI Tools** (`pg_dump`, `pg_restore`) for creating and restoring backups.
+- A **Database connection string** for your Prisma Postgres database.
+
+To create and restore backups, ensure you have the PostgreSQL command-line tools installed. Run the following commands based on your operating system:
+
+
+
+
+
+```terminal
+brew install postgresql@16
+which pg_dump
+which pg_restore
+```
+
+
+
+
+
+```terminal
+# Download from the official PostgreSQL website:
+# https://www.postgresql.org/download/windows/
+# During installation, select "Command Line Tools".
+# Then verify with:
+
+where pg_dump
+where pg_restore
+```
+
+
+
+
+```terminal
+sudo apt-get update
+sudo apt-get install postgresql-client-16
+which pg_dump
+which pg_restore
+```
+
+
+
+
+
+:::tip
+If you installed PostgreSQL but still see a “command not found” error for pg_dump or pg_restore, ensure your installation directory is in your system’s PATH environment variable.
+:::
+
+:::note
+Please make sure that you are installing Postgresql version 16. Other versions may cause errors during the backup and restore process.
+:::
+
+## Option A: Interactive approach
+
+This approach is recommended if you prefer a guided, one-command solution. In this mode, the `@prisma/ppg-tunnel` CLI:
+
+1. Prompts you for your Early Access (EA) database API key (or `DATABASE_URL`).
+2. Uses `pg_dump` behind the scenes to back up your EA database to a file in the current directory.
+3. Prompts you for your new GA database URL or API Key.
+4. Uses `pg_restore` to import the backup file into your GA database.
+
+Interactive mode does not accept any CLI arguments or read API keys from the environment. You must provide them interactively.
+
+### Steps
+
+1. Open a terminal and run:
+```bash
+npx @prisma/ppg-tunnel migrate-from-ea
+```
+
+2. When prompted, paste your Early Access database key or connection string. The CLI will create a `.bak` file in the current directory.
+
+3. When prompted again, paste your GA database key or connection string. The CLI will automatically restore the .bak file into the new GA database.
+
+4. Once complete, connect with your favorite Database IDE to verify your data in the GA database.
+
+## Option B: Manual backup-and-restore approach
+
+If you prefer or need finer control over the migration process (or to pass environment variables directly), follow these manual steps.
+The migration involves three main parts:
+
+1. Back up your EA database via `pg_dump`.
+2. Create a new GA database.
+3. Import your backup into the GA database via `pg_restore`.
+
+We will still be using the `@prisma/ppg-tunnel` package to securely connect to both databases.
+
+## 1. Back up the EA database
+
+### 1.1. Connecting to the EA database directly with `@prisma/ppg-tunnel`
+
+In your terminal, run `npx @prisma/ppg-tunnel` to establish a secure tunnel to your Early Access database.
+
+If you already have a `.env` file in your current directory with `DATABASE_URL` set, the tunnel CLI will automatically pick it up—no need to manually export it. However, if you haven't set up a `.env` file, you'll need to set the `DATABASE_URL` environment variable explicitly.
+
+To set environment variable (with your actual EA database URL):
+```bash
+export DATABASE_URL="prisma+postgres://accelerate.prisma-data.net/?api_key=eyJhbGciOiJIUzI..."
+```
+:::note
+If you explicitly set `DATABASE_URL` in your terminal, that value will take precedence over the one in your `.env` file.
+:::
+
+Run the tunnel:
+```bash
+npx @prisma/ppg-tunnel --host 127.0.0.1 --port 5432
+```
+
+You should see output similar to:
+
+```cmd
+Prisma Postgres auth proxy listening on 127.0.0.1:5432 🚀
+
+Your connection is authenticated using your Prisma Postgres API key.
+...
+
+==============================
+hostname: 127.0.0.1
+port: 5432
+username:
+password:
+==============================
+```
+
+:::note
+Please note that the port you will see in your output will be a randomly assigned port which may be different from the one mentioned here.
+Also, Keep this terminal window open so the tunnel remains active! If you close it, the tunnel disconnects.
+:::
+
+Copy the port number from the terminal output, you’ll need it in the next step for the `pg_dump` command.
+
+### 1.2. Creating the Backup with `pg_dump`
+
+With the tunnel running, you can now dump the EA database by running the following command:
+```bash
+PGSSLMODE=disable \
+pg_dump \
+ -h 127.0.0.1 \
+ -p 5432 \
+ -Fc \
+ -v \
+ -d postgres \
+ -f ./mydatabase.bak \
+&& echo "-complete-"
+```
+
+`PGSSLMODE=disable` indicates SSL is not required locally because the tunnel already encrypts the connection.
+
+```
+`-h` is the host (127.0.0.1)
+`-p` is the port, which should match the one from the tunnel output.
+`-Fc` uses the custom format for backups, recommended for pg_restore.
+`-d` postgres is the default database name used in Prisma Postgres.
+`-f` ./mydatabase.bak specifies the backup file name and location.
+`-v` runs pg_dump in verbose mode.
+```
+
+This should create your backup file named `mydatabase.bak` in the current directory. We will use this backup file for importing in next steps.
+
+## 2. Create a new GA database
+
+Next, create your GA (General Availability) database:
+1. Visit [console.prisma.io](https://console.prisma.io) and sign in (or create an account).
+2. Create a Prisma Postgres database in the region of your choice.
+3. Copy the Database URL for later use.
+
+Prisma Postgres GA uses PostgreSQL 17, so you’ll be restoring your EA backup into this new environment.
+
+## 3. Import the backup into the GA database
+
+### 3.1. Connecting to the GA Database with `@prisma/ppg-tunnel`
+
+Open a new terminal (or stop the previous tunnel) and connect to your GA database:
+
+Set environment variables for the new GA database:
+```bash
+export DATABASE_URL="prisma+postgres://accelerate.prisma-data.net/?api_key=eyJhbGciOiJIUzI..."
+```
+
+Run the tunnel:
+```bash
+npx @prisma/ppg-tunnel --host 127.0.0.1 --port 5432
+```
+
+You should see output similar to:
+
+```cmd
+Prisma Postgres auth proxy listening on 127.0.0.1:52604 🚀
+
+Your connection is authenticated using your Prisma Postgres API key.
+...
+
+==============================
+hostname: 127.0.0.1
+port: 52604
+username:
+password:
+==============================
+```
+
+
+:::note
+Again, keep this tunnel process running to maintain the connection!
+:::
+
+### 3.2. Restoring the Backup with `pg_restore`
+
+Use the backup file from **Step 1** to restore data into your GA database with `pg_restore` by running this command:
+
+```bash
+PGSSLMODE=disable \
+pg_restore \
+ -h 127.0.0.1 \
+ -p 5432 \
+ -v \
+ -d postgres \
+ ./mydatabase.bak \
+&& echo "-complete-"
+```
+
+Also, in this case the database name is `postgres`. You can replace it with your desired database name. It does not matter what you name your database as you will be able to use Prisma Postgres as usual.
+The backup file name (mydatabase.bak in our example) should match the one you created in Step 1.
+
+This command restores the backup into the GA database. If successful, you should see `-complete-` in the terminal.
+
+## Next steps
+
+Connect with your favorite Database IDE or Prisma Client to confirm all tables, rows, and schemas match your old EA environment.
+
+Congratulations! You have successfully migrated your Prisma Postgres Early Access database to Prisma Postgres GA. If you encounter any issues, please reach out to our [support team](https://www.prisma.io/support).
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/03-prisma-postgres/index.mdx b/versioned_docs/version-6.0.0/100-getting-started/03-prisma-postgres/index.mdx
new file mode 100644
index 0000000000..8ca0965f41
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/03-prisma-postgres/index.mdx
@@ -0,0 +1,12 @@
+---
+title: 'Prisma Postgres'
+metaTitle: 'Prisma Postgres'
+metaDescription: 'Get started with Prisma ORM and your favorite database. Learn about data modeling, migrations and querying.'
+hide_table_of_contents: true
+staticLink: true
+---
+
+
+## In this section
+
+
diff --git a/versioned_docs/version-6.0.0/100-getting-started/index.mdx b/versioned_docs/version-6.0.0/100-getting-started/index.mdx
new file mode 100644
index 0000000000..110d5db0e6
--- /dev/null
+++ b/versioned_docs/version-6.0.0/100-getting-started/index.mdx
@@ -0,0 +1,182 @@
+---
+title: 'Get Started'
+metaTitle: 'Get started with Prisma'
+metaDescription: 'Build data-driven applications with ease using Prisma ORM, add connection pooling or global caching with Prisma Accelerate.'
+hide_title: true
+sidebar_position: 0
+sidebar_class_name: firstTitle
+pagination_next: 'getting-started/quickstart-sqlite'
+---
+
+import {
+ Bolt,
+ BorderBox,
+ BoxTitle,
+ Inspect,
+ Database,
+ Grid,
+ LinkCard,
+ List,
+ Plus,
+ Plug,
+ SignalStream,
+ PrismaPostgres,
+ SquareLogo,
+ QuickstartLinkCard
+} from '@site/src/components/GettingStarted';
+
+
+Getting started
+
+
+
+
+
+[**Prisma ORM**](/orm/overview/introduction/what-is-prisma) is an open-source ORM that provides fast, type-safe access to Postgres, MySQL, SQLite, and more databases, and runs smoothly across Node.js, Bun, and Deno.
+
+```terminal
+npx prisma init --db
+```
+
+
+
+
+
+[**Prisma Postgres**](/postgres) is a fully managed PostgreSQL database that scales to zero, integrates with Prisma ORM and Prisma Studio, and includes a generous free tier.
+
+```terminal
+npx create-db
+```
+
+
+
+
+
+
+
+
+The fastest way to set up **Prisma ORM** with a ready-to-use **Prisma Postgres** database.
+
+
+
+
+
+
+### Already have your own database?
+
+The fastest way to set Prisma ORM up with a ready-to-use database.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ {/* ### Using Prisma Postgres with other tools?
+
+You can also use Prisma Postgres with different tools or ORMs. Pick one of the options below to see how to connect.
+
+
+
+
+
+
+
+
+
+ */}
+
+### Add Prisma to your favorite framework?
+
+Working with **Next.js**, **Remix**, or another framework? You can easily add Prisma to your setup in just a few steps and start using it right away.
+
+
+
+
+
+
+
+
+
+
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/100-what-is-prisma.mdx b/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/100-what-is-prisma.mdx
new file mode 100644
index 0000000000..ea7fd22348
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/100-what-is-prisma.mdx
@@ -0,0 +1,272 @@
+---
+title: 'What is Prisma ORM?'
+metaTitle: 'What is Prisma ORM? (Overview)'
+metaDescription: "This page gives a high-level overview of what Prisma ORM is and how it works. It's a great starting point for Prisma newcomers!"
+---
+
+Prisma ORM is an [open-source](https://github.com/prisma/prisma) next-generation ORM. It consists of the following parts:
+
+- **Prisma Client**: Auto-generated and type-safe query builder for Node.js & TypeScript
+- **Prisma Migrate**: Migration system
+- **Prisma Studio**: GUI to view and edit data in your database.
+
+ :::info
+
+ **Prisma Studio** is the only part of Prisma ORM that is not open source. You can only run Prisma Studio locally.
+
+ :::
+
+Prisma Client can be used in _any_ Node.js (supported versions) or TypeScript backend application (including serverless applications and microservices). This can be a [REST API](/orm/overview/prisma-in-your-stack/rest), a [GraphQL API](/orm/overview/prisma-in-your-stack/graphql), a gRPC API, or anything else that needs a database.
+
+
+
+
+
+## How does Prisma ORM work?
+
+### The Prisma schema
+
+Every project that uses a tool from the Prisma ORM toolkit starts with a [Prisma schema](/orm/prisma-schema). The Prisma schema allows developers to define their _application models_ in an intuitive data modeling language. It also contains the connection to a database and defines a _generator_:
+
+
+
+```prisma
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+
+generator client {
+ provider = "prisma-client-js"
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ content String?
+ published Boolean @default(false)
+ author User? @relation(fields: [authorId], references: [id])
+ authorId Int?
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ posts Post[]
+}
+```
+
+
+
+```prisma
+datasource db {
+ provider = "mongodb"
+ url = env("DATABASE_URL")
+}
+
+generator client {
+ provider = "prisma-client-js"
+}
+
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ title String
+ content String?
+ published Boolean @default(false)
+ author User? @relation(fields: [authorId], references: [id])
+ authorId String @db.ObjectId
+}
+
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ email String @unique
+ name String?
+ posts Post[]
+}
+```
+
+
+
+
+> **Note**: The Prisma schema has powerful data modeling features. For example, it allows you to define "Prisma-level" [relation fields](/orm/prisma-schema/data-model/relations) which will make it easier to work with [relations in the Prisma Client API](/orm/prisma-client/queries/relation-queries). In the case above, the `posts` field on `User` is defined only on "Prisma-level", meaning it does not manifest as a foreign key in the underlying database.
+
+In this schema, you configure three things:
+
+- **Data source**: Specifies your database connection (via an environment variable)
+- **Generator**: Indicates that you want to generate Prisma Client
+- **Data model**: Defines your application models
+
+### The Prisma schema data model
+
+On this page, the focus is on the data model. You can learn more about [Data sources](/orm/prisma-schema/overview/data-sources) and [Generators](/orm/prisma-schema/overview/generators) on the respective docs pages.
+
+#### Functions of Prisma schema data models
+
+The data model is a collection of [models](/orm/prisma-schema/data-model/models#defining-models). A model has two major functions:
+
+- Represent a table in relational databases or a collection in MongoDB
+- Provide the foundation for the queries in the Prisma Client API
+
+#### Getting a data model
+
+There are two major workflows for "getting" a data model into your Prisma schema:
+
+- Manually writing the data model and mapping it to the database with [Prisma Migrate](/orm/prisma-migrate)
+- Generating the data model by [introspecting](/orm/prisma-schema/introspection) a database
+
+Once the data model is defined, you can [generate Prisma Client](/orm/prisma-client/setup-and-configuration/generating-prisma-client) which will expose CRUD and more queries for the defined models. If you're using TypeScript, you'll get full type-safety for all queries (even when only retrieving the subsets of a model's fields).
+
+### Accessing your database with Prisma Client
+
+#### Generating Prisma Client
+
+The first step when using Prisma Client is installing the `@prisma/client` and `prisma` npm packages:
+
+```terminal
+npm install prisma --save-dev
+npm install @prisma/client
+```
+
+Then, you can run `prisma generate`:
+
+```terminal
+npx prisma generate
+```
+
+The `prisma generate` command reads your Prisma schema and _generates_ Prisma Client code. The code is [generated into the `node_modules/.prisma/client` folder by default](/orm/prisma-client/setup-and-configuration/generating-prisma-client#the-prismaclient-npm-package).
+
+After you change your data model, you'll need to manually re-generate Prisma Client by running `prisma generate` to ensure the code inside `node_modules/.prisma/client` gets updated.
+
+#### Using Prisma Client to send queries to your database
+
+Once Prisma Client has been generated, you can import it in your code and send queries to your database. This is what the setup code looks like.
+
+##### Import and instantiate Prisma Client
+
+
+
+
+```ts
+import { PrismaClient } from '@prisma/client'
+
+const prisma = new PrismaClient()
+```
+
+
+
+
+```js
+const { PrismaClient } = require('@prisma/client')
+
+const prisma = new PrismaClient()
+```
+
+
+
+
+Now you can start sending queries via the generated Prisma Client API, here are a few sample queries. Note that all Prisma Client queries return _plain old JavaScript objects_.
+
+Learn more about the available operations in the [Prisma Client API reference](/orm/prisma-client).
+
+##### Retrieve all `User` records from the database
+
+```ts
+// Run inside `async` function
+const allUsers = await prisma.user.findMany()
+```
+
+##### Include the `posts` relation on each returned `User` object
+
+```ts
+// Run inside `async` function
+const allUsers = await prisma.user.findMany({
+ include: { posts: true },
+})
+```
+
+##### Filter all `Post` records that contain `"prisma"`
+
+```ts
+// Run inside `async` function
+const filteredPosts = await prisma.post.findMany({
+ where: {
+ OR: [
+ { title: { contains: 'prisma' } },
+ { content: { contains: 'prisma' } },
+ ],
+ },
+})
+```
+
+##### Create a new `User` and a new `Post` record in the same query
+
+```ts
+// Run inside `async` function
+const user = await prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ posts: {
+ create: { title: 'Join us for Prisma Day 2020' },
+ },
+ },
+})
+```
+
+##### Update an existing `Post` record
+
+```ts
+// Run inside `async` function
+const post = await prisma.post.update({
+ where: { id: 42 },
+ data: { published: true },
+})
+```
+
+#### Usage with TypeScript
+
+Note that when using TypeScript, the result of this query will be _statically typed_ so that you can't accidentally access a property that doesn't exist (and any typos are caught at compile-time). Learn more about leveraging Prisma Client's generated types on the [Advanced usage of generated types](/orm/prisma-client/type-safety/operating-against-partial-structures-of-model-types) page in the docs.
+
+## Typical Prisma ORM workflows
+
+As mentioned above, there are two ways for "getting" your data model into the Prisma schema. Depending on which approach you choose, your main Prisma ORM workflow might look different.
+
+### Prisma Migrate
+
+With **Prisma Migrate**, Prisma ORM's integrated database migration tool, the workflow looks as follows:
+
+1. Manually adjust your [Prisma schema data model](/orm/prisma-schema/data-model/models)
+1. Migrate your development database using the `prisma migrate dev` CLI command
+1. Use Prisma Client in your application code to access your database
+
+
+
+To learn more about the Prisma Migrate workflow, see:
+
+- [Deploying database changes with Prisma Migrate](/orm/prisma-client/deployment/deploy-database-changes-with-prisma-migrate)
+
+* [Developing with Prisma Migrate](/orm/prisma-migrate)
+
+### SQL migrations and introspection
+
+If for some reason, you can not or do not want to use Prisma Migrate, you can still use introspection to update your Prisma schema from your database schema.
+The typical workflow when using **SQL migrations and introspection** is slightly different:
+
+1. Manually adjust your database schema using SQL or a third-party migration tool
+1. (Re-)introspect your database
+1. Optionally [(re-)configure your Prisma Client API](/orm/prisma-client/setup-and-configuration/custom-model-and-field-names)
+1. (Re-)generate Prisma Client
+1. Use Prisma Client in your application code to access your database
+
+
+
+To learn more about the introspection workflow, please refer the [introspection section](/orm/prisma-schema/introspection).
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/200-why-prisma.mdx b/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/200-why-prisma.mdx
new file mode 100644
index 0000000000..7c48398cce
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/200-why-prisma.mdx
@@ -0,0 +1,95 @@
+---
+title: 'Why Prisma ORM?'
+metaTitle: 'Why Prisma ORM? Comparison with SQL query builders & ORMs'
+metaDescription: 'Learn about the motivation for Prisma ORM and how it compares to other Node.js and TypeScript database tools like ORMs and SQL query builders.'
+---
+
+
+
+On this page, you'll learn about the motivation for Prisma ORM and how it compares to other database tools like traditional ORMs and SQL query builders.
+
+Working with relational databases is a major bottleneck in application development. Debugging SQL queries or complex ORM objects often consume hours of development time.
+
+Prisma ORM makes it easy for developers to reason about their database queries by providing a clean and type-safe API for submitting database queries which returns _plain old JavaScript objects_.
+
+
+
+## TLDR
+
+Prisma ORM's main goal is to make application developers more productive when working with databases. Here are a few examples of how Prisma ORM achieves this:
+
+- **Thinking in objects** instead of mapping relational data
+- **Queries not classes** to avoid complex model objects
+- **Single source of truth** for database and application models
+- **Healthy constraints** that prevent common pitfalls and anti-patterns
+- **An abstraction that makes the right thing easy** ("pit of success")
+- **Type-safe database queries** that can be validated at compile time
+- **Less boilerplate** so developers can focus on the important parts of their app
+- **Auto-completion in code editors** instead of needing to look up documentation
+
+The remaining parts of this page discuss how Prisma ORM compares to existing database tools.
+
+## Problems with SQL, traditional ORMs and other database tools
+
+The main problem with the database tools that currently exist in the Node.js and TypeScript ecosystem is that they require a major tradeoff between _productivity_ and _control_.
+
+
+
+### Raw SQL: Full control, low productivity
+
+With raw SQL (e.g. using the native [`pg`](https://node-postgres.com/) or [`mysql`](https://github.com/mysqljs/mysql) Node.js database drivers) you have full control over your database operations. However, productivity suffers as sending plain SQL strings to the database is cumbersome and comes with a lot of overhead (manual connection handling, repetitive boilerplate, ...).
+
+Another major issue with this approach is that you don't get any type safety for your query results. Of course, you can type the results manually but this is a huge amount of work and requires major refactorings each time you change your database schema or queries to keep the typings in sync.
+
+Furthermore, submitting SQL queries as plain strings means you don't get any autocompletion in your editors.
+
+### SQL query builders: High control, medium productivity
+
+A common solution that retains a high level of control and provides better productivity is to use a SQL query builder (e.g. [knex.js](https://knexjs.org/)). These sort of tools provide a programmatic abstraction to construct SQL queries.
+
+The biggest drawback with SQL query builders is that application developers still need to think about their data in terms of SQL. This incurs a cognitive and practical cost of translating relational data into objects. Another issue is that it's too easy to shoot yourself in the foot if you don't know exactly what you're doing in your SQL queries.
+
+### Traditional ORMs: Less control, better productivity
+
+Traditional ORMs abstract away from SQL by letting you _define your application models as classes_, these classes are mapped to tables in the database.
+
+> "Object relational mappers" (ORMs) exist to bridge the gap between the programmers' friend (the object), and the database's primitive (the relation). The reasons for these differing models are as much cultural as functional: programmers like objects because they encapsulate the state of a single thing in a running program. Databases like relations because they better suit whole-dataset constraints and efficient access patterns for the entire dataset.
+>
+> [The Troublesome Active Record Pattern, Cal Paterson (2020)](https://calpaterson.com/activerecord.html)
+
+You can then read and write data by calling methods on the instances of your model classes.
+
+This is way more convenient and comes closer to the mental model developers have when thinking about their data. So, what's the catch?
+
+> ORM represents a quagmire which starts well, gets more complicated as time passes, and before long entraps its users in a commitment that has no clear demarcation point, no clear win conditions, and no clear exit strategy.
+>
+> [The Vietnam of Computer Science, Ted Neward (2006)](https://blog.codinghorror.com/object-relational-mapping-is-the-vietnam-of-computer-science/)
+
+As an application developer, the mental model you have for your data is that of an _object_. The mental model for data in SQL on the other hand are _tables_.
+
+The divide between these two different representations of data is often referred to as the [object-relational impedance mismatch](https://en.wikipedia.org/wiki/Object-relational_impedance_mismatch). The object-relational impedance mismatch also is a major reason why many developers don't like working with traditional ORMs.
+
+As an example, consider how data is organized and relationships are handled with each approach:
+
+- **Relational databases**: Data is typically normalized (flat) and uses foreign keys to link across entities. The entities then need to be JOINed to manifest the actual relationships.
+- **Object-oriented**: Objects can be deeply nested structures where you can traverse relationships simply by using dot notation.
+
+This alludes to one of the major pitfalls with traditional ORMs: While they make it _seem_ that you can simply traverse relationships using familiar dot notation, under the hood the ORM generates SQL JOINs which are expensive and have the potential to drastically slow down your application (one symptom of this is the [n+1 problem](https://stackoverflow.com/questions/97197/what-is-the-n1-selects-problem-in-orm-object-relational-mapping)).
+
+To conclude: The appeal of traditional ORMs is the premise of abstracting away the relational model and thinking about your data purely in terms of objects. While the premise is great, it's based on the wrong assumption that relational data can easily be mapped to objects which leads to lots of complications and pitfalls.
+
+## Application developers should care about data – not SQL
+
+Despite being developed in the 1970s(!), SQL has stood the test of time in an impressive manner. However, with the advancement and modernization of developers tools, it's worth asking if SQL really is the best abstraction for application developers to work with?
+
+After all, **developers should only care about the _data_ they need to implement a feature** and not spend time figuring out complicated SQL queries or massaging query results to fit their needs.
+
+There's another argument to be made against SQL in application development. The power of SQL can be a blessing if you know exactly what you're doing, but its complexity can be a curse. There are a lot of [anti-patterns](https://www.slideshare.net/billkarwin/sql-antipatterns-strike-back) and pitfalls that even experienced SQL users struggle to anticipate, often at the cost of performance and hours of debugging time.
+
+Developers should be able to ask for the data they need instead of having to worry about "doing the right thing" in their SQL queries. They should be using an abstraction that makes the right decisions for them. This can mean that the abstraction imposes certain "healthy" constraints that prevent developers from making mistakes.
+
+## Prisma ORM makes developers productive
+
+Prisma ORM's main goal is to make application developers more productive when working with databases. Considering the tradeoff between productivity and control again, this is how Prisma ORM fits in:
+
+
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/250-should-you-use-prisma.mdx b/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/250-should-you-use-prisma.mdx
new file mode 100644
index 0000000000..8fce765442
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/250-should-you-use-prisma.mdx
@@ -0,0 +1,106 @@
+---
+title: 'Should you use Prisma ORM?'
+metaTitle: 'Should you use Prisma ORM as a Node.js/TypeScript ORM?'
+metaDescription: 'Prisma ORM is a new kind of ORM. This page explains when Prisma ORM would be a good fit, and provides alternatives for other scenarios.'
+tocDepth: 3
+toc: true
+---
+
+
+
+Prisma ORM is a new kind of ORM that - like any other tool - comes with its own tradeoffs. This page explains when Prisma ORM would be a good fit, and provides alternatives for other scenarios.
+
+
+
+## Prisma ORM likely _is_ a good fit for you if ...
+
+### ... you are building a server-side application that talks to a database
+
+This is the main use case for Prisma ORM. Server-side applications typically are API servers that expose data operations via technologies like REST, GraphQL or gRPC. They are commonly built as microservices or monolithic apps and deployed via long-running servers or serverless functions. Prisma ORM is a great fit for all of these application and deployment models.
+
+Refer to the full list of databases (relational, NoSQL, and NewSQL) that Prisma ORM [supports](/orm/reference/supported-databases).
+
+### ... you care about productivity and developer experience
+
+Productivity and developer experience are core to how we're building our tools. We're looking to build developer-friendly abstractions for tasks that are complex, error-prone and time-consuming when performed manually.
+
+No matter if you're a SQL newcomer or veteran, Prisma ORM will give you a significant productivity boost for the most common database workflows.
+
+Here are a couple of the guiding principles and general practices we apply when designing and building our tools:
+
+- [make the right thing easy](https://jason.energy/right-thing-easy-thing/)
+- [pit of success](https://blog.codinghorror.com/falling-into-the-pit-of-success/)
+- offer intelligent autocompletion where possible
+- build powerful editor extensions (e.g. for [VS Code](https://marketplace.visualstudio.com/items?itemName=Prisma.prisma))
+- go the extra mile to achieve full type-safety
+
+### ... you are working in a team
+
+Prisma ORM shines especially when used in collaborative environments.
+
+The declarative [Prisma schema](/orm/prisma-schema) provides an overview of the current state of the database that's easy to understand for everyone. This is a major improvement to traditional workflows where developers have to dig through migration files to understand the current table structure.
+
+[Prisma Client](/orm/prisma-client)'s minimal API surface enables developers to pick it up quickly without much learning overhead, so onboarding new developers to a team becomes a lot smoother.
+
+The [Prisma Migrate](/orm/prisma-migrate) workflows are designed in a way to cover database schema changes in collaborative environments. From the initial schema creation up to the point of deploying schema changes to production and resolving conflicts that were introduced by parallel modifications, Prisma Migrate has you covered.
+
+### ... you want a tool that holistically covers your database workflows
+
+Prisma ORM is a lot more than "just another ORM". We are building a database toolkit that covers the daily workflows of application developers that interact with databases. A few examples are:
+
+- querying (with [Prisma Client](/orm/prisma-client))
+- data modeling (in the [Prisma schema](/orm/prisma-schema))
+- migrations (with [Prisma Migrate](/orm/prisma-migrate))
+- prototyping (via [`prisma db push`](/orm/reference/prisma-cli-reference#db-push))
+- seeding (via [`prisma db seed`](/orm/reference/prisma-cli-reference#db-seed))
+- visual viewing and editing (with [Prisma Studio](https://www.prisma.io/studio))
+
+### ... you value type-safety
+
+Prisma ORM is the only _fully_ type-safe ORM in the TypeScript ecosystem. The generated Prisma Client ensures typed query results even for partial queries and relations. You can learn more about this in the [type-safety comparison with TypeORM](/orm/more/comparisons/prisma-and-typeorm#type-safety).
+
+### ... you want to write raw, type-safe SQL
+
+In addition to the intuitive, higher-level query API, Prisma ORM also offers a way for you to [write raw SQL with full type safety](https://www.prisma.io/blog/announcing-typedsql-make-your-raw-sql-queries-type-safe-with-prisma-orm).
+
+### ... you want an ORM with a transparent development process, proper maintenance & support
+
+Development of Prisma ORM's open source tools is happening in the open. Most of it happens directly on GitHub in the main [`prisma/prisma`](https://github.com/prisma/prisma) repo:
+
+- issues and PRs in our repos are triaged and prioritized (usually within 1-2 days)
+- new [releases](https://github.com/prisma/prisma/releases) with new features and improvements are issued every three weeks
+- we have a dedicated support team that responds to questions in [GitHub Discussions](https://github.com/prisma/prisma/discussions)
+
+### ... you want to be part of an awesome community
+
+Prisma has a lively [community](https://www.prisma.io/community) that you can find on [Discord](https://pris.ly/discord?utm_source=docs&utm_medium=inline_text). We also regularly host Meetups, conferences and other developer-focused events. Join us!
+
+## Prisma ORM likely is _not_ a good fit for you if ...
+
+### ... you need _full_ control over all database queries
+
+Prisma ORM is an abstraction. As such, an inherent tradeoff of Prisma ORM is a reduced amount of control in exchange for higher productivity. This means, the [Prisma Client API](/orm/prisma-client) might have less capabilities in some scenarios than you get with plain SQL.
+
+If your application has requirements for database queries that Prisma ORM does not provide and the workarounds are too costly, you might be better off with a tool that allows you to exercise full control over your database operations using plain SQL.
+
+> **Note**: If you can work around a certain limitation but still would like to see an improvement in the way how Prisma ORM handles the situation, we encourage you to create a [feature request](https://github.com/prisma/prisma/issues/new?assignees=&labels=&template=feature_request.md&title=) on GitHub so that our Product and Engineering teams can look into it.
+
+_Alternatives_: SQL drivers (e.g. [`node-postgres`](https://node-postgres.com/), [`mysql`](https://github.com/mysqljs/mysql), [`sqlite3`](https://github.com/TryGhost/node-sqlite3), ...)
+
+### ... you do not want to write any code for your backend
+
+If you don't want to write any code for your backend and just be able to generate your API server and the database out-of-the-box, you might rather choose a Backend-as-a-Service (BaaS) for your project.
+
+With a BaaS, you can typically configure your data model via a high-level API (e.g. [GraphQL SDL](https://www.prisma.io/blog/graphql-sdl-schema-definition-language-6755bcb9ce51)) or a visual editor. Based on this data model, the BaaS generates a CRUD API and provisions a database for you. With this setup, you typically don't have control over the infrastructure the API server and database are running on.
+
+With Prisma ORM, you are building the backend yourself using Node.js or TypeScript. This means you'll have to do a lot more coding work compared to using a BaaS. The benefit of this approach is that you have full flexibility for building, deploying, scaling and maintaining your backend and are not dependent on 3rd party software for a crucial part of your stack.
+
+_Alternatives_: [AWS AppSync](https://aws.amazon.com/appsync/), [8base](https://www.8base.com/), [Nhost](https://nhost.io/), [Supabase](https://supabase.com/), [Firebase](https://firebase.google.com/), [Amplication](https://amplication.com/)
+
+### ... you want a CRUD GraphQL API without writing any code
+
+While tools like the [`nexus-plugin-prisma`](https://nexusjs.org/docs/plugins/prisma/overview) and [`typegraphql-prisma`](https://github.com/MichalLytek/typegraphql-prisma#readme) allow you to quickly generate CRUD operations for your Prisma ORM models in a GraphQL API, these approaches still require you to set up your GraphQL server manually and do some work to expose GraphQL queries and mutations for the models defined in your Prisma schema.
+
+If you want to get a GraphQL endpoint for your database out-of-the box, other tools might be better suited for your use case.
+
+_Alternatives_: [Hasura](https://hasura.io/), [Postgraphile](https://www.graphile.org/postgraphile/)
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/300-data-modeling.mdx b/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/300-data-modeling.mdx
new file mode 100644
index 0000000000..af5cd1a998
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/300-data-modeling.mdx
@@ -0,0 +1,246 @@
+---
+title: 'Data modeling'
+metaTitle: 'Data modeling with Prisma'
+metaDescription: 'Learn how data modeling with Prisma differs from data modeling with SQL or ORMs. Prisma uses a declarative data modeling language to describe a database schema.'
+---
+
+## What is data modeling?
+
+The term _data modeling_ refers to the **process of defining the shape and structure of the objects in an application**, these objects are often called "application models". In relational databases (like PostgreSQL), they are stored in _tables_ . When using document databases (like MongoDB), they are stored in _collections_.
+
+Depending on the domain of your application, the models will be different. For example, if you're writing a blogging application, you might have models such as _blog_, _author_, _article_. When writing a car-sharing app, you probably have models like _driver_, _car_, _route_. Application models enable you to represent these different entities in your code by creating respective _data structures_.
+
+When modeling data, you typically ask questions like:
+
+- What are the main entities/concepts in my application?
+- How do they relate to each other?
+- What are their main characteristics/properties?
+- How can they be represented with my technology stack?
+
+## Data modeling without Prisma ORM
+
+Data modeling typically needs to happen on (at least) two levels:
+
+- On the **database** level
+- On the **application** level (i.e., in your programming language)
+
+The way that the application models are represented on both levels might differ due to a few reasons:
+
+- Databases and programming languages use different data types
+- Relations are represented differently in a database than in a programming language
+- Databases typically have more powerful data modeling capabilities, like indexes, cascading deletes, or a variety of additional constraints (e.g. unique, not null, ...)
+- Databases and programming languages have different technical constraints
+
+### Data modeling on the database level
+
+#### Relational databases
+
+In relational databases, models are represented by _tables_. For example, you might define a `users` table to store information about the users of your application. Using PostgreSQL, you'd define it as follows:
+
+```sql
+CREATE TABLE users (
+ user_id SERIAL PRIMARY KEY NOT NULL,
+ name VARCHAR(255),
+ email VARCHAR(255) UNIQUE NOT NULL,
+ isAdmin BOOLEAN NOT NULL DEFAULT false
+);
+```
+
+A visual representation of the `users` table with some random data might look as follows:
+
+| `user_id` | `name` | `email` | `isAdmin` |
+| :-------- | :------ | :---------------- | :-------- |
+| `1` | `Alice` | `alice@prisma.io` | `false` |
+| `2` | `Bob` | `bob@prisma.io` | `false` |
+| `3` | `Sarah` | `sarah@prisma.io` | `true` |
+
+It has the following columns:
+
+- `user_id`: An integer that increments with every new record in the `users` table. It also represents the [primary key](https://en.wikipedia.org/wiki/Primary_key) for each record.
+- `name`: A string with at most 255 characters.
+- `email`: A string with at most 255 characters. Additionally, the added constraints express that no two records can have duplicate values for the `email` column, and that _every_ record needs to have a value for it.
+- `isAdmin`: A boolean that indicates whether the user has admin rights (default value: `false`)
+
+#### MongoDB
+
+In MongoDB databases, models are represented by _collections_ and contain _documents_ that can have any structure:
+
+```js
+{
+ _id: '607ee94800bbe41f001fd568',
+ slug: 'prisma-loves-mongodb',
+ title: 'Prisma <3 MongoDB',
+ body: "This is my first post. Isn't MongoDB + Prisma awesome?!"
+}
+```
+
+Prisma Client currently expects a consistent model and [normalized model design](https://www.mongodb.com/docs/manual/data-modeling/concepts/embedding-vs-references/#references). This means that:
+
+- If a model or field is not present in the Prisma schema, it is ignored
+- If a field is mandatory but not present in the MongoDB dataset, you will get an error
+
+### Data modeling on the application level
+
+In addition to creating the tables that represent the entities from your application domain, you also need to create application models in your programming language. In object-oriented languages, this is often done by creating _classes_ to represent your models. Depending on the programming language, this might also be done with _interfaces_ or _structs_.
+
+There often is a strong correlation between the tables in your database and the models you define in your code. For example, to represent records from the aforementioned `users` table in your application, you might define a JavaScript (ES6) class looking similar to this:
+
+```js
+class User {
+ constructor(user_id, name, email, isAdmin) {
+ this.user_id = user_id
+ this.name = name
+ this.email = email
+ this.isAdmin = isAdmin
+ }
+}
+```
+
+When using TypeScript, you might define an interface instead:
+
+```js
+interface User {
+ user_id: number
+ name: string
+ email: string
+ isAdmin: boolean
+}
+```
+
+Notice how the `User` model in both cases has the same properties as the `users` table in the previous example. While it's often the case that there's a 1:1 mapping between database tables and application models, it can also happen that models are represented completely differently in the database and your application.
+
+With this setup, you can retrieve records from the `users` table and store them as instances of your `User` type. The following example code snippet uses [`pg`](https://node-postgres.com/) as the driver for PostgreSQL and creates a `User` instance based on the above defined JavaScript class:
+
+```js
+const resultRows = await client.query('SELECT * FROM users WHERE user_id = 1')
+const userData = resultRows[0]
+const user = new User(
+ userData.user_id,
+ userData.name,
+ userData.email,
+ userData.isAdmin
+)
+// user = {
+// user_id: 1,
+// name: "Alice",
+// email: "alice@prisma.io",
+// isAdmin: false
+// }
+```
+
+Notice that in these examples, the application models are "dumb", meaning they don't implement any logic but their sole purpose is to carry data as _plain old JavaScript objects_.
+
+### Data modeling with ORMs
+
+ORMs are commonly used in object-oriented languages to make it easier for developers to work with a database. The key characteristic of an ORM is that it lets you model your application data in terms of _classes_ which are mapped to _tables_ in the underlying database.
+
+The main difference compared to the approaches explained above is these classes not only carry data but also implement a substantial amount of logic. Mostly for storage, retrieval, serialization, and deserialization, but sometimes they also implement business logic that's specific to your application.
+
+This means, you don't write SQL statements to read and write data in the database, but instead the instances of your model classes provide an API to store and retrieve data.
+
+[Sequelize](https://sequelize.org/) is a popular ORM in the Node.js ecosystem, this is how you'd define the same `User` model from the sections before using Sequelize's modeling approach:
+
+```js
+class User extends Model {}
+User.init(
+ {
+ user_id: {
+ type: Sequelize.INTEGER,
+ primaryKey: true,
+ autoIncrement: true,
+ },
+ name: Sequelize.STRING(255),
+ email: {
+ type: Sequelize.STRING(255),
+ unique: true,
+ },
+ isAdmin: Sequelize.BOOLEAN,
+ },
+ { sequelize, modelName: 'user' }
+)
+```
+
+To get an example with this `User` class to work, you still need to create the corresponding table in the database. With Sequelize, you have two ways of doing this:
+
+- Run `User.sync()` (typically not recommended for production)
+- Use [Sequelize migrations](https://sequelize.org/v5/manual/migrations.html) to change your database schema
+
+Note that you'll never instantiate the `User` class manually (using `new User(...)`) as was shown in the previous section, but rather call _static_ methods on the `User` class which then return the `User` model instances:
+
+```js
+const user = await User.findByPk(42)
+```
+
+The call to `findByPk` creates a SQL statement to retrieve the `User` record that's identified by the ID value `42`.
+
+The resulting `user` object is an instance of Sequelize's `Model` class (because `User` inherits from `Model`). It's not a POJO, but an object that implements additional behavior from Sequelize.
+
+## Data modeling with Prisma ORM
+
+Depending on which parts of Prisma ORM you want to use in your application, the data modeling flow looks slightly different. The following two sections explain the workflows for using [**only Prisma Client**](#using-only-prisma-client) and using [**Prisma Client and Prisma Migrate**](#using-prisma-client-and-prisma-migrate).
+
+No matter which approach though, with Prisma ORM you never create application models in your programming language by manually defining classes, interfaces, or structs. Instead, the application models are defined in your [Prisma schema](/orm/prisma-schema):
+
+- **Only Prisma Client**: Application models in the Prisma schema are _generated based on the introspection of your database schema_. Data modeling happens primarily on the database-level.
+- **Prisma Client and Prisma Migrate**: Data modeling happens in the Prisma schema by _manually adding application models_ to it. Prisma Migrate maps these application models to tables in the underlying database (currently only supported for relational databases).
+
+As an example, the `User` model from the previous example would be represented as follows in the Prisma schema:
+
+```prisma
+model User {
+ user_id Int @id @default(autoincrement())
+ name String?
+ email String @unique
+ isAdmin Boolean @default(false)
+}
+```
+
+Once the application models are in your Prisma schema (whether they were added through introspection or manually by you), the next step typically is to generate Prisma Client which provides a programmatic and type-safe API to read and write data in the shape of your application models.
+
+Prisma Client uses TypeScript [type aliases](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#type-aliases) to represent your application models in your code. For example, the `User` model would be represented as follows in the generated Prisma Client library:
+
+```ts
+export type User = {
+ id: number
+ name: string | null
+ email: string
+ isAdmin: boolean
+}
+```
+
+In addition to the generated types, Prisma Client also provides a data access API that you can use once you've installed the `@prisma/client` package:
+
+```js
+import { PrismaClient } from '@prisma/client'
+// or
+// const { PrismaClient } = require('@prisma/client')
+
+const prisma = new PrismaClient()
+
+// use inside an `async` function to `await` the result
+await prisma.user.findUnique(...)
+await prisma.user.findMany(...)
+await prisma.user.create(...)
+await prisma.user.update(...)
+await prisma.user.delete(...)
+await prisma.user.upsert(...)
+```
+
+### Using only Prisma Client
+
+When using only Prisma Client and _not_ using Prisma Migrate in your application, data modeling needs to happen on the database level via SQL. Once your SQL schema is ready, you use Prisma's introspection feature to add the application models to your Prisma schema. Finally, you generate Prisma Client which creates the types as well as the programmatic API for you to read and write data in your database.
+
+Here is an overview of the main workflow:
+
+1. Change your database schema using SQL (e.g. `CREATE TABLE`, `ALTER TABLE`, ...)
+1. Run `prisma db pull` to introspect the database and add application models to the Prisma schema
+1. Run `prisma generate` to update your Prisma Client API
+
+### Using Prisma Client and Prisma Migrate
+
+When using [Prisma Migrate](/orm/prisma-migrate), you define your application model in the Prisma schema and with relational databases use the `prisma migrate` subcommand to generate plain SQL migration files, which you can edit before applying. With MongoDB, you use `prisma db push` instead which applies the changes to your database directly.
+
+Here is an overview of the main workflow:
+
+1. Manually change your application models in the Prisma schema (e.g. add a new model, remove an existing one, ...)
+1. Run `prisma migrate dev` to create and apply a migration or run `prisma db push` to apply the changes directly (in both cases Prisma Client is automatically generated)
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/index.mdx b/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/index.mdx
new file mode 100644
index 0000000000..cd69911fad
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/index.mdx
@@ -0,0 +1,21 @@
+---
+title: 'Introduction to Prisma ORM'
+sidebar_label: 'Introduction'
+metaTitle: 'Introduction (Overview)'
+metaDescription: "This section gives a high-level overview of what Prisma is and how it works. It's a great starting point for Prisma newcomers!"
+hide_table_of_contents: true
+---
+
+
+
+This page gives a high-level overview of what Prisma ORM is and how it works.
+
+If you want to get started with a _practical introduction_ and learn about the Prisma Client API, head over to the [**Getting Started**](/getting-started) documentation.
+
+To learn more about the _motivation_ for Prisma ORM, check out the [**Why Prisma ORM?**](/orm/overview/introduction/why-prisma) page.
+
+
+
+## In this section
+
+
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/node-js-db-tools-tradeoffs.png b/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/node-js-db-tools-tradeoffs.png
new file mode 100644
index 0000000000..8037da2e08
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/node-js-db-tools-tradeoffs.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/prisma-makes-devs-productive.png b/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/prisma-makes-devs-productive.png
new file mode 100644
index 0000000000..fcd68959c6
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/prisma-makes-devs-productive.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/prisma-rest-apis.png b/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/prisma-rest-apis.png
new file mode 100644
index 0000000000..9e374a2fa0
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/prisma-rest-apis.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/user-post-relation-1-n.png b/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/user-post-relation-1-n.png
new file mode 100644
index 0000000000..bab7611d32
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/user-post-relation-1-n.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/user-table.png b/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/user-table.png
new file mode 100644
index 0000000000..a44df94e25
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/user-table.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/user-table.svg b/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/user-table.svg
new file mode 100644
index 0000000000..1bc2e636a6
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/100-introduction/user-table.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/300-prisma-in-your-stack/01-rest.mdx b/versioned_docs/version-6.0.0/200-orm/050-overview/300-prisma-in-your-stack/01-rest.mdx
new file mode 100644
index 0000000000..5b7c5e3442
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/300-prisma-in-your-stack/01-rest.mdx
@@ -0,0 +1,153 @@
+---
+title: 'REST'
+metaTitle: 'Building REST APIs with Prisma ORM'
+metaDescription: 'This page gives an overview of the most important things when building REST APIs with Prisma. It shows practical examples and the supported libraries.'
+---
+
+
+
+When building REST APIs, Prisma Client can be used inside your _route controllers_ to send databases queries.
+
+
+
+
+
+## Supported libraries
+
+As Prisma Client is "only" responsible for sending queries to your database, it can be combined with any HTTP server library or web framework of your choice.
+
+Here's a non-exhaustive list of libraries and frameworks you can use with Prisma ORM:
+
+- [Express](https://expressjs.com/)
+- [koa](https://koajs.com/)
+- [hapi](https://hapi.dev/)
+- [Fastify](https://fastify.dev/)
+- [Sails](https://sailsjs.com/)
+- [AdonisJs](https://adonisjs.com/)
+- [NestJS](https://nestjs.com/)
+- [Next.js](https://nextjs.org/)
+- [Foal TS](https://foalts.org/)
+- [Polka](https://github.com/lukeed/polka)
+- [Micro](https://github.com/zeit/micro)
+- [Feathers](https://feathersjs.com/)
+- [Remix](https://remix.run/)
+
+## REST API server example
+
+Assume you have a Prisma schema that looks similar to this:
+
+```prisma
+datasource db {
+ provider = "sqlite"
+ url = "file:./dev.db"
+}
+
+generator client {
+ provider = "prisma-client-js"
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ content String?
+ published Boolean @default(false)
+ author User? @relation(fields: [authorId], references: [id])
+ authorId Int?
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ posts Post[]
+}
+```
+
+You can now implement route controller (e.g. using Express) that use the generated [Prisma Client API](/orm/prisma-client) to perform a database operation when an incoming HTTP request arrives. This page only shows few sample code snippets; if you want to run these code snippets, you can use a [REST API example](https://pris.ly/e/ts/rest-express).
+
+#### `GET`
+
+```ts
+app.get('/feed', async (req, res) => {
+ const posts = await prisma.post.findMany({
+ where: { published: true },
+ include: { author: true },
+ })
+ res.json(posts)
+})
+```
+
+Note that the `feed` endpoint in this case returns a nested JSON response of `Post` objects that _include_ an `author` object. Here's a sample response:
+
+```json
+[
+ {
+ "id": "21",
+ "title": "Hello World",
+ "content": "null",
+ "published": "true",
+ "authorId": 42,
+ "author": {
+ "id": "42",
+ "name": "Alice",
+ "email": "alice@prisma.io"
+ }
+ }
+]
+```
+
+#### `POST`
+
+```ts
+app.post(`/post`, async (req, res) => {
+ const { title, content, authorEmail } = req.body
+ const result = await prisma.post.create({
+ data: {
+ title,
+ content,
+ published: false,
+ author: { connect: { email: authorEmail } },
+ },
+ })
+ res.json(result)
+})
+```
+
+#### `PUT`
+
+```ts
+app.put('/publish/:id', async (req, res) => {
+ const { id } = req.params
+ const post = await prisma.post.update({
+ where: { id: Number(id) },
+ data: { published: true },
+ })
+ res.json(post)
+})
+```
+
+#### `DELETE`
+
+```ts
+app.delete(`/post/:id`, async (req, res) => {
+ const { id } = req.params
+ const post = await prisma.post.delete({
+ where: {
+ id: Number(id),
+ },
+ })
+ res.json(post)
+})
+```
+
+## Ready-to-run example projects
+
+You can find several ready-to-run examples that show how to implement a REST API with Prisma Client, as well as build full applications, in the [`prisma-examples`](https://github.com/prisma/prisma-examples/) repository.
+
+| **Example** | **Stack** | **Description** |
+| ----------------------------------------------------------------------------------------------------------------------------- | ------------ | ---------------------------------------------- |
+| [`express`](https://pris.ly/e/ts/rest-express) | Backend only | REST API with Express for TypeScript |
+| [`fastify`](https://pris.ly/e/ts/rest-fastify) | Backend only | REST API using Fastify and Prisma Client. |
+| [`hapi`](https://pris.ly/e/ts/rest-hapi) | Backend only | REST API using hapi and Prisma Client |
+| [`nestjs`](https://pris.ly/e/ts/rest-nestjs) | Backend only | Nest.js app (Express) with a REST API |
+| [`nextjs`](https://pris.ly/e/orm/nextjs) | Fullstack | Next.js app (React) with a REST API |
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/300-prisma-in-your-stack/02-graphql.mdx b/versioned_docs/version-6.0.0/200-orm/050-overview/300-prisma-in-your-stack/02-graphql.mdx
new file mode 100644
index 0000000000..78d3e23332
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/300-prisma-in-your-stack/02-graphql.mdx
@@ -0,0 +1,75 @@
+---
+title: 'GraphQL'
+metaTitle: 'Building GraphQL servers with Prisma ORM'
+metaDescription: 'This page gives explains how to build GraphQL servers with Prisma ORM. It shows how Prisma ORM fits into the GraphQL ecosystem and provides practical examples.'
+---
+
+
+
+[GraphQL](https://graphql.org/) is a query language for APIs. It is often used as an alternative to RESTful APIs, but can also be used as an additional "gateway" layer on top of existing RESTful services.
+
+With Prisma ORM, you can build GraphQL servers that connect to a database. Prisma ORM is completely agnostic to the GraphQL tools you use. When building a GraphQL server, you can combine Prisma ORM with tools like Apollo Server, GraphQL Yoga, TypeGraphQL, GraphQL.js, or pretty much any tool or library that you're using in your GraphQL server setup.
+
+
+
+## GraphQL servers under the hood
+
+A GraphQL server consists of two major components:
+
+- GraphQL schema (type definitions + resolvers)
+- HTTP server
+
+Note that a GraphQL schema can be written code-first or SDL-first. Check out this [article](https://www.prisma.io/blog/the-problems-of-schema-first-graphql-development-x1mn4cb0tyl3) to learn more about these two approaches. If you like the SDL-first approach but still want to make your code type-safe, check out [GraphQL Code Generator](https://the-guild.dev/graphql/codegen) to generate various type definitions based on SDL.
+
+The GraphQL schema and HTTP server are typically handled by separate libraries. Here is an overview of current GraphQL server tools and their purpose:
+
+| Library (npm package) | Purpose | Compatible with Prisma ORM | Prisma integration |
+| :-------------------- | :-------------------------- | :------------------------- | :----------------------------------------------------------------------------- |
+| `graphql` | GraphQL schema (code-first) | Yes | No |
+| `graphql-tools` | GraphQL schema (SDL-first) | Yes | No |
+| `type-graphql` | GraphQL schema (code-first) | Yes | [`typegraphql-prisma`](https://www.npmjs.com/package/typegraphql-prisma) |
+| `nexus` | GraphQL schema (code-first) | Yes | [`nexus-prisma`](https://graphql-nexus.github.io/nexus-prisma/) _Early Preview_ |
+| `apollo-server` | HTTP server | Yes | n/a |
+| `express-graphql` | HTTP server | Yes | n/a |
+| `fastify-gql` | HTTP server | Yes | n/a |
+| `graphql-yoga` | HTTP server | Yes | n/a |
+
+In addition to these standalone and single-purpose libraries, there are several projects building integrated _application frameworks_:
+
+| Framework | Stack | Built by | Prisma ORM | Description |
+| :---------------------------------- | :-------- | :------------------------------------------------ | :------------------------- | :------------------------------------- |
+| [Redwood.js](https://rwsdk.com/) | Fullstack | [Tom Preston-Werner](https://github.com/mojombo/) | Built on top of Prisma ORM | _Bringing full-stack to the JAMstack._ |
+
+> **Note**: If you notice any GraphQL libraries/frameworks missing from the list, please let us know.
+
+## Prisma ORM & GraphQL examples
+
+In the following section will find several ready-to-run examples that showcase how to use Prisma ORM with different combinations of the tools mentioned in the table above.
+
+| Example | HTTP Server | GraphQL schema | Description |
+| :------------------------------------------------------------------------------------------------------------------------------- | :---------------------- | :-------------- | :--------------------------------------------------------------------------------------------- |
+| [GraphQL API (Pothos)](https://pris.ly/e/ts/graphql) | `graphql-yoga` | `pothos` | GraphQL server based on [`graphql-yoga`](https://the-guild.dev/graphql/yoga-server) |
+| [GraphQL API (SDL-first)](https://pris.ly/e/ts/graphql-sdl-first) | `graphql-yoga` | n/a | GraphQL server based on the SDL-first approach |
+| [GraphQL API -- NestJs](https://pris.ly/e/ts/graphql-nestjs) | `@nestjs/apollo` | n/a | GraphQL server based on [NestJS](https://nestjs.com/) |
+| [GraphQL API -- NestJs (SDL-first)](https://pris.ly/e/ts/graphql-nestjs-sdl-first) | `@nestjs/apollo` | n/a | GraphQL server based on [NestJS](https://nestjs.com/) |
+| [GraphQL API (Nexus)](https://pris.ly/e/ts/graphql-nexus) | `@apollo/server` | `nexus` | GraphQL server based on [`@apollo/server`](https://www.apollographql.com/docs/apollo-server) |
+| [GraphQL API (TypeGraphQL)](https://pris.ly/e/ts/graphql-typegraphql) | `apollo-server` | `type-graphql` | GraphQL server based on the code-first approach of [TypeGraphQL](https://typegraphql.com/) |
+| [GraphQL API (Auth)](https://pris.ly/e/ts/graphql-auth) | `apollo-server` | `nexus` | GraphQL server with email-password authentication & permissions |
+| [Fullstack app](https://pris.ly/e/ts/graphql-nextjs) | `graphql-yoga` | `pothos` | Fullstack app with Next.js (React), Apollo Client, GraphQL Yoga and Pothos |
+| [GraphQL subscriptions](https://pris.ly/e/ts/graphql-subscriptions) | `apollo-server` | `nexus` | GraphQL server implementing realtime GraphQL subscriptions |
+| [GraphQL API -- Hapi](https://pris.ly/e/ts/graphql-hapi) | `apollo-server-hapi` | `nexus` | GraphQL server based on [Hapi](https://hapi.dev/) |
+| [GraphQL API -- Hapi (SDL-first)](https://pris.ly/e/ts/graphql-hapi-sdl-first) | `apollo-server-hapi` | `graphql-tools` | GraphQL server based on [Hapi](https://hapi.dev/) |
+| [GraphQL API -- Fastify](https://pris.ly/e/ts/graphql-fastify) | `fastify` & `mercurius` | n/a | GraphQL server based on [Fastify](https://fastify.dev/) and [Mercurius](https://mercurius.dev/) |
+| [GraphQL API -- Fastify (SDL-first)](https://pris.ly/e/ts/graphql-fastify-sdl-first) | `fastify` | `Nexus` | GraphQL server based on [Fastify](https://fastify.dev/) and [Mercurius](https://mercurius.dev/) |
+
+## FAQ
+
+### What is Prisma ORM's role in a GraphQL server?
+
+No matter which of the above GraphQL tools/libraries you use, Prisma ORM is used inside your GraphQL resolvers to connect to your database. It has the same role that any other ORM or SQL query builder would have inside your resolvers.
+
+In the resolver of a GraphQL query, Prisma ORM typically reads data from the database to return it in the GraphQL response. In the resolver of a GraphQL mutation, Prisma ORM typically also writes data to the database (e.g. creating new or updating existing records).
+
+## Other GraphQL Resources
+
+Prisma curates [GraphQL Weekly](https://www.graphqlweekly.com/), a newsletter highlighting resources and updates from the GraphQL community. Subscribe to keep up-to-date with GraphQL articles, videos, tutorials, libraries, and more.
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/300-prisma-in-your-stack/03-fullstack.mdx b/versioned_docs/version-6.0.0/200-orm/050-overview/300-prisma-in-your-stack/03-fullstack.mdx
new file mode 100644
index 0000000000..df9b99e3ed
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/300-prisma-in-your-stack/03-fullstack.mdx
@@ -0,0 +1,115 @@
+---
+title: 'Fullstack'
+metaTitle: 'Building fullstack applications with Prisma ORM'
+metaDescription: 'This page gives explains how to build fullstack applications with Prisma. It shows how Prisma fits in with fullstack frameworks and provides practical examples'
+---
+
+
+
+Fullstack frameworks, such as Next.js, Remix or SvelteKit, blur the lines between the server and the client. These frameworks also provide different patterns for fetching and mutating data on the server.
+
+You can query your database using Prisma Client, using your framework of choice, from the server-side part of your application.
+
+
+
+## Supported frameworks
+
+Here's a non-exhaustive list of frameworks and libraries you can use with Prisma ORM:
+
+- [Next.js](https://nextjs.org/)
+- [Remix](https://remix.run)
+- [SvelteKit](https://svelte.dev/)
+- [Nuxt](https://nuxt.com/)
+- [Redwood](https://rwsdk.com/)
+- [t3 stack — using tRPC](https://create.t3.gg/)
+- [Wasp](https://wasp-lang.dev/)
+
+## Fullstack app example (e.g. Next.js)
+
+:::tip
+
+If you want to learn how to build an app with Next.js and Prisma ORM, check out this comprehensive [video tutorial](https://www.youtube.com/watch?v=QXxy8Uv1LnQ&ab_channel=ByteGrad).
+
+:::
+
+Assume you have a Prisma schema that looks similar to this:
+
+```prisma
+datasource db {
+ provider = "sqlite"
+ url = "file:./dev.db"
+}
+
+generator client {
+ provider = "prisma-client-js"
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ content String?
+ published Boolean @default(false)
+ author User? @relation(fields: [authorId], references: [id])
+ authorId Int?
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ posts Post[]
+}
+```
+
+You can now implement the logic for querying your database using [Prisma Client API](/orm/prisma-client) inside `getServerSideProps`, `getStaticProps`, API routes, or using API libraries such as [tRPC](https://trpc.io/) and [GraphQL](https://graphql.org/).
+
+### `getServerSideProps`
+
+```ts
+// (in /pages/index.tsx)
+
+// Alternatively, you can use `getStaticProps`
+// in place of `getServerSideProps`.
+export const getServerSideProps = async () => {
+ const feed = await prisma.post.findMany({
+ where: {
+ published: true,
+ },
+ })
+ return { props: { feed } }
+}
+```
+
+Next.js will pass the props to your React component where you can display the data from your database.
+
+### API Routes
+
+```ts
+// Fetch all posts (in /pages/api/posts.ts)
+const prisma = new PrismaClient()
+
+export default async function handle(req, res) {
+ const posts = await prisma.post.findMany({
+ where: {
+ published: true,
+ },
+ })
+ res.json(posts)
+}
+```
+
+Note that you can use Prisma ORM inside of Next.js API routes to send queries to your database – with REST, GraphQL, and tRPC.
+
+You can then fetch data and display it in your frontend.
+
+## Ready-to-run fullstack example projects
+
+You can find several ready-to-run examples that show how to fullstack apps with Prisma Client in the [`prisma-examples`](https://github.com/prisma/prisma-examples/) repository.
+
+| **Example** | **Description** |
+| :----------------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------- |
+| [Next.js](https://pris.ly/e/orm/nextjs) | Fullstack Next.js 15 app |
+| [Next.js (GraphQL)](https://pris.ly/e/ts/graphql-nextjs) | Fullstack Next.js app using GraphQL Yoga, Pothos, & Apollo Client |
+| [Remix](https://pris.ly/e/ts/remix) | Fullstack Remix app using actions and loaders |
+| [SvelteKit](https://pris.ly/e/ts/sveltekit) | Fullstack Sveltekit app using actions and loaders |
+| [Nuxt](https://pris.ly/e/ts/rest-nuxtjs) | Fullstack Nuxt app using API routes |
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/300-prisma-in-your-stack/04-is-prisma-an-orm.mdx b/versioned_docs/version-6.0.0/200-orm/050-overview/300-prisma-in-your-stack/04-is-prisma-an-orm.mdx
new file mode 100644
index 0000000000..9ae264f8c9
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/300-prisma-in-your-stack/04-is-prisma-an-orm.mdx
@@ -0,0 +1,447 @@
+---
+title: 'Is Prisma ORM an ORM?'
+metaTitle: 'Is Prisma ORM an ORM? | What is an ORM?'
+metaDescription: 'Learn about how Prisma ORM implements the Data Mapper ORM pattern and how it achieves the same goal as traditional ORMs without requiring you to map classes to tables as traditional ORMs do.'
+---
+
+
+
+To answer the question briefly: _Yes, Prisma ORM is a new kind of ORM that fundamentally differs from traditional ORMs and doesn't suffer from many of the problems commonly associated with these_.
+
+Traditional ORMs provide an object-oriented way for working with relational databases by mapping tables to _model classes_ in your programming language. This approach leads to many problems that are caused by the [object-relational impedance mismatch](https://en.wikipedia.org/wiki/Object%E2%80%93relational_impedance_mismatch).
+
+Prisma ORM works fundamentally different compared to that. With Prisma ORM, you define your models in the declarative [Prisma schema](/orm/prisma-schema) which serves as the single source of truth for your database schema and the models in your programming language. In your application code, you can then use Prisma Client to read and write data in your database in a type-safe manner without the overhead of managing complex model instances. This makes the process of querying data a lot more natural as well as more predictable since Prisma Client always returns plain JavaScript objects.
+
+In this article, you will learn in more detail about ORM patterns and workflows, how Prisma ORM implements the Data Mapper pattern, and the benefits of Prisma ORM's approach.
+
+
+
+## What are ORMs?
+
+If you're already familiar with ORMs, feel free to jump to the [next section](#prisma-orm) on Prisma ORM.
+
+### ORM Patterns - Active Record and Data Mapper
+
+ORMs provide a high-level database abstraction. They expose a programmatic interface through objects to create, read, delete, and manipulate data while hiding some of the complexity of the database.
+
+The idea with ORMs is that you define your models as **classes** that map to tables in a database. The classes and their instances provide you with a programmatic API to read and write data in the database.
+
+There are two common ORM patterns: [_Active Record_](https://en.wikipedia.org/wiki/Active_record_pattern) and [_Data Mapper_](https://en.wikipedia.org/wiki/Data_mapper_pattern) which differ in how they transfer data between objects and the database. While both patterns require you to define classes as the main building block, the most notable difference between the two is that the Data Mapper pattern decouples in-memory objects in the application code from the database and uses the data mapper layer to transfer data between the two. In practice, this means that with Data Mapper the in-memory objects (representing data in the database) don't even know that there’s a database present.
+
+#### Active Record
+
+_Active Record_ ORMs map model classes to database tables where the structure of the two representations is closely related, e.g. each field in the model class will have a matching column in the database table. Instances of the model classes wrap database rows and carry both the data and the access logic to handle persisting changes in the database. Additionally, model classes can carry business logic specific to the data in the model.
+
+The model class typically has methods that do the following:
+
+- Construct an instance of the model from an SQL query.
+- Construct a new instance for later insertion into the table.
+- Wrap commonly used SQL queries and return Active Record objects.
+- Update the database and insert into it the data in the Active Record.
+- Get and set the fields.
+- Implement business logic.
+
+#### Data Mapper
+
+_Data Mapper_ ORMs, in contrast to Active Record, decouple the application's in-memory representation of data from the database's representation. The decoupling is achieved by requiring you to separate the mapping responsibility into two types of classes:
+
+- **Entity classes**: The application's in-memory representation of entities which have no knowledge of the database
+- **Mapper classes**: These have two responsibilities:
+ - Transforming the data between the two representations.
+ - Generating the SQL necessary to fetch data from the database and persist changes in the database.
+
+Data Mapper ORMs allow for greater flexibility between the problem domain as implemented in code and the database. This is because the data mapper pattern allows you to hide the ways in which your database is implemented which isn’t an ideal way to think about your domain behind the whole data-mapping layer.
+
+One of the reasons that traditional data mapper ORMs do this is due to the structure of organizations where the two responsibilities would be handled by separate teams, e.g., [DBAs](https://en.wikipedia.org/wiki/Database_administrator) and backend developers.
+
+In reality, not all Data Mapper ORMs adhere to this pattern strictly. For example, [TypeORM](https://github.com/typeorm/typeorm), a popular ORM in the TypeScript ecosystem which supports both Active Record and Data Mapper, takes the following approach to Data Mapper:
+
+- Entity classes use decorators (`@Column`) to map class properties to table columns and are aware of the database.
+- Instead of mapper classes, _repository_ classes are used for querying the database and may contain custom queries. Repositories use the decorators to determine the mapping between entity properties and database columns.
+
+Given the following `User` table in the database:
+
+
+
+This is what the corresponding entity class would look like:
+
+```ts
+import { Entity, PrimaryGeneratedColumn, Column } from 'typeorm'
+
+@Entity()
+export class User {
+ @PrimaryGeneratedColumn()
+ id: number
+
+ @Column({ name: 'first_name' })
+ firstName: string
+
+ @Column({ name: 'last_name' })
+ lastName: string
+
+ @Column({ unique: true })
+ email: string
+}
+```
+
+### Schema migration workflows
+
+A central part of developing applications that make use of a database is changing the database schema to accommodate new features and to better fit the problem you're solving. In this section, we'll discuss what [schema migrations](https://www.prisma.io/dataguide/types/relational/what-are-database-migrations) are and how they affect the workflow.
+
+Because the ORM sits between the developer and the database, most ORMs provide a **migration tool** to assist with the creation and modification of the database schema.
+
+A migration is a set of steps to take the database schema from one state to another. The first migration usually creates tables and indices. Subsequent migrations may add or remove columns, introduce new indices, or create new tables. Depending on the migration tool, the migration may be in the form of SQL statements or programmatic code which will get converted to SQL statements (as with [ActiveRecord](https://guides.rubyonrails.org/active_record_migrations.html) and [SQLAlchemy](https://alembic.sqlalchemy.org/en/latest/tutorial.html#create-a-migration-script)).
+
+Because databases usually contain data, migrations assist you with breaking down schema changes into smaller units which helps avoid inadvertent data loss.
+
+Assuming you were starting a project from scratch, this is what a full workflow would look like: you create a migration that will create the `User` table in the database schema and define the `User` entity class as in the example above.
+
+Then, as the project progresses and you decide you want to add a new `salutation` column to the `User` table, you would create another migration which would alter the table and add the `salutation` column.
+
+Let's take a look at how that would look like with a TypeORM migration:
+
+```ts
+import { MigrationInterface, QueryRunner } from 'typeorm'
+
+export class UserRefactoring1604448000 implements MigrationInterface {
+ async up(queryRunner: QueryRunner): Promise {
+ await queryRunner.query(`ALTER TABLE "User" ADD COLUMN "salutation" TEXT`)
+ }
+
+ async down(queryRunner: QueryRunner): Promise {
+ await queryRunner.query(`ALTER TABLE "User" DROP COLUMN "salutation"`)
+ }
+}
+```
+
+Once a migration is carried out and the database schema has been altered, the entity and mapper classes must also be updated to account for the new `salutation` column.
+
+With TypeORM that means adding a `salutation` property to the `User` entity class:
+
+```ts highlight=17,18;normal
+import { Entity, PrimaryGeneratedColumn, Column } from 'typeorm'
+
+@Entity()
+export class User {
+ @PrimaryGeneratedColumn()
+ id: number
+
+ @Column({ name: 'first_name' })
+ firstName: string
+
+ @Column({ name: 'last_name' })
+ lastName: string
+
+ @Column({ unique: true })
+ email: string
+
+ //highlight-start
+ @Column()
+ salutation: string
+ //highlight-end
+}
+```
+
+Synchronizing such changes can be a challenge with ORMs because the changes are applied manually and are not easily verifiable programmatically. Renaming an existing column can be even more cumbersome and involve searching and replacing references to the column.
+
+> **Note:** Django's [makemigrations](https://docs.djangoproject.com/en/3.1/ref/django-admin/#django-admin-makemigrations) CLI generates migrations by inspecting changes in models which, similar to Prisma ORM, does away with the synchronization problem.
+
+In summary, evolving the schema is a key part of building applications. With ORMs, the workflow for updating the schema involves using a migration tool to create a migration followed by updating the corresponding entity and mapper classes (depending on the implementation). As you'll see, Prisma ORM takes a different approach to this.
+
+Now that you've seen what migrations are and how they fit into the development workflows, you will learn more about the benefits and drawbacks of ORMs.
+
+### Benefits of ORMs
+
+There are different reasons why developers choose to use ORMs:
+
+- ORMs facilitate implementing the domain model. The domain model is an object model that incorporates the behavior and data of your business logic. In other words, it allows you to focus on real business concepts rather than the database structure or SQL semantics.
+- ORMs help reduce the amount of code. They save you from writing repetitive SQL statements for common CRUD (Create Read Update Delete) operations and escaping user input to prevent vulnerabilities such as SQL injections.
+- ORMs require you to write little to no SQL (depending on your complexity you may still need to write the odd raw query). This is beneficial for developers who are not familiar with SQL but still want to work with a database.
+- Many ORMs abstract database-specific details. In theory, this means that an ORM can make changing from one database to another easier. It should be noted that in practice applications rarely change the database they use.
+
+As with all abstractions that aim to improve productivity, there are also drawbacks to using ORMs.
+
+### Drawbacks of ORMs
+
+The drawbacks of ORMs are not always apparent when you start using them. This section covers some of the commonly accepted ones:
+
+- With ORMs, you form an object graph representation of database tables which may lead to the [object-relational impedance mismatch](https://en.wikipedia.org/wiki/Object-relational_impedance_mismatch). This happens when the problem you are solving forms a complex object graph which doesn't trivially map to a relational database. Synchronizing between two different representations of data, one in the relational database, and the other in-memory (with objects) is quite difficult. This is because objects are more flexible and varied in the way they can relate to each other compared to relational database records.
+- While ORMs handle the complexity associated with the problem, the synchronization problem doesn't go away. Any changes to the database schema or the data model require the changes to be mapped back to the other side. This burden is often on the developer. In the context of a team working on a project, database schema changes require coordination.
+- ORMs tend to have a large API surface due to the complexity they encapsulate. The flip side of not having to write SQL is that you spend a lot of time learning how to use the ORM. This applies to most abstractions, however without understanding how the database works, improving slow queries can be difficult.
+- Some _complex queries_ aren't supported by ORMs due to the flexibility that SQL offers. This problem is alleviated by raw SQL querying functionality in which you pass the ORM a SQL statement string and the query is run for you.
+
+Now that the costs and benefits of ORMs have been covered, you can better understand what Prisma ORM is and how it fits in.
+
+## Prisma ORM
+
+Prisma ORM is a **next-generation ORM** that makes working with databases easy for application developers and features the following tools:
+
+- [**Prisma Client**](/orm/prisma-client): Auto-generated and type-safe database client for use in your application.
+- [**Prisma Migrate**](/orm/prisma-migrate): A declarative data modeling and migration tool.
+- [**Prisma Studio**](/orm/tools/prisma-studio): A modern GUI for browsing and managing data in your database.
+
+> **Note:** Since Prisma Client is the most prominent tool, we often refer to it as simply Prisma.
+
+These three tools use the [Prisma schema](/orm/prisma-schema) as a single source of truth for the database schema, your application's object schema, and the mapping between the two. It's defined by you and is your main way of configuring Prisma ORM.
+
+Prisma ORM makes you productive and confident in the software you're building with features such as _type safety_, rich auto-completion, and a natural API for fetching relations.
+
+In the next section, you will learn about how Prisma ORM implements the Data Mapper ORM pattern.
+
+### How Prisma ORM implements the Data Mapper pattern
+
+As mentioned earlier in the article, the Data Mapper pattern aligns well with organizations where the database and application are owned by different teams.
+
+With the rise of modern cloud environments with managed database services and DevOps practices, more teams embrace a cross-functional approach, whereby teams own both the full development cycle including the database and operational concerns.
+
+Prisma ORM enables the evolution of the DB schema and object schema in tandem, thereby reducing the need for deviation in the first place, while still allowing you to keep your application and database somewhat decoupled using `@map` attributes. While this may seem like a limitation, it prevents the domain model's evolution (through the object schema) from getting imposed on the database as an afterthought.
+
+To understand how Prisma ORM's implementation of the Data Mapper pattern differs conceptually to traditional Data Mapper ORMs, here's a brief comparison of their concepts and building blocks:
+
+| Concept | Description | Building block in traditional ORMs | Building block in Prisma ORM | Source of truth in Prisma ORM |
+| --------------- | -------------------------------------------------------------------- | ---------------------------------------------- | ------------------------------------ | ------------------------------------ |
+| Object schema | The in-memory data structures in your applications | Model classes | Generated TypeScript types | Models in the Prisma schema |
+| Data Mapper | The code which transforms between the object schema and the database | Mapper classes | Generated functions in Prisma Client | @map attributes in the Prisma schema |
+| Database schema | The structure of data in the database, e.g., tables and columns | SQL written by hand or with a programmatic API | SQL generated by Prisma Migrate | Prisma schema |
+
+Prisma ORM aligns with the Data Mapper pattern with the following added benefits:
+
+- Reducing the boilerplate of defining classes and mapping logic by generating a Prisma Client based on the Prisma schema.
+- Eliminating the synchronization challenges between application objects and the database schema.
+- Database migrations are a first-class citizen as they're derived from the Prisma schema.
+
+Now that we've talked about the concepts behind Prisma ORM's approach to Data Mapper, we can go through how the Prisma schema works in practice.
+
+### Prisma schema
+
+At the heart of Prisma's implementation of the Data Mapper pattern is the _Prisma schema_ – a single source of truth for the following responsibilities:
+
+- Configuring how Prisma connects to your database.
+- Generating Prisma Client – the type-safe ORM for use in your application code.
+- Creating and evolving the database schema with Prisma Migrate.
+- Defining the mapping between application objects and database columns.
+
+Models in Prisma ORM mean something slightly different to Active Record ORMs. With Prisma ORM, models are defined in the Prisma schema as abstract entities which describe tables, relations, and the mappings between columns to properties in Prisma Client.
+
+As an example, here's a Prisma schema for a blog:
+
+```prisma
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+
+generator client {
+ provider = "prisma-client-js"
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ content String? @map("post_content")
+ published Boolean @default(false)
+ author User? @relation(fields: [authorId], references: [id])
+ authorId Int?
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ posts Post[]
+}
+```
+
+Here's a break down of the example above:
+
+- The `datasource` block defines the connection to the database.
+- The `generator` block tells Prisma ORM to generate Prisma Client for TypeScript and Node.js.
+- The `Post` and `User` models map to database tables.
+- The two models have a _1-n_ relation where each `User` can have many related `Post`s.
+- Each field in the models has a type, e.g. the `id` has the type `Int`.
+- Fields may contain field attributes to define:
+ - Primary keys with the `@id` attribute.
+ - Unique keys with the `@unique` attribute.
+ - Default values with the `@default` attribute.
+ - Mapping between table columns and Prisma Client fields with the `@map` attribute, e.g., the `content` field (which will be accessible in Prisma Client) maps to the `post_content` database column.
+
+The `User` / `Post` relation can be visualized with the following diagram:
+
+
+
+At a Prisma ORM level, the `User` / `Post` relation is made up of:
+
+- The scalar `authorId` field, which is referenced by the `@relation` attribute. This field exists in the database table – it is the foreign key that connects Post and User.
+- The two relation fields: `author` and `posts` **do not exist** in the database table. Relation fields define connections between models at the Prisma ORM level and exist only in the Prisma schema and generated Prisma Client, where they are used to access the relations.
+
+The declarative nature of Prisma schema is concise and allows defining the database schema and corresponding representation in Prisma Client.
+
+In the next section, you will learn about Prisma ORM's supported workflows.
+
+### Prisma ORM workflow
+
+The workflow with Prisma ORM is slightly different to traditional ORMs. You can use Prisma ORM when building new applications from scratch or adopt it incrementally:
+
+- _New application_ (greenfield): Projects that have no database schema yet can use Prisma Migrate to create the database schema.
+- _Existing application_ (brownfield): Projects that already have a database schema can be [introspected](/orm/prisma-schema/introspection) by Prisma ORM to generate the Prisma schema and Prisma Client. This use-case works with any existing migration tool and is useful for incremental adoption. It's possible to switch to Prisma Migrate as the migration tool. However, this is optional.
+
+With both workflows, the Prisma schema is the main configuration file.
+
+#### Workflow for incremental adoption in projects with an existing database
+
+Brownfield projects typically already have some database abstraction and schema. Prisma ORM can integrate with such projects by introspecting the existing database to obtain a Prisma schema that reflects the existing database schema and to generate Prisma Client. This workflow is compatible with any migration tool and ORM which you may already be using. If you prefer to incrementally evaluate and adopt, this approach can be used as part of a [parallel adoption strategy](https://en.wikipedia.org/wiki/Parallel_adoption).
+
+A non-exhaustive list of setups compatible with this workflow:
+
+- Projects using plain SQL files with `CREATE TABLE` and `ALTER TABLE` to create and alter the database schema.
+- Projects using a third party migration library like [db-migrate](https://github.com/db-migrate/node-db-migrate) or [Umzug](https://github.com/sequelize/umzug).
+- Projects already using an ORM. In this case, database access through the ORM remains unchanged while the generated Prisma Client can be incrementally adopted.
+
+In practice, these are the steps necessary to introspect an existing DB and generate Prisma Client:
+
+1. Create a `schema.prisma` defining the `datasource` (in this case, your existing DB) and `generator`:
+
+```prisma
+datasource db {
+ provider = "postgresql"
+ url = "postgresql://janedoe:janedoe@localhost:5432/hello-prisma"
+}
+
+generator client {
+ provider = "prisma-client-js"
+}
+```
+
+2. Run `prisma db pull` to populate the Prisma schema with models derived from your database schema.
+3. (Optional) Customize [field and model mappings](/orm/prisma-schema/data-model/models#mapping-model-names-to-tables-or-collections) between Prisma Client and the database.
+4. Run `prisma generate`.
+
+Prisma ORM will generate Prisma Client inside the `node_modules` folder, from which it can be imported in your application. For more extensive usage documentation, see the [Prisma Client API](/orm/prisma-client) docs.
+
+To summarize, Prisma Client can be integrated into projects with an existing database and tooling as part of a parallel adoption strategy. New projects will use a different workflow detailed next.
+
+#### Workflow for new projects
+
+Prisma ORM is different from ORMs in terms of the workflows it supports. A closer look at the steps necessary to create and change a new database schema is useful for understanding Prisma Migrate.
+
+Prisma Migrate is a CLI for declarative data modeling & migrations. Unlike most migration tools that come as part of an ORM, you only need to describe the current schema, instead of the operations to move from one state to another. Prisma Migrate infers the operations, generates the SQL and carries out the migration for you.
+
+This example demonstrates using Prisma ORM in a new project with a new database schema similar to the blog example above:
+
+1. Create the Prisma schema:
+
+```prisma
+// schema.prisma
+datasource db {
+ provider = "postgresql"
+ url = "postgresql://janedoe:janedoe@localhost:5432/hello-prisma"
+}
+
+generator client {
+ provider = "prisma-client-js"
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ content String? @map("post_content")
+ published Boolean @default(false)
+ author User? @relation(fields: [authorId], references: [id])
+ authorId Int?
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ posts Post[]
+}
+```
+
+2. Run `prisma migrate` to generate the SQL for the migration, apply it to the database, and generate Prisma Client.
+
+For any further changes to the database schema:
+
+1. Apply changes to the Prisma schema, e.g., add a `registrationDate` field to the `User` model
+1. Run `prisma migrate` again.
+
+The last step demonstrates how declarative migrations work by adding a field to the Prisma schema and using Prisma Migrate to transform the database schema to the desired state. After the migration is run, Prisma Client is automatically regenerated so that it reflects the updated schema.
+
+If you don't want to use Prisma Migrate but still want to use the type-safe generated Prisma Client in a new project, see the next section.
+
+##### Alternative for new projects without Prisma Migrate
+
+It is possible to use Prisma Client in a new project with a third-party migration tool instead of Prisma Migrate. For example, a new project could choose to use the Node.js migration framework [db-migrate](https://github.com/db-migrate/node-db-migrate) to create the database schema and migrations and Prisma Client for querying. In essence, this is covered by the [workflow for existing databases](#workflow-for-incremental-adoption-in-projects-with-an-existing-database).
+
+## Accessing data with Prisma Client
+
+So far, the article covered the concepts behind Prisma ORM, its implementation of the Data Mapper pattern, and the workflows it supports. In this last section, you will see how to access data in your application using Prisma Client.
+
+Accessing the database with Prisma Client happens through the query methods it exposes. All queries return plain old JavaScript objects. Given the blog schema from above, fetching a user looks as follows:
+
+```ts
+import { PrismaClient } from '@prisma/client'
+
+const prisma = new PrismaClient()
+
+const user = await prisma.user.findUnique({
+ where: {
+ email: 'alice@prisma.io',
+ },
+})
+```
+
+In this query, the `findUnique()` method is used to fetch a single row from the `User` table. By default, Prisma ORM will return all the scalar fields in the `User` table.
+
+> **Note:** The example uses TypeScript to make full use of the type safety features offered by Prisma Client. However, Prisma ORM also works with [JavaScript in Node.js](https://dev.to/prisma/productive-development-with-prisma-s-zero-cost-type-safety-4od2).
+
+Prisma Client maps queries and results to [structural types](https://en.wikipedia.org/wiki/Structural_type_system) by generating code from the Prisma schema. This means that `user` has an associated type in the generated Prisma Client:
+
+```
+export type User = {
+ id: number
+ email: string
+ name: string | null
+}
+```
+
+This ensures that accessing a non-existent field will raise a type error. More broadly, it means that the result's type for every query is known ahead of running the query, which helps catch errors. For example, the following code snippet will raise a type error:
+
+```ts
+console.log(user.lastName) // Property 'lastName' does not exist on type 'User'.
+```
+
+### Fetching relations
+
+Fetch relations with Prisma Client is done with the `include` option. For example, to fetch a user and their posts would be done as follows:
+
+```ts
+const user = await prisma.user.findUnique({
+ where: {
+ email: 'alice@prisma.io',
+ },
+ include: {
+ posts: true,
+ },
+})
+```
+
+With this query, `user`'s type will also include `Post`s which can be accessed with the `posts` array field:
+
+```ts
+console.log(user.posts[0].title)
+```
+
+The example only scratches the surface of Prisma Client's API for [CRUD operations](/orm/prisma-client/queries/crud) which you can learn more about in the docs. The main idea is that all queries and results are backed by types and you have full control over how relations are fetched.
+
+## Conclusion
+
+In summary, Prisma ORM is a new kind of Data Mapper ORM that differs from traditional ORMs and doesn't suffer from the problems commonly associated with them.
+
+Unlike traditional ORMs, with Prisma ORM, you define the Prisma schema – a declarative single source of truth for the database schema and application models. All queries in Prisma Client return plain JavaScript objects which makes the process of interacting with the database a lot more natural as well as more predictable.
+
+Prisma ORM supports two main workflows for starting new projects and adopting in an existing project. For both workflows, your main avenue for configuration is via the Prisma schema.
+
+Like all abstractions, both Prisma ORM and other ORMs hide away some of the underlying details of the database with different assumptions.
+
+These differences and your use case all affect the workflow and cost of adoption. Hopefully understanding how they differ can help you make an informed decision.
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/300-prisma-in-your-stack/index.mdx b/versioned_docs/version-6.0.0/200-orm/050-overview/300-prisma-in-your-stack/index.mdx
new file mode 100644
index 0000000000..8e030cae0b
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/300-prisma-in-your-stack/index.mdx
@@ -0,0 +1,16 @@
+---
+title: 'Prisma ORM in your stack'
+metaTitle: 'How Prisma ORM fits into your stack'
+metaDescription: 'How Prisma ORM fits into your stack'
+hide_table_of_contents: true
+---
+
+
+
+Prisma ORM provides a fully type-safe API and simplified database access. You can use Prisma ORM tools to build a GraphQL or REST API, or as part of a fullstack application - the extent to which you incorporate Prisma ORM is up to you.
+
+
+
+## In this section
+
+
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/200-database-drivers.mdx b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/200-database-drivers.mdx
new file mode 100644
index 0000000000..323f9ca92c
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/200-database-drivers.mdx
@@ -0,0 +1,232 @@
+---
+title: 'Database drivers'
+metaTitle: 'Database drivers'
+metaDescription: 'Learn how Prisma connects to your database using the built-in drivers and how you can use Prisma along with other JavaScript database drivers using driver adapters (Preview)'
+tocDepth: 4
+toc_max_heading_level: 4
+---
+
+## Default built-in drivers
+
+One of Prisma Client's components is the [Query Engine](/orm/more/under-the-hood/engines) (which is implemented in Rust). The Query Engine is responsible for transforming Prisma Client queries into SQL statements. It connects to your database via TCP using built-in drivers that don't require additional setup.
+
+:::note
+
+As of [v6.15.0](https://pris.ly/release/6.16.0), Prisma ORM can be used without Rust engines in production applications. Learn more [here](/orm/prisma-client/setup-and-configuration/no-rust-engine).
+
+**When enabled, your Prisma Client will be generated without a Rust-based query engine binary**:
+
+```prisma
+generator client {
+ provider = "prisma-client-js" // or "prisma-client"
+ output = "../src/generated/prisma"
+ engineType = "client" // no Rust engine
+}
+```
+
+Note that [driver adapters](/orm/overview/databases/database-drivers#driver-adapters) are required if you want to use Prisma ORM without Rust engines.
+
+You can [read about the performance and DX improvements](https://www.prisma.io/blog/prisma-orm-without-rust-latest-performance-benchmarks) of this change on our blog.
+
+:::
+
+
+
+
+## Driver adapters
+
+Prisma Client can connect and run queries against your database using JavaScript database drivers using **driver adapters**. Adapters act as _translators_ between Prisma Client and the JavaScript database driver.
+
+Prisma Client will use the Query Engine to transform the Prisma Client query to SQL and run the generated SQL queries via the JavaScript database driver.
+
+
+
+There are two different types of driver adapters:
+- [Database driver adapters](#database-driver-adapters)
+- [Serverless driver adapters](#serverless-driver-adapters)
+
+> **Note**: Driver adapters enable [edge deployments](/orm/prisma-client/deployment/edge/overview) of applications that use Prisma ORM.
+
+### Database driver adapters
+
+You can connect to your database using a Node.js-based driver from Prisma Client using a database driver adapter. Prisma maintains the adapters for the following drivers:
+
+- PostgreSQL
+ - [`pg`](/orm/overview/databases/postgresql#using-the-node-postgres-driver)
+- MySQL/MariaDB
+ - [`mariadb`](/orm/overview/databases/mysql#using-the-mariadb-driver)
+- SQLite
+ - [`better-sqlite3`](/orm/overview/databases/sqlite#using-the-better-sqlite3-driver)
+ - [`libSQL`](/orm/overview/databases/turso#how-to-connect-and-query-a-turso-database) (Turso)
+- MS SQL Server
+ - [`node-mssql`](/orm/overview/databases/sql-server#using-the-node-mssql-driver)
+
+### Serverless driver adapters
+
+Database providers, such as Neon and PlanetScale, allow you to connect to your database using other protocols besides TCP, such as HTTP and WebSockets. These database drivers are optimized for connecting to your database in serverless and edge environments.
+
+Prisma ORM maintains the following serverless driver adapters:
+- [Neon](/orm/overview/databases/neon#how-to-use-neons-serverless-driver-with-prisma-orm) (and Vercel Postgres)
+- [PlanetScale](/orm/overview/databases/planetscale#how-to-use-the-planetscale-serverless-driver-with-prisma-orm-preview)
+- [Cloudflare D1](/orm/overview/databases/cloudflare-d1)
+
+### Community-maintained database driver adapters
+
+You can also build your own driver adapter for the database you're using. The following is a list of community-maintained driver adapters:
+- [TiDB Cloud Serverless Driver](https://github.com/tidbcloud/prisma-adapter)
+- [PGlite - Postgres in WASM](https://github.com/lucasthevenet/pglite-utils/tree/main/packages/prisma-adapter)
+
+## How to use driver adapters
+
+Refer to the following pages to learn more about how to use the specific driver adapters with the specific database providers:
+- [PostgreSQL](/orm/overview/databases/postgresql#using-the-node-postgres-driver)
+- [MySQL/MariaDB](/orm/overview/databases/mysql#using-the-mariadb-driver)
+- [MS SQL Server](/orm/overview/databases/sql-server#using-the-node-mssql-driver)
+- [Neon](/orm/overview/databases/neon#how-to-use-neons-serverless-driver-with-prisma-orm)
+- [PlanetScale](/orm/overview/databases/planetscale#how-to-use-the-planetscale-serverless-driver-with-prisma-orm-preview)
+- [Turso](/orm/overview/databases/turso#how-to-connect-and-query-a-turso-database)
+- [Cloudflare D1](/orm/overview/databases/cloudflare-d1)
+
+## Notes about using driver adapters
+
+### New driver adapters API in v6.6.0
+
+In [v6.6.0](https://github.com/prisma/prisma/releases/tag/6.6.0), we introduced a simplified version for instantiating Prisma Client when using driver adapters. You now don't need to create an instance of the driver/client to pass to a driver adapter, instead you can just create the driver adapter directly (and pass the driver's options to it if needed).
+
+Here is an example using the `@prisma/adapter-libsql` adapter:
+
+#### Before 6.6.0
+
+Earlier versions of Prisma ORM required you to first instantiate the driver itself, and then use that instance to create the Prisma driver adapter. Here is an example using the `@libsql/client` driver for LibSQL:
+
+```typescript
+import { createClient } from '@libsql/client'
+import { PrismaLibSQL } from '@prisma/adapter-libsql'
+import { PrismaClient } from '@prisma/client'
+
+// Old way of using driver adapters (before 6.6.0)
+const driver = createClient({
+ url: env.LIBSQL_DATABASE_URL,
+ authToken: env.LIBSQL_DATABASE_TOKEN,
+})
+const adapter = new PrismaLibSQL(driver)
+
+const prisma = new PrismaClient({ adapter })
+```
+
+#### 6.6.0 and later
+
+As of the 6.6.0 release, you instantiate the driver adapter _directly_ with the options of your preferred JS-native driver.:
+
+```typescript
+import { PrismaLibSQL } from '@prisma/adapter-libsql'
+import { PrismaClient } from '../prisma/prisma-client'
+
+const adapter = new PrismaLibSQL({
+ url: env.LIBSQL_DATABASE_URL,
+ authToken: env.LIBSQL_DATABASE_TOKEN,
+})
+
+const prisma = new PrismaClient({ adapter })
+```
+
+### Driver adapters don't read the connection string from the Prisma schema
+
+When using Prisma ORM's built-in drivers, the connection string is read from the `url` field of the `datasource` block in your Prisma schema.
+
+On the other hand, when using a driver adapter, the connection string needs to be provided in your _application code_ when the driver adapter is set up initially. Here is how this is done for the `pg` driver and the `@prisma/adapter-pg` adapter:
+
+```ts
+import { PrismaClient } from '@prisma/client'
+import { PrismaPg } from '@prisma/adapter-pg'
+
+const adapter = new PrismaPg({ connectionString: env.DATABASE_URL })
+const prisma = new PrismaClient({ adapter })
+```
+
+See the docs for the driver adapter you're using for concrete setup instructions.
+
+### Driver adapters and custom output paths
+
+Since Prisma 5.9.0, when using the driver adapters Preview feature along with a [custom output path for Prisma Client](/orm/prisma-client/setup-and-configuration/generating-prisma-client#using-a-custom-output-path), you cannot reference Prisma Client using a relative path.
+
+Let's assume you had `output` in your Prisma schema set to `../src/generated/client`:
+
+```prisma
+generator client {
+ provider = "prisma-client-js"
+ output = "../src/generated/client"
+}
+```
+
+What you should _not_ do is reference that path relatively:
+
+```ts no-copy
+// what not to do!
+import { PrismaClient } from './src/generated/client'
+
+const client = new PrismaClient()
+```
+
+Instead, you will need to use a linked dependency.
+
+
+
+
+
+```terminal
+npm add db@./src/generated/client
+```
+
+
+
+
+
+```terminal
+pnpm add db@link:./src/generated/client
+```
+
+
+
+
+
+```terminal
+yarn add db@link:./src/generated/client
+```
+
+
+
+
+
+Now, you should be able to reference your generated client using `db`!
+
+```ts
+import { PrismaClient } from 'db'
+
+const client = new PrismaClient()
+```
+
+### Driver adapters and specific frameworks
+
+#### Nuxt
+
+Using a driver adapter with [Nuxt](https://nuxt.com/) to deploy to an edge function environment does not work out of the box, but adding the `nitro.experimental.wasm` configuration option fixes that:
+
+```ts
+export default defineNuxtConfig({
+ // ...
+ nitro: {
+ // ...
+ experimental: {
+ wasm: true,
+ },
+ },
+ // ...
+})
+```
+
+### Driver adapters and TypedSQL
+
+[TypedSQL](/orm/prisma-client/using-raw-sql/typedsql) lets you write fully type-safe SQL queries that integrate directly with Prisma Client. This feature is useful if you want the flexibility of writing SQL while still benefiting from Prisma's type-safety.
+
+You can also use driver adapters together with TypedSQL to connect through JavaScript database drivers. TypedSQL works with all supported driver adapters except `@prisma/adapter-better-sqlite3`. For SQLite support, use [`@prisma/adapter-libsql`](https://www.npmjs.com/package/@prisma/adapter-libsql) instead.
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/300-postgresql.mdx b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/300-postgresql.mdx
new file mode 100644
index 0000000000..fc4144ba28
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/300-postgresql.mdx
@@ -0,0 +1,295 @@
+---
+title: 'PostgreSQL'
+metaTitle: 'PostgreSQL database connector'
+metaDescription: 'This page explains how Prisma can connect to a PostgreSQL database using the PostgreSQL database connector.'
+---
+
+The PostgreSQL data source connector connects Prisma ORM to a [PostgreSQL](https://www.postgresql.org/) database server.
+
+By default, the PostgreSQL connector contains a database driver responsible for connecting to your database. You can use a [driver adapter](/orm/overview/databases/database-drivers#driver-adapters) (Preview) to connect to your database using a JavaScript database driver from Prisma Client.
+
+:::info
+
+Need a Postgres instance yesterday?
+
+With [Prisma Postgres](https://www.prisma.io/postgres?utm_source=docs&utm_campaign=postgresql) you can get a database running on bare-metal in three clicks. Connection pooling, query caching, and automated backups are all included. [Visit the Console](https://console.prisma.io?utm_source=docs&utm_campaign=postgresql) to get started today.
+
+Want any even faster way to get started with Prisma Postgres? Just run `npx prisma init --db` in your terminal. 🚀
+
+:::
+
+## Example
+
+To connect to a PostgreSQL database server, you need to configure a [`datasource`](/orm/prisma-schema/overview/data-sources) block in your [Prisma schema](/orm/prisma-schema):
+
+```prisma file=schema.prisma
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+```
+
+The fields passed to the `datasource` block are:
+
+- `provider`: Specifies the `postgresql` data source connector.
+- `url`: Specifies the [connection URL](#connection-url) for the PostgreSQL database server. In this case, an [environment variable is used](/orm/prisma-schema/overview#accessing-environment-variables-from-the-schema) to provide the connection URL.
+
+## Using the `node-postgres` driver
+
+As of [`v5.4.0`](https://github.com/prisma/prisma/releases/tag/5.4.0), you can use Prisma ORM with database drivers from the JavaScript ecosystem (instead of using Prisma ORM's built-in drivers). You can do this by using a [driver adapter](/orm/overview/databases/database-drivers).
+
+For PostgreSQL, [`node-postgres`](https://node-postgres.com) (`pg`) is one of the most popular drivers in the JavaScript ecosystem. It can be used with any PostgreSQL database that's accessed via TCP.
+
+This section explains how you can use it with Prisma ORM and the `@prisma/adapter-pg` driver adapter.
+
+### 1. Install the dependencies
+
+First, install Prisma ORM's driver adapter for `pg`:
+
+```terminal
+npm install @prisma/adapter-pg
+```
+
+### 2. Instantiate Prisma Client using the driver adapter
+
+Now, when you instantiate Prisma Client, you need to pass an instance of Prisma ORM's driver adapter to the `PrismaClient` constructor:
+
+```ts
+import { PrismaPg } from '@prisma/adapter-pg'
+import { PrismaClient } from '@prisma/client'
+
+const connectionString = `${process.env.DATABASE_URL}`
+
+const adapter = new PrismaPg({ connectionString });
+const prisma = new PrismaClient({ adapter });
+```
+
+Notice that this code requires the `DATABASE_URL` environment variable to be set to your PostgreSQL connection string. You can learn more about the connection string below.
+
+### Notes
+
+#### Specifying a PostgreSQL schema
+
+You can specify a [PostgreSQL schema](https://www.postgresql.org/docs/current/ddl-schemas.html) by passing in the `schema` option when instantiating `PrismaPg`:
+
+```ts
+const adapter = new PrismaPg(
+ { connectionString },
+ { schema: 'myPostgresSchema' }
+)
+```
+
+## Connection details
+
+### Connection URL
+
+Prisma ORM follows the connection URL format specified by [PostgreSQL's official guidelines](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING), but does not support all arguments and includes additional arguments such as `schema`. Here's an overview of the components needed for a PostgreSQL connection URL:
+
+
+
+#### Base URL and path
+
+Here is an example of the structure of the _base URL_ and the _path_ using placeholder values in uppercase letters:
+
+```
+postgresql://USER:PASSWORD@HOST:PORT/DATABASE
+```
+
+The following components make up the _base URL_ of your database, they are always required:
+
+| Name | Placeholder | Description |
+| :------- | :---------- | :-------------------------------------------------------------------------------------------------------------- |
+| Host | `HOST` | IP address/domain of your database server, e.g. `localhost` |
+| Port | `PORT` | Port on which your database server is running, e.g. `5432` |
+| User | `USER` | Name of your database user, e.g. `janedoe` |
+| Password | `PASSWORD` | Password for your database user |
+| Database | `DATABASE` | Name of the [database](https://www.postgresql.org/docs/12/manage-ag-overview.html) you want to use, e.g. `mydb` |
+
+
+
+You must [percentage-encode special characters](/orm/reference/connection-urls#special-characters).
+
+
+
+#### Arguments
+
+A connection URL can also take arguments. Here is the same example from above with placeholder values in uppercase letters for three _arguments_:
+
+```
+postgresql://USER:PASSWORD@HOST:PORT/DATABASE?KEY1=VALUE&KEY2=VALUE&KEY3=VALUE
+```
+
+The following arguments can be used:
+
+| Argument name | Required | Default | Description |
+| :--------------------- | :------- | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `schema` | **Yes** | `public` | Name of the [schema](https://www.postgresql.org/docs/12/ddl-schemas.html) you want to use, e.g. `myschema` |
+| `connection_limit` | No | `num_cpus * 2 + 1` | Maximum size of the [connection pool](/orm/prisma-client/setup-and-configuration/databases-connections/connection-pool) |
+| `connect_timeout` | No | `5` | Maximum number of seconds to wait for a new connection to be opened, `0` means no timeout |
+| `pool_timeout` | No | `10` | Maximum number of seconds to wait for a new connection from the pool, `0` means no timeout |
+| `sslmode` | No | `prefer` | Configures whether to use TLS. Possible values: `prefer`, `disable`, `require` |
+| `sslcert` | No | | Path of the server certificate. Certificate paths are [resolved relative to the `./prisma folder`](/orm/prisma-schema/overview/data-sources#securing-database-connections) |
+| `sslrootcert` | No | | Path of the root certificate. Certificate paths are [resolved relative to the `./prisma folder`](/orm/prisma-schema/overview/data-sources#securing-database-connections) |
+| `sslidentity` | No | | Path to the PKCS12 certificate |
+| `sslpassword` | No | | Password that was used to secure the PKCS12 file |
+| `sslaccept` | No | `accept_invalid_certs` | Configures whether to check for missing values in the certificate. Possible values: `accept_invalid_certs`, `strict` |
+| `host` | No | | Points to a directory that contains a socket to be used for the connection |
+| `socket_timeout` | No | | Maximum number of seconds to wait until a single query terminates |
+| `pgbouncer` | No | `false` | Configure the Engine to [enable PgBouncer compatibility mode](/orm/prisma-client/setup-and-configuration/databases-connections/pgbouncer) |
+| `statement_cache_size` | No | `100` | Since 2.1.0: Specifies the number of [prepared statements](#prepared-statement-caching) cached per connection |
+| `application_name` | No | | Since 3.3.0: Specifies a value for the application_name configuration parameter |
+| `channel_binding` | No | `prefer` | Since 4.8.0: Specifies a value for the channel_binding configuration parameter |
+| `options` | No | | Since 3.8.0: Specifies command line options to send to the server at connection start |
+
+As an example, if you want to connect to a schema called `myschema`, set the connection pool size to `5` and configure a timeout for queries of `3` seconds. You can use the following arguments:
+
+```
+postgresql://USER:PASSWORD@HOST:PORT/DATABASE?schema=myschema&connection_limit=5&socket_timeout=3
+```
+
+### Configuring an SSL connection
+
+You can add various parameters to the connection URL if your database server uses SSL. Here's an overview of the possible parameters:
+
+- `sslmode=(disable|prefer|require)`:
+ - `prefer` (default): Prefer TLS if possible, accept plain text connections.
+ - `disable`: Do not use TLS.
+ - `require`: Require TLS or fail if not possible.
+- `sslcert=`: Path to the server certificate. This is the root certificate used by the database server to sign the client certificate. You need to provide this if the certificate doesn't exist in the trusted certificate store of your system. For Google Cloud this likely is `server-ca.pem`. Certificate paths are [resolved relative to the `./prisma folder`](/orm/prisma-schema/overview/data-sources#securing-database-connections)
+- `sslidentity=`: Path to the PKCS12 certificate database created from client cert and key. This is the SSL identity file in PKCS12 format which you will generate using the client key and client certificate. It combines these two files in a single file and secures them via a password (see next parameter). You can create this file using your client key and client certificate by using the following command (using `openssl`):
+ ```
+ openssl pkcs12 -export -out client-identity.p12 -inkey client-key.pem -in client-cert.pem
+ ```
+- `sslpassword=`: Password that was used to secure the PKCS12 file. The `openssl` command listed in the previous step will ask for a password while creating the PKCS12 file, you will need to provide that same exact password here.
+- `sslaccept=(strict|accept_invalid_certs)`:
+ - `strict`: Any missing value in the certificate will lead to an error. For Google Cloud, especially if the database doesn't have a domain name, the certificate might miss the domain/IP address, causing an error when connecting.
+ - `accept_invalid_certs` (default): Bypass this check. Be aware of the security consequences of this setting.
+
+Your database connection URL will look similar to this:
+
+```
+postgresql://USER:PASSWORD@HOST:PORT/DATABASE?sslidentity=client-identity.p12&sslpassword=mypassword&sslcert=rootca.cert
+```
+
+### Connecting via sockets
+
+To connect to your PostgreSQL database via sockets, you must add a `host` field as a _query parameter_ to the connection URL (instead of setting it as the `host` part of the URI).
+The value of this parameter then must point to the directory that contains the socket, e.g.: `postgresql://USER:PASSWORD@localhost/database?host=/var/run/postgresql/`
+
+Note that `localhost` is required, the value itself is ignored and can be anything.
+
+> **Note**: You can find additional context in this [GitHub issue](https://github.com/prisma/prisma-client-js/issues/437#issuecomment-592436707).
+
+## Type mapping between PostgreSQL and Prisma schema
+
+These two tables show the type mapping between PostgreSQL and Prisma schema. First [how Prisma ORM scalar types are translated into PostgreSQL database column types](#mapping-between-prisma-orm-scalar-types-and-postgresql-database-column-types), and then [how PostgreSQL database column types relate to Prisma ORM scalar and native types](#mapping-between-postgresql-database-column-types-to-prisma-orm-scalar-and-native-types).
+
+> Alternatively, see [Prisma schema reference](/orm/reference/prisma-schema-reference#model-field-scalar-types) for type mappings organized by Prisma type.
+
+### Mapping between Prisma ORM scalar types and PostgreSQL database column types
+
+The PostgreSQL connector maps the [scalar types](/orm/prisma-schema/data-model/models#scalar-fields) from the Prisma ORM [data model](/orm/prisma-schema/data-model/models) as follows to database column types:
+
+| Prisma ORM | PostgreSQL |
+| ---------- | ------------------ |
+| `String` | `text` |
+| `Boolean` | `boolean` |
+| `Int` | `integer` |
+| `BigInt` | `bigint` |
+| `Float` | `double precision` |
+| `Decimal` | `decimal(65,30)` |
+| `DateTime` | `timestamp(3)` |
+| `Json` | `jsonb` |
+| `Bytes` | `bytea` |
+
+### Mapping between PostgreSQL database column types to Prisma ORM scalar and native types
+
+- When [introspecting](/orm/prisma-schema/introspection) a PostgreSQL database, the database types are mapped to Prisma ORM types according to the following table.
+- When [creating a migration](/orm/prisma-migrate) or [prototyping your schema](/orm/prisma-migrate/workflows/prototyping-your-schema) the table is also used - in the other direction.
+
+| PostgreSQL (Type \| Aliases) | Supported | Prisma ORM | Native database type attribute | Notes |
+| ------------------------------------------- | :-------: | ------------- | :--------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `bigint` \| `int8` | ✔️ | `BigInt` | `@db.BigInt`\* | \*Default mapping for `BigInt` - no type attribute added to schema. |
+| `boolean` \| `bool` | ✔️ | `Bool` | `@db.Boolean`\* | \*Default mapping for `Bool` - no type attribute added to schema. |
+| `timestamp with time zone` \| `timestamptz` | ✔️ | `DateTime` | `@db.Timestamptz(x)` |
+| `time without time zone` \| `time` | ✔️ | `DateTime` | `@db.Time(x)` |
+| `time with time zone` \| `timetz` | ✔️ | `DateTime` | `@db.Timetz(x)` |
+| `numeric(p,s)` \| `decimal(p,s)` | ✔️ | `Decimal` | `@db.Decimal(x, y)` |
+| `real` \| `float`, `float4` | ✔️ | `Float` | `@db.Real` |
+| `double precision` \| `float8` | ✔️ | `Float` | `@db.DoublePrecision`\* | \*Default mapping for `Float` - no type attribute added to schema. |
+| `smallint` \| `int2` | ✔️ | `Int` | `@db.SmallInt` | |
+| `integer` \| `int`, `int4` | ✔️ | `Int` | `@db.Int`\* | \*Default mapping for `Int` - no type attribute added to schema. |
+| `smallserial` \| `serial2` | ✔️ | `Int` | `@db.SmallInt @default(autoincrement())` |
+| `serial` \| `serial4` | ✔️ | `Int` | `@db.Int @default(autoincrement())` |
+| `bigserial` \| `serial8` | ✔️ | `Int` | `@db.BigInt @default(autoincrement()` |
+| `character(n)` \| `char(n)` | ✔️ | `String` | `@db.Char(x)` |
+| `character varying(n)` \| `varchar(n)` | ✔️ | `String` | `@db.VarChar(x)` |
+| `money` | ✔️ | `Decimal` | `@db.Money` |
+| `text` | ✔️ | `String` | `@db.Text`\* | \*Default mapping for `String` - no type attribute added to schema. |
+| `timestamp` | ✔️ | `DateTime` | `@db.TimeStamp`\* | \*Default mapping for `DateTime` - no type attribute added to schema. |
+| `date` | ✔️ | `DateTime` | `@db.Date` |
+| `enum` | ✔️ | `Enum` | N/A |
+| `inet` | ✔️ | `String` | `@db.Inet` |
+| `bit(n)` | ✔️ | `String` | `@Bit(x)` |
+| `bit varying(n)` | ✔️ | `String` | `@VarBit` |
+| `oid` | ✔️ | `Int` | `@db.Oid` |
+| `uuid` | ✔️ | `String` | `@db.Uuid` |
+| `json` | ✔️ | `Json` | `@db.Json` |
+| `jsonb` | ✔️ | `Json` | `@db.JsonB`\* | \*Default mapping for `Json` - no type attribute added to schema. |
+| `bytea` | ✔️ | `Bytes` | `@db.ByteA`\* | \*Default mapping for `Bytes` - no type attribute added to schema. |
+| `xml` | ✔️ | `String` | `@db.Xml` |
+| Array types | ✔️ | `[]` |
+| `citext` | ✔️\* | `String` | `@db.Citext` | \* Only available if [Citext extension is enabled](/orm/prisma-schema/data-model/unsupported-database-features#enable-postgresql-extensions-for-native-database-functions). |
+| `interval` | Not yet | `Unsupported` | | |
+| `cidr` | Not yet | `Unsupported` | | |
+| `macaddr` | Not yet | `Unsupported` | | |
+| `tsvector` | Not yet | `Unsupported` | | |
+| `tsquery` | Not yet | `Unsupported` | | |
+| `int4range` | Not yet | `Unsupported` | | |
+| `int8range` | Not yet | `Unsupported` | | |
+| `numrange` | Not yet | `Unsupported` | | |
+| `tsrange` | Not yet | `Unsupported` | | |
+| `tstzrange` | Not yet | `Unsupported` | | |
+| `daterange` | Not yet | `Unsupported` | | |
+| `point` | Not yet | `Unsupported` | | |
+| `line` | Not yet | `Unsupported` | | |
+| `lseg` | Not yet | `Unsupported` | | |
+| `box` | Not yet | `Unsupported` | | |
+| `path` | Not yet | `Unsupported` | | |
+| `polygon` | Not yet | `Unsupported` | | |
+| `circle` | Not yet | `Unsupported` | | |
+| Composite types | Not yet | n/a | | |
+| Domain types | Not yet | n/a | | |
+
+[Introspection](/orm/prisma-schema/introspection) adds native database types that are **not yet supported** as [`Unsupported`](/orm/reference/prisma-schema-reference#unsupported) fields:
+
+```prisma file=schema.prisma
+model Device {
+ id Int @id @default(autoincrement())
+ name String
+ data Unsupported("circle")
+}
+```
+
+## Prepared statement caching
+
+A [prepared statement](https://www.postgresql.org/docs/current/sql-prepare.html) is a feature that can be used to optimize performance. A prepared statement is parsed, compiled, and optimized only once and then can be executed directly multiple times without the overhead of parsing the query again.
+
+By caching prepared statements, Prisma Client's [query engine](/orm/more/under-the-hood/engines) does not repeatedly compile the same query which reduces database CPU usage and query latency.
+
+For example, here is the generated SQL for two different queries made by Prisma Client:
+
+```sql
+SELECT * FROM user WHERE name = "John";
+SELECT * FROM user WHERE name = "Brenda";
+```
+
+The two queries after parameterization will be the same, and the second query can skip the preparing step, saving database CPU and one extra roundtrip to the database. Query after parameterization:
+
+```sql
+SELECT * FROM user WHERE name = $1
+```
+
+Every database connection maintained by Prisma Client has a separate cache for storing prepared statements. The size of this cache can be tweaked with the `statement_cache_size` parameter in the connection string. By default, Prisma Client caches `100` statements per connection.
+
+Due to the nature of pgBouncer, if the `pgbouncer` parameter is set to `true`, the prepared statement cache is automatically disabled for that connection.
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/400-mysql.mdx b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/400-mysql.mdx
new file mode 100644
index 0000000000..d9b7033275
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/400-mysql.mdx
@@ -0,0 +1,263 @@
+---
+title: 'MySQL/MariaDB'
+metaTitle: 'MySQL database connector'
+metaDescription: 'This page explains how Prisma can connect to a MySQL or MariaDB database using the MySQL database connector.'
+tocDepth: 3
+---
+
+The MySQL data source connector connects Prisma ORM to a [MySQL](https://www.mysql.com/) or [MariaDB](https://mariadb.org/) database server.
+
+By default, the MySQL connector contains a database driver responsible for connecting to your database. You can use a [driver adapter](/orm/overview/databases/database-drivers#driver-adapters) (Preview) to connect to your database using a JavaScript database driver from Prisma Client.
+
+## Example
+
+To connect to a MySQL database server, you need to configure a [`datasource`](/orm/prisma-schema/overview/data-sources) block in your [Prisma schema](/orm/prisma-schema):
+
+```prisma file=schema.prisma showLineNumbers
+datasource db {
+ provider = "mysql"
+ url = env("DATABASE_URL")
+}
+```
+
+The fields passed to the `datasource` block are:
+
+- `provider`: Specifies the `mysql` data source connector, which is used both for MySQL and MariaDB.
+- `url`: Specifies the [connection URL](#connection-url) for the MySQL database server. In this case, an [environment variable is used](/orm/prisma-schema/overview#accessing-environment-variables-from-the-schema) to provide the connection URL.
+
+## Using the `mariadb` driver
+
+As of [`v5.4.0`](https://github.com/prisma/prisma/releases/tag/5.4.0), you can use Prisma ORM with database drivers from the JavaScript ecosystem (instead of using Prisma ORM's built-in drivers). You can do this by using a [driver adapter](/orm/overview/databases/database-drivers).
+
+For MySQL and MariaDB, [`mariadb`](https://github.com/mariadb-corporation/mariadb-connector-nodejs) is one of the most popular drivers in the JavaScript ecosystem.
+
+This section explains how you can use it with Prisma ORM and the `@prisma/adapter-mariadb` driver adapter.
+
+### 1. Install the dependencies
+
+First, install Prisma ORM's driver adapter for `mariadb`:
+
+```terminal
+npm install @prisma/adapter-mariadb
+```
+
+### 2. Instantiate Prisma Client using the driver adapter
+
+Now, when you instantiate Prisma Client, you need to pass an instance of Prisma ORM's driver adapter to the `PrismaClient` constructor:
+
+```ts
+import { PrismaMariaDb } from '@prisma/adapter-mariadb';
+import { PrismaClient } from './generated/prisma';
+
+const adapter = new PrismaMariaDb({
+ host: "localhost",
+ port: 3306,
+ connectionLimit: 5
+});
+const prisma = new PrismaClient({ adapter });
+```
+
+## Connection details
+
+### Connection URL
+
+Here's an overview of the components needed for a MySQL connection URL:
+
+
+
+#### Base URL and path
+
+Here is an example of the structure of the _base URL_ and the _path_ using placeholder values in uppercase letters:
+
+```
+mysql://USER:PASSWORD@HOST:PORT/DATABASE
+```
+
+The following components make up the _base URL_ of your database, they are always required:
+
+| Name | Placeholder | Description |
+| :------- | :---------- | :------------------------------------------------------------------------------------------------------------------ |
+| Host | `HOST` | IP address/domain of your database server, e.g. `localhost` |
+| Port | `PORT` | Port on which your database server is running, e.g. `5432` (default is `3306`, or no port when using Unix socket) |
+| User | `USER` | Name of your database user, e.g. `janedoe` |
+| Password | `PASSWORD` | Password for your database user |
+| Database | `DATABASE` | Name of the [database](https://dev.mysql.com/doc/refman/8.0/en/creating-database.html) you want to use, e.g. `mydb` |
+
+
+
+You must [percentage-encode special characters](/orm/reference/connection-urls#special-characters).
+
+
+
+#### Arguments
+
+A connection URL can also take arguments. Here is the same example from above with placeholder values in uppercase letters for three _arguments_:
+
+```
+mysql://USER:PASSWORD@HOST:PORT/DATABASE?KEY1=VALUE&KEY2=VALUE&KEY3=VALUE
+```
+
+The following arguments can be used:
+
+| Argument name | Required | Default | Description |
+| :----------------- | :------- | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `connection_limit` | No | `num_cpus * 2 + 1` | Maximum size of the [connection pool](/orm/prisma-client/setup-and-configuration/databases-connections/connection-pool) |
+| `connect_timeout` | No | `5` | Maximum number of seconds to wait for a new connection to be opened, `0` means no timeout |
+| `pool_timeout` | No | `10` | Maximum number of seconds to wait for a new connection from the pool, `0` means no timeout |
+| `sslcert` | No | | Path to the server certificate. Certificate paths are [resolved relative to the `./prisma folder`](/orm/prisma-schema/overview/data-sources#securing-database-connections) |
+| `sslidentity` | No | | Path to the PKCS12 certificate |
+| `sslpassword` | No | | Password that was used to secure the PKCS12 file |
+| `sslaccept` | No | `accept_invalid_certs` | Configures whether to check for missing values in the certificate. Possible values: `accept_invalid_certs`, `strict` |
+| `socket` | No | | Points to a directory that contains a socket to be used for the connection |
+| `socket_timeout` | No | | Number of seconds to wait until a single query terminates |
+
+As an example, if you want to set the connection pool size to `5` and configure a timeout for queries of `3` seconds, you can use the following arguments:
+
+```
+mysql://USER:PASSWORD@HOST:PORT/DATABASE?connection_limit=5&socket_timeout=3
+```
+
+### Configuring an SSL connection
+
+You can add various parameters to the connection URL if your database server uses SSL. Here's an overview of the possible parameters:
+
+- `sslcert=`: Path to the server certificate. This is the root certificate used by the database server to sign the client certificate. You need to provide this if the certificate doesn't exist in the trusted certificate store of your system. For Google Cloud this likely is `server-ca.pem`. Certificate paths are [resolved relative to the `./prisma folder`](/orm/prisma-schema/overview/data-sources#securing-database-connections)
+
+- `sslidentity=`: Path to the PKCS12 certificate database created from client cert and key. This is the SSL identity file in PKCS12 format which you will generate using the client key and client certificate. It combines these two files in a single file and secures them via a password (see next parameter). You can create this file using your client key and client certificate by using the following command (using `openssl`):
+ ```
+ openssl pkcs12 -export -out client-identity.p12 -inkey client-key.pem -in client-cert.pem
+ ```
+- `sslpassword=`: Password that was used to secure the PKCS12 file. The `openssl` command listed in the previous step will ask for a password while creating the PKCS12 file, you will need to provide that same exact password here.
+- `sslaccept=(strict|accept_invalid_certs)`:
+ - `strict`: Any missing value in the certificate will lead to an error. For Google Cloud, especially if the database doesn't have a domain name, the certificate might miss the domain/IP address, causing an error when connecting.
+ - `accept_invalid_certs` (default): Bypass this check. Be aware of the security consequences of this setting.
+
+Your database connection URL will look similar to this:
+
+```
+mysql://USER:PASSWORD@HOST:PORT/DATABASE?sslidentity=client-identity.p12&sslpassword=mypassword&sslcert=rootca.cert
+```
+
+### Connecting via sockets
+
+To connect to your MySQL/MariaDB database via a socket, you must add a `socket` field as a _query parameter_ to the connection URL (instead of setting it as the `host` part of the URI).
+The value of this parameter then must point to the directory that contains the socket, e.g. on a default installation of MySQL/MariaDB on Ubuntu or Debian use: `mysql://USER:PASSWORD@HOST/DATABASE?socket=/run/mysqld/mysqld.sock`
+
+Note that `localhost` is required, the value itself is ignored and can be anything.
+
+> **Note**: You can find additional context in this [GitHub issue](https://github.com/prisma/prisma-client-js/issues/437#issuecomment-592436707).
+
+## Type mapping between MySQL to Prisma schema
+
+The MySQL connector maps the [scalar types](/orm/prisma-schema/data-model/models#scalar-fields) from the Prisma ORM [data model](/orm/prisma-schema/data-model/models) as follows to native column types:
+
+> Alternatively, see [Prisma schema reference](/orm/reference/prisma-schema-reference#model-field-scalar-types) for type mappings organized by Prisma ORM type.
+
+### Native type mapping from Prisma ORM to MySQL
+
+| Prisma ORM | MySQL | Notes |
+| ---------- | ---------------- | ------------------------------------------------------------------------------------- |
+| `String` | `VARCHAR(191)` | |
+| `Boolean` | `BOOLEAN` | In MySQL `BOOLEAN` is a synonym for `TINYINT(1)` |
+| `Int` | `INT` | |
+| `BigInt` | `BIGINT` | |
+| `Float` | `DOUBLE` | |
+| `Decimal` | `DECIMAL(65,30)` | |
+| `DateTime` | `DATETIME(3)` | Currently, Prisma ORM does not support zero dates (`0000-00-00`, `00:00:00`) in MySQL |
+| `Json` | `JSON` | Supported in MySQL 5.7+ only |
+| `Bytes` | `LONGBLOB` | |
+
+### Native type mapping from Prisma ORM to MariaDB
+
+| Prisma ORM | MariaDB | Notes |
+| ---------- | ---------------- | -------------------------------------------------- |
+| `String` | `VARCHAR(191)` | |
+| `Boolean` | `BOOLEAN` | In MariaDB `BOOLEAN` is a synonym for `TINYINT(1)` |
+| `Int` | `INT` | |
+| `BigInt` | `BIGINT` | |
+| `Float` | `DOUBLE` | |
+| `Decimal` | `DECIMAL(65,30)` | |
+| `DateTime` | `DATETIME(3)` | |
+| `Json` | `LONGTEXT` | See https://mariadb.com/kb/en/json-data-type/ |
+| `Bytes` | `LONGBLOB` | |
+
+### Native type mappings
+
+When introspecting a MySQL database, the database types are mapped to Prisma ORM according to the following table:
+
+| MySQL | Prisma ORM | Supported | Native database type attribute | Notes |
+| ------------------------- | ------------- | --------- | ---------------------------------------------- | ------------------------------------------------------------------ |
+| `serial` | `BigInt` | ✔️ | `@db.UnsignedBigInt @default(autoincrement())` |
+| `bigint` | `BigInt` | ✔️ | `@db.BigInt` |
+| `bigint unsigned` | `BigInt` | ✔️ | `@db.UnsignedBigInt` |
+| `bit` | `Bytes` | ✔️ | `@db.Bit(x)` | `bit(1)` maps to `Boolean` - all other `bit(x)` map to `Bytes` |
+| `boolean` \| `tinyint(1)` | `Boolean` | ✔️ | `@db.TinyInt(1)` |
+| `varbinary` | `Bytes` | ✔️ | `@db.VarBinary` |
+| `longblob` | `Bytes` | ✔️ | `@db.LongBlob` |
+| `tinyblob` | `Bytes` | ✔️ | `@db.TinyBlob` |
+| `mediumblob` | `Bytes` | ✔️ | `@db.MediumBlob` |
+| `blob` | `Bytes` | ✔️ | `@db.Blob` |
+| `binary` | `Bytes` | ✔️ | `@db.Binary` |
+| `date` | `DateTime` | ✔️ | `@db.Date` |
+| `datetime` | `DateTime` | ✔️ | `@db.DateTime` |
+| `timestamp` | `DateTime` | ✔️ | `@db.TimeStamp` |
+| `time` | `DateTime` | ✔️ | `@db.Time` |
+| `decimal(a,b)` | `Decimal` | ✔️ | `@db.Decimal(x,y)` |
+| `numeric(a,b)` | `Decimal` | ✔️ | `@db.Decimal(x,y)` |
+| `enum` | `Enum` | ✔️ | N/A |
+| `float` | `Float` | ✔️ | `@db.Float` |
+| `double` | `Float` | ✔️ | `@db.Double` |
+| `smallint` | `Int` | ✔️ | `@db.SmallInt` |
+| `smallint unsigned` | `Int` | ✔️ | `@db.UnsignedSmallInt` |
+| `mediumint` | `Int` | ✔️ | `@db.MediumInt` |
+| `mediumint unsigned` | `Int` | ✔️ | `@db.UnsignedMediumInt` |
+| `int` | `Int` | ✔️ | `@db.Int` |
+| `int unsigned` | `Int` | ✔️ | `@db.UnsignedInt` |
+| `tinyint` | `Int` | ✔️ | `@db.TinyInt(x)` | `tinyint(1)` maps to `Boolean` all other `tinyint(x)` map to `Int` |
+| `tinyint unsigned` | `Int` | ✔️ | `@db.UnsignedTinyInt(x)` | `tinyint(1) unsigned` **does not** map to `Boolean` |
+| `year` | `Int` | ✔️ | `@db.Year` |
+| `json` | `Json` | ✔️ | `@db.Json` | Supported in MySQL 5.7+ only |
+| `char` | `String` | ✔️ | `@db.Char(x)` |
+| `varchar` | `String` | ✔️ | `@db.VarChar(x)` |
+| `tinytext` | `String` | ✔️ | `@db.TinyText` |
+| `text` | `String` | ✔️ | `@db.Text` |
+| `mediumtext` | `String` | ✔️ | `@db.MediumText` |
+| `longtext` | `String` | ✔️ | `@db.LongText` |
+| `set` | `Unsupported` | Not yet | |
+| `geometry` | `Unsupported` | Not yet | |
+| `point` | `Unsupported` | Not yet | |
+| `linestring` | `Unsupported` | Not yet | |
+| `polygon` | `Unsupported` | Not yet | |
+| `multipoint` | `Unsupported` | Not yet | |
+| `multilinestring` | `Unsupported` | Not yet | |
+| `multipolygon` | `Unsupported` | Not yet | |
+| `geometrycollection` | `Unsupported` | Not yet | |
+
+[Introspection](/orm/prisma-schema/introspection) adds native database types that are **not yet supported** as [`Unsupported`](/orm/reference/prisma-schema-reference#unsupported) fields:
+
+```prisma file=schema.prisma showLineNumbers
+model Device {
+ id Int @id @default(autoincrement())
+ name String
+ data Unsupported("circle")
+}
+```
+
+## Engine
+
+If you are using a version of MySQL where MyISAM is the default engine, you must specify `ENGINE = InnoDB;` when you create a table. If you introspect a database that uses a different engine, relations in the Prisma Schema are not created (or lost, if the relation already existed).
+
+## Permissions
+
+A fresh new installation of MySQL/MariaDB has by default only a `root` database user. Do not use `root` user in your Prisma configuration, but instead create a database and database user for each application. On most Linux hosts (e.g. Ubuntu) you can simply run this as the Linux `root` user (which automatically has database `root` access as well):
+
+```
+mysql -e "CREATE DATABASE IF NOT EXISTS $DB_PRISMA;"
+mysql -e "GRANT ALL PRIVILEGES ON $DB_PRISMA.* TO $DB_USER@'%' IDENTIFIED BY '$DB_PASSWORD';"
+```
+
+The above is enough to run the `prisma db pull` and `prisma db push` commands. In order to also run `prisma migrate` commands these permissions need to be granted:
+
+```
+mysql -e "GRANT CREATE, DROP, REFERENCES, ALTER ON *.* TO $DB_USER@'%';"
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/500-sqlite.mdx b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/500-sqlite.mdx
new file mode 100644
index 0000000000..db904f7aa8
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/500-sqlite.mdx
@@ -0,0 +1,166 @@
+---
+title: 'SQLite'
+metaTitle: 'SQLite database connector'
+metaDescription: 'This page explains how Prisma can connect to a SQLite database using the SQLite database connector.'
+tocDepth: 3
+---
+
+The SQLite data source connector connects Prisma ORM to a [SQLite](https://www.sqlite.org/) database file. These files always have the file ending `.db` (e.g.: `dev.db`).
+
+By default, the SQLite connector contains a database driver responsible for connecting to your database. You can use a [driver adapter](/orm/overview/databases/database-drivers#driver-adapters) (Preview) to connect to your database using a JavaScript database driver from Prisma Client.
+
+## Example
+
+To connect to a SQLite database file, you need to configure a [`datasource`](/orm/prisma-schema/overview/data-sources) block in your [Prisma schema](/orm/prisma-schema):
+
+```prisma file=schema.prisma
+datasource db {
+ provider = "sqlite"
+ url = "file:./dev.db"
+}
+```
+
+The fields passed to the `datasource` block are:
+
+- `provider`: Specifies the `sqlite` data source connector.
+- `url`: Specifies the [connection URL](/orm/reference/connection-urls) for the SQLite database. The connection URL always starts with the prefix `file:` and then contains a file path pointing to the SQLite database file. In this case, the file is located in the same directory and called `dev.db`.
+
+## Using the `better-sqlite3` driver
+
+As of [`v5.4.0`](https://github.com/prisma/prisma/releases/tag/5.4.0), you can use Prisma ORM with database drivers from the JavaScript ecosystem (instead of using Prisma ORM's built-in drivers). You can do this by using a [driver adapter](/orm/overview/databases/database-drivers).
+
+For SQLite, [`better-sqlite3`](https://github.com/WiseLibs/better-sqlite3) is one of the most popular drivers in the JavaScript ecosystem.
+
+This section explains how you can use it with Prisma ORM and the `@prisma/adapter-better-sqlite3` driver adapter.
+
+### 1. Install the dependencies
+
+First, install Prisma ORM's driver adapter for `better-sqlite3`:
+
+```terminal
+npm install @prisma/adapter-better-sqlite3
+```
+
+### 2. Instantiate Prisma Client using the driver adapter
+
+Now, when you instantiate Prisma Client, you need to pass an instance of Prisma ORM's driver adapter to the `PrismaClient` constructor:
+
+```ts
+import { PrismaBetterSQLite3 } from '@prisma/adapter-better-sqlite3';
+import { PrismaClient } from './generated/prisma';
+
+const adapter = new PrismaBetterSQLite3({
+ url: "file:./prisma/dev.db"
+});
+const prisma = new PrismaClient({ adapter });
+```
+
+### 3. Configure timestamp format for backward compatibility
+
+When using driver adapters with SQLite, you can configure how `DateTime` values are stored in the database using the `timestampFormat` option.
+
+By default, driver adapters store `DateTime` values as **ISO 8601 strings**, which is the most convenient format for SQLite since SQLite date/time functions expect ISO 8601 by default.
+
+However, if you need **100% backward compatibility** with Prisma ORM's native SQLite driver (for example, when migrating an existing database), you should use the `unixepoch-ms` format, which stores timestamps as the number of milliseconds since the Unix epoch:
+
+```ts
+import { PrismaBetterSQLite3 } from '@prisma/adapter-better-sqlite3';
+import { PrismaClient } from './generated/prisma';
+
+const adapter = new PrismaBetterSQLite3({
+ url: "file:./prisma/dev.db"
+}, {
+ timestampFormat: 'unixepoch-ms'
+});
+const prisma = new PrismaClient({ adapter });
+```
+
+:::info
+
+The `timestampFormat` option is available for both `@prisma/adapter-better-sqlite3` and `@prisma/adapter-libsql` driver adapters.
+
+:::
+
+**When to use each format:**
+
+- **ISO 8601 (default)**: Best for new projects and integrates well with SQLite's built-in date/time functions.
+- **`unixepoch-ms`**: Required when migrating from Prisma ORM's native SQLite driver to maintain compatibility with existing timestamp data.
+
+## Type mapping between SQLite to Prisma schema
+
+The SQLite connector maps the [scalar types](/orm/prisma-schema/data-model/models#scalar-fields) from the [data model](/orm/prisma-schema/data-model/models) to native column types as follows:
+
+> Alternatively, see [Prisma schema reference](/orm/reference/prisma-schema-reference#model-field-scalar-types) for type mappings organized by Prisma ORM type.
+
+### Native type mapping from Prisma ORM to SQLite
+
+| Prisma ORM | SQLite |
+| ---------- | ------------- |
+| `String` | `TEXT` |
+| `Boolean` | `BOOLEAN` |
+| `Int` | `INTEGER` |
+| `BigInt` | `INTEGER` |
+| `Float` | `REAL` |
+| `Decimal` | `DECIMAL` |
+| `DateTime` | `NUMERIC` |
+| `Json` | `JSONB` |
+| `Bytes` | `BLOB` |
+| `Enum` | `TEXT` |
+
+:::note
+
+SQLite doesn't have a dedicated Boolean type. While this table shows `BOOLEAN`, columns are assigned a **NUMERIC affinity** (storing `0` for false and `1` for true). [Learn more](https://www.sqlite.org/datatype3.html#boolean).
+
+:::
+
+:::warning
+
+When using `enum` fields in SQLite, be aware of the following:
+
+- **No database-level enforcement for correctness**: If you bypass Prisma ORM and store an invalid enum entry in the database, Prisma Client queries will fail at runtime when reading that entry.
+- **No migration-level enforcement for correctness**: It's possible to end up with incorrect data after schema changes similarly to MongoDB (since the enums aren't checked by the database).
+
+:::
+
+## Rounding errors on big numbers
+
+SQLite is a loosely-typed database. If your Schema has a field of type `Int`, then Prisma ORM prevents you from inserting a value larger than an integer. However, nothing prevents the database from directly accepting a bigger number. These manually-inserted big numbers cause rounding errors when queried.
+
+To avoid this problem, Prisma ORM 4.0.0 and later checks numbers on the way out of the database to verify that they fit within the boundaries of an integer. If a number does not fit, then Prisma ORM throws a P2023 error, such as:
+
+```
+Inconsistent column data: Conversion failed:
+Value 9223372036854775807 does not fit in an INT column,
+try migrating the 'int' column type to BIGINT
+```
+
+## Connection details
+
+### Connection URL
+
+The connection URL of a SQLite connector points to a file on your file system. For example, the following two paths are equivalent because the `.db` is in the same directory:
+
+```prisma file=schema.prisma
+datasource db {
+ provider = "sqlite"
+ url = "file:./dev.db"
+}
+```
+
+is the same as:
+
+```prisma file=schema.prisma
+datasource db {
+ provider = "sqlite"
+ url = "file:dev.db"
+}
+```
+
+You can also target files from the root or any other place in your file system:
+
+```prisma file=schema.prisma
+datasource db {
+ provider = "sqlite"
+ url = "file:/Users/janedoe/dev.db"
+}
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/600-mongodb.mdx b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/600-mongodb.mdx
new file mode 100644
index 0000000000..58a8213cae
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/600-mongodb.mdx
@@ -0,0 +1,592 @@
+---
+title: 'Prisma ORM MongoDB database connector'
+sidebar_label: 'MongoDB'
+metaTitle: 'MongoDB database connector'
+metaDescription: 'How Prisma can connect to a MongoDB database using the MongoDB database connector.'
+hidePage: false
+tocDepth: 3
+codeStyle: false
+---
+
+
+
+This guide discusses the concepts behind using Prisma ORM and MongoDB, explains the commonalities and differences between MongoDB and other database providers, and leads you through the process for configuring your application to integrate with MongoDB using Prisma ORM.
+
+
+
+To connect Prisma ORM with MongoDB, refer to our [Getting Started documentation](/getting-started/setup-prisma/start-from-scratch/mongodb-typescript-mongodb).
+
+
+
+
+
+## What is MongoDB?
+
+[MongoDB](https://www.mongodb.com/) is a NoSQL database that stores data in [BSON](https://bsonspec.org/) format, a JSON-like document format designed for storing data in key-value pairs. It is commonly used in JavaScript application development because the document model maps easily to objects in application code, and there is built in support for high availability and horizontal scaling.
+
+MongoDB stores data in collections that do not need a schema to be defined in advance, as you would need to do with tables in a relational database. The structure of each collection can also be changed over time. This flexibility can allow rapid iteration of your data model, but it does mean that there are a number of differences when using Prisma ORM to work with your MongoDB database.
+
+## Commonalities with other database providers
+
+Some aspects of using Prisma ORM with MongoDB are the same as when using Prisma ORM with a relational database. You can still:
+
+- model your database with the [Prisma Schema Language](/orm/prisma-schema)
+- connect to your database, using the [`mongodb` database connector](/orm/overview/databases)
+- use [Introspection](/orm/prisma-schema/introspection) for existing projects if you already have a MongoDB database
+- use [`db push`](/orm/prisma-migrate/workflows/prototyping-your-schema) to push changes in your schema to the database
+- use [Prisma Client](/orm/prisma-client) in your application to query your database in a type safe way based on your Prisma Schema
+
+## Differences to consider
+
+MongoDB's document-based structure and flexible schema means that using Prisma ORM with MongoDB differs from using it with a relational database in a number of ways. These are some areas where there are differences that you need to be aware of:
+
+- **Defining IDs**: MongoDB documents have an `_id` field (that often contains an [ObjectID](https://www.mongodb.com/docs/manual/reference/bson-types/#std-label-objectid)). Prisma ORM does not support fields starting with `_`, so this needs to be mapped to a Prisma ORM field using the `@map` attribute. For more information, see [Defining IDs in MongoDB](/orm/prisma-schema/data-model/models#defining-ids-in-mongodb).
+
+- **Migrating existing data to match your Prisma schema**: In relational databases, all your data must match your schema. If you change the type of a particular field in your schema when you migrate, all the data must also be updated to match. In contrast, MongoDB does not enforce any particular schema, so you need to take care when migrating. For more information, see [How to migrate old data to new schemas](#how-to-migrate-existing-data-to-match-your-prisma-schema).
+
+- **Introspection and Prisma ORM relations**: When you introspect an existing MongoDB database, you will get a schema with no relations and will need to add the missing relations in manually. For more information, see [How to add in missing relations after Introspection](#how-to-add-in-missing-relations-after-introspection).
+
+- **Filtering for `null` and missing fields**: MongoDB makes a distinction between setting a field to `null` and not setting it at all, which is not present in relational databases. Prisma ORM currently does not express this distinction, which means that you need to be careful when filtering for `null` and missing fields. For more information, see [How to filter for `null` and missing fields](#how-to-filter-for-null-and-missing-fields)
+
+- **Enabling replication**: Prisma ORM uses [MongoDB transactions](https://www.mongodb.com/docs/manual/core/transactions/) internally to avoid partial writes on nested queries. When using transactions, MongoDB requires replication of your data set to be enabled. To do this, you will need to configure a [replica set](https://www.mongodb.com/docs/manual/replication/) — this is a group of MongoDB processes that maintain the same data set. Note that it is still possible to use a single database, by creating a replica set with only one node in it. If you use MongoDB's [Atlas](https://www.mongodb.com/atlas/database) hosting service, the replica set is configured for you, but if you are running MongoDB locally you will need to set up a replica set yourself. For more information, see MongoDB's [guide to deploying a replica set](https://www.mongodb.com/docs/manual/tutorial/deploy-replica-set/).
+
+### Performance considerations for large collections
+#### Problem
+When working with large MongoDB collections through Prisma, certain operations can become slow and resource-intensive. In particular, operations that require scanning the entire collection, such as `count()`, can hit query execution time limits and significantly impact performance as your dataset grows.
+
+#### Solution
+To address performance issues with large MongoDB collections, consider the following approaches:
+
+1. For large collections, consider using MongoDB's `estimatedDocumentCount()` instead of `count()`. This method is much faster as it uses metadata about the collection. You can use Prisma's `runCommandRaw` method to execute this command.
+
+2. For frequently accessed counts, consider implementing a counter cache. This involves maintaining a separate document with pre-calculated counts that you update whenever documents are added or removed.
+
+
+## How to use Prisma ORM with MongoDB
+
+This section provides instructions for how to carry out tasks that require steps specific to MongoDB.
+
+### How to migrate existing data to match your Prisma schema
+
+Migrating your database over time is an important part of the development cycle. During development, you will need to update your Prisma schema (for example, to add new fields), then update the data in your development environment’s database, and eventually push both the updated schema and the new data to the production database.
+
+
+
+When using MongoDB, be aware that the “coupling” between your schema and the database is purposefully designed to be less rigid than with SQL databases; MongoDB will not enforce the schema, so you have to verify data integrity.
+
+
+
+These iterative tasks of updating the schema and the database can result in inconsistencies between your schema and the actual data in the database. Let’s look at one scenario where this can happen, and then examine several strategies for you and your team to consider for handling these inconsistencies.
+
+**Scenario**: you need to include a phone number for users, as well as an email. You currently have the following `User` model in your `schema.prisma` file:
+
+```prisma file=prisma/schema.prisma showLineNumbers
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ email String
+}
+```
+
+There are a number of strategies you could use for migrating this schema:
+
+- **"On-demand" updates**: with this strategy, you and your team have agreed that updates can be made to the schema as needed. However, in order to avoid migration failures due to inconsistencies between the data and schema, there is agreement in the team that any new fields added are explicitly defined as optional.
+
+ In our scenario above, you can add an optional `phoneNumber` field to the `User` model in your Prisma schema:
+
+ ```prisma file=prisma/schema.prisma highlight=4;add showLineNumbers
+ model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ email String
+ //add-next-line
+ phoneNumber String?
+ }
+ ```
+
+ Then regenerate your Prisma Client using the `npx prisma generate` command.
+
+ Next, update your application to reflect the new field, and redeploy your app.
+
+ As the `phoneNumber` field is optional, you can still query the old users where the phone number has not been defined. The records in the database will be updated "on demand" as the application's users begin to enter their phone number in the new field.
+
+ Another option is to add a default value on a required field, for example:
+
+ ```prisma file=prisma/schema.prisma highlight=4;add showLineNumbers
+ model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ email String
+ //add-next-line
+ phoneNumber String @default("000-000-0000")
+ }
+ ```
+
+ Then when you encounter a missing `phoneNumber`, the value will be coerced into `000-000-0000`.
+
+- **"No breaking changes" updates**: this strategy builds on the first one, with further consensus amongst your team that you don't rename or delete fields, only add new fields, and always define the new fields as optional. This policy can be reinforced by adding checks in the CI/CD process to verify that there are no backwards-incompatible changes to the schema.
+
+- **"All-at-once" updates**: this strategy is similar to traditional migrations in relational databases, where all data is updated to reflect the new schema. In the scenario above, you would create a script to add a value for the phone number field to all existing users in your database. You can then make the field a required field in the application because the schema and the data are consistent.
+
+### How to add in missing relations after Introspection
+
+After introspecting an existing MongoDB database, you will need to manually add in relations between models. MongoDB does not have the concept of defining relations via foreign keys, as you would in a relational database. However, if you have a collection in MongoDB with a "foreign-key-like" field that matches the ID field of another collection, Prisma ORM will allow you to emulate relations between the collections.
+
+As an example, take a MongoDB database with two collections, `User` and `Post`. The data in these collections has the following format, with a `userId` field linking users to posts:
+
+`User` collection:
+
+- `_id` field with a type of `objectId`
+- `email` field with a type of `string`
+
+`Post` collection:
+
+- `_id` field with a type of `objectId`
+- `title` field with a type of `string`
+- `userId` with a type of `objectID`
+
+On introspection with `db pull`, this is pulled in to the Prisma Schema as follows:
+
+```prisma file=prisma/schema.prisma showLineNumbers
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ title String
+ userId String @db.ObjectId
+}
+
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ email String
+}
+```
+
+This is missing the relation between the `User` and `Post` models. To fix this, manually add a `user` field to the `Post` model with a `@relation` attribute using `userId` as the `fields` value, linking it to the `User` model, and a `posts` field to the `User` model as the back relation:
+
+```prisma file=prisma/schema.prisma highlight=5;add|11;add showLineNumbers
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ title String
+ userId String @db.ObjectId
+ //add-next-line
+ user User @relation(fields: [userId], references: [id])
+}
+
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ email String
+ //add-next-line
+ posts Post[]
+}
+```
+
+For more information on how to use relations in Prisma ORM, see [our documentation](/orm/prisma-schema/data-model/relations).
+
+### How to filter for `null` and missing fields
+
+To understand how MongoDB distinguishes between `null` and missing fields, consider the example of a `User` model with an optional `name` field:
+
+```ts
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ email String
+ name String?
+}
+```
+
+First, try creating a record with the `name` field explicitly set to `null`. Prisma ORM will return `name: null` as expected:
+
+
+
+
+
+```ts
+const createNull = await prisma.user.create({
+ data: {
+ email: 'user1@prisma.io',
+ name: null,
+ },
+})
+console.log(createNull)
+```
+
+
+
+
+
+```code no-copy
+{
+ id: '6242c4ae032bc76da250b207',
+ email: 'user1@prisma.io',
+ name: null
+}
+```
+
+
+
+
+
+If you check your MongoDB database directly, you will also see a new record with `name` set to `null`:
+
+```json
+{
+ "_id": "6242c4af032bc76da250b207",
+ "email": "user1@prisma.io",
+ "name": null
+}
+```
+
+Next, try creating a record without explicitly setting the `name` field:
+
+
+
+
+
+```ts
+const createMissing = await prisma.user.create({
+ data: {
+ email: 'user2@prisma.io',
+ },
+})
+console.log(createMissing)
+```
+
+
+
+
+
+```code no-copy
+{
+ id: '6242c4ae032bc76da250b208',
+ email: 'user2@prisma.io',
+ name: null
+}
+```
+
+
+
+
+
+Prisma ORM still returns `name: null`, but if you look in the database directly you will see that the record has no `name` field defined at all:
+
+```json
+{
+ "_id": "6242c4af032bc76da250b208",
+ "email": "user2@prisma.io"
+}
+```
+
+Prisma ORM returns the same result in both cases, because we currently don't have a way to specify this difference in MongoDB between fields that are `null` in the underlying database, and fields that are not defined at all — see [this Github issue](https://github.com/prisma/prisma/issues/12555) for more information.
+
+This means that you currently have to be careful when filtering for `null` and missing fields. Filtering for records with `name: null` will only return the first record, with the `name` explicitly set to `null`:
+
+
+
+
+
+```ts
+const findNulls = await prisma.user.findMany({
+ where: {
+ name: null,
+ },
+})
+console.log(findNulls)
+```
+
+
+
+
+
+```terminal no-copy
+[
+ {
+ id: '6242c4ae032bc76da250b207',
+ email: 'user1@prisma.io',
+ name: null
+ }
+]
+```
+
+
+
+
+
+This is because `name: null` is checking for equality, and a non-existing field isn't equal to `null`.
+
+To include missing fields as well, use the [`isSet` filter](/6.0/orm/reference/prisma-client-reference#isset) to explicitly search for fields which are either `null` or not set. This will return both records:
+
+
+
+
+
+```ts
+const findNullOrMissing = await prisma.user.findMany({
+ where: {
+ OR: [
+ {
+ name: null,
+ },
+ {
+ name: {
+ isSet: false,
+ },
+ },
+ ],
+ },
+})
+console.log(findNullOrMissing)
+```
+
+
+
+
+
+```terminal no-copy
+[
+ {
+ id: '6242c4ae032bc76da250b207',
+ email: 'user1@prisma.io',
+ name: null
+ },
+ {
+ id: '6242c4ae032bc76da250b208',
+ email: 'user2@prisma.io',
+ name: null
+ }
+]
+```
+
+
+
+
+
+## More on using MongoDB with Prisma ORM
+
+The fastest way to start using MongoDB with Prisma ORM is to refer to our Getting Started documentation:
+
+- [Start from scratch](/getting-started/setup-prisma/start-from-scratch/mongodb-typescript-mongodb)
+- [Add to existing project](/getting-started/setup-prisma/add-to-existing-project/mongodb-typescript-mongodb)
+
+These tutorials will take you through the process of connecting to MongoDB, pushing schema changes, and using Prisma Client.
+
+Further reference information is available in the [MongoDB connector documentation](/orm/overview/databases/mongodb).
+
+For more information on how to set up and manage a MongoDB database, see the [Prisma Data Guide](https://www.prisma.io/dataguide#mongodb).
+
+## Example
+
+To connect to a MongoDB server, configure the [`datasource`](/orm/prisma-schema/overview/data-sources) block in your [Prisma Schema](/orm/prisma-schema):
+
+```prisma file=schema.prisma showLineNumbers
+datasource db {
+ provider = "mongodb"
+ url = env("DATABASE_URL")
+}
+```
+
+The fields passed to the `datasource` block are:
+
+- `provider`: Specifies the `mongodb` data source connector.
+- `url`: Specifies the [connection URL](#connection-url) for the MongoDB server. In this case, an [environment variable is used](/orm/more/development-environment/environment-variables) to provide the connection URL.
+
+
+
+The MongoDB database connector uses transactions to support nested writes. Transactions **require** a [replica set](https://www.mongodb.com/docs/manual/tutorial/deploy-replica-set/) deployment. The easiest way to deploy a replica set is with [Atlas](https://www.mongodb.com/docs/atlas/getting-started/). It's free to get started.
+
+
+
+## Connection details
+
+### Connection URL
+
+The MongoDB connection URL can be configured in different ways depending on how you are hosting your database. The standard configuration is made up of the following components:
+
+
+
+#### Base URL and path
+
+The base URL and path sections of the connection URL are made up of your authentication credentials followed by the host (and optionally, a port number) and database.
+
+```
+mongodb://USERNAME:PASSWORD@HOST/DATABASE
+```
+
+The following components make up the _base URL_ of your database:
+
+| Name | Placeholder | Description |
+| :------- | :---------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| User | `USERNAME` | Name of your database user, e.g. `janedoe` |
+| Password | `PASSWORD` | Password for your database user |
+| Host | `HOST` | The host where a [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod/#mongodb-binary-bin.mongod) instance is running. If you are running a sharded cluster this will a [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos/#mongodb-binary-bin.mongos) instance. This can be a hostname, IP address or UNIX domain socket. |
+| Port | `PORT` | Port on which your database server is running, e.g. `1234`. If none is provided the default `27017` is used. |
+| Database | `DATABASE` | Name of the database to use. If none is specified but the `authSource` option is set then the `authSource` database name is used. If neither the database in the connection string nor the `authSource` option is specified then it defaults to `admin` |
+
+
+
+You must [percentage-encode special characters](/orm/reference/connection-urls#special-characters).
+
+
+
+#### Arguments
+
+A connection URL can also take arguments. The following example sets three arguments:
+
+- An `ssl` connection
+- A `connectTimeoutMS`
+- And the `maxPoolSize`
+
+```
+mongodb://USERNAME:PASSWORD@HOST/DATABASE?ssl=true&connectTimeoutMS=5000&maxPoolSize=50
+```
+
+Refer to the [MongoDB connection string documentation](https://www.mongodb.com/docs/manual/reference/connection-string/) for a complete list of connection string arguments. There are no Prisma ORM-specific arguments.
+
+## Using `ObjectId`
+
+It is common practice for the `_id` field of a MongoDB document to contain an [ObjectId](https://www.mongodb.com/docs/manual/reference/bson-types/#std-label-objectid):
+
+```json
+{
+ "_id": { "$oid": "60d599cb001ef98000f2cad2" },
+ "createdAt": { "$date": { "$numberLong": "1624611275577" } },
+ "email": "ella@prisma.io",
+ "name": "Ella",
+ "role": "ADMIN"
+}
+```
+
+Any field (most commonly IDs and relation scalar fields) that maps to an `ObjectId` in the underlying database:
+
+- Must be of type `String` or `Bytes`
+- Must include the `@db.ObjectId` attribute
+- Can optionally use `@default(auto())` to auto-generate a valid `ObjectId` on document creation
+
+Here is an example that uses `String`:
+
+```prisma
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ // Other fields
+}
+```
+
+And here is another example that uses `Bytes`:
+
+```prisma
+model User {
+ id Bytes @id @default(auto()) @map("_id") @db.ObjectId
+ // Other fields
+}
+```
+
+See also: [Defining ID fields in MongoDB](/orm/prisma-schema/data-model/models#defining-ids-in-mongodb)
+
+### Generating `ObjectId`
+
+To generate a valid `ObjectId` (for testing purposes or to manually set an ID field value) in your application, use the [`bson`](https://www.npmjs.com/package/bson) package.
+
+```
+npm install --save bson
+```
+
+```ts
+import { ObjectId } from 'bson'
+
+const id = new ObjectId()
+```
+
+## Differences to connectors for relational databases
+
+This section covers ways in which the MongoDB connector differs from Prisma ORM connectors for relational databases.
+
+### No support for Prisma Migrate
+
+Currently, there are no plans to add support for [Prisma Migrate](/orm/prisma-migrate) as MongoDB projects do not rely on internal schemas where changes need to be managed with an extra tool. Management of `@unique` indexes is realized through `db push`.
+
+### No support for `@@id` and `autoincrement()`
+
+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-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
+
+If you have cyclic references in your models, either from self-relations or a cycle of relations between models, and you use [referential actions](/orm/prisma-schema/data-model/relations/referential-actions), you must set a referential action of `NoAction` to prevent an infinite loop of actions.
+
+See [Special rules for referential actions](/orm/prisma-schema/data-model/relations/referential-actions/special-rules-for-referential-actions) for more details.
+
+### Replica set configuration
+
+MongoDB only allows you to start a transaction on a replica set. Prisma ORM uses transactions internally to avoid partial writes on nested queries. This means we inherit the requirement of needing a replica set configured.
+
+When you try to use Prisma ORM's MongoDB connector on a deployment that has no replica set configured, Prisma ORM shows the message `Error: Transactions are not supported by this deployment`. The full text of the error message is the following:
+
+```
+PrismaClientUnknownRequestError2 [PrismaClientUnknownRequestError]:
+Invalid `prisma.post.create()` invocation in
+/index.ts:9:21
+
+ 6 await prisma.$connect()
+ 7
+ 8 // Create the first post
+→ 9 await prisma.post.create(
+ Error in connector: Database error. error code: unknown, error message: Transactions are not supported by this deployment
+ at cb (/node_modules/@prisma/client/runtime/index.js:34804:17)
+ at processTicksAndRejections (internal/process/task_queues.js:97:5) {
+ clientVersion: '3.xx.0'
+}
+```
+
+To resolve this, we suggest you change your deployment to one with a replica set configured.
+
+One simple way for this is to use [MongoDB Atlas](https://www.mongodb.com/cloud/atlas) to launch a free instance that has replica set support out of the box.
+
+There's also an option to run the replica set locally with this guide: https://www.mongodb.com/docs/manual/tutorial/convert-standalone-to-replica-set
+
+## Type mapping between MongoDB and the Prisma schema
+
+The MongoDB connector maps the [scalar types](/orm/prisma-schema/data-model/models#scalar-fields) from the Prisma ORM [data model](/orm/prisma-schema/data-model/models) to MongoDB's native column types as follows:
+
+> Alternatively, see [Prisma schema reference](/orm/reference/prisma-schema-reference#model-field-scalar-types) for type mappings organized by Prisma type.
+
+### Native type mapping from Prisma ORM to MongoDB
+
+| Prisma ORM | MongoDB |
+| ---------- | ---------------------------------------------------------------------- |
+| `String` | `string` |
+| `Boolean` | `bool` |
+| `Int` | `int` |
+| `BigInt` | `long` |
+| `Float` | `double` |
+| `Decimal` | [Currently unsupported](https://github.com/prisma/prisma/issues/12637) |
+| `DateTime` | `timestamp` |
+| `Bytes` | `binData` |
+| `Json` | |
+
+MongoDB types that are currently unsupported:
+
+- `Decimal128`
+- `Undefined`
+- `DBPointer`
+- `Null`
+- `Symbol`
+- `MinKey`
+- `MaxKey`
+- `Object`
+- `Javascript`
+- `JavascriptWithScope`
+- `Regex`
+
+### Mapping from MongoDB to Prisma ORM types on Introspection
+
+When introspecting a MongoDB database, Prisma ORM uses the relevant [scalar types](/orm/prisma-schema/data-model/models#scalar-fields). Some special types also get additional native type annotations:
+
+| MongoDB (Type \| Aliases) | Prisma ORM | Supported | Native database type attribute | Notes |
+| ------------------------- | ---------- | :-------: | :----------------------------- | :---- |
+| `objectId` | `String` | ✔️ | `@db.ObjectId` | |
+
+[Introspection](/orm/prisma-schema/introspection) adds native database types that are **not yet supported** as [`Unsupported`](/orm/reference/prisma-schema-reference#unsupported) fields:
+
+```prisma file=schema.prisma showLineNumbers
+model Example {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ name String
+ regex Unsupported("RegularExpression")
+}
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/800-sql-server/020-sql-server-local.mdx b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/800-sql-server/020-sql-server-local.mdx
new file mode 100644
index 0000000000..67ee63f3f5
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/800-sql-server/020-sql-server-local.mdx
@@ -0,0 +1,53 @@
+---
+title: 'SQL Server on Windows (local)'
+metaTitle: 'SQL Server on Windows'
+metaDescription: 'Set up and configure SQL Server on Windows.'
+---
+
+
+
+To run a Microsoft SQL Server locally on a Windows machine:
+
+1. If you do not have access to an instance of Microsoft SQL Server, download and set up [SQL Server 2019 Developer](https://www.microsoft.com/en-us/sql-server/sql-server-downloads).
+
+1. Download and install [SQL Server Management Studio](https://learn.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms?view=sql-server-ver15).
+
+1. Use Windows Authentication to log in to Microsoft SQL Server Management Studio (expand the **Server Name** dropdown and click **<Browse for more...>** to find your database engine):
+
+
+
+
+
+## Enable TCP/IP
+
+Prisma Client requires TCP/IP to be enabled. To enable TCP/IP:
+
+1. Open SQL Server Configuration Manager. (Search for "SQL Server Configuration Manager" in the Start Menu, or open the Start Menu and type "SQL Server Configuration Manager".)
+
+1. In the left-hand panel, click **SQL Server Network Configuration** > **Protocols for MSSQLSERVER**
+
+1. Right-click **TCP/IP** and choose **Enable**.
+
+## Enable authentication with SQL logins (Optional)
+
+If you want to use a username and password in your connection URL rather than integrated security, [enable mixed authentication mode](https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/change-server-authentication-mode?view=sql-server-ver15&tabs=ssms) as follows:
+
+1. Right-click on your database engine in the Object Explorer and click **Properties**.
+
+1. In the Server Properties window, click **Security** in the left-hand list and tick the **SQL Server and Windows Authentication Mode** option, then click **OK**.
+
+1. Right-click on your database engine in the Object Explorer and click **Restart**.
+
+### Enable the `sa` login
+
+To enable the default `sa` (administrator) SQL Server login:
+
+1. In SQL Server Management Studio, in the Object Explorer, expand **Security** > **Logins** and double-click **sa**.
+
+1. On the **General** page, choose a password for the `sa` account (untick **Enforce password policy** if you do not want to enforce a policy).
+
+1. On the **Status** page, under **Settings** > **Login**, tick **Enabled**, then click **OK**.
+
+You can now use the `sa` account in a connection URL and when you log in to SQL Server Management Studio.
+
+> **Note**: The `sa` user has extensive permissions. You can also [create your own login with fewer permissions](https://learn.microsoft.com/en-us/sql/relational-databases/security/authentication-access/create-a-login?view=sql-server-ver15).
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/800-sql-server/030-sql-server-docker.mdx b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/800-sql-server/030-sql-server-docker.mdx
new file mode 100644
index 0000000000..95c0f96a89
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/800-sql-server/030-sql-server-docker.mdx
@@ -0,0 +1,49 @@
+---
+title: 'SQL Server on Docker'
+metaTitle: 'SQL Server on Docker'
+metaDescription: 'Download and use the Microsoft SQL Server Docker image.'
+---
+
+
+
+To run a Microsoft SQL Server container image with Docker:
+
+1. Install and set up [Docker](https://docs.docker.com/get-started/get-docker/)
+1. Run the following command in your terminal to download the Microsoft SQL Server 2019 image:
+
+ ```terminal
+ docker pull mcr.microsoft.com/mssql/server:2019-latest
+ ```
+
+1. Create an instance of the container image, replacing the value of `SA_PASSWORD` with a password of your choice:
+
+ ```terminal wrap
+ docker run --name sql_container -e 'ACCEPT_EULA=Y' -e 'SA_PASSWORD=myPassword' -p 1433:1433 -d mcr.microsoft.com/mssql/server:2019-latest
+ ```
+
+1. [Follow Microsoft's instructions to connect to SQL Server and use the `sqlcmd` tool](https://learn.microsoft.com/en-us/sql/linux/quickstart-install-connect-docker?view=sql-server-ver15&pivots=cs1-cmd&tabs=cli#connect-to-sql-server), replacing the image name and password with your own.
+
+1. From the `sqlcmd` command prompt, create a new database:
+
+ ```terminal
+ CREATE DATABASE quickstart
+ GO
+ ```
+
+1. Run the following command to check that your database was created successfully:
+
+ ```terminal
+ sp_databases
+ GO
+ ```
+
+
+
+## Connection URL credentials
+
+Based on this example, your credentials are:
+
+- **Username**: sa
+- **Password**: myPassword
+- **Database**: quickstart
+- **Port**: 1433
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/800-sql-server/index.mdx b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/800-sql-server/index.mdx
new file mode 100644
index 0000000000..b118b92b32
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/800-sql-server/index.mdx
@@ -0,0 +1,247 @@
+---
+title: 'Microsoft SQL Server'
+metaTitle: 'Microsoft SQL Server'
+metaDescription: 'This page explains how Prisma can connect to a Microsoft SQL Server database using the Microsoft SQL Server database connector.'
+tocDepth: 4
+toc_max_heading_level: 4
+---
+
+The Microsoft SQL Server data source connector connects Prisma ORM to a [Microsoft SQL Server](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver15) database server.
+
+## Example
+
+To connect to a Microsoft SQL Server database, you need to configure a [`datasource`](/orm/prisma-schema/overview/data-sources) block in your [Prisma schema](/orm/prisma-schema):
+
+```prisma file=schema.prisma showLineNumbers
+datasource db {
+ provider = "sqlserver"
+ url = env("DATABASE_URL")
+}
+```
+
+The fields passed to the `datasource` block are:
+
+- `provider`: Specifies the `sqlserver` data source connector.
+- `url`: Specifies the [connection URL](#connection-details) for the Microsoft SQL Server database. In this case, an [environment variable is used](/orm/prisma-schema/overview#accessing-environment-variables-from-the-schema) to provide the connection URL.
+
+
+## Using the `node-mssql` driver
+
+As of [`v5.4.0`](https://github.com/prisma/prisma/releases/tag/5.4.0), you can use Prisma ORM with database drivers from the JavaScript ecosystem (instead of using Prisma ORM's built-in drivers). You can do this by using a [driver adapter](/orm/overview/databases/database-drivers).
+
+For SQLite, [`node-mssql`](https://github.com/tediousjs/node-mssql) is one of the most popular drivers in the JavaScript ecosystem.
+
+This section explains how you can use it with Prisma ORM and the `@prisma/adapter-mssql` driver adapter.
+
+### 1. Install the dependencies
+
+First, install Prisma ORM's driver adapter for `node-mssql`:
+
+```terminal
+npm install @prisma/adapter-mssql
+```
+
+### 2. Instantiate Prisma Client using the driver adapter
+
+Now, when you instantiate Prisma Client, you need to pass an instance of Prisma ORM's driver adapter to the `PrismaClient` constructor:
+
+```ts
+import { PrismaMssql } from '@prisma/adapter-mssql'
+import { PrismaClient } from '@prisma/client'
+
+const config = {
+ server: 'localhost',
+ port: 1433,
+ database: 'mydb',
+ user: 'sa',
+ password: 'mypassword',
+ options: {
+ encrypt: true, // Use this if you're on Windows Azure
+ trustServerCertificate: true, // Use this if you're using self-signed certificates
+ },
+}
+
+const adapter = new PrismaMssql(config)
+const prisma = new PrismaClient({ adapter })
+```
+
+## Connection details
+
+The connection URL used to connect to an Microsoft SQL Server database follows the [JDBC standard](https://learn.microsoft.com/en-us/sql/connect/jdbc/building-the-connection-url?view=sql-server-ver15).
+
+The following example uses SQL authentication (username and password) with an enabled TLS encrypted connection:
+
+```
+sqlserver://HOST[:PORT];database=DATABASE;user=USER;password=PASSWORD;encrypt=true
+```
+
+
+
+Note: If you are using any of the following characters in your connection string, [you will need to escape them](https://learn.microsoft.com/en-us/sql/connect/jdbc/building-the-connection-url?view=sql-server-ver16#escaping-values-in-the-connection-url).
+
+```terminal
+:\=;/[]{} # these are characters that will need to be escaped
+```
+
+To escape these characters, use curly braces `{}` around values that contain special characters. As an example:
+
+```terminal
+sqlserver://HOST[:PORT];database=DATABASE;user={MyServer/MyUser};password={ThisIsA:SecurePassword;};encrypt=true
+```
+
+
+
+### Arguments
+
+| Argument name | Required | Default | Comments |
+| :------------------------------------------------------------------------------------ | :---------------- | :----------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|
`database`
`initial catalog`
| No | `master` | The database to connect to. |
+|
`username`
`user`
`uid`
`userid`
| No - see Comments | | SQL Server login (such as `sa`) _or_ a valid Windows (Active Directory) username if `integratedSecurity` is set to `true` (Windows only). |
+|
`password`
`pwd`
| No - see Comments | | Password for SQL Server login _or_ Windows (Active Directory) username if `integratedSecurity` is set to `true` (Windows only). |
+| `encrypt` | No | `true` | Configures whether to use TLS all the time, or only for the login procedure, possible values: `true` (use always), `false` (only for login credentials). |
+| `integratedSecurity` | No | | Enables [Windows authentication (integrated security)](https://learn.microsoft.com/en-us/previous-versions/dotnet/framework/data/adonet/sql/authentication-in-sql-server), possible values: `true`, `false`, `yes`, `no`. If set to `true` or `yes` and `username` and `password` are present, login is performed through Windows Active Directory. If login details are not given via separate arguments, the current logged in Windows user is used to login to the server. |
+| `connectionLimit` | No | `num_cpus * 2 + 1` | Maximum size of the [connection pool](/orm/prisma-client/setup-and-configuration/databases-connections/connection-pool) |
+| `connectTimeout` | No | `5` | Maximum number of seconds to wait for a new connection |
+| `schema` | No | `dbo` | Added as a prefix to all the queries if schema name is not the default. |
+|
`loginTimeout`
`connectTimeout`
`connectionTimeout`
| No | | Number of seconds to wait for login to succeed. |
+| `socketTimeout` | No | | Number of seconds to wait for each query to succeed. |
+| `isolationLevel` | No | | Sets [transaction isolation level](https://learn.microsoft.com/en-us/sql/t-sql/statements/set-transaction-isolation-level-transact-sql?view=sql-server-ver15). |
+| `poolTimeout` | No | `10` | Maximum number of seconds to wait for a new connection from the pool. If all connections are in use, the database will return a `PoolTimeout` error after waiting for the given time. |
+|
`ApplicationName`
`Application Name`
(case insensitive) | No | | Sets the application name for the connection. Since version 2.28.0. |
+| `trustServerCertificate` | No | `false` | Configures whether to trust the server certificate. |
+| `trustServerCertificateCA` | No | | A path to a certificate authority file to be used instead of the system certificates to authorize the server certificate. Must be either in `pem`, `crt` or `der` format. Cannot be used together with `trustServerCertificate` parameter. |
+
+### Using [integrated security](https://learn.microsoft.com/en-us/previous-versions/dotnet/framework/data/adonet/sql/authentication-in-sql-server) (Windows only)
+
+The following example uses the currently logged in Windows user to log in to Microsoft SQL Server:
+
+```
+sqlserver://localhost:1433;database=sample;integratedSecurity=true;trustServerCertificate=true;
+```
+
+The following example uses a specific Active Directory user to log in to Microsoft SQL Server:
+
+```
+sqlserver://localhost:1433;database=sample;integratedSecurity=true;username=prisma;password=aBcD1234;trustServerCertificate=true;
+```
+
+#### Connect to a named instance
+
+The following example connects to a named instance of Microsoft SQL Server (`mycomputer\sql2019`) using integrated security:
+
+```
+sqlserver://mycomputer\sql2019;database=sample;integratedSecurity=true;trustServerCertificate=true;
+```
+
+## Type mapping between Microsoft SQL Server to Prisma schema
+
+For type mappings organized by Prisma ORM type, refer to the [Prisma schema reference](/orm/reference/prisma-schema-reference#model-field-scalar-types) documentation.
+
+## Supported versions
+
+See [Supported databases](/orm/reference/supported-databases).
+
+## Limitations and known issues
+
+### Prisma Migrate caveats
+
+Prisma Migrate is supported in [2.13.0](https://github.com/prisma/prisma/releases/tag/2.13.0) and later with the following caveats:
+
+#### Database schema names
+
+SQL Server does not have an equivalent to the PostgreSQL `SET search_path` command familiar from PostgreSQL. This means that when you create migrations, you must define the same schema name in the connection URL that is used by the production database. For most of the users this is `dbo` (the default value). However, if the production database uses another schema name, all the migration SQL must be either edited by hand to reflect the production _or_ the connection URL must be changed before creating migrations (for example: `schema=name`).
+
+#### Cyclic references
+
+Circular references can occur between models when each model references another, creating a closed loop. When using a Microsoft SQL Server database, Prisma ORM will show a validation error if the [referential action](/orm/prisma-schema/data-model/relations/referential-actions) on a relation is set to something other than [`NoAction`](/orm/prisma-schema/data-model/relations/referential-actions#noaction).
+
+See [Special rules for referential actions in SQL Server](/orm/prisma-schema/data-model/relations/referential-actions/special-rules-for-referential-actions) for more information.
+
+#### Destructive changes
+
+Certain migrations will cause more changes than you might expect. For example:
+
+- Adding or removing `autoincrement()`. This cannot be achieved by modifying the column, but requires recreating the table (including all constraints, indices, and foreign keys) and moving all data between the tables.
+- Additionally, it is not possible to delete all the columns from a table (possible with PostgreSQL or MySQL). If a migration needs to recreate all table columns, it will also re-create the table.
+
+#### Shared default values are not supported
+
+In some cases, user might want to define default values as shared objects:
+
+```sql file=default_objects.sql
+CREATE DEFAULT catcat AS 'musti';
+
+CREATE TABLE cats (
+ id INT IDENTITY PRIMARY KEY,
+ name NVARCHAR(1000)
+);
+
+sp_bindefault 'catcat', 'dbo.cats.name';
+```
+
+Using the stored procedure `sp_bindefault`, the default value `catcat` can be used in more than one table. The way Prisma ORM manages default values is per table:
+
+```sql file=default_per_table.sql showLineNumbers
+CREATE TABLE cats (
+ id INT IDENTITY PRIMARY KEY,
+ name NVARCHAR(1000) CONSTRAINT DF_cat_name DEFAULT 'musti'
+);
+```
+
+The last example, when introspected, leads to the following model:
+
+```prisma file=schema.prisma showLineNumbers
+model cats {
+ id Int @id @default(autoincrement())
+ name String? @default("musti")
+}
+```
+
+And the first doesn't get the default value introspected:
+
+```prisma file=schema.prisma showLineNumbers
+model cats {
+ id Int @id @default(autoincrement())
+ name String?
+}
+```
+
+If using Prisma Migrate together with shared default objects, changes to them must be done manually to the SQL.
+
+### Data model limitations
+
+#### Cannot use column with `UNIQUE` constraint and filtered index as foreign key
+
+Microsoft SQL Server [only allows one `NULL` value in a column that has a `UNIQUE` constraint](https://learn.microsoft.com/en-us/sql/relational-databases/tables/unique-constraints-and-check-constraints?view=sql-server-ver15). For example:
+
+- A table of users has a column named `license_number`
+- The `license_number` field has a `UNIQUE` constraint
+- The `license_number` field only allows **one** `NULL` value
+
+The standard way to get around this issue is to create a filtered unique index that excludes `NULL` values. This allows you to insert multiple `NULL` values. If you do not create an index in the database, you will get an error if you try to insert more than one `null` value into a column with Prisma Client.
+
+_However_, creating an index makes it impossible to use `license_number` as a foreign key in the database (or a relation scalar field in corresponding Prisma Schema)
+
+### Raw query considerations
+
+#### Raw queries with `String @db.VarChar(n)` fields / `VARCHAR(N)` columns
+
+`String` query parameters in [raw queries](/orm/prisma-client/using-raw-sql/raw-queries) are always encoded to SQL Server as `NVARCHAR(4000)` (if your `String` length is \<= 4000) or `NVARCHAR(MAX)`. If you compare a `String` query parameter to a column of type `String @db.VarChar(N)`/`VARCHAR(N)`, this can lead to implicit conversion on SQL Server which affects your index performance and can lead to high CPU usage.
+
+Here is an example:
+```prisma
+model user {
+ id Int @id
+ name String @db.VarChar(40)
+}
+```
+This query would be affected:
+```ts
+await prisma.$queryRaw`SELECT * FROM user WHERE name = ${"John"}`
+```
+
+To avoid the problem, we recommend you always manually cast your `String` query parameters to `VARCHAR(N)` in the raw query:
+```ts
+await prisma.$queryRaw`SELECT * FROM user WHERE name = CAST(${"John"} AS VARCHAR(40))`
+```
+This enables SQL Server to perform a Clustered Index Seek instead of a Clustered Index Scan.
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/840-cockroachdb.mdx b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/840-cockroachdb.mdx
new file mode 100644
index 0000000000..3d3bdf18b9
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/840-cockroachdb.mdx
@@ -0,0 +1,221 @@
+---
+title: 'CockroachDB'
+metaTitle: 'CockroachDB'
+metaDescription: 'Guide to CockroachDB'
+tocDepth: 3
+toc: true
+---
+
+
+
+This guide discusses the concepts behind using Prisma ORM and CockroachDB, explains the commonalities and differences between CockroachDB and other database providers, and leads you through the process for configuring your application to integrate with CockroachDB.
+
+
+
+
+
+The CockroachDB connector is generally available in versions `3.14.0` and later. It was first added as a [Preview feature](/orm/reference/preview-features) in version [`3.9.0`](https://github.com/prisma/prisma/releases/tag/3.9.0) with support for Introspection, and Prisma Migrate support was added in [`3.11.0`](https://github.com/prisma/prisma/releases/tag/3.11.0).
+
+
+
+## What is CockroachDB?
+
+CockroachDB is a distributed database that is designed for scalability and high availability. Features include:
+
+- **Compatibility with PostgreSQL:** CockroachDB is compatible with PostgreSQL, allowing interoperability with a large ecosystem of existing products
+- **Built-in scaling:** CockroachDB comes with automated replication, failover and repair capabilities to allow easy horizontal scaling of your application
+
+## Commonalities with other database providers
+
+CockroachDB is largely compatible with PostgreSQL, and can mostly be used with Prisma ORM in the same way. You can still:
+
+- model your database with the [Prisma Schema Language](/orm/prisma-schema)
+- connect to your database, using Prisma ORM's [`cockroachdb` database connector](/orm/overview/databases/cockroachdb)
+- use [Introspection](/orm/prisma-schema/introspection) for existing projects if you already have a CockroachDB database
+- use [Prisma Migrate](/orm/prisma-migrate) to migrate your database schema to a new version
+- use [Prisma Client](/orm/prisma-client) in your application to query your database in a type safe way based on your Prisma Schema
+
+## Differences to consider
+
+There are some CockroachDB-specific differences to be aware of when working with Prisma ORM's `cockroachdb` connector:
+
+- **Cockroach-specific native types:** Prisma ORM's `cockroachdb` database connector provides support for CockroachDB's native data types. To learn more, see [How to use CockroachDB's native types](#how-to-use-cockroachdbs-native-types).
+
+- **Creating database keys:** Prisma ORM allows you to generate a unique identifier for each record using the [`autoincrement()`](/orm/reference/prisma-schema-reference#autoincrement) function. For more information, see [How to use database keys with CockroachDB](#how-to-use-database-keys-with-cockroachdb).
+
+## How to use Prisma ORM with CockroachDB
+
+This section provides more details on how to use CockroachDB-specific features.
+
+### How to use CockroachDB's native types
+
+CockroachDB has its own set of native [data types](https://www.cockroachlabs.com/docs/stable/data-types.html) which are supported in Prisma ORM. For example, CockroachDB uses the `STRING` data type instead of PostgreSQL's `VARCHAR`.
+
+As a demonstration of this, say you create a `User` table in your CockroachDB database using the following SQL command:
+
+```sql
+CREATE TABLE public."Post" (
+ "id" INT8 NOT NULL,
+ "title" VARCHAR(200) NOT NULL,
+ CONSTRAINT "Post_pkey" PRIMARY KEY ("id" ASC),
+ FAMILY "primary" ("id", "title")
+);
+```
+
+After introspecting your database with `npx prisma db pull`, you will have a new `Post` model in your Prisma Schema:
+
+```prisma file=schema.prisma showLineNumbers
+model Post {
+ id BigInt @id
+ title String @db.String(200)
+}
+```
+
+Notice that the `title` field has been annotated with `@db.String(200)` — this differs from PostgreSQL where the annotation would be `@db.VarChar(200)`.
+
+For a full list of type mappings, see our [connector documentation](/orm/overview/databases/cockroachdb#type-mapping-between-cockroachdb-and-the-prisma-schema).
+
+### How to use database keys with CockroachDB
+
+When generating unique identifiers for records in a distributed database like CockroachDB, it is best to avoid using sequential IDs – for more information on this, see CockroachDB's [blog post on choosing index keys](https://www.cockroachlabs.com/blog/how-to-choose-db-index-keys/).
+
+Instead, Prisma ORM provides the [`autoincrement()`](/orm/reference/prisma-schema-reference#autoincrement) attribute function, which uses CockroachDB's [`unique_rowid()` function](https://www.cockroachlabs.com/docs/stable/serial.html) for generating unique identifiers. For example, the following `User` model has an `id` primary key, generated using the `autoincrement()` function:
+
+```prisma file=schema.prisma showLineNumbers
+model User {
+ id BigInt @id @default(autoincrement())
+ name String
+}
+```
+
+For compatibility with existing databases, you may sometimes still need to generate a fixed sequence of integer key values. In these cases, you can use Prisma ORM's inbuilt [`sequence()`](/orm/reference/prisma-schema-reference#sequence) function for CockroachDB. For a list of available options for the `sequence()` function, see our [reference documentation](/orm/reference/prisma-schema-reference#sequence).
+
+For more information on generating database keys, see CockroachDB's [Primary key best practices](https://www.cockroachlabs.com/docs/v21.2/schema-design-table#primary-key-best-practices) guide.
+
+## Example
+
+To connect to a CockroachDB database server, you need to configure a [`datasource`](/orm/prisma-schema/overview/data-sources) block in your [Prisma schema](/orm/prisma-schema):
+
+```prisma file=schema.prisma showLineNumbers
+datasource db {
+ provider = "cockroachdb"
+ url = env("DATABASE_URL")
+}
+```
+
+The fields passed to the `datasource` block are:
+
+- `provider`: Specifies the `cockroachdb` data source connector.
+- `url`: Specifies the [connection URL](#connection-details) for the CockroachDB database server. In this case, an [environment variable is used](/orm/prisma-schema/overview#accessing-environment-variables-from-the-schema) to provide the connection URL.
+
+
+
+While `cockroachdb` and `postgresql` connectors are similar, it is mandatory to use the `cockroachdb` connector instead of `postgresql` when connecting to a CockroachDB database from version 5.0.0.
+
+
+
+## Connection details
+
+CockroachDB uses the PostgreSQL format for its connection URL. See the [PostgreSQL connector documentation](/orm/overview/databases/postgresql#connection-details) for details of this format, and the optional arguments it takes.
+
+## Differences between CockroachDB and PostgreSQL
+
+The following table lists differences between CockroachDB and PostgreSQL:
+
+| Issue | Area | Notes |
+| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| By default, the `INT` type is an alias for `INT8` in CockroachDB, whereas in PostgreSQL it is an alias for `INT4`. This means that Prisma ORM will introspect an `INT` column in CockroachDB as `BigInt`, whereas in PostgreSQL Prisma ORM will introspect it as `Int`. | Schema | For more information on the `INT` type, see the [CockroachDB documentation](https://www.cockroachlabs.com/docs/stable/int.html#considerations-for-64-bit-signed-integers) |
+| When using `@default(autoincrement())` on a field, CockroachDB will automatically generate 64-bit integers for the row IDs. These integers will be increasing but not consecutive. This is in contrast to PostgreSQL, where generated row IDs are consecutive and start from 1. | Schema | For more information on generated values, see the [CockroachDB documentation](https://www.cockroachlabs.com/docs/stable/serial.html#generated-values-for-modes-rowid-and-virtual_sequence) |
+| The `@default(autoincrement())` attribute can only be used together with the `BigInt` field type. | Schema | For more information on generated values, see the [CockroachDB documentation](https://www.cockroachlabs.com/docs/stable/serial.html#generated-values-for-modes-rowid-and-virtual_sequence) |
+
+## Type mapping limitations in CockroachDB
+
+The CockroachDB connector maps the [scalar types](/orm/prisma-schema/data-model/models#scalar-fields) from the Prisma ORM [data model](/orm/prisma-schema/data-model/models) to native column types. These native types are mostly the same as for PostgreSQL — see the [Native type mapping from Prisma ORM to CockroachDB](#native-type-mapping-from-prisma-orm-to-cockroachdb) for details. However, there are some limitations:
+
+| CockroachDB (Type \| Aliases) | Prisma ORM | Supported | Native database type attribute | Notes |
+| ----------------------------- | ---------- | :-------: | :----------------------------- | :------------------------------------------------------------------------------------------------------------------------- |
+| `money` | `Decimal` | Not yet | `@db.Money` | Supported in PostgreSQL but [not currently in CockroachDB](https://github.com/cockroachdb/cockroach/issues/41578) |
+| `xml` | `String` | Not yet | `@db.Xml` | Supported in PostgreSQL but [not currently in CockroachDB](https://github.com/cockroachdb/cockroach/issues/43355) |
+| `jsonb` arrays | `Json[]` | Not yet | N/A | `Json[]` supported in PostgreSQL but [not currently in CockroachDB](https://github.com/cockroachdb/cockroach/issues/23468) |
+
+## Other limitations
+
+The following table lists any other current known limitations of CockroachDB compared to PostgreSQL:
+
+| Issue | Area | Notes |
+| ---------------------------------------------------------------------------------------------------- | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Index types `Hash`, `Gist`, `SpGist` or `Brin` are not supported. | Schema | In PostgreSQL, Prisma ORM allows [configuration of indexes](/orm/prisma-schema/data-model/indexes#configuring-the-access-type-of-indexes-with-type-postgresql) to use the different index access method. CockroachDB only currently supports `BTree` and `Gin`. |
+| Pushing to `Enum` types not supported | Client | Pushing to `Enum` types (e.g. `data: { enum { push: "A" }, }`) is currently [not supported in CockroachDB](https://github.com/cockroachdb/cockroach/issues/71388) |
+| Searching on `String` fields without a full text index not supported | Client | Searching on `String` fields without a full text index (e.g. `where: { text: { search: "cat & dog", }, },`) is currently [not supported in CockroachDB](https://github.com/cockroachdb/cockroach/issues/7821) |
+| Integer division not supported | Client | Integer division (e.g. `data: { int: { divide: 10, }, }`) is currently [not supported in CockroachDB](https://github.com/cockroachdb/cockroach/issues/41448) |
+| Limited filtering on `Json` fields | Client | Currently CockroachDB [only supports](https://github.com/cockroachdb/cockroach/issues/49144) `equals` and `not` filtering on `Json` fields |
+
+## Type mapping between CockroachDB and the Prisma schema
+
+The CockroachDB connector maps the [scalar types](/orm/prisma-schema/data-model/models#scalar-fields) from the Prisma ORM [data model](/orm/prisma-schema/data-model/models) as follows to native column types:
+
+> Alternatively, see the [Prisma schema reference](/orm/reference/prisma-schema-reference#model-field-scalar-types) for type mappings organized by Prisma ORM type.
+
+### Native type mapping from Prisma ORM to CockroachDB
+
+| Prisma ORM | CockroachDB |
+| ---------- | ---------------- |
+| `String` | `STRING` |
+| `Boolean` | `BOOL` |
+| `Int` | `INT4` |
+| `BigInt` | `INT8` |
+| `Float` | `FLOAT8` |
+| `Decimal` | `DECIMAL(65,30)` |
+| `DateTime` | `TIMESTAMP(3)` |
+| `Json` | `JSONB` |
+| `Bytes` | `BYTES` |
+
+### Mapping from CockroachDB to Prisma ORM types on Introspection
+
+When introspecting a CockroachDB database, the database types are mapped to Prisma ORM according to the following table:
+
+| CockroachDB (Type \| Aliases) | Prisma ORM | Supported | Native database type attribute | Notes |
+| -------------------------------------------- | ---------- | :-------: | :----------------------------- | :--------------------------------------------------------------------- |
+| `INT` \| `BIGINT`, `INTEGER` | `BigInt` | ✔️ | `@db.Int8` | |
+| `BOOL` \| `BOOLEAN` | `Bool` | ✔️ | `@db.Bool`\* | |
+| `TIMESTAMP` \| `TIMESTAMP WITHOUT TIME ZONE` | `DateTime` | ✔️ | `@db.Timestamp(x)` | |
+| `TIMESTAMPTZ` \| `TIMESTAMP WITH TIME ZONE` | `DateTime` | ✔️ | `@db.Timestamptz(x)` | |
+| `TIME` \| `TIME WITHOUT TIME ZONE` | `DateTime` | ✔️ | `@db.Time(x)` | |
+| `TIMETZ` \| `TIME WITH TIME ZONE` | `DateTime` | ✔️ | `@db.Timetz(x)` | |
+| `DECIMAL(p,s)` \| `NUMERIC(p,s)`, `DEC(p,s)` | `Decimal` | ✔️ | `@db.Decimal(x, y)` | |
+| `REAL` \| `FLOAT4`, `FLOAT` | `Float` | ✔️ | `@db.Float4` | |
+| `DOUBLE PRECISION` \| `FLOAT8` | `Float` | ✔️ | `@db.Float8` | |
+| `INT2` \| `SMALLINT` | `Int` | ✔️ | `@db.Int2` | |
+| `INT4` | `Int` | ✔️ | `@db.Int4` | |
+| `CHAR(n)` \| `CHARACTER(n)` | `String` | ✔️ | `@db.Char(x)` | |
+| `"char"` | `String` | ✔️ | `@db.CatalogSingleChar` | Internal type for CockroachDB catalog tables, not meant for end users. |
+| `STRING` \| `TEXT`, `VARCHAR` | `String` | ✔️ | `@db.String` | |
+| `DATE` | `DateTime` | ✔️ | `@db.Date` | |
+| `ENUM` | `enum` | ✔️ | N/A | |
+| `INET` | `String` | ✔️ | `@db.Inet` | |
+| `BIT(n)` | `String` | ✔️ | `@Bit(x)` | |
+| `VARBIT(n)` \| `BIT VARYING(n)` | `String` | ✔️ | `@VarBit` | |
+| `OID` | `Int` | ✔️ | `@db.Oid` | |
+| `UUID` | `String` | ✔️ | `@db.Uuid` | |
+| `JSONB` \| `JSON` | `Json` | ✔️ | `@db.JsonB` | |
+| Array types | `[]` | ✔️ | | |
+
+[Introspection](/orm/prisma-schema/introspection) adds native database types that are **not yet supported** as [`Unsupported`](/orm/reference/prisma-schema-reference#unsupported) fields:
+
+```prisma file=schema.prisma showLineNumbers
+model Device {
+ id BigInt @id @default(autoincrement())
+ interval Unsupported("INTERVAL")
+}
+```
+
+## More on using CockroachDB with Prisma ORM
+
+The fastest way to start using CockroachDB with Prisma ORM is to refer to our Getting Started documentation:
+
+- [Start from scratch](/getting-started/setup-prisma/start-from-scratch/relational-databases-typescript-cockroachdb)
+- [Add to existing project](/getting-started/setup-prisma/add-to-existing-project/relational-databases-typescript-cockroachdb)
+
+These tutorials will take you through the process of connecting to CockroachDB, migrating your schema, and using Prisma Client.
+
+Further reference information is available in the [CockroachDB connector documentation](/orm/overview/databases/cockroachdb).
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/850-planetscale.mdx b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/850-planetscale.mdx
new file mode 100644
index 0000000000..f000a80a33
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/850-planetscale.mdx
@@ -0,0 +1,374 @@
+---
+title: 'PlanetScale'
+metaTitle: 'PlanetScale'
+metaDescription: 'Guide to PlanetScale'
+tocDepth: 3
+toc: true
+---
+
+Prisma and [PlanetScale](https://planetscale.com/) together provide a development arena that optimizes rapid, type-safe development of data access applications, using Prisma's ORM and PlanetScale's highly scalable MySQL-based platform.
+
+This document discusses the concepts behind using Prisma ORM and PlanetScale, explains the commonalities and differences between PlanetScale and other database providers, and leads you through the process for configuring your application to integrate with PlanetScale.
+
+## What is PlanetScale?
+
+PlanetScale uses the [Vitess](https://vitess.io/) database clustering system to provide a MySQL-compatible database platform. Features include:
+
+- **Enterprise scalability.** PlanetScale provides a highly available production database cluster that supports scaling across multiple database servers. This is particularly useful in a serverless context, as it avoids the problem of having to [manage connection limits](/orm/prisma-client/setup-and-configuration/databases-connections#serverless-environments-faas).
+- **Database branches.** PlanetScale allows you to create [branches of your database schema](https://planetscale.com/docs/concepts/branching), so that you can test changes on a development branch before applying them to your production database.
+- **Support for [non-blocking schema changes](https://planetscale.com/docs/concepts/nonblocking-schema-changes).** PlanetScale provides a workflow that allows users to update database schemas without locking the database or causing downtime.
+
+## Commonalities with other database providers
+
+Many aspects of using Prisma ORM with PlanetScale are just like using Prisma ORM with any other relational database. You can still:
+
+- model your database with the [Prisma Schema Language](/orm/prisma-schema)
+- use Prisma ORM's existing [`mysql` database connector](/orm/overview/databases/mysql) in your schema, along with the [connection string PlanetScale provides you](https://planetscale.com/docs/concepts/connection-strings)
+- use [Introspection](/orm/prisma-schema/introspection) for existing projects if you already have a database schema in PlanetScale
+- use [`db push`](/orm/prisma-migrate/workflows/prototyping-your-schema) to push changes in your schema to the database
+- use [Prisma Client](/orm/prisma-client) in your application to talk to the database server at PlanetScale
+
+## Differences to consider
+
+PlanetScale's branching model and design for scalability means that there are also a number of differences to consider. You should be aware of the following points when deciding to use PlanetScale with Prisma ORM:
+
+- **Branching and deploy requests.** PlanetScale provides two types of database branches: _development branches_, which allow you to test out schema changes, and _production branches_, which are protected from direct schema changes. Instead, changes must be first created on a development branch and then deployed to production using a deploy request. Production branches are highly available and include automated daily backups. To learn more, see [How to use branches and deploy requests](#how-to-use-branches-and-deploy-requests).
+- **Referential actions and integrity.** To support scaling across multiple database servers, PlanetScale [by default does not use foreign key constraints](https://planetscale.com/docs/learn/operating-without-foreign-key-constraints), which are normally used in relational databases to enforce relationships between data in different tables, and asks users to handle this manually in their applications. However, you can explicitly [enable them in the PlanetScale database settings](https://planetscale.com/docs/concepts/foreign-key-constraints). If you don't enable these explicitly, you can still maintain these relationships in your data and allow the use of [referential actions](/orm/prisma-schema/data-model/relations/referential-actions) by using Prisma ORM's ability to [emulate relations in Prisma Client](/orm/prisma-schema/data-model/relations/relation-mode#emulate-relations-in-prisma-orm-with-the-prisma-relation-mode) with the `prisma` relation mode. For more information, see [How to emulate relations in Prisma Client](#option-1-emulate-relations-in-prisma-client).
+- **Creating indexes on foreign keys.** When [emulating relations in Prisma ORM](#option-1-emulate-relations-in-prisma-client) (i.e. when _not_ using foreign key constraints on the database-level), you will need to create dedicated indexes on foreign keys. In a standard MySQL database, if a table has a column with a foreign key constraint, an index is automatically created on that column. When PlanetScale is configured to not use foreign key constraints, these indexes are [currently](https://github.com/prisma/prisma/issues/10611) not created when Prisma Client emulates relations, which can lead to issues with queries not being well optimized. To avoid this, you can create indexes in Prisma ORM. For more information, see [How to create indexes on foreign keys](#2-create-indexes-on-foreign-keys).
+- **Making schema changes with `db push`.** When you merge a development branch into your production branch, PlanetScale will automatically compare the two schemas and generate its own schema diff. This means that Prisma ORM's [`prisma migrate`](/orm/prisma-migrate) workflow, which generates its own history of migration files, is not a natural fit when working with PlanetScale. These migration files may not reflect the actual schema changes run by PlanetScale when the branch is merged.
+
+
+
+ We recommend not using `prisma migrate` when making schema changes with PlanetScale. Instead, we recommend that you use the `prisma db push` command.
+
+
+
+ For an example of how this works, see [How to make schema changes with `db push`](#how-to-make-schema-changes-with-db-push)
+
+- **Introspection**. When you introspect on an existing database and you have _not_ enabled [foreign key constraints in your PlanetScale database](#option-2-enable-foreign-key-constraints-in-the-planetscale-database-settings), you will get a schema with no relations, as they are usually defined based on foreign keys that connect tables. In that case, you will need to add the missing relations in manually. For more information, see [How to add in missing relations after Introspection](#how-to-add-in-missing-relations-after-introspection).
+
+## How to use branches and deploy requests
+
+When connecting to PlanetScale with Prisma ORM, you will need to use the correct connection string for your branch. The connection URL for a given database branch can be found from your PlanetScale account by going to the overview page for the branch and selecting the 'Connect' dropdown. In the 'Passwords' section, generate a new password and select 'Prisma' from the dropdown to get the Prisma format for the connection URL. See Prisma ORM's [Getting Started guide](/getting-started/setup-prisma/start-from-scratch/relational-databases/connect-your-database-typescript-planetscale) for more details of how to connect to a PlanetScale database.
+
+Every PlanetScale database is created with a branch called `main`, which is initially a development branch that you can use to test schema changes on. Once you are happy with the changes you make there, you can [promote it](https://planetscale.com/docs/concepts/branching#promote-a-branch-to-production) to become a production branch. Note that you can only push new changes to a development branch, so further changes will need to be created on a separate development branch and then later deployed to production using a [deploy request](https://planetscale.com/docs/concepts/branching#promote-a-branch-to-production).
+
+If you try to push to a production branch, you will get the [error message](/orm/reference/error-reference#p3022) `Direct execution of DDL (Data Definition Language) SQL statements is disabled on this database.`
+
+## How to use relations (and enable referential integrity) with PlanetScale
+
+### Option 1: Emulate relations in Prisma Client
+
+#### 1. Set `relationMode = "prisma"`
+
+PlanetScale does not use foreign key constraints in its database schema by default. However, Prisma ORM relies on foreign key constraints in the underlying database to enforce referential integrity between models in your Prisma schema.
+
+In Prisma ORM versions 3.1.1 and later, you can [emulate relations in Prisma Client with the `prisma` relation mode](/orm/prisma-schema/data-model/relations/relation-mode#emulate-relations-in-prisma-orm-with-the-prisma-relation-mode), which avoids the need for foreign key constraints in the database.
+
+To enable emulation of relations in Prisma Client, set the `relationMode` field to `"prisma"` in the `datasource` block:
+
+```prisma file=schema.prisma
+datasource db {
+ provider = "mysql"
+ url = env("DATABASE_URL")
+ relationMode = "prisma"
+}
+```
+
+
+
+The ability to set the relation mode was introduced as part of the `referentialIntegrity` preview feature in Prisma ORM version 3.1.1, and is generally available in Prisma ORM versions 4.8.0 and later.
The `relationMode` field was renamed in Prisma ORM version 4.5.0, and was previously named `referentialIntegrity`.
+
+
+
+If you use relations in your Prisma schema with the default `"foreignKeys"` option for the `relationMode` field, PlanetScale will error and Prisma ORM output the [P3021 error message](/orm/reference/error-reference#p3021) when it tries to create foreign keys. (In versions before 2.27.0 it will output a raw database error.)
+
+#### 2. Create indexes on foreign keys
+
+When [you emulate relations in Prisma Client](#option-1-emulate-relations-in-prisma-client), you need to create your own indexes. As an example of a situation where you would want to add an index, take this schema for a blog with posts and comments:
+
+```prisma file=schema.prisma
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ content String
+ likes Int @default(0)
+ comments Comment[]
+}
+
+model Comment {
+ id Int @id @default(autoincrement())
+ comment String
+ postId Int
+ post Post @relation(fields: [postId], references: [id], onDelete: Cascade)
+}
+```
+
+The `postId` field in the `Comment` model refers to the corresponding `id` field in the `Post` model. However this is not implemented as a foreign key in PlanetScale, so the column doesn't have an automatic index. This means that some queries may not be well optimized. For example, if you query for all comments with a certain post `id`, PlanetScale may have to do a full table lookup. This could be slow, and also expensive because PlanetScale's billing model charges for the number of rows read.
+
+To avoid this, you can define an index on the `postId` field using [Prisma ORM's `@@index` argument](/orm/reference/prisma-schema-reference#index):
+
+```prisma file=schema.prisma highlight=15;add
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ content String
+ likes Int @default(0)
+ comments Comment[]
+}
+
+model Comment {
+ id Int @id @default(autoincrement())
+ comment String
+ postId Int
+ post Post @relation(fields: [postId], references: [id], onDelete: Cascade)
+
+ //add-next-line
+ @@index([postId])
+}
+```
+
+You can then add this change to your schema [using `db push`](#how-to-make-schema-changes-with-db-push).
+
+In versions 4.7.0 and later, Prisma ORM warns you if you have a relation with no index on the relation scalar field. For more information, see [Index validation](/orm/prisma-schema/data-model/relations/relation-mode#index-validation).
+
+
+
+One issue to be aware of is that [implicit many-to-many relations](/orm/prisma-schema/data-model/relations/many-to-many-relations#implicit-many-to-many-relations) cannot have an index added in this way. If query speed or cost is an issue, you may instead want to use an [explicit many-to-many relation](/orm/prisma-schema/data-model/relations/many-to-many-relations#explicit-many-to-many-relations) in this case.
+
+
+
+### Option 2: Enable foreign key constraints in the PlanetScale database settings
+
+Support for foreign key constraints in PlanetScale databases has been Generally Available since February 2024. Follow the instructions in the [PlanetScale documentation](https://planetscale.com/docs/concepts/foreign-key-constraints) to enable them in your database.
+
+You can then use Prisma ORM and define relations in your Prisma schema without the need for extra configuration.
+
+In that case, you can define a relation as with other database that supports foreign key constraints, for example:
+
+```prisma file=schema.prisma
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ content String
+ likes Int @default(0)
+ comments Comment[]
+}
+
+model Comment {
+ id Int @id @default(autoincrement())
+ comment String
+ postId Int
+ post Post @relation(fields: [postId], references: [id], onDelete: Cascade)
+}
+```
+
+With this approach, it is _not_ necessary to:
+
+- set `relationMode = "prisma"` in your Prisma schema
+- define additional indexes on foreign keys
+
+Also, introspection will automatically create relation fields in your Prisma schema because it can detect the foreign key constraints in the database.
+
+## How to make schema changes with `db push`
+
+To use `db push` with PlanetScale, you will first need to [enable emulation of relations in Prisma Client](#option-1-emulate-relations-in-prisma-client). Pushing to your branch without referential emulation enabled will give the [error message](/orm/reference/error-reference#p3021) `Foreign keys cannot be created on this database.`
+
+As an example, let's say you decide to decide to add a new `excerpt` field to the blog post schema above. You will first need to [create a new development branch and connect to it](#how-to-use-branches-and-deploy-requests).
+
+Next, add the following to your `schema.prisma` file:
+
+```prisma file=schema.prisma highlight=5;edit
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ content String
+ //edit-next-line
+ excerpt String?
+ likes Int @default(0)
+ comments Comment[]
+}
+
+model Comment {
+ id Int @id @default(autoincrement())
+ comment String
+ postId Int
+ post Post @relation(fields: [postId], references: [id], onDelete: Cascade)
+
+ @@index([postId])
+}
+```
+
+To push these changes, navigate to your project directory in your terminal and run
+
+```terminal
+npx prisma db push
+```
+
+Once you are happy with your changes on your development branch, you can open a deploy request to deploy these to your production branch.
+
+For more examples, see PlanetScale's tutorial on [automatic migrations with Prisma ORM](https://planetscale.com/docs/prisma/automatic-prisma-migrations) using `db push`.
+
+## How to add in missing relations after introspection
+
+> **Note**: This section is only relevant if you use `relationMode = "prisma"` to emulate foreign key constraints with Prisma ORM. If you enabled foreign key constraints in your PlanetScale database, you can ignore this section.
+
+After introspecting with `npx prisma db pull`, the schema you get may be missing some relations. For example, the following schema is missing a relation between the `User` and `Post` models:
+
+```prisma file=schema.prisma
+model Post {
+ id Int @id @default(autoincrement())
+ createdAt DateTime @default(now())
+ title String @db.VarChar(255)
+ content String?
+ authorId Int
+
+ @@index([authorId])
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+}
+```
+
+In this case you need to add the relation in manually:
+
+```prisma file=schema.prisma highlight=6,16;add
+model Post {
+ id Int @id @default(autoincrement())
+ createdAt DateTime @default(now())
+ title String @db.VarChar(255)
+ content String?
+ //add-next-line
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+
+ @@index([authorId])
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ //add-next-line
+ posts Post[]
+}
+```
+
+For a more detailed example, see the [Getting Started guide for PlanetScale](/getting-started/setup-prisma/add-to-existing-project/relational-databases/introspection-typescript-planetscale).
+
+## How to define shard keys in your Prisma schema (Preview)
+
+[Sharding](https://planetscale.com/docs/vitess/sharding) is a popular technique to scale up when database load grows.
+
+As of [v6.10.0](https://github.com/prisma/prisma/releases/tag/6.10.0), Prisma ORM supports sharding on PlanetScale natively (as a [Preview](/orm/more/releases#preview) feature) via the [`@shardKey`](/orm/reference/prisma-schema-reference#shardkey) and [`@@shardKey`](/orm/reference/prisma-schema-reference#shardkey-1) attributes in the Prisma schema which you can apply to the fields in your models that should serve as shard keys in your database setup.
+
+In order to use the shard key attributes, you need to specify the `shardKeys` Preview feature on your `generator`:
+
+```prisma
+generator client {
+ provider = "prisma-client-js"
+ output = "../generated/prisma"
+ previewFeatures = ["shardKeys"]
+}
+```
+
+Now you can use the `@shardKey` and `@@shardKey` attributes:
+
+**Single-column shard key**
+
+```prisma
+model User {
+ id String @default(uuid())
+ region String @shardKey
+}
+```
+
+**Multi-column shard key**
+
+```prisma
+model User {
+ id String @default(uuid())
+ country String
+ customerId String
+ @@shardKey([country, customerId])
+}
+```
+
+## How to use the PlanetScale serverless driver with Prisma ORM (Preview)
+
+The [PlanetScale serverless driver](https://planetscale.com/docs/tutorials/planetscale-serverless-driver) provides a way of communicating with your database and executing queries over HTTP.
+
+You can use Prisma ORM along with the PlanetScale serverless driver using the [`@prisma/adapter-planetscale`](https://www.npmjs.com/package/@prisma/adapter-planetscale) driver adapter. The driver adapter allows you to communicate with your database over HTTP.
+
+:::info
+
+This feature has been Generally Available since Prisma ORM [v6.16.0](https://pris.ly/release/6.16.0).
+
+:::
+
+
+:::info
+
+Ensure you update the host value in your connection string to `aws.connect.psdb.cloud`. You can learn more about this [here](https://planetscale.com/docs/tutorials/planetscale-serverless-driver#add-and-use-the-planetscale-serverless-driver-for-javascript-to-your-project).
+
+```bash
+DATABASE_URL='mysql://johndoe:strongpassword@aws.connect.psdb.cloud/clear_nightsky?sslaccept=strict'
+```
+
+:::
+
+Install the Prisma ORM adapter for PlanetScale, PlanetScale serverless driver and `undici` packages:
+
+```terminal
+npm install @prisma/adapter-planetscale undici
+```
+
+:::info
+
+When using a Node.js version below 18, you must provide a custom fetch function implementation. We recommend the `undici` package on which Node's built-in fetch is based. Node.js versions 18 and later include a built-in global `fetch` function, so you don't have to install an extra package.
+
+:::
+
+Update your Prisma Client instance to use the PlanetScale serverless driver:
+
+```ts
+import { PrismaPlanetScale } from '@prisma/adapter-planetscale'
+import { PrismaClient } from '@prisma/client'
+import dotenv from 'dotenv'
+import { fetch as undiciFetch } from 'undici'
+
+dotenv.config()
+const connectionString = `${process.env.DATABASE_URL}`
+
+const adapter = new PrismaPlanetScale({ url: connectionString, fetch: undiciFetch })
+const prisma = new PrismaClient({ adapter })
+```
+
+You can then use Prisma Client as you normally would with full type-safety. Prisma Migrate, introspection, and Prisma Studio will continue working as before using the connection string defined in the Prisma schema.
+
+## More on using PlanetScale with Prisma ORM
+
+The fastest way to start using PlanetScale with Prisma ORM is to refer to our Getting Started documentation:
+
+- [Start from scratch](/getting-started/setup-prisma/start-from-scratch/relational-databases-typescript-planetscale)
+- [Add to existing project](/getting-started/setup-prisma/add-to-existing-project/relational-databases-typescript-planetscale)
+
+These tutorials will take you through the process of connecting to PlanetScale, pushing schema changes, and using Prisma Client.
+
+For further tips on best practices when using Prisma ORM and PlanetScale together, watch our video:
+
+
+
+
+
+
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/880-supabase.mdx b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/880-supabase.mdx
new file mode 100644
index 0000000000..9f338d42d4
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/880-supabase.mdx
@@ -0,0 +1,85 @@
+---
+title: 'Supabase'
+metaTitle: 'Supabase'
+metaDescription: 'Guide to Supabase'
+tocDepth: 2
+toc: true
+---
+
+This guide discusses the concepts behind using Prisma ORM and Supabase, explains the commonalities and differences between Supabase and other database providers, and leads you through the process for configuring your application to integrate with Supabase.
+
+## What is Supabase?
+
+[Supabase](https://supabase.com/) is a PostgreSQL hosting service and open source Firebase alternative providing all the backend features you need to build a product. Unlike Firebase, Supabase is backed by PostgreSQL which can be accessed directly using Prisma ORM.
+
+To learn more about Supabase, you can check out their architecture [here](https://supabase.com/docs/guides/getting-started/architecture) and features [here](https://supabase.com/docs/guides/getting-started/features)
+
+## Commonalities with other database providers
+
+Many aspects of using Prisma ORM with Supabase are just like using Prisma ORM with any other relational database. You can still:
+
+- Model your database with the [Prisma Schema Language](/orm/prisma-schema)
+- Use Prisma ORM's existing [`postgresql` database connector](/orm/overview/databases/postgresql) in your schema, along with the [connection string Supabase provides you](https://supabase.com/docs/guides/database/connecting-to-postgres#connecting-to-external-libraries-and-tools)
+- Use [Introspection](/orm/prisma-schema/introspection) for existing projects if you already have a database schema in Supabase
+- Use [`db push`](/orm/prisma-migrate/workflows/prototyping-your-schema) to push changes in your schema to Supabase
+- Use [Prisma Client](/orm/prisma-client) in your application to talk to the database server at Supabase
+
+## Specific considerations
+
+If you'd like to use the [connection pooling feature](https://supabase.com/docs/guides/database/connecting-to-postgres#connection-pooling-in-depth) available with Supabase, you will need to use the connection pooling connection string available via your [Supabase database settings](https://supabase.com/dashboard/project/_/settings/database) with `?pgbouncer=true` appended to the end of your `DATABASE_URL` environment variable:
+
+```env file=.env
+# Connect to Supabase via connection pooling with Supavisor.
+DATABASE_URL="postgres://postgres.[your-supabase-project]:[password]@aws-0-[aws-region].pooler.supabase.com:6543/postgres?pgbouncer=true"
+```
+
+Supabase provides three types of connection strings for each database:
+
+1. **Direct Database Connection string** – `postgresql://postgres:password@db.[your-project-ref].supabase.co:5432/postgres`
+
+2. **Transaction Pooler Connection string** – `postgresql://postgres.[your-project-ref]:password@aws-0-[region].pooler.supabase.com:6543/postgres`
+
+3. **Session Pooler Connection string** – `postgresql://postgres.[your-project-ref]:password@aws-0-[region].pooler.supabase.com:5432/postgres`
+
+If you would like to use the Prisma CLI in order to perform other actions on your database (e.g. migrations), your setup depends on the connection string used:
+
+- If your `DATABASE_URL` uses the Transaction Pooler (connection string 2), you must provide a `DIRECT_URL` with either the Direct Database (1) or Session Pooler (3) connection string in order for Prisma Migrate to work.
+
+- If your `DATABASE_URL` already uses the Session Pooler (connection string 3), you do not need to provide a `DIRECT_URL`. Prisma Migrate will work without it.
+
+```env file=.env highlight=4-5;add showLineNumbers
+# Connect to Supabase via connection pooling with Supavisor.
+DATABASE_URL="postgres://postgres.[your-supabase-project]:[password]@aws-0-[aws-region].pooler.supabase.com:6543/postgres?pgbouncer=true"
+
+//add-start
+# Direct connection to the database. Used for migrations.
+DIRECT_URL="postgres://postgres.[your-supabase-project]:[password]@aws-0-[aws-region].pooler.supabase.com:5432/postgres"
+# or
+DIRECT_URL="postgresql://postgres:password@db.[your-project-ref].supabase.co:5432/postgres"
+//add-end
+```
+
+You can then update your `schema.prisma` to use the new direct URL:
+
+```prisma file=schema.prisma highlight=4;add showLineNumbers
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+ //add-next-line
+ directUrl = env("DIRECT_URL")
+}
+```
+
+More information about the `directUrl` field can be found [here](/orm/reference/prisma-schema-reference#fields).
+
+
+
+We strongly recommend using connection pooling with Supavisor in addition to `DIRECT_URL`. You will gain the great developer experience of the Prisma CLI while also allowing for connections to be pooled regardless of your deployment strategy. While this is not strictly necessary for every app, serverless solutions will inevitably require connection pooling.
+
+
+
+## Getting started with Supabase
+
+If you're interested in learning more, Supabase has a great guide for connecting a database provided by Supabase to your Prisma project available [here](https://supabase.com/partners/integrations/prisma).
+
+If you're running into issues integrating with Supabase, check out these [specific troubleshooting tips](https://supabase.com/partners/integrations/prisma) or [Prisma's GitHub Discussions](https://github.com/prisma/prisma/discussions) for more help.
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/890-neon.mdx b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/890-neon.mdx
new file mode 100644
index 0000000000..d5be0b9d74
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/890-neon.mdx
@@ -0,0 +1,155 @@
+---
+title: 'Neon'
+metaTitle: 'Neon'
+metaDescription: 'Guide to Neon'
+tocDepth: 2
+toc: true
+---
+
+This guide explains how to:
+
+- [Connect Prisma ORM using Neon's connection pooling feature](#how-to-use-neons-connection-pooling)
+- [Resolve connection timeout issues](#resolving-connection-timeouts)
+- [Use Neon's serverless driver with Prisma ORM](#how-to-use-neons-serverless-driver-with-prisma-orm)
+
+## What is Neon?
+
+[Neon](https://neon.tech/) is a fully managed serverless PostgreSQL with a generous free tier. Neon separates storage and compute, and offers modern developer features such as serverless, branching, bottomless storage, and more. Neon is open source and written in Rust.
+
+Learn more about Neon [here](https://neon.tech/docs/introduction).
+
+## Commonalities with other database providers
+
+Many aspects of using Prisma ORM with Neon are just like using Prisma ORM with any other PostgreSQL database. You can:
+
+- model your database with the [Prisma Schema Language](/orm/prisma-schema)
+- use Prisma ORM's [`postgresql` database connector](/orm/overview/databases/postgresql) in your schema, along with the [connection string Neon provides you](https://neon.tech/docs/connect/connect-from-any-app)
+- use [Introspection](/orm/prisma-schema/introspection) for existing projects if you already have a database schema on Neon
+- use [`prisma migrate dev`](/orm/prisma-migrate/workflows/development-and-production) to track schema migrations in your Neon database
+- use [`prisma db push`](/orm/prisma-migrate/workflows/prototyping-your-schema) to push changes in your schema to Neon
+- use [Prisma Client](/orm/prisma-client) in your application to communicate with the database hosted by Neon
+
+## Differences to consider
+
+There are a few differences between Neon and PostgreSQL you should be aware of the following when deciding to use Neon with Prisma ORM:
+
+- **Neon's serverless model** — By default, Neon scales a [compute](https://neon.tech/docs/introduction/compute-lifecycle) to zero after 5 minutes of inactivity. During this state, a compute instance is in _idle_ state. A characteristic of this feature is the concept of a "cold start". Activating a compute from an idle state takes from 500ms to a few seconds. Depending on how long it takes to connect to your database, your application may timeout. To learn more, see: [Connection latency and timeouts](https://neon.tech/docs/guides/prisma#connection-timeouts).
+- **Neon's connection pooler** — Neon offers connection pooling using PgBouncer, enabling up to 10,000 concurrent connections. To learn more, see: [Connection pooling](https://neon.tech/docs/connect/connection-pooling).
+
+## How to use Neon's connection pooling
+
+If you would like to use the [connection pooling](https://neon.tech/docs/guides/prisma#use-connection-pooling-with-prisma) available in Neon, you will
+need to add `-pooler` in the hostname of your `DATABASE_URL` environment variable used in the `url` property of the `datasource` block of your Prisma schema:
+
+```bash file=.env
+# Connect to Neon with Pooling.
+DATABASE_URL=postgres://daniel:@ep-mute-rain-952417-pooler.us-east-2.aws.neon.tech:5432/neondb?sslmode=require
+```
+
+If you would like to use Prisma CLI in order to perform other actions on your database (e.g. for migrations) you will need to add a `DIRECT_URL` environment variable to use in the `directUrl` property of the `datasource` block of your Prisma schema so that the CLI will use a direct connection string (without PgBouncer):
+
+```env file=.env highlight=4-5;add showLineNumbers
+# Connect to Neon with Pooling.
+DATABASE_URL=postgres://daniel:@ep-mute-rain-952417-pooler.us-east-2.aws.neon.tech/neondb?sslmode=require
+
+//add-start
+# Direct connection to the database used by Prisma CLI for e.g. migrations.
+DIRECT_URL="postgres://daniel:@ep-mute-rain-952417.us-east-2.aws.neon.tech/neondb"
+//add-end
+```
+
+You can then update your `schema.prisma` to use the new direct URL:
+
+```prisma file=schema.prisma highlight=4;add showLineNumbers
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+ //add-next-line
+ directUrl = env("DIRECT_URL")
+}
+```
+
+More information about the `directUrl` field can be found [here](/orm/reference/prisma-schema-reference#fields).
+
+
+
+We strongly recommend using the pooled connection string in your `DATABASE_URL` environment variable. You will gain the great developer experience of the Prisma CLI while also allowing for connections to be pooled regardless of deployment strategy. While this is not strictly necessary for every app, serverless solutions will inevitably require connection pooling.
+
+
+
+## Resolving connection timeouts
+
+A connection timeout that occurs when connecting from Prisma ORM to Neon causes an error similar to the following:
+
+```text no-copy
+Error: P1001: Can't reach database server at `ep-white-thunder-826300.us-east-2.aws.neon.tech`:`5432`
+Please make sure your database server is running at `ep-white-thunder-826300.us-east-2.aws.neon.tech`:`5432`.
+```
+
+This error most likely means that the connection created by Prisma Client timed out before the Neon compute was activated.
+
+A Neon compute has two main states: _Active_ and _Idle_. Active means that the compute is currently running. If there is no query activity for 5 minutes, Neon places a compute into an idle state by default. Refer to Neon's docs to [learn more](https://neon.tech/docs/introduction/compute-lifecycle).
+
+When you connect to an idle compute from Prisma ORM, Neon automatically activates it. Activation typically happens within a few seconds but added latency can result in a connection timeout. To address this issue, your can adjust your Neon connection string by adding a `connect_timeout` parameter. This parameter defines the maximum number of seconds to wait for a new connection to be opened. The default value is 5 seconds. A higher setting should provide the time required to avoid connection timeout issues. For example:
+
+```text wrap
+DATABASE_URL=postgres://daniel:@ep-mute-rain-952417.us-east-2.aws.neon.tech/neondb?connect_timeout=10
+```
+
+:::info
+
+A `connect_timeout` setting of 0 means no timeout.
+
+:::
+
+Another possible cause of connection timeouts is Prisma ORM's [connection pool](/orm/prisma-client/setup-and-configuration/databases-connections/connection-pool), which has a default timeout of 10 seconds. This is typically enough time for Neon, but if you are still experiencing connection timeouts, you can try increasing this limit (in addition to the `connect_timeout` setting described above) by setting the `pool_timeout` parameter to a higher value. For example:
+
+```text wrap
+DATABASE_URL=postgres://daniel:@ep-mute-rain-952417.us-east-2.aws.neon.tech/neondb?connect_timeout=15&pool_timeout=15
+```
+
+## How to use Neon's serverless driver with Prisma ORM
+
+The [Neon serverless driver](https://github.com/neondatabase/serverless) is a low-latency Postgres driver for JavaScript and TypeScript that allows you to query data from serverless and edge environments over HTTP or WebSockets in place of TCP.
+
+You can use Prisma ORM along with the Neon serverless driver using a [driver adapter](/orm/overview/databases/database-drivers#driver-adapters) . A driver adapter allows you to use a different database driver from the default Prisma ORM provides to communicate with your database.
+
+:::info
+
+This feature has been Generally Available since Prisma ORM [v6.16.0](https://pris.ly/release/6.16.0).
+
+:::
+
+To get started, istall the Prisma ORM adapter for Neon:
+
+```terminal
+npm install @prisma/adapter-neon
+```
+
+Update your Prisma Client instance:
+
+```ts
+import { PrismaClient } from '@prisma/client'
+import { PrismaNeon } from '@prisma/adapter-neon'
+import dotenv from 'dotenv'
+
+dotenv.config()
+const connectionString = `${process.env.DATABASE_URL}`
+
+const adapter = new PrismaNeon({ connectionString })
+const prisma = new PrismaClient({ adapter })
+```
+
+You can then use Prisma Client as you normally would with full type-safety. Prisma Migrate, introspection, and Prisma Studio will continue working as before, using the connection string defined in the Prisma schema.
+
+### Notes
+
+#### Specifying a PostgreSQL schema
+
+You can specify a [PostgreSQL schema](https://www.postgresql.org/docs/current/ddl-schemas.html) by passing in the `schema` option when instantiating `PrismaNeon`:
+
+```ts
+const adapter = new PrismaNeon(
+ { connectionString },
+ { schema: 'myPostgresSchema' })
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/900-turso.mdx b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/900-turso.mdx
new file mode 100644
index 0000000000..d4bdb03925
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/900-turso.mdx
@@ -0,0 +1,236 @@
+---
+title: 'Turso'
+metaTitle: 'Turso (Early Access)'
+metaDescription: 'Guide to Turso'
+tocDepth: 3
+---
+
+This guide discusses the concepts behind using Prisma ORM and Turso, explains the commonalities and differences between Turso and other database providers, and leads you through the process for configuring your application to integrate with Turso.
+
+Prisma ORM support for Turso is currently in [Early Access](/orm/more/releases#early-access). We would appreciate your feedback in this [GitHub discussion](https://github.com/prisma/prisma/discussions/21345).
+
+## What is Turso?
+
+[Turso](https://turso.tech/) is an edge-hosted, distributed database that's based on [libSQL](https://turso.tech/libsql), an open-source and open-contribution fork of [SQLite](https://sqlite.org/), enabling you to bring data closer to your application and minimize query latency. Turso can also be hosted on a remote server.
+
+:::warning
+Support for Turso is available in [Early Access](/orm/more/releases#early-access) from Prisma ORM versions 5.4.2 and later.
+:::
+
+## Commonalities with other database providers
+
+libSQL is 100% compatible with SQLite. libSQL extends SQLite and adds the following features and capabilities:
+
+- Support for replication
+- Support for automated backups
+- Ability to embed Turso as part of other programs such as the Linux kernel
+- Supports user-defined functions
+- Support for asynchronous I/O
+
+> To learn more about the differences between libSQL and how it is different from SQLite, see [libSQL Manifesto](https://turso.tech/libsql-manifesto).
+
+Many aspects of using Prisma ORM with Turso are just like using Prisma ORM with any other relational database. You can still:
+
+- model your database with the [Prisma Schema Language](/orm/prisma-schema)
+- use Prisma ORM's existing [`sqlite` database connector](/orm/overview/databases/sqlite) in your schema
+- use [Prisma Client](/orm/prisma-client) in your application to talk to the database server at Turso
+
+## Differences to consider
+
+There are a number of differences between Turso and SQLite to consider. You should be aware of the following when deciding to use Turso and Prisma ORM:
+
+- **Remote and embedded SQLite databases**. libSQL uses HTTP to connect to the remote SQLite database. libSQL also supports remote database replicas and embedded replicas. Embedded replicas enable you to replicate your primary database inside your application.
+- **Making schema changes**. Since libSQL uses HTTP to connect to the remote database, this makes it incompatible with Prisma Migrate. However, you can use [`prisma migrate diff`](/orm/reference/prisma-cli-reference#migrate-diff) to create a schema migration and then apply the changes to your database using [Turso's CLI](https://docs.turso.tech/reference/turso-cli).
+
+## How to connect and query a Turso database
+
+The subsequent section covers how you can create a Turso database, retrieve your database credentials and connect to your database.
+
+### How to provision a database and retrieve database credentials
+
+:::info
+
+Ensure that you have the [Turso CLI](https://docs.turso.tech/reference/turso-cli) installed to manage your databases.
+
+:::
+
+If you don't have an existing database, you can provision a database by running the following command:
+
+```terminal
+turso db create turso-prisma-db
+```
+
+The above command will create a database in the closest region to your location.
+
+Run the following command to retrieve your database's connection string:
+
+```terminal
+turso db show turso-prisma-db
+```
+
+Next, create an authentication token that will allow you to connect to the database:
+
+```terminal
+turso db tokens create turso-prisma-db
+```
+
+Update your `.env` file with the authentication token and connection string:
+
+```bash file=.env
+TURSO_AUTH_TOKEN="eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9..."
+TURSO_DATABASE_URL="libsql://turso-prisma-db-user.turso.io"
+```
+
+### How to connect to a Turso database
+
+To get started, install the Prisma ORM driver adapter for libSQL packages:
+
+```terminal
+npm install @prisma/adapter-libsql
+```
+
+Update your Prisma Client instance:
+
+```ts
+import { PrismaClient } from '@prisma/client'
+import { PrismaLibSQL } from '@prisma/adapter-libsql'
+
+const adapter = new PrismaLibSQL({
+ url: `${process.env.TURSO_DATABASE_URL}`,
+ authToken: `${process.env.TURSO_AUTH_TOKEN}`,
+})
+const prisma = new PrismaClient({ adapter })
+```
+
+You can use Prisma Client as you normally would with full type-safety in your project.
+
+## Using Prisma Migrate via a driver adapter in Prisma Config
+
+As of [Prisma v6.6.0](https://github.com/prisma/prisma/releases/tag/6.6.0) we added support for the Prisma Config file. You can use the Prisma Config file to perform `prisma db push` and make changes to your database schema. You can learn more about [the Prisma Config file in our reference page](/orm/reference/prisma-config-reference).
+
+### 1. Install the LibSQL driver adapter
+
+Run this command in your terminal:
+
+```termina
+npm install @prisma/adapter-libsql
+```
+
+### 2. Set environment variables
+
+In order to set up the LibSQL adapter, you'll need to add a few secrets to a `.env` file:
+
+- `LIBSQL_DATABASE_URL`: The connection URL of your Turso database instance.
+- `LIBSQL_DATABASE_TOKEN`: The token of your Turso database instance.
+
+You can then add these to your `.env` file or use them directly if they are stored in a different secret store:
+
+```bash file=.env
+LIBSQL_DATABASE_URL="..."
+LIBSQL_DATABASE_TOKEN="..."
+```
+
+### 3. Set up Prisma Config file
+
+Make sure that you have a [`prisma.config.ts`](/orm/reference/prisma-config-reference) file for your project. Then, set up the [migration driver adapter](/orm/reference/prisma-config-reference#adapter) to use `PrismaLibSQL`:
+
+```ts file=prisma.config.ts
+import path from 'node:path'
+import { defineConfig } from 'prisma/config'
+import { PrismaLibSQL } from '@prisma/adapter-libsql'
+
+// import your .env file
+import 'dotenv/config'
+
+export default defineConfig({
+ experimental: {
+ adapter: true,
+ },
+ schema: path.join('prisma', 'schema.prisma'),
+ async adapter() {
+ return new PrismaLibSQL({
+ url: process.env.LIBSQL_DATABASE_URL,
+ authToken: process.env.LIBSQL_DATABASE_TOKEN,
+ })
+ }
+})
+```
+
+### 4. Migrate your database
+
+Prisma Migrate now will run migrations against your remote Turso database based on the configuration provided in `prisma.config.ts`.
+
+To create your first migration with this workflow, run the following command:
+
+```terminal
+npx prisma db push
+```
+
+## Embedded Turso database replicas
+
+Turso supports [embedded replicas](https://turso.tech/blog/introducing-embedded-replicas-deploy-turso-anywhere-2085aa0dc242). Turso's embedded replicas enable you to have a copy of your primary, remote database _inside_ your application. Embedded replicas behave similarly to a local SQLite database. Database queries are faster because your database is inside your application.
+
+### How embedded database replicas work
+
+When your app initially establishes a connection to your database, the primary database will fulfill the query:
+
+
+
+Turso will (1) create an embedded replica inside your application and (2) copy data from your primary database to the replica so it is locally available:
+
+
+
+The embedded replica will fulfill subsequent read queries. The libSQL client provides a [`sync()`](https://docs.turso.tech/sdk/ts/reference#manual-sync) method which you can invoke to ensure the embedded replica's data remains fresh.
+
+
+
+With embedded replicas, this setup guarantees a responsive application, because the data will be readily available locally and faster to access.
+
+Like a read replica setup you may be familiar with, write operations are forwarded to the primary remote database and executed before being propagated to all embedded replicas.
+
+
+
+1. Write operations propagation are forwarded to the database.
+1. Database responds to the server with the updates from 1.
+1. Write operations are propagated to the database replica.
+
+Your application's data needs will determine how often you should synchronize data between your remote database and embedded database replica. For example, you can use either middleware functions (e.g. Express and Fastify) or a cron job to synchronize the data.
+
+### How to synchronize data between your remote database and embedded replica
+
+To get started using embedded replicas with Prisma ORM, add the `sync()` method from libSQL in your application. The example below shows how you can synchronize data using Express middleware.
+
+```ts highlight=5-8;add;
+import express from 'express'
+const app = express()
+
+// ... the rest of your application code
+//add-start
+app.use(async (req, res, next) => {
+ await libsql.sync()
+ next()
+})
+//add-end
+
+app.listen(3000, () => console.log(`Server ready at http://localhost:3000`))
+```
+It could be also implemented as a [Prisma Client extension](/orm/prisma-client/client-extensions). The below example shows auto-syncing after create, update or delete operation is performed.
+
+```ts highlight=5-8
+const prisma = new PrismaClient().$extends({
+ query: {
+ $allModels: {
+ async $allOperations({ operation, model, args, query }) {
+ const result = await query(args)
+
+ // Synchronize the embedded replica after any write operation
+ if (['create', 'update', 'delete'].includes(operation)) {
+ await libsql.sync()
+ }
+
+ return result
+ }
+ }
+ }
+})
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/950-cloudflare-d1.mdx b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/950-cloudflare-d1.mdx
new file mode 100644
index 0000000000..3f6da24c51
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/950-cloudflare-d1.mdx
@@ -0,0 +1,332 @@
+---
+title: 'Cloudflare D1'
+metaTitle: 'Cloudflare D1'
+metaDescription: 'Guide to Cloudflare D1'
+tocDepth: 3
+preview: true
+---
+
+This page discusses the concepts behind using Prisma ORM and Cloudflare D1, explains the commonalities and differences between Cloudflare D1 and other database providers, and leads you through the process for configuring your application to integrate with Cloudflare D1.
+
+Prisma ORM support for Cloudflare D1 is currently in [Preview](/orm/more/releases#preview). We would appreciate your feedback [on GitHub](https://github.com/prisma/prisma/discussions/23646).
+
+If you want to deploy a Cloudflare Worker with D1 and Prisma ORM, follow this [tutorial](/guides/cloudflare-d1).
+
+## What is Cloudflare D1?
+
+D1 is Cloudflare's native serverless database and was initially [launched in 2022](https://blog.cloudflare.com/introducing-d1/). It's based on SQLite and can be used when deploying applications with Cloudflare Workers.
+
+Following Cloudflare's principles of geographic distribution and bringing compute and data closer to application users, D1 supports automatic read-replication. It dynamically manages the number of database instances and locations of read-only replicas based on how many queries a database is getting, and from where.
+
+For write-operations, queries travel to a single primary instance in order to propagate the changes to all read-replicas and ensure data consistency.
+
+## Commonalities with other database providers
+
+D1 is based on SQLite.
+
+Many aspects of using Prisma ORM with D1 are just like using Prisma ORM with any other relational database. You can still:
+
+- model your database with the [Prisma Schema Language](/orm/prisma-schema)
+- use Prisma ORM's existing [`sqlite` database connector](/orm/overview/databases/sqlite) in your schema
+- use [Prisma Client](/orm/prisma-client) in your application to talk to the database server at D1
+
+## Differences to consider
+
+There are a number of differences between D1 and SQLite to consider. You should be aware of the following when deciding to use D1 and Prisma ORM:
+
+- **Making schema changes**. As of [v6.6.0](https://pris.ly/release/6.6.0) and with a `prisma.config.ts` file, you can use `prisma db push`. However, if you prefer a Cloudflare first approach, you can use D1's [migration system](https://developers.cloudflare.com/d1/reference/migrations/) and the [`prisma migrate diff`](/orm/reference/prisma-cli-reference#migrate-diff) command for your migration workflows. See the [Schema migrations with Prisma ORM on D1](#schema-migrations-with-prisma-orm-on-d1) section below for more information.
+- **Local and remote D1 (SQLite) databases**. Cloudflare provides local and remote versions of D1. The [local](https://developers.cloudflare.com/d1/build-with-d1/local-development/) version is managed using the `--local` option of the `wrangler d1` CLI and is located in `.wrangler/state`. The [remote](https://developers.cloudflare.com/d1/build-with-d1/remote-development/) version is managed by Cloudflare and is accessed via HTTP.
+
+## How to connect to D1 in Cloudflare Workers or Cloudflare Pages
+
+When using Prisma ORM with D1, you need to use the `sqlite` database provider and the `@prisma/adapter-d1` [driver adapter](/orm/overview/databases/database-drivers#driver-adapters).
+
+If you want to deploy a Cloudflare Worker with D1 and Prisma ORM, follow these [step-by-step instructions](/guides/cloudflare-d1).
+
+## Schema migrations with Prisma ORM on D1
+
+You can use two approaches for migrating your database schema with Prisma ORM and D1:
+- Using `prisma db push` via a driver adapter in `prisma.config.ts`
+- Using the Wrangler CLI
+
+### Using Prisma Migrate via a driver adapter in Prisma Config
+
+As of [Prisma v6.6.0](https://github.com/prisma/prisma/releases/tag/6.6.0) we added support for the Prisma Config file. You can use the Prisma Config file to perform `prisma db push` and make changes to your database schema. You can learn more about [the Prisma Config file in our reference page](/orm/reference/prisma-config-reference).
+
+#### 1. Install the Prisma D1 driver adapter
+
+Run this command in your terminal:
+
+```terminal
+npm install @prisma/adapter-d1
+```
+
+#### 2. Set environment variables
+
+In order to set up the D1 adapter, you'll need to add a few secrets to a `.env` file:
+
+- `CLOUDFLARE_ACCOUNT_ID`: Your Cloudflare account ID, fetched via `npx wrangler whoami`.
+- `CLOUDFLARE_DATABASE_ID`: Retrieved during D1 database creation. If you have an existing D1 database, you can use `npx wrangler d1 list` and `npx wrangler d1 info ` to get the ID.
+- `CLOUDFLARE_D1_TOKEN`: This API token is used by Prisma ORM to communicate with your D1 instance directly. To create it, follow these steps:
+ 1. Visit https://dash.cloudflare.com/profile/api-tokens
+ 2. Click **Create Token**
+ 3. Click **Custom token** template
+ 4. Fill out the template: Make sure you use a recognizable name and add the **Account / D1 / Edit** permission.
+ 5. Click **Continue to summary** and then **Create Token**.
+
+You can then add these to your `.env` file or use them directly if they are stored in a different secret store:
+
+```bash file=.env
+CLOUDFLARE_ACCOUNT_ID="0773..."
+CLOUDFLARE_DATABASE_ID="01f30366-..."
+CLOUDFLARE_D1_TOKEN="F8Cg..."
+```
+
+#### 3. Set up Prisma Config file
+
+Make sure that you have a [`prisma.config.ts`](/orm/reference/prisma-config-reference) file for your project. Then, set up the [migration driver adapter](/orm/reference/prisma-config-reference#adapter) to reference D1:
+
+```ts file=prisma.config.ts
+import type { PrismaConfig } from 'prisma';
+import { PrismaD1 } from '@prisma/adapter-d1';
+
+// import your .env file
+import 'dotenv/config';
+
+export default {
+ // add-start
+ experimental: {
+ adapter: true,
+ },
+ // add-end
+ schema: 'prisma/schema.prisma',
+ // add-start
+ async adapter() {
+ return new PrismaD1({
+ CLOUDFLARE_D1_TOKEN: process.env.CLOUDFLARE_D1_TOKEN!,
+ CLOUDFLARE_ACCOUNT_ID: process.env.CLOUDFLARE_ACCOUNT_ID!,
+ CLOUDFLARE_DATABASE_ID: process.env.CLOUDFLARE_DATABASE_ID!,
+ });
+ },
+ // add-end
+} satisfies PrismaConfig;
+```
+
+:::note
+
+As of [Prisma ORM v6.11.0](https://github.com/prisma/prisma/releases/tag/6.11.0), the D1 adapter has been renamed from `PrismaD1HTTP` to `PrismaD1`.
+
+:::
+
+#### 4. Migrate your database
+
+Prisma Migrate now will run migrations against your remote D1 database based on the configuration provided in `prisma.config.ts`.
+
+To update the remote schema with this workflow, run the following command:
+
+```terminal
+npx prisma db push
+```
+
+:::note
+
+Note that for querying the database, you keep using the `PrismaD1` driver adapter from the `@prisma/adapter-d1` package:
+
+```ts
+import { PrismaD1 } from '@prisma/adapter-d1'
+```
+
+:::
+
+### Using the Wrangler CLI
+
+Cloudflare D1 comes with its own [migration system](https://developers.cloudflare.com/d1/reference/migrations/). While we recommend that you use the [native Prisma Migrate workflow](#using-prisma-migrate-via-a-driver-adapter-in-prisma-config), this migration system via the `wrangler d1 migrations` command is available.
+
+This command doesn't help you in figuring out the SQL statements for creating your database schema that need to be put _inside_ of these migration files though. If you want to query your database using Prisma Client, it's important that your database schema maps to your Prisma schema, this is why it's recommended to generate the SQL statements from your Prisma schema.
+
+When using D1, you can use the [`prisma migrate diff`](/orm/reference/prisma-cli-reference#migrate-diff) command for that purpose.
+
+#### Creating an initial migration
+
+The workflow for creating an initial migration looks as follows. Assume you have a fresh D1 instance without any tables.
+
+##### 1. Update your Prisma data model
+
+This is your initial version of the Prisma schema that you want to map to your D1 instance:
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+}
+```
+
+##### 2. Create migration file using `wrangler` CLI
+
+Next, you need to create the migration file using the [`wrangler d1 migrations create`](https://developers.cloudflare.com/workers/wrangler/commands/#migrations-create) command:
+
+```terminal
+npx wrangler d1 migrations create __YOUR_DATABASE_NAME__ create_user_table
+```
+
+Since this is the very first migration, this command will prompt you to also create a `migrations` folder. Note that if you want your migration files to be stored in a different location, you can [customize it using Wrangler](https://developers.cloudflare.com/d1/reference/migrations/#wrangler-customizations).
+
+Once the command has executed and assuming you have chosen the default `migrations` name for the location of your migration files, the command has created the following folder and file for you:
+
+```no-copy
+migrations/
+└── 0001_create_user_table.sql
+```
+
+However, before you can apply the migration to your D1 instance, you actually need to put a SQL statement into the currently empty `0001_create_user_table.sql` file.
+
+##### 3. Generate SQL statements using `prisma migrate diff`
+
+To generate the initial SQL statement, you can use the `prisma migrate diff` command which compares to _schemas_ (via its `--to-X` and `--from-X` options) and generates the steps that are needed to "evolve" from one to the other. These schemas can be either Prisma or SQL schemas.
+
+For the initial migration, you can use the special `--from-empty` option though:
+
+```terminal
+npx prisma migrate diff \
+ --from-empty \
+ --to-schema-datamodel ./prisma/schema.prisma \
+ --script \
+ --output migrations/0001_create_user_table.sql
+```
+
+The command above uses the following options:
+
+- `--from-empty`: The source for the SQL statement is an empty schema.
+- `--to-schema-datamodel ./prisma/schema.prisma`: The target for the SQL statement is the data model in `./prisma/schema.prisma`.
+- `--script`: Output the result as SQL. If you omit this option, the "migration steps" will be generated in plain English.
+- `--output migrations/0001_create_user_table.sql`: Store the result in `migrations/0001_create_user_table.sql`.
+
+After running this command, `migrations/0001_create_user_table.sql` will have the following contents:
+
+```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");
+```
+
+##### 4. Execute the migration using `wrangler d1 migrations apply`
+
+Finally, you can apply the migration against your D1 instances.
+
+For the **local** instance, run:
+
+```terminal
+npx wrangler d1 migrations apply __YOUR_DATABASE_NAME__ --local
+```
+
+For the **remote** instance, run:
+
+```terminal
+npx wrangler d1 migrations apply __YOUR_DATABASE_NAME__ --remote
+```
+
+#### Evolve your schema with further migrations
+
+For any further migrations, you can use the same workflow but instead of using `--from-empty`, you'll need to use `--from-local-d1` because your source schema for the `prisma migrate diff` command now is the current schema of that local D1 instance, while the target remains your (then updated) Prisma schema.
+
+##### 1. Update your Prisma data model
+
+Assume you have updated your Prisma schema with another model:
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ posts Post[]
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+}
+```
+
+##### 2. Create migration file using `wrangler` CLI
+
+Like before, you first need to create the migration file:
+
+```terminal
+npx wrangler d1 migrations create __YOUR_DATABASE_NAME__ create_post_table
+```
+
+Once the command has executed (again assuming you have chosen the default `migrations` name for the location of your migration files), the command has created a new file inside of the `migrations` folder:
+
+```no-copy
+migrations/
+├── 0001_create_user_table.sql
+└── 0002_create_post_table.sql
+```
+
+As before, you now need to put a SQL statement into the currently empty `0002_create_post_table.sql` file.
+
+##### 3. Generate SQL statements using `prisma migrate diff`
+
+As explained above, you now need to use `--from-local-d1` instead of `--from-empty` to specify a source schema:
+
+```terminal
+npx prisma migrate diff \
+ --from-local-d1 \
+ --to-schema-datamodel ./prisma/schema.prisma \
+ --script \
+ --output migrations/0002_create_post_table.sql
+```
+
+The command above uses the following options:
+
+- `--from-local-d1`: The source for the SQL statement is the local D1 database file.
+- `--to-schema-datamodel ./prisma/schema.prisma`: The target for the SQL statement is the data model in `./prisma/schema.prisma`.
+- `--script`: Output the result as SQL. If you omit this option, the "migration steps" will be generated in plain English.
+- `--output migrations/0002_create_post_table.sql`: Store the result in `migrations/0002_create_post_table.sql`.
+
+After running this command, `migrations/0002_create_post_table.sql` will have the following contents:
+
+```sql file=migrations/0002_create_post_table.sql no-copy
+-- CreateTable
+CREATE TABLE "Post" (
+ "id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
+ "title" TEXT NOT NULL,
+ "authorId" INTEGER NOT NULL,
+ CONSTRAINT "Post_authorId_fkey" FOREIGN KEY ("authorId") REFERENCES "User" ("id") ON DELETE RESTRICT ON UPDATE CASCADE
+);
+```
+
+##### 4. Execute the migration using `wrangler d1 migrations apply`
+
+Finally, you can apply the migration against your D1 instances.
+
+For the **local** instance, run:
+
+```terminal
+npx wrangler d1 migrations apply __YOUR_DATABASE_NAME__ --local
+```
+
+For the **remote** instance, run:
+
+```terminal
+npx wrangler d1 migrations apply __YOUR_DATABASE_NAME__ --remote
+```
+
+## Limitations
+
+### Transactions not supported
+
+Cloudflare D1 currently does not support transactions (see the [open feature request](https://github.com/cloudflare/workers-sdk/issues/2733)). As a result, Prisma ORM does not support transactions for Cloudflare D1. When using Prisma's D1 adapter, implicit & explicit transactions will be ignored and run as individual queries, which breaks the guarantees of the ACID properties of transactions.
+
+### Prisma Migrate only supports remote D1 databases
+
+The Wrangler CLI can distinguish between local and remote D1 (i.e. SQLite) database instances via the `--local` and `--remote` options. This distinction is currently not available with the [native Prisma Migrate workflow](#using-prisma-migrate-via-a-driver-adapter-in-prisma-config).
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/images/drivers/qe-query-engine-adapter.png b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/images/drivers/qe-query-engine-adapter.png
new file mode 100644
index 0000000000..068f9c76c5
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/images/drivers/qe-query-engine-adapter.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/images/drivers/qe-query-execution-flow.png b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/images/drivers/qe-query-execution-flow.png
new file mode 100644
index 0000000000..aca500b4fe
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/images/drivers/qe-query-execution-flow.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/images/embedded-replica-create-replica.png b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/images/embedded-replica-create-replica.png
new file mode 100644
index 0000000000..830501d9c2
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/images/embedded-replica-create-replica.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/images/embedded-replica-read.png b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/images/embedded-replica-read.png
new file mode 100644
index 0000000000..0edaebcf2e
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/images/embedded-replica-read.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/images/embedded-replica-remote-read.png b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/images/embedded-replica-remote-read.png
new file mode 100644
index 0000000000..7762e8bfaa
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/images/embedded-replica-remote-read.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/images/embedded-replica-write-propagation.png b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/images/embedded-replica-write-propagation.png
new file mode 100644
index 0000000000..fa36c87335
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/images/embedded-replica-write-propagation.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/index.mdx b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/index.mdx
new file mode 100644
index 0000000000..b6f32c43e5
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/index.mdx
@@ -0,0 +1,16 @@
+---
+title: 'Databases'
+metaTitle: 'Databases'
+metaDescription: 'Databases'
+hide_table_of_contents: true
+---
+
+
+
+Learn about the different databases Prisma ORM supports.
+
+
+
+## In this section
+
+
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/mongodb.png b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/mongodb.png
new file mode 100644
index 0000000000..192f87b08d
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/mongodb.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/mysql-connection-string.png b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/mysql-connection-string.png
new file mode 100644
index 0000000000..5ded2e0d6f
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/mysql-connection-string.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/postgresql-connection-string.png b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/postgresql-connection-string.png
new file mode 100644
index 0000000000..56e7347da5
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/050-overview/500-databases/postgresql-connection-string.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/600-beyond-prisma-orm.mdx b/versioned_docs/version-6.0.0/200-orm/050-overview/600-beyond-prisma-orm.mdx
new file mode 100644
index 0000000000..bcb0a883e0
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/600-beyond-prisma-orm.mdx
@@ -0,0 +1,78 @@
+---
+title: Beyond Prisma ORM
+sidebar_label: Beyond Prisma ORM
+description: Prisma ORM addresses many development needs, but Prisma's additional products like Prisma Postgres, Accelerate and Optimize can further enhance scalability and performance for your applications.
+---
+
+As a Prisma ORM user, you're already experiencing the power of type-safe database queries and intuitive data modeling. When scaling production applications, however, new challenges emerge. As an app matures it’s a given that you’ll begin to experience connection pooling complexities or find ways to effectively cache common queries.
+
+Instead of spending your valuable time overcoming these challenges, let’s explore how Prisma can help by extending the capabilities of the ORM as your application grows.
+
+## Boost application performance with Prisma Accelerate
+
+As your application scales, you'll likely need tools to handle increased traffic efficiently. This often involves implementing connection pooling to manage database connections and caching strategies to reduce database load and improve response times. Prisma Accelerate addresses these needs in a single solution, eliminating the need to set up and manage separate infrastructure.
+
+Prisma Accelerate is particularly useful for applications deployed to serverless and edge environments (also know as Function-as-a-Service) because these deployments lend themselves towards many orders of magnitude more connections being created than a traditional, long-lived application. For these apps, Prisma Accelerate has the added benefit of protecting your database from day one and keeping your app online [regardless of traffic you experience](https://www.prisma.io/blog/saving-black-friday-with-connection-pooling).
+
+Try out the [Accelerate speed test](https://accelerate-speed-test.prisma.io/) to see what’s possible.
+
+### Improve query performance with connection pooling
+
+Place your connection pooler in one of 15+ global regions, minimizing latency for database operations. Enable high-performance distributed workloads across serverless and edge environments.
+
+### Reduce query latency and database load with caching
+
+Cache query results across 300+ global points of presence. Accelerate extends your Prisma Client, offering intuitive, granular control over caching patterns such as `ttl` and `swr` on a per-query basis.
+
+### Handle scaling traffic with managed infrastructure
+
+Scale to millions of queries per day without infrastructure changes. Efficiently manage database connections and serve more users with fewer resources.
+
+### Get started with Accelerate today
+
+Accelerate integrates seamlessly with your Prisma ORM project through the `@prisma/extension-accelerate` client extension. Get started quickly with our [setup guide](/accelerate/getting-started) and instantly access full edge environment support, connection pooling, and global caching.
+
+```tsx
+import { PrismaClient } from '@prisma/client'
+import { withAccelerate } from '@prisma/extension-accelerate'
+
+// 1. Extend your Prisma Client with the Accelerate extension
+const prisma = new PrismaClient().$extends(withAccelerate())
+
+// 2. (Optionally) add cache to your Prisma queries
+const users = await prisma.user.findMany({
+ cacheStrategy: {
+ ttl: 30, // Consider data fresh for 30 seconds
+ swr: 60 // Serve stale data for up to 60 seconds while fetching fresh data
+ }
+})
+```
+
+To see more examples, visit our [examples repo](https://github.com/prisma/prisma-examples) or try them out yourself with `npx try-prisma`.
+
+[Sign up for Accelerate](https://console.prisma.io/login)
+
+## Grow with Prisma
+
+Prisma Accelerate take features built into Prisma ORM and build upon them by adding additional capabilities like globally-optimized caching and connection pooling. Get started for free the [Prisma Data Platform](https://console.prisma.io/login) and explore how Accelerate can help you build scalable, high-performance applications!
+
+Improving developer experience doesn’t stop at Accelerate. Prisma is building and expanding our products, such as [Prisma Optimize](https://www.prisma.io/optimize) and [Prisma Postgres](https://www.prisma.io/postgres), to improve every aspect of Data DX and we’d love to hear what you think. Join our community and learn more about our products below.
+
+Accelerate and Optimize build on Prisma ORM through [Prisma Client Extensions](/orm/prisma-client/client-extensions). This opens up features that we couldn’t include in the ORM like globally-optimized caching and connection pooling. Create a free [Prisma Data Platform](https://console.prisma.io/login) account and explore how Accelerate can help you build scalable, high-performance applications!
+
+Improving developer experience doesn’t stop at Prisma Postgres, Accelerate and Optimize. Prisma is building and expanding our products to improve every aspect of Data DX and we’d love to hear what you think. Join our community and learn more about our products below
+
+
+
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/_category_.json b/versioned_docs/version-6.0.0/200-orm/050-overview/_category_.json
new file mode 100644
index 0000000000..42c3080f16
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/_category_.json
@@ -0,0 +1,5 @@
+{
+ "label": "Overview",
+ "collapsible": false,
+ "collapsed": false
+}
diff --git a/versioned_docs/version-6.0.0/200-orm/050-overview/index.mdx b/versioned_docs/version-6.0.0/200-orm/050-overview/index.mdx
new file mode 100644
index 0000000000..0167695db8
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/050-overview/index.mdx
@@ -0,0 +1,13 @@
+---
+title: 'Overview'
+sidebar_label: 'Overview'
+metaTitle: 'Overview'
+metaDescription: 'Overview'
+staticLink: true
+hide_table_of_contents: true
+---
+
+
+## In this section
+
+
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/10-overview/02-data-sources.mdx b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/10-overview/02-data-sources.mdx
new file mode 100644
index 0000000000..ff10a603d4
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/10-overview/02-data-sources.mdx
@@ -0,0 +1,42 @@
+---
+title: 'Data sources'
+metaTitle: 'Data sources (Reference)'
+metaDescription: 'Data sources enable Prisma to connect to your database. This page explains how to configure data sources in your Prisma schema.'
+---
+
+A data source determines how Prisma ORM connects to your database, and is represented by the [`datasource`](/orm/reference/prisma-schema-reference#datasource) block in the Prisma schema. The following data source uses the `postgresql` provider and includes a connection URL:
+
+```prisma
+datasource db {
+ provider = "postgresql"
+ url = "postgresql://johndoe:mypassword@localhost:5432/mydb?schema=public"
+}
+```
+
+A Prisma schema can only have _one_ data source. However, you can:
+
+- [Programmatically override a data source `url` when creating your `PrismaClient`](/6.0/orm/reference/prisma-client-reference#programmatically-override-a-datasource-url)
+- [Specify a different URL for Prisma Migrate's shadow database if you are working with cloud-hosted development databases](/orm/prisma-migrate/understanding-prisma-migrate/shadow-database#cloud-hosted-shadow-databases-must-be-created-manually)
+
+> **Note**: Multiple provider support was removed in 2.22.0. Please see [Deprecation of provider array notation](https://github.com/prisma/prisma/issues/3834) for more information.
+
+## Securing database connections
+
+Some data source `provider`s allow you to configure your connection with SSL/TLS, and provide parameters for the `url` to specify the location of certificates.
+
+- [Configuring an SSL connection with PostgreSQL](/orm/overview/databases/postgresql#configuring-an-ssl-connection)
+- [Configuring an SSL connection with MySQL](/orm/overview/databases/mysql#configuring-an-ssl-connection)
+- [Configure a TLS connection with Microsoft SQL Server](/orm/overview/databases/sql-server#connection-details)
+
+Prisma ORM resolves SSL certificates relative to the `./prisma` directory. If your certificate files are located outside that directory, e.g. your project root directory, use relative paths for certificates:
+
+:::note
+When you're using a [multi-file Prisma schema](/orm/prisma-schema/overview/location#multi-file-prisma-schema), Prisma ORM resolves SSL certificates relative to the `./prisma/schema` directory.
+:::
+
+```prisma
+datasource db {
+ provider = "postgresql"
+ url = "postgresql://johndoe:mypassword@localhost:5432/mydb?schema=public&sslmode=require&sslcert=../server-ca.pem&sslidentity=../client-identity.p12&sslpassword="
+}
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/10-overview/03-generators.mdx b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/10-overview/03-generators.mdx
new file mode 100644
index 0000000000..843aef49f0
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/10-overview/03-generators.mdx
@@ -0,0 +1,445 @@
+---
+title: "Generators"
+metaTitle: "Generators (Reference)"
+metaDescription: "Generators in your Prisma schema specify what assets are generated when the `prisma generate` command is invoked. This page explains how to configure generators."
+---
+
+A Prisma schema can have one or more generators, represented by the [`generator`](/orm/reference/prisma-schema-reference#generator) block:
+
+```prisma
+generator client {
+ provider = "prisma-client"
+ output = "../generated/prisma"
+}
+```
+
+A generator determines which assets are created when you run the `prisma generate` command.
+
+There are two generators for Prisma Client:
+
+- `prisma-client` (recommended): Newer and more flexible version of `prisma-client-js` with ESM support; it outputs plain TypeScript code and _requires_ a custom `output` path (read more about it [here](https://www.prisma.io/blog/why-prisma-orm-generates-code-into-node-modules-and-why-it-ll-change))
+- `prisma-client-js`: Generates Prisma Client into `node_modules`
+
+Alternatively, you can configure any npm package that complies with our generator specification.
+
+## `prisma-client-js`
+
+The `prisma-client-js` is the default generator for Prisma ORM 6.X versions and before. It requires the `@prisma/client` npm package and generates Prisma Client into `node_modules`.
+
+### Field reference
+
+The generator for Prisma's JavaScript Client accepts multiple additional properties:
+
+- `previewFeatures`: [Preview features](/orm/reference/preview-features) to include
+- `binaryTargets`: Engine binary targets for `prisma-client-js` (for example, `debian-openssl-1.1.x` if you are deploying to Ubuntu 18+, or `native` if you are working locally)
+
+```prisma
+generator client {
+ provider = "prisma-client-js"
+ previewFeatures = ["sample-preview-feature"]
+ binaryTargets = ["debian-openssl-1.1.x"] // defaults to `"native"`
+}
+```
+
+### Binary targets
+
+:::note
+
+As of [v6.16.0](https://pris.ly/release/6.16.0), Prisma ORM can be used without Rust engines in production applications. Learn more [here](/orm/prisma-client/setup-and-configuration/no-rust-engine).
+
+**When enabled, your Prisma Client will be generated without a Rust-based query engine binary**:
+
+```prisma
+generator client {
+ provider = "prisma-client-js" // or "prisma-client"
+ output = "../src/generated/prisma"
+ engineType = "client" // no Rust engine
+}
+```
+
+Note that [driver adapters](/orm/overview/databases/database-drivers#driver-adapters) are required if you want to use Prisma ORM without Rust engines.
+
+When using Prisma ORM without Rust, the `binaryTargets` field is obsolete and not needed.
+
+You can [read about the performance and DX improvements](https://www.prisma.io/blog/prisma-orm-without-rust-latest-performance-benchmarks) of this change on our blog.
+
+:::
+
+The `prisma-client-js` generator uses several [engines](https://github.com/prisma/prisma-engines). Engines are implemented in Rust and are used by Prisma Client in the form of executable, platform-dependent engine files. Depending on which platform you are executing your code on, you need the correct file. "Binary targets" are used to define which files should be present for the target platform(s).
+
+The correct file is particularly important when [deploying](/orm/prisma-client/deployment/deploy-prisma) your application to production, which often differs from your local development environment.
+
+#### The `native` binary target
+
+The `native` binary target is special. It doesn't map to a concrete operating system. Instead, when `native` is specified in `binaryTargets`, Prisma Client detects the _current_ operating system and automatically specifies the correct binary target for it.
+
+As an example, assume you're running **macOS** and you specify the following generator:
+
+```prisma file=prisma/schema.prisma
+generator client {
+ provider = "prisma-client-js"
+ binaryTargets = ["native"]
+}
+```
+
+In that case, Prisma Client detects your operating system and finds the right binary file for it based on the [list of supported operating systems](/orm/reference/prisma-schema-reference#binarytargets-options) .
+If you use macOS Intel x86 (`darwin`), then the binary file that was compiled for `darwin` will be selected.
+If you use macOS ARM64 (`darwin-arm64`), then the binary file that was compiled for `darwin-arm64` will be selected.
+
+> **Note**: The `native` binary target is the default. You can set it explicitly if you wish to include additional [binary targets](/orm/reference/prisma-schema-reference#binarytargets-options) for deployment to different environments.
+
+## `prisma-client`
+
+The new `prisma-client` generator offers greater control and flexibility when using Prisma ORM across different JavaScript environments (such as ESM, Bun, Deno, ...).
+
+It generates Prisma Client into a custom directory in your application's codebase that's specified via the `output` field on the `generator` block. This gives you full visibility and control over the generated code. It also [splits](#importing-types) the generated Prisma Client library into multiple files.
+
+This generator ensures you can bundle your application code exactly the way you want, without relying on hidden or automatic behaviors.
+
+Here are the main differences compared to `prisma-client-js`:
+
+- Requires an `output` path; no "magic" generation into `node_modules` any more
+- Doesn't load `.env` at runtime; use `dotenv` or set environment variables manually instead
+- Supports ESM and CommonJS via the `moduleFormat` field
+- More flexible thanks to additional [fields](#field-reference)
+- Outputs plain TypeScript that's bundled just like the rest of your application code
+
+The `prisma-client` generator has been Generally Available since [v6.16.0](https://pris.ly/releases/6.16.0) will become the new default with Prisma ORM v7.
+
+### Getting started
+
+Follow these steps to use the new `prisma-client` generator in your project.
+
+#### 1. Configure the `prisma-client` generator in `schema.prisma`
+
+Update your [`generator`](/orm/prisma-schema/overview/generators) block:
+
+```prisma file=prisma/schema.prisma
+generator client {
+ //add-start
+ provider = "prisma-client" // Required
+ output = "../src/generated/prisma" // Required
+ //add-end
+}
+```
+
+The **`output` option is required** and tells Prisma ORM where to put the generated Prisma Client code. You can choose any location suitable for your project structure. For instance, if you have the following layout:
+
+```txt
+.
+├── package.json
+├── prisma
+│ └── schema.prisma
+├── src
+│ └── index.ts
+└── tsconfig.json
+```
+
+Then `../src/generated/prisma` places the generated code in `src/generated/prisma` relative to `schema.prisma`.
+
+#### 2. Generate Prisma Client
+
+Generate Prisma Client by running:
+
+```terminal
+npx prisma generate
+```
+
+This generates the code for Prisma Client (including the query engine binary) into the specified `output` folder.
+
+#### 3. Exclude the generated directory from version control
+
+The new generator includes both the TypeScript client code _and_ the [query engine](/orm/more/under-the-hood/engines#the-query-engine-file). Including the query engine in version control can cause compatibility issues on different machines. To avoid this, add the generated directory to `.gitignore`:
+
+```bash file=.gitignore
+# Keep the generated Prisma Client + query engine out of version control
+/src/generated/prisma
+```
+
+:::note
+
+In the future, you can safely include the generated directory in version control when [Prisma ORM is fully transitioned from Rust to TypeScript](https://www.prisma.io/blog/rust-to-typescript-update-boosting-prisma-orm-performance?utm_source=docs&utm_medium=inline_text).
+
+:::
+
+#### 4. Use Prisma Client in your application
+
+#### Importing Prisma Client
+
+After generating the Prisma Client, import it from the path you specified:
+
+```ts file=src/index.ts
+import { PrismaClient } from "./generated/prisma/client";
+
+const prisma = new PrismaClient();
+```
+
+Prisma Client is now ready to use in your project.
+
+#### Importing generated model types
+
+If you're importing types generated for your models, you can do so as follows:
+
+```ts file=src/index.ts
+import { UserModel, PostModel } from "./generated/prisma/models";
+```
+
+#### Importing generated enum types
+
+If you're importing types generated for your enums, you can do so as follows:
+
+```ts file=src/index.ts
+import { Role, User } from "./generated/prisma/enums";
+```
+
+#### Importing in browser environments
+
+If you need to access generated types in your frontend code, you can import them as follows:
+
+```ts file=src/index.ts
+import { Role } from "./generated/prisma/browser";
+```
+
+Note that `./generated/prisma/browser` does not expose a `PrismaClient`.
+
+### Field reference
+
+Use the following options in the `generator client { ... }` block. Only `output` is required. The other fields have defaults or are inferred from your environment and `tsconfig.json`.
+
+```prisma file=schema.prisma
+generator client {
+ // Required
+ provider = "prisma-client"
+ output = "../src/generated/prisma"
+
+ // Optional
+ engineType = "client"
+ runtime = "nodejs"
+ moduleFormat = "esm"
+ generatedFileExtension = "ts"
+ importFileExtension = "ts"
+}
+```
+
+Below are the options for the `prisma-client` generator:
+
+| **Option** | **Default** | **Description** |
+| ------------------------ | ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `output` (**required**) | | Directory where Prisma Client is generated, e.g. `../src/generated/prisma`. |
+| `runtime` | `nodejs` | Target runtime environment. Supported values: `nodejs`, `deno`, `bun`, `workerd` (alias `cloudflare`), `vercel-edge` (alias `edge-light`), `react-native`. |
+| `moduleFormat` | Inferred from environment | Module format (`esm` or `cjs`). Determines whether `import.meta.url` or `__dirname` is used. |
+| `generatedFileExtension` | `ts` | File extension for generated TypeScript files (`ts`, `mts`, `cts`). |
+| `importFileExtension` | Inferred from environment | File extension used in **import statements**. Can be `ts`, `mts`, `cts`, `js`, `mjs`, `cjs`, or empty (for bare imports). |
+
+:::note
+
+`nodejs`, `deno`, and `bun` all map to the same internal codepath but are preserved as separate user-facing values for clarity.
+
+:::
+
+### Importing types
+
+The new `prisma-client` generator creates individual `.ts` files which allow for a more fine granular import of types. This can improve compile and typecheck performance and be useful for tree-shaking, too.
+You can still use the top level barrel files that export all types through a single import.
+
+The overall structure of the generated output looks like this:
+
+```
+generated/
+└── prisma
+ ├── browser.ts
+ ├── client.ts
+ ├── commonInputTypes.ts
+ ├── enums.ts
+ ├── internal
+ │ ├── ...
+ ├── models
+ │ ├── Post.ts
+ │ └── User.ts
+ └── models.ts
+```
+
+#### `client.ts`
+
+For use in your server code.
+
+- Provides access to the `PrismaClient` instance and all model and utility types.
+- Provides best compatibility with the `prisma-client-js` generated output.
+- Contains transitive dependencies on server only-packages, so cannot be used in browser contexts.
+
+Example:
+
+```ts
+import { Prisma, type Post, PrismaClient } from "./generated/prisma/client"
+```
+
+#### `browser.ts`
+
+For using types in your frontend (i.e. code that runs in the browser).
+
+- Contains no transitive dependencies on Node.js or other server-only packages.
+- Contains no real `PrismaClient` constructor.
+- Contains all model and enum types and values.
+- Provides access to various utilities like `Prisma.JsonNull` and `Prisma.Decimal`.
+- Available since `v6.16.0`.
+
+:::note
+
+The old `prisma-client-js` generator created a `node_modules` package and used export maps to dynamically provide a browser compatible export of the generated Prisma Client library. As the new `prisma-client` generator creates direct TypeScript source code and no `package.json` file anymore, this approach is not possible. Hence you need to be explicit about your imports and whether things run on server or client!
+
+You can still wrap the generated code in a package and use a similar approach as with `prisma-client-js` on your own.
+
+:::
+
+Example:
+
+```ts
+import { Prisma, type Post } from "./generated/prisma/browser"
+```
+
+#### `enums.ts`
+
+Isolated access to user defined enum types and values.
+
+- Contains no transitive dependencies and is very slim.
+- Can be used on backend and frontend.
+- Prefer this for optimal tree shaking and typecheck performance when accessing enums.
+
+Example:
+
+```ts
+import { MyEnum } from "./generated/prisma/enums"
+```
+
+#### `models.ts`
+
+Isolated access to all model types.
+
+- Can be used on backend and frontend.
+- Contains all models including their derived utility types like `WhereInput` or `UpdateInput>`.
+
+:::note
+
+Plain model types are exposed here as `Model` (e.g. `PostModel`). This is in contrast to the exposed name in `client.ts` and `browser.ts` which is simply `` (e.g. `Post`).
+
+This is necessary due to internal constraints to avoid potential naming conflicts with internal types.
+
+:::
+
+Example:
+
+```ts
+import type { UserModel, PostModel, PostWhereInput, UserUpdateInput } from "./generated/prisma/models"
+```
+
+
+#### `models/.ts`
+
+Isolated access to the types for an individual model.
+
+- Can be used on backend and frontend.
+- Contains the models including its derived utility types like `WhereInput` or `UpdateInput>`.
+
+:::note
+
+The plain model type is exposed here as `Model` (e.g. `PostModel`).
+
+:::
+
+Example:
+
+```ts
+import type { UserModel, UserWhereInput, UserUpdateInput } from "./generated/prisma/models/User"
+```
+
+
+#### `commonInputTypes.ts`
+
+Provides shared utility types that you should rarely directly need.
+
+Example:
+
+```ts
+import type { IntFilter } from "./generated/prisma/commonInputTypes"
+```
+
+#### `internal/*`
+
+:::warning
+
+Do not directly import from these files! They are not part of the stable API of the generated code and can change at any time in breaking ways.
+
+Usually anything you might need from there is exposed via `browser.ts` or `client.ts` under the `Prisma` namespace.
+
+:::
+
+### Breaking changes from `prisma-client-js`
+
+- Requires an `output` path on the `generator` block
+- No `Prisma.validator` function; you can use TypeScript native [`satisfies`](https://www.prisma.io/blog/satisfies-operator-ur8ys8ccq7zb) keyword instead
+
+### Examples
+
+To see what the new `prisma-client` generator looks like in practice, check out our minimal and [ready-to-run examples](https://github.com/prisma/prisma-examples):
+
+| Example | Framework | Bundler | Runtime | Monorepo |
+| ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------- | ----------------- | ------------------------------------------------ | --------- |
+| [`nextjs-starter-webpack`](https://github.com/prisma/prisma-examples/tree/latest/generator-prisma-client/nextjs-starter-webpack) | Next.js 15 | Webpack | Node.js | n/a |
+| [`nextjs-starter-turbopack`](https://github.com/prisma/prisma-examples/tree/latest/generator-prisma-client/nextjs-starter-turbopack) | Next.js 15 | Turbopack (alpha) | Node.js | n/a |
+| [`nextjs-starter-webpack-monorepo`](https://github.com/prisma/prisma-examples/tree/latest/generator-prisma-client/nextjs-starter-webpack-monorepo) | Next.js 15 | Webpack | Node.js | pnpm |
+| [`nextjs-starter-webpack-with-middleware`](https://github.com/prisma/prisma-examples/tree/latest/generator-prisma-client/nextjs-starter-webpack-with-middleware) | Next.js 15 | Webpack | Node.js (main pages), `vercel-edge` (middleware) | n/a |
+| [`nextjs-starter-webpack-turborepo`](https://github.com/prisma/prisma-examples/tree/latest/generator-prisma-client/nextjs-starter-webpack-turborepo) | Next.js 15 | Webpack | Node.js | turborepo |
+| [`react-router-starter-nodejs`](https://github.com/prisma/prisma-examples/tree/latest/generator-prisma-client/react-router-starter-nodejs) | React Router 7 | Vite 6 | Node.js | n/a |
+| [`react-router-starter-cloudflare-workerd`](https://github.com/prisma/prisma-examples/tree/latest/generator-prisma-client/react-router-starter-cloudflare-workerd) | React Router 7 | | | n/a |
+| [`nuxt3-starter-nodejs`](https://github.com/prisma/prisma-examples/tree/latest/generator-prisma-client/nuxt3-starter-nodejs) | Nuxt 3 | Vite 6 | Node.js | n/a |
+| [`nuxt4-starter-nodejs`](https://github.com/prisma/prisma-examples/tree/latest/generator-prisma-client/nuxt4-starter-nodejs) | Nuxt 4 | Vite 7 | Node.js | n/a |
+| [`bun`](https://github.com/prisma/prisma-examples/tree/latest/generator-prisma-client/deno-deploy) | None | None | Deno 2 | n/a |
+| [`deno`](https://github.com/prisma/prisma-examples/tree/latest/generator-prisma-client/deno-deploy) | None | None | Deno 2 | n/a |
+
+## Community generators
+
+:::note
+
+Existing generators or new ones should not be affected if you are using a [multi-file Prisma schema](/orm/prisma-schema/overview/location#multi-file-prisma-schema), unless a generator reads the schema manually.
+
+:::
+
+The following is a list of community created generators.
+
+- [`prisma-dbml-generator`](https://notiz.dev/blog/prisma-dbml-generator/): Transforms the Prisma schema into [Database Markup Language](https://dbml.dbdiagram.io/home/) (DBML) which allows for an easy visual representation
+- [`prisma-docs-generator`](https://github.com/pantharshit00/prisma-docs-generator): Generates an individual API reference for Prisma Client
+- [`prisma-json-schema-generator`](https://github.com/valentinpalkovic/prisma-json-schema-generator): Transforms the Prisma schema in [JSON schema](https://json-schema.org/)
+- [`prisma-json-types-generator`](https://github.com/arthurfiorette/prisma-json-types-generator): Enhances `prisma-client-js` (or `prisma-client`) to provide strongly typed JSON fields for all databases, based on your schema. It improves code generation, Intellisense, and more, without affecting runtime code.
+- [`typegraphql-prisma`](https://github.com/MichalLytek/typegraphql-prisma#readme): Generates [TypeGraphQL](https://typegraphql.com/) CRUD resolvers for Prisma models
+- [`typegraphql-prisma-nestjs`](https://github.com/EndyKaufman/typegraphql-prisma-nestjs#readme): Fork of [`typegraphql-prisma`](https://github.com/MichalLytek/typegraphql-prisma), which also generates CRUD resolvers for Prisma models but for NestJS
+- [`prisma-typegraphql-types-gen`](https://github.com/YassinEldeeb/prisma-tgql-types-gen): Generates [TypeGraphQL](https://typegraphql.com/) class types and enums from your prisma type definitions, the generated output can be edited without being overwritten by the next gen and has the ability to correct you when you mess up the types with your edits.
+- [`nexus-prisma`](https://github.com/prisma/nexus-prisma/): Allows to project Prisma models to GraphQL via [GraphQL Nexus](https://nexusjs.org/docs/)
+- [`prisma-nestjs-graphql`](https://github.com/unlight/prisma-nestjs-graphql): Generates object types, inputs, args, etc. from the Prisma Schema for usage with `@nestjs/graphql` module
+- [`prisma-appsync`](https://github.com/maoosi/prisma-appsync): Generates a full-blown GraphQL API for [AWS AppSync](https://aws.amazon.com/appsync/)
+- [`prisma-kysely`](https://github.com/valtyr/prisma-kysely): Generates type definitions for Kysely, a TypeScript SQL query builder. This can be useful to perform queries against your database from an edge runtime, or to write more complex SQL queries not possible in Prisma without dropping type safety.
+- [`prisma-generator-nestjs-dto`](https://github.com/vegardit/prisma-generator-nestjs-dto): Generates DTO and Entity classes with relation `connect` and `create` options for use with [NestJS Resources](https://docs.nestjs.com/recipes/crud-generator) and [@nestjs/swagger](https://www.npmjs.com/package/@nestjs/swagger)
+- [`prisma-erd-generator`](https://github.com/keonik/prisma-erd-generator): Generates an entity relationship diagram
+- [`prisma-generator-plantuml-erd`](https://github.com/dbgso/prisma-generator-plantuml-erd/tree/main/packages/generator): Generator to generate ER diagrams for PlantUML. Markdown and Asciidoc documents can also be generated by activating the option.
+- [`prisma-class-generator`](https://github.com/kimjbstar/prisma-class-generator): Generates classes from your Prisma Schema that can be used as DTO, Swagger Response, TypeGraphQL and so on.
+- [`zod-prisma`](https://github.com/CarterGrimmeisen/zod-prisma): Creates Zod schemas from your Prisma models.
+- [`prisma-pothos-types`](https://github.com/hayes/pothos/tree/main/packages/plugin-prisma): Makes it easier to define Prisma-based object types, and helps solve n+1 queries for relations. It also has integrations for the Relay plugin to make defining nodes and connections easy and efficient.
+- [`prisma-generator-pothos-codegen`](https://github.com/Cauen/prisma-generator-pothos-codegen): Auto generate input types (for use as args) and auto generate decoupled type-safe base files makes it easy to create customizable objects, queries and mutations for [Pothos](https://pothos-graphql.dev/) from Prisma schema. Optionally generate all crud at once from the base files.
+- [`prisma-joi-generator`](https://github.com/omar-dulaimi/prisma-joi-generator): Generate full Joi schemas from your Prisma schema.
+- [`prisma-yup-generator`](https://github.com/omar-dulaimi/prisma-yup-generator): Generate full Yup schemas from your Prisma schema.
+- [`prisma-class-validator-generator`](https://github.com/omar-dulaimi/prisma-class-validator-generator): Emit TypeScript models from your Prisma schema with class validator validations ready.
+- [`prisma-zod-generator`](https://github.com/omar-dulaimi/prisma-zod-generator): Emit Zod schemas from your Prisma schema.
+- [`prisma-trpc-generator`](https://github.com/omar-dulaimi/prisma-trpc-generator): Emit fully implemented tRPC routers.
+- [`prisma-json-server-generator`](https://github.com/omar-dulaimi/prisma-json-server-generator): Emit a JSON file that can be run with json-server.
+- [`prisma-trpc-shield-generator`](https://github.com/omar-dulaimi/prisma-trpc-shield-generator): Emit a tRPC shield from your Prisma schema.
+- [`prisma-custom-models-generator`](https://github.com/omar-dulaimi/prisma-custom-models-generator): Emit custom models from your Prisma schema, based on Prisma recommendations.
+- [`nestjs-prisma-graphql-crud-gen`](https://github.com/mk668a/nestjs-prisma-graphql-crud-gen): Generate CRUD resolvers from GraphQL schema with NestJS and Prisma.
+- [`prisma-generator-dart`](https://github.com/FredrikBorgstrom/abcx3/tree/master/libs/prisma-generator-dart): Generates Dart/Flutter class files with to- and fromJson methods.
+- [`prisma-generator-graphql-typedef`](https://github.com/mavvy22/prisma-generator-graphql-typedef): Generates graphql schema.
+- [`prisma-markdown`](https://github.com/samchon/prisma-markdown): Generates markdown document composed with ERD diagrams and their descriptions. Supports pagination of ERD diagrams through `@namespace` comment tag.
+- [`prisma-models-graph`](https://github.com/dangchinh25/prisma-models-graph): Generates a bi-directional models graph for schema without strict relationship defined in the schema, works via a custom schema annotation.
+- [`prisma-generator-fake-data`](https://github.com/luisrudge/prisma-generator-fake-data): Generates realistic-looking fake data for your Prisma models that can be used in unit/integration tests, demos, and more.
+- [`prisma-generator-drizzle`](https://github.com/farreldarian/prisma-generator-drizzle): A Prisma generator for generating Drizzle schema with ease.
+- [`prisma-generator-express`](https://github.com/multipliedtwice/prisma-generator-express): Generates Express CRUD and Router generator function.
+- [`prismabox`](https://github.com/m1212e/prismabox): Generates versatile [typebox](https://github.com/sinclairzx81/typebox) schema from your Prisma models.
+- [`prisma-generator-typescript-interfaces`](https://github.com/mogzol/prisma-generator-typescript-interfaces): Generates zero-dependency TypeScript interfaces from your Prisma schema.
+- [`prisma-openapi`](https://github.com/nitzano/prisma-openapi): Generates OpenAPI schema from Prisma models.
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/10-overview/04-location.mdx b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/10-overview/04-location.mdx
new file mode 100644
index 0000000000..b3d89f6a04
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/10-overview/04-location.mdx
@@ -0,0 +1,124 @@
+---
+title: Schema location
+metaTitle: Prisma Schema Location and Configuration
+metaDescription: Documentation regarding proper location of Prisma Schema including default naming and multiple files.
+---
+
+The default name for the Prisma Schema is a single file `schema.prisma` in your `prisma` folder. When your schema is named like this, the Prisma CLI will detect it automatically.
+
+## Prisma Schema location
+
+The Prisma CLI looks for the Prisma Schema in the following locations, in the following order:
+
+1. The location specified by the [`--schema` flag](/orm/reference/prisma-cli-reference), which is available when you `introspect`, `generate`, `migrate`, and `studio`:
+
+ ```terminal
+ prisma generate --schema=./alternative/schema.prisma
+ ```
+
+2. The location specified in the `package.json` file (version 2.7.0 and later):
+
+ ```json
+ "prisma": {
+ "schema": "db/schema.prisma"
+ }
+ ```
+
+3. Default locations:
+
+ - `./prisma/schema.prisma`
+ - `./schema.prisma`
+
+The Prisma CLI outputs the path of the schema that will be used. The following example shows the terminal output for `prisma db pull`:
+
+```no-lines
+Environment variables loaded from .env
+//highlight-next-line
+Prisma Schema loaded from prisma/schema.prisma
+
+Introspecting based on datasource defined in prisma/schema.prisma …
+
+✔ Introspected 4 models and wrote them into prisma/schema.prisma in 239ms
+
+Run prisma generate to generate Prisma Client.
+```
+
+## Multi-file Prisma schema
+
+If you prefer splitting your Prisma schema into multiple files, you can have a setup that looks as follows:
+
+```
+.
+├── migrations
+├── models
+│ ├── posts.prisma
+│ ├── users.prisma
+│ └── ... other `.prisma` files
+└── schema.prisma
+```
+
+:::note
+
+Multi-file Prisma schemas are Generally Available since [v6.7.0](https://pris.ly/release/6.7.0). Before that, they could be used via the `prismaSchemaFolder` Preview feature flag.
+
+:::
+
+### Usage
+
+When using a multi-file Prisma schema, you must always explicitly specify the location of the directory that contains the `.prisma` file with your `datasource` block.
+
+You can do this in either of three ways:
+
+- pass the the `--schema` option to your Prisma CLI command (e.g. `prisma migrate dev --schema ./prisma`)
+- set the `prisma.schema` field in `package.json`:
+ ```jsonc
+ // package.json
+ {
+ "prisma": {
+ "schema": "./prisma"
+ }
+ }
+ ```
+- set the `schema` property in [`prisma.config.ts`](/orm/reference/prisma-config-reference#schema):
+ ```ts
+ import path from 'node:path'
+ import type { PrismaConfig } from 'prisma'
+
+ export default {
+ schema: path.join('prisma'),
+ } satisfies PrismaConfig
+ ```
+
+ :::note
+
+ We recommend using the [Prisma Config file](/orm/reference/prisma-config-reference#schema) to specify the location of your Prisma schema. This is the most flexible way to specify the location of your Prisma schema alongside other configuration options.
+
+ :::
+
+All examples above assume that your `datasource` block is defined in a `.prisma` file inside the `prisma` directory.
+
+You also must place the `migrations` directory next to the `.prisma` file that defines the `datasource` block.
+
+For example, assuming `schema.prisma` defines the `datasource`, here's how how need to place the migrations folder:
+
+```
+# `migrations` and `schema.prisma` must be on the same level
+.
+├── migrations
+├── models
+│ ├── posts.prisma
+│ └── users.prisma
+└── schema.prisma
+```
+
+### Tips for multi-file Prisma Schema
+
+We've found that a few patterns work well with this feature and will help you get the most out of it:
+
+- Organize your files by domain: group related models into the same file. For example, keep all user-related models in `user.prisma` while post-related models go in `post.prisma`.
+- Use clear naming conventions: schema files should be named clearly and succinctly. Use names like `user.prisma` and `post.prisma` and not `myModels.prisma` or `CommentFeaturesSchema.prisma`.
+- Have an obvious "main" schema file: while you can now have as many schema files as you want, you'll still need a place where you define `datasource` and `generator` blocks. We recommend having a single schema file that's obviously the "main" file so that these blocks are easy to find. `main.prisma`, `schema.prisma`, and `base.prisma` are a few we've seen that work well.
+
+### Examples
+
+Our fork of [`dub` by dub.co](https://github.com/prisma/dub) is a great example of a real world project adapted to use a multi-file Prisma Schema.
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/10-overview/index.mdx b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/10-overview/index.mdx
new file mode 100644
index 0000000000..447ed608e5
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/10-overview/index.mdx
@@ -0,0 +1,259 @@
+---
+title: 'Overview on Prisma Schema'
+sidebar_label: 'Overview'
+metaTitle: 'Prisma Schema Overview'
+metaDescription: 'The Prisma schema is the main method of configuration when using Prisma. It is typically called schema.prisma and contains your database connection and data model.'
+---
+
+The Prisma Schema (or _schema_ for short) is the main method of configuration for your Prisma ORM setup. It consists of the following parts:
+
+- [**Data sources**](/orm/prisma-schema/overview/data-sources): Specify the details of the data sources Prisma ORM should connect to (e.g. a PostgreSQL database)
+- [**Generators**](/orm/prisma-schema/overview/generators): Specifies what clients should be generated based on the data model (e.g. Prisma Client)
+- [**Data model definition**](/orm/prisma-schema/data-model): Specifies your application [models](/orm/prisma-schema/data-model/models#defining-models) (the shape of the data per data source) and their [relations](/orm/prisma-schema/data-model/relations)
+
+It is typically a single file called `schema.prisma` (or multiple files with `.prisma` file extension) that is stored in a defined but customizable [location](/orm/prisma-schema/overview/location). You can also [organize your Prisma schema in multiple files](/orm/prisma-schema/overview/location#multi-file-prisma-schema) if you prefer that.
+
+See the [Prisma schema API reference](/orm/reference/prisma-schema-reference) for detailed information about each section of the schema.
+
+Whenever a `prisma` command is invoked, the CLI typically reads some information from the schema, e.g.:
+
+- `prisma generate`: Reads _all_ above mentioned information from the Prisma schema to generate the correct data source client code (e.g. Prisma Client).
+- `prisma migrate dev`: Reads the data sources and data model definition to create a new migration.
+
+You can also [use environment variables](#accessing-environment-variables-from-the-schema) inside the schema to provide configuration options when a CLI command is invoked.
+
+## Example
+
+The following is an example of a Prisma Schema that specifies:
+
+- A data source (PostgreSQL or MongoDB)
+- A generator (Prisma Client)
+- A data model definition with two models (with one relation) and one `enum`
+- Several [native data type attributes](/orm/prisma-schema/data-model/models#native-types-mapping) (`@db.VarChar(255)`, `@db.ObjectId`)
+
+
+
+
+```prisma
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+
+generator client {
+ provider = "prisma-client-js"
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ createdAt DateTime @default(now())
+ email String @unique
+ name String?
+ role Role @default(USER)
+ posts Post[]
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ createdAt DateTime @default(now())
+ updatedAt DateTime @updatedAt
+ published Boolean @default(false)
+ title String @db.VarChar(255)
+ author User? @relation(fields: [authorId], references: [id])
+ authorId Int?
+}
+
+enum Role {
+ USER
+ ADMIN
+}
+```
+
+
+
+
+```prisma
+datasource db {
+ provider = "mongodb"
+ url = env("DATABASE_URL")
+}
+
+generator client {
+ provider = "prisma-client-js"
+}
+
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ createdAt DateTime @default(now())
+ email String @unique
+ name String?
+ role Role @default(USER)
+ posts Post[]
+}
+
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ createdAt DateTime @default(now())
+ updatedAt DateTime @updatedAt
+ published Boolean @default(false)
+ title String
+ author User? @relation(fields: [authorId], references: [id])
+ authorId String @db.ObjectId
+}
+
+enum Role {
+ USER
+ ADMIN
+}
+```
+
+
+
+
+## Syntax
+
+Prisma Schema files are written in Prisma Schema Language (PSL). See the [data sources](/orm/prisma-schema/overview/data-sources), [generators](/orm/prisma-schema/overview/generators), [data model definition](/orm/prisma-schema/data-model) and of course [Prisma Schema API reference](/orm/reference/prisma-schema-reference) pages for details and examples.
+
+### VS Code
+
+Syntax highlighting for PSL is available via a [VS Code extension](https://marketplace.visualstudio.com/items?itemName=Prisma.prisma) (which also lets you auto-format the contents of your Prisma schema and indicates syntax errors with red squiggly lines). Learn more about [setting up Prisma ORM in your editor](/orm/more/development-environment/editor-setup).
+
+### GitHub
+
+PSL code snippets on GitHub can be rendered with syntax highlighting as well by using the `.prisma` file extension or annotating fenced code blocks in Markdown with `prisma`:
+
+````
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ createdAt DateTime @default(now())
+ email String @unique
+ name String?
+}
+```
+````
+
+## Accessing environment variables from the schema
+
+You can use environment variables to provide configuration options when a CLI command is invoked, or a Prisma Client query is run.
+
+Hardcoding URLs directly in your schema is possible but is discouraged because it poses a security risk. Using environment variables in the schema allows you to **keep secrets out of the schema** which in turn **improves the portability of the schema** by allowing you to use it in different environments.
+
+Environment variables can be accessed using the `env()` function:
+
+```prisma
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+```
+
+You can use the `env()` function in the following places:
+
+- A datasource url
+- Generator binary targets
+
+See [Environment variables](/orm/more/development-environment/environment-variables) for more information about how to use an `.env` file during development.
+
+## Comments
+
+There are three types of comments that are supported in Prisma Schema Language:
+
+- `// comment`: This comment is for the reader's clarity and is not present in the abstract syntax tree (AST) of the schema.
+- `/// comment`: These comments will show up in the abstract syntax tree (AST) of the schema as descriptions to AST nodes. Tools can then use these comments to provide additional information. All comments are attached to the next available node - [free-floating comments](https://github.com/prisma/prisma/issues/3544) are not supported and are not included in the AST.
+- `/* block comment */`: These comments will show up in the abstract syntax tree, similarly to `///` comments.
+
+Here are some different examples:
+
+```prisma
+/// This comment will get attached to the `User` node in the AST
+model User {
+ /// This comment will get attached to the `id` node in the AST
+ id Int @default(autoincrement())
+ // This comment is just for you
+ weight Float /// This comment gets attached to the `weight` node
+}
+
+// This comment is just for you. It will not
+// show up in the AST.
+
+/// This comment will get attached to the
+/// Customer node.
+model Customer {
+ /**
+ * ...and so will this comment
+ */
+}
+```
+
+## Auto formatting
+
+Prisma ORM supports formatting `.prisma` files automatically. There are two ways to format `.prisma` files:
+
+- Run the [`prisma format`](/orm/reference/prisma-cli-reference#format) command.
+- Install the [Prisma VS Code extension](https://marketplace.visualstudio.com/items?itemName=Prisma.prisma) and invoke the [VS Code format action](https://code.visualstudio.com/docs/editor/codebasics#_formatting) - manually or on save.
+
+There are no configuration options - [formatting rules](#formatting-rules) are fixed (similar to Golang's `gofmt` but unlike Javascript's `prettier`):
+
+### Formatting rules
+
+#### Configuration blocks are aligned by their `=` sign
+
+```
+block _ {
+ key = "value"
+ key2 = 1
+ long_key = true
+}
+```
+
+#### Field definitions are aligned into columns separated by 2 or more spaces
+
+```
+block _ {
+ id String @id
+ first_name LongNumeric @default
+}
+```
+
+#### Empty lines resets block alignment and formatting rules
+
+```
+block _ {
+ key = "value"
+ key2 = 1
+ key10 = true
+
+ long_key = true
+ long_key_2 = true
+}
+```
+
+```
+block _ {
+ id String @id
+ @default
+
+ first_name LongNumeric @default
+}
+```
+
+#### Multiline field attributes are properly aligned with the rest of the field attributes
+
+```
+block _ {
+ id String @id
+ @default
+ first_name LongNumeric @default
+}
+```
+
+#### Block attributes are sorted to the end of the block
+
+```
+block _ {
+ key = "value"
+
+ @@attribute
+}
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/10-models.mdx b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/10-models.mdx
new file mode 100644
index 0000000000..7dc1340ade
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/10-models.mdx
@@ -0,0 +1,1225 @@
+---
+title: 'Models'
+metaTitle: 'Models'
+metaDescription: 'Learn about the concepts for building your data model with Prisma: Models, scalar types, enums, attributes, functions, IDs, default values and more.'
+tocDepth: 3
+---
+
+The data model definition part of the [Prisma schema](/orm/prisma-schema) defines your application models (also called **Prisma models**). Models:
+
+- Represent the **entities** of your application domain
+- Map to the **tables** (relational databases like PostgreSQL) or **collections** (MongoDB) in your database
+- Form the foundation of the **queries** available in the generated [Prisma Client API](/orm/prisma-client)
+- When used with TypeScript, Prisma Client provides generated **type definitions** for your models and any [variations](/orm/prisma-client/type-safety/operating-against-partial-structures-of-model-types) of them to make database access entirely type safe.
+
+The following schema describes a blogging platform - the data model definition is highlighted:
+
+
+
+
+```prisma highlight=10-46;normal
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+
+generator client {
+ provider = "prisma-client-js"
+}
+
+//highlight-start
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ role Role @default(USER)
+ posts Post[]
+ profile Profile?
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String
+ user User @relation(fields: [userId], references: [id])
+ userId Int @unique
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ createdAt DateTime @default(now())
+ updatedAt DateTime @updatedAt
+ title String
+ published Boolean @default(false)
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+ categories Category[]
+}
+
+model Category {
+ id Int @id @default(autoincrement())
+ name String
+ posts Post[]
+}
+
+enum Role {
+ USER
+ ADMIN
+}
+//highlight-end
+```
+
+
+
+
+```prisma highlight=10-45;normal
+datasource db {
+ provider = "mongodb"
+ url = env("DATABASE_URL")
+}
+
+generator client {
+ provider = "prisma-client-js"
+}
+
+//highlight-start
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ email String @unique
+ name String?
+ role Role @default(USER)
+ posts Post[]
+ profile Profile?
+}
+
+model Profile {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ bio String
+ user User @relation(fields: [userId], references: [id])
+ userId String @unique @db.ObjectId
+}
+
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ createdAt DateTime @default(now())
+ title String
+ published Boolean @default(false)
+ author User @relation(fields: [authorId], references: [id])
+ authorId String @db.ObjectId
+ categoryIDs String[] @db.ObjectId
+ categories Category[] @relation(fields: [categoryIDs], references: [id])
+}
+
+model Category {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ name String
+ postIDs String[] @db.ObjectId
+ posts Post[] @relation(fields: [postIDs], references: [id])
+}
+
+enum Role {
+ USER
+//highlight-end
+ ADMIN
+}
+```
+
+
+
+
+The data model definition is made up of:
+
+- [Models](#defining-models) ([`model`](/orm/reference/prisma-schema-reference#model) primitives) that define a number of fields, including [relations between models](#relation-fields)
+- [Enums](#defining-enums) ([`enum`](/orm/reference/prisma-schema-reference#enum) primitives) (if your connector supports Enums)
+- [Attributes](#defining-attributes) and [functions](#using-functions) that change the behavior of fields and models
+
+The corresponding database looks like this:
+
+
+
+
+
+A model maps to the underlying structures of the data source.
+
+- In relational databases like PostgreSQL and MySQL, a `model` maps to a **table**
+- In MongoDB, a `model` maps to a **collection**
+
+> **Note**: In the future there might be connectors for non-relational databases and other data sources. For example, for a REST API it would map to a _resource_.
+
+
+
+The following query uses Prisma Client that's generated from this data model to create:
+
+- A `User` record
+- Two nested `Post` records
+- Three nested `Category` records
+
+
+
+
+
+```ts
+const user = await prisma.user.create({
+ data: {
+ email: 'ariadne@prisma.io',
+ name: 'Ariadne',
+ posts: {
+ create: [
+ {
+ title: 'My first day at Prisma',
+ categories: {
+ create: {
+ name: 'Office',
+ },
+ },
+ },
+ {
+ title: 'How to connect to a SQLite database',
+ categories: {
+ create: [{ name: 'Databases' }, { name: 'Tutorials' }],
+ },
+ },
+ ],
+ },
+ },
+})
+```
+
+
+
+
+
+```ts
+import { PrismaClient } from '@prisma/client'
+
+const prisma = new PrismaClient({})
+
+// A `main` function so that you can use async/await
+async function main() {
+ // Create user, posts, and categories
+ const user = await prisma.user.create({
+ data: {
+ email: 'ariadne@prisma.io',
+ name: 'Ariadne',
+ posts: {
+ create: [
+ {
+ title: 'My first day at Prisma',
+ categories: {
+ create: {
+ name: 'Office',
+ },
+ },
+ },
+ {
+ title: 'How to connect to a SQLite database',
+ categories: {
+ create: [{ name: 'Databases' }, { name: 'Tutorials' }],
+ },
+ },
+ ],
+ },
+ },
+ })
+
+ // Return user, and posts, and categories
+ const returnUser = await prisma.user.findUnique({
+ where: {
+ id: user.id,
+ },
+ include: {
+ posts: {
+ include: {
+ categories: true,
+ },
+ },
+ },
+ })
+
+ console.log(returnUser)
+}
+
+main()
+```
+
+
+
+
+
+Your data model reflects _your_ application domain. For example:
+
+- In an **ecommerce** application you probably have models like `Customer`, `Order`, `Item` and `Invoice`.
+- In a **social media** application you probably have models like `User`, `Post`, `Photo` and `Message`.
+
+## Introspection and migration
+
+There are two ways to define a data model:
+
+- **Write the data model manually and use Prisma Migrate**: You can write your data model manually and map it to your database using [Prisma Migrate](/orm/prisma-migrate). In this case, the data model is the single source of truth for the models of your application.
+- **Generate the data model via introspection**: When you have an existing database or prefer migrating your database schema with SQL, you generate the data model by [introspecting](/orm/prisma-schema/introspection) your database. In this case, the database schema is the single source of truth for the models of your application.
+
+## Defining models
+
+Models represent the entities of your application domain. Models are represented by [`model`](/orm/reference/prisma-schema-reference#model) blocks and define a number of [fields](/orm/reference/prisma-schema-reference#model-fields). In the example data model above, `User`, `Profile`, `Post` and `Category` are models.
+
+A blogging platform can be extended with the following models:
+
+```prisma
+model Comment {
+ // Fields
+}
+
+model Tag {
+ // Fields
+}
+```
+
+### Mapping model names to tables or collections
+
+Prisma model [naming conventions (singular form, PascalCase)](/orm/reference/prisma-schema-reference#naming-conventions) do not always match table names in the database. A common approach for naming tables/collections in databases is to use plural form and [snake_case](https://en.wikipedia.org/wiki/Snake_case) notation - for example: `comments`. When you introspect a database with a table named `comments`, the result Prisma model will look like this:
+
+```prisma
+model comments {
+ // Fields
+}
+```
+
+However, you can still adhere to the naming convention without renaming the underlying `comments` table in the database by using the [`@@map`](/orm/reference/prisma-schema-reference#map-1) attribute:
+
+```prisma
+model Comment {
+ // Fields
+
+ @@map("comments")
+}
+```
+
+With this model definition, Prisma ORM automatically maps the `Comment` model to the `comments` table in the underlying database.
+
+> **Note**: You can also [`@map`](/orm/reference/prisma-schema-reference#map) a column name or enum value, and `@@map` an enum name.
+
+`@map` and `@@map` allow you to [tune the shape of your Prisma Client API](/orm/prisma-client/setup-and-configuration/custom-model-and-field-names#using-map-and-map-to-rename-fields-and-models-in-the-prisma-client-api) by decoupling model and field names from table and column names in the underlying database.
+
+
+
+
+
+
+
+## Defining fields
+
+The properties of a model are called _fields_, which consist of:
+
+- A **[field name](/orm/reference/prisma-schema-reference#model-fields)**
+- A **[field type](/orm/reference/prisma-schema-reference#model-fields)**
+- Optional **[type modifiers](#type-modifiers)**
+- Optional **[attributes](#defining-attributes)**, including [native database type attributes](#native-types-mapping)
+
+A field's type determines its _structure_, and fits into one of two categories:
+
+- [Scalar types](#scalar-fields) (includes [enums](#defining-enums)) that map to columns (relational databases) or document fields (MongoDB) in the database - for example, [`String`](/orm/reference/prisma-schema-reference#string) or [`Int`](/orm/reference/prisma-schema-reference#int)
+- Model types (the field is then called [relation field](/orm/prisma-schema/data-model/relations#relation-fields)) - for example `Post` or `Comment[]`.
+
+The following table describes `User` model's fields from the sample schema:
+
+
+
+Expand to see table
+
+| Name | Type | Scalar vs Relation | Type modifier | Attributes |
+| :-------- | :-------- | :---------------------------- | :------------ | :------------------------------------ |
+| `id` | `Int` | Scalar | - | `@id` and `@default(autoincrement())` |
+| `email` | `String` | Scalar | - | `@unique` |
+| `name` | `String` | Scalar | `?` | - |
+| `role` | `Role` | Scalar (`enum`) | - | `@default(USER)` |
+| `posts` | `Post` | Relation (Prisma-level field) | `[]` | - |
+| `profile` | `Profile` | Relation (Prisma-level field) | `?` | - |
+
+
+
+### Scalar fields
+
+The following example extends the `Comment` and `Tag` models with several scalar types. Some fields include [attributes](#defining-attributes):
+
+
+
+
+```prisma highlight=2-4,8;normal
+model Comment {
+ //highlight-start
+ id Int @id @default(autoincrement())
+ title String
+ content String
+ //highlight-end
+}
+
+model Tag {
+ //highlight-next-line
+ name String @id
+}
+```
+
+
+
+
+```prisma highlight=2-4,8;normal
+model Comment {
+ //highlight-start
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ title String
+ content String
+ //highlight-end
+}
+
+model Tag {
+ //highlight-next-line
+ name String @id @map("_id")
+}
+```
+
+
+
+
+See [complete list of scalar field types](/orm/reference/prisma-schema-reference#model-field-scalar-types) .
+
+### Relation fields
+
+A relation field's type is another model - for example, a post (`Post`) can have multiple comments (`Comment[]`):
+
+
+
+
+```prisma highlight=4,10;normal
+model Post {
+ id Int @id @default(autoincrement())
+ // Other fields
+ //highlight-next-line
+ comments Comment[] // A post can have many comments
+}
+
+model Comment {
+ id Int
+ // Other fields
+ //highlight-next-line
+ post Post? @relation(fields: [postId], references: [id]) // A comment can have one post
+ postId Int?
+}
+```
+
+
+
+
+```prisma highlight=4,10;normal
+model Post {
+ id String @id @default(auto()) @map("_id") @db.Objectid
+ // Other fields
+ //highlight-next-line
+ comments Comment[] // A post can have many comments
+}
+
+model Comment {
+ id String @id @default(auto()) @map("_id") @db.Objectid
+ // Other fields
+ //highlight-next-line
+ post Post? @relation(fields: [postId], references: [id]) // A comment can have one post
+ postId String? @db.ObjectId
+}
+```
+
+
+
+
+Refer to the [relations documentation](/orm/prisma-schema/data-model/relations) for more examples and information about relationships between models.
+
+### Native types mapping
+
+Version [2.17.0](https://github.com/prisma/prisma/releases/tag/2.17.0) and later support **native database type attributes** (type attributes) that describe the underlying database type:
+
+```prisma highlight=3;normal
+model Post {
+ id Int @id
+ //highlight-next-line
+ title String @db.VarChar(200)
+ content String
+}
+```
+
+Type attributes are:
+
+- Specific to the underlying provider - for example, PostgreSQL uses `@db.Boolean` for `Boolean` whereas MySQL uses `@db.TinyInt(1)`
+- Written in PascalCase (for example, `VarChar` or `Text`)
+- Prefixed by `@db`, where `db` is the name of the `datasource` block in your schema
+
+Furthermore, during [Introspection](/orm/prisma-schema/introspection) type attributes are _only_ added to the schema if the underlying native type is **not the default type**. For example, if you are using the PostgreSQL provider, `String` fields where the underlying native type is `text` will not have a type attribute.
+
+See [complete list of native database type attributes per scalar type and provider](/orm/reference/prisma-schema-reference#model-field-scalar-types) .
+
+#### Benefits and workflows
+
+- Control **the exact native type** that [Prisma Migrate](/orm/prisma-migrate) creates in the database - for example, a `String` can be `@db.VarChar(200)` or `@db.Char(50)`
+- See an **enriched schema** when you introspect
+
+### Type modifiers
+
+The type of a field can be modified by appending either of two modifiers:
+
+- [`[]`](/orm/reference/prisma-schema-reference#-modifier) Make a field a list
+- [`?`](/orm/reference/prisma-schema-reference#-modifier-1) Make a field optional
+
+> **Note**: You **cannot** combine type modifiers - optional lists are not supported.
+
+#### Lists
+
+The following example includes a scalar list and a list of related models:
+
+
+
+
+```prisma highlight=4,5;normal
+model Post {
+ id Int @id @default(autoincrement())
+ // Other fields
+ //highlight-start
+ comments Comment[] // A list of comments
+ keywords String[] // A scalar list
+ //highlight-end
+}
+```
+
+
+
+
+```prisma highlight=4,5;normal
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ // Other fields
+ //highlight-start
+ comments Comment[] // A list of comments
+ keywords String[] // A scalar list
+ //highlight-end
+}
+```
+
+
+
+
+> **Note**: Scalar lists are **only** supported if the database connector supports scalar lists, either natively or at a Prisma ORM level.
+
+#### Optional and mandatory fields
+
+
+
+
+```prisma highlight=4;normal
+model Comment {
+ id Int @id @default(autoincrement())
+ title String
+ //highlight-next-line
+ content String?
+}
+
+model Tag {
+ name String @id
+}
+```
+
+
+
+
+```prisma highlight=4;normal
+model Comment {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ title String
+ //highlight-next-line
+ content String?
+}
+
+model Tag {
+ name String @id @map("_id")
+}
+```
+
+
+
+
+When **not** annotating a field with the `?` type modifier, the field will be _required_ on every record of the model. This has effects on two levels:
+
+- **Databases**
+ - **Relational databases**: Required fields are represented via `NOT NULL` constraints in the underlying database.
+ - **MongoDB**: Required fields are not a concept on a MongoDB database level.
+- **Prisma Client**: Prisma Client's generated [TypeScript types](#type-definitions) that represent the models in your application code will also define these fields as required to ensure they always carry values at runtime.
+
+> **Note**: The default value of an optional field is `null`.
+
+### Unsupported types
+
+When you introspect a relational database, unsupported data types are added as [`Unsupported`](/orm/reference/prisma-schema-reference#unsupported) :
+
+```prisma
+location Unsupported("POLYGON")?
+```
+
+The `Unsupported` type allows you to define fields in the Prisma schema for database types that are not yet supported by Prisma ORM. For example, MySQL's `POLYGON` type is not currently supported by Prisma ORM, but can now be added to the Prisma schema using the `Unsupported("POLYGON")` type.
+
+Fields of type `Unsupported` do not appear in the generated Prisma Client API, but you can still use Prisma ORM’s [raw database access feature](/orm/prisma-client/using-raw-sql/raw-queries) to query these fields.
+
+> **Note**: If a model has **mandatory `Unsupported` fields**, the generated client will not include `create` or `update` methods for that model.
+
+> **Note**: The MongoDB connector does not support nor require the `Unsupported` type because it supports all scalar types.
+
+## Defining attributes
+
+Attributes modify the behavior of fields or model blocks. The following example includes three field attributes ([`@id`](/orm/reference/prisma-schema-reference#id) , [`@default`](/orm/reference/prisma-schema-reference#default) , and [`@unique`](/orm/reference/prisma-schema-reference#unique) ) and one block attribute ([`@@unique`](/orm/reference/prisma-schema-reference#unique-1)):
+
+
+
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ firstName String
+ lastName String
+ email String @unique
+ isAdmin Boolean @default(false)
+
+ @@unique([firstName, lastName])
+}
+```
+
+
+
+
+```prisma
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ firstName String
+ lastName String
+ email String @unique
+ isAdmin Boolean @default(false)
+
+ @@unique([firstName, lastName])
+}
+```
+
+
+
+
+Some attributes accept [arguments](/orm/reference/prisma-schema-reference#attribute-argument-types) - for example, `@default` accepts `true` or `false`:
+
+```prisma
+isAdmin Boolean @default(false) // short form of @default(value: false)
+```
+
+See [complete list of field and block attributes](/orm/reference/prisma-schema-reference#attributes)
+
+### Defining an ID field
+
+An ID uniquely identifies individual records of a model. A model can only have _one_ ID:
+
+- In **relational databases**, the ID can be a single field or based on multiple fields. If a model does not have an `@id` or an `@@id`, you must define a mandatory `@unique` field or `@@unique` block instead.
+- In **MongoDB**, an ID must be a single field that defines an `@id` attribute and a `@map("_id")` attribute.
+
+#### Defining IDs in relational databases
+
+In relational databases, an ID can be defined by a single field using the [`@id`](/orm/reference/prisma-schema-reference#id) attribute, or multiple fields using the [`@@id`](/orm/reference/prisma-schema-reference#id-1) attribute.
+
+##### Single field IDs
+
+In the following example, the `User` ID is represented by the `id` integer field:
+
+```prisma highlight=2;normal
+model User {
+ //highlight-next-line
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ role Role @default(USER)
+ posts Post[]
+ profile Profile?
+}
+```
+
+##### Composite IDs
+
+In the following example, the `User` ID is represented by a combination of the `firstName` and `lastName` fields:
+
+```prisma highlight=7;normal
+model User {
+ firstName String
+ lastName String
+ email String @unique
+ isAdmin Boolean @default(false)
+
+ //highlight-next-line
+ @@id([firstName, lastName])
+}
+```
+
+By default, the name of this field in Prisma Client queries will be `firstName_lastName`.
+
+You can also provide your own name for the composite ID using the [`@@id`](/orm/reference/prisma-schema-reference#id-1) attribute's `name` field:
+
+```prisma highlight=7;normal
+model User {
+ firstName String
+ lastName String
+ email String @unique
+ isAdmin Boolean @default(false)
+
+ //highlight-next-line
+ @@id(name: "fullName", fields: [firstName, lastName])
+}
+```
+
+The `firstName_lastName` field will now be named `fullName` instead.
+
+
+
+Refer to the documentation on [working with composite IDs](/orm/prisma-client/special-fields-and-types/working-with-composite-ids-and-constraints) to learn how to interact with a composite ID in Prisma Client.
+
+
+
+##### `@unique` fields as unique identifiers
+
+In the following example, users are uniquely identified by a `@unique` field. Because the `email` field functions as a unique identifier for the model (which is required), it must be mandatory:
+
+```prisma highlight=2;normal
+model User {
+ //highlight-next-line
+ email String @unique
+ name String?
+ role Role @default(USER)
+ posts Post[]
+ profile Profile?
+}
+```
+
+
+
+**Constraint names in relational databases**
+You can optionally define a [custom primary key constraint name](/orm/prisma-schema/data-model/database-mapping#constraint-and-index-names) in the underlying database.
+
+
+
+#### Defining IDs in MongoDB
+
+The MongoDB connector has [specific rules for defining an ID field](/orm/reference/prisma-schema-reference#mongodb) that differs from relational databases. An ID must be defined by a single field using the [`@id`](/orm/reference/prisma-schema-reference#id) attribute and must include `@map("_id")`.
+
+In the following example, the `User` ID is represented by the `id` string field that accepts an auto-generated `ObjectId`:
+
+```prisma highlight=2;normal
+model User {
+ //highlight-next-line
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ email String @unique
+ name String?
+ role Role @default(USER)
+ posts Post[]
+ profile Profile?
+}
+```
+
+In the following example, the `User` ID is represented by the `id` string field that accepts something other than an `ObjectId` - for example, a unique username:
+
+```prisma highlight=2;normal
+model User {
+ //highlight-next-line
+ id String @id @map("_id")
+ email String @unique
+ name String?
+ role Role @default(USER)
+ posts Post[]
+ profile Profile?
+}
+```
+
+
+
+**MongoDB does not support `@@id`**
+MongoDB does not support composite IDs, which means you cannot identify a model with a `@@id` block.
+
+
+
+### Defining a default value
+
+You can define default values for scalar fields of your models using the [`@default`](/orm/reference/prisma-schema-reference#default) attribute:
+
+
+
+
+```prisma highlight=3,5;normal
+model Post {
+ id Int @id @default(autoincrement())
+ //highlight-next-line
+ createdAt DateTime @default(now())
+ title String
+ //highlight-next-line
+ published Boolean @default(false)
+ //highlight-next-line
+ data Json @default("{ \"hello\": \"world\" }")
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+ categories Category[] @relation(references: [id])
+}
+```
+
+
+
+
+```prisma highlight=3,5;normal
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ createdAt DateTime @default(now())
+ title String
+ published Boolean @default(false)
+ author User @relation(fields: [authorId], references: [id])
+ authorId String @db.ObjectId
+ categories Category[] @relation(references: [id])
+}
+```
+
+
+
+
+`@default` attributes either:
+
+- Represent `DEFAULT` values in the underlying database (relational databases only) _or_
+- Use a Prisma ORM-level function. For example, `cuid()` and `uuid()` are provided by Prisma Client's [query engine](/orm/more/under-the-hood/engines) for all connectors.
+
+Default values can be:
+
+- Static values that correspond to the field type, such as `5` (`Int`), `Hello` (`String`), or `false` (`Boolean`)
+- [Lists](/orm/reference/prisma-schema-reference#-modifier) of static values, such as `[5, 6, 8]` (`Int[]`) or `["Hello", "Goodbye"]` (`String`[]). These are available in Prisma ORM versions `4.0.0` and later, when using supported databases (PostgreSQL, CockroachDB and MongoDB)
+- [Functions](#using-functions), such as [`now()`](/orm/reference/prisma-schema-reference#now) or [`uuid()`](/orm/reference/prisma-schema-reference#uuid)
+- JSON data. Note that JSON needs to be enclosed with double-quotes inside the `@default` attribute, e.g.: `@default("[]")`. If you want to provide a JSON object, you need to enclose it with double-quotes and then escape any internal double quotes using a backslash, e.g.: `@default("{ \"hello\": \"world\" }")`.
+
+
+
+Refer to the [attribute function reference documentation](/orm/reference/prisma-schema-reference#attribute-functions) for information about connector support for functions.
+
+
+
+### Defining a unique field
+
+You can add unique attributes to your models to be able to uniquely identify individual records of that model. Unique attributes can be defined on a single field using [`@unique`](/orm/reference/prisma-schema-reference#unique) attribute, or on multiple fields (also called composite or compound unique constraints) using the [`@@unique`](/orm/reference/prisma-schema-reference#unique-1) attribute.
+
+In the following example, the value of the `email` field must be unique:
+
+
+
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+}
+```
+
+
+
+
+```prisma
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ email String @unique
+ name String?
+}
+```
+
+
+
+
+In the following example, a combination of `authorId` and `title` must be unique:
+
+
+
+
+```prisma highlight=10;normal
+model Post {
+ id Int @id @default(autoincrement())
+ createdAt DateTime @default(now())
+ title String
+ published Boolean @default(false)
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+ categories Category[] @relation(references: [id])
+
+ //highlight-next-line
+ @@unique([authorId, title])
+}
+```
+
+
+
+
+```prisma highlight=10;normal
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ createdAt DateTime @default(now())
+ title String
+ published Boolean @default(false)
+ author User @relation(fields: [authorId], references: [id])
+ authorId String @db.ObjectId
+ categories Category[] @relation(references: [id])
+
+ //highlight-next-line
+ @@unique([authorId, title])
+}
+```
+
+
+
+
+
+
+**Constraint names in relational databases**
+You can optionally define a [custom unique constraint name](/orm/prisma-schema/data-model/database-mapping#constraint-and-index-names) in the underlying database.
+
+
+
+By default, the name of this field in Prisma Client queries will be `authorId_title`.
+
+You can also provide your own name for the composite unique constraint using the [`@@unique`](/orm/prisma-schema/data-model/database-mapping#constraint-and-index-names) attribute's `name` field:
+
+```prisma highlight=10;normal
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ createdAt DateTime @default(now())
+ title String
+ published Boolean @default(false)
+ author User @relation(fields: [authorId], references: [id])
+ authorId String @db.ObjectId
+ categories Category[] @relation(references: [id])
+
+ //highlight-next-line
+ @@unique(name: "authorTitle", [authorId, title])
+}
+```
+
+The `authorId_title` field will now be named `authorTitle` instead.
+
+
+
+Refer to the documentation on [working with composite unique identifiers](/orm/prisma-client/special-fields-and-types/working-with-composite-ids-and-constraints) to learn how to interact with a composite unique constraints in Prisma Client.
+
+
+
+#### Composite type unique constraints
+
+When using the MongoDB provider in version `3.12.0` and later, you can define a unique constraint on a field of a [composite type](#defining-composite-types) using the syntax `@@unique([compositeType.field])`. As with other fields, composite type fields can be used as part of a multi-column unique constraint.
+
+The following example defines a multi-column unique constraint based on the `email` field of the `User` model and the `number` field of the `Address` composite type which is used in `User.address`:
+
+```prisma file=schema.prisma showLineNumbers
+type Address {
+ street String
+ number Int
+}
+
+model User {
+ id Int @id
+ email String
+ address Address
+
+ @@unique([email, address.number])
+}
+```
+
+This notation can be chained if there is more than one nested composite type:
+
+```prisma file=schema.prisma showLineNumbers
+type City {
+ name String
+}
+
+type Address {
+ number Int
+ city City
+}
+
+model User {
+ id Int @id
+ address Address[]
+
+ @@unique([address.city.name])
+}
+```
+
+### Defining an index
+
+You can define indexes on one or multiple fields of your models via the [`@@index`](/orm/reference/prisma-schema-reference#index) on a model. The following example defines a multi-column index based on the `title` and `content` field:
+
+```prisma
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ content String?
+
+ @@index([title, content])
+}
+```
+
+
+
+**Index names in relational databases**
+You can optionally define a [custom index name](/orm/prisma-schema/data-model/database-mapping#constraint-and-index-names) in the underlying database.
+
+
+
+#### Defining composite type indexes
+
+When using the MongoDB provider in version `3.12.0` and later, you can define an index on a field of a [composite type](#defining-composite-types) using the syntax `@@index([compositeType.field])`. As with other fields, composite type fields can be used as part of a multi-column index.
+
+The following example defines a multi-column index based on the `email` field of the `User` model and the `number` field of the `Address` composite type:
+
+```prisma file=schema.prisma showLineNumbers
+type Address {
+ street String
+ number Int
+}
+
+model User {
+ id Int @id
+ email String
+ address Address
+
+ @@index([email, address.number])
+}
+```
+
+This notation can be chained if there is more than one nested composite type:
+
+```prisma file=schema.prisma showLineNumbers
+type City {
+ name String
+}
+
+type Address {
+ number Int
+ city City
+}
+
+model User {
+ id Int @id
+ address Address[]
+
+ @@index([address.city.name])
+}
+```
+
+## Defining enums
+
+You can define enums in your data model [if enums are supported for your database connector](/orm/reference/database-features#misc), either natively or at Prisma ORM level.
+
+Enums are considered [scalar](#scalar-fields) types in the Prisma schema data model. They're therefore [by default](/orm/prisma-client/queries/select-fields#return-the-default-fields) included as return values in [Prisma Client queries](/orm/prisma-client/queries/crud).
+
+Enums are defined via the [`enum`](/orm/reference/prisma-schema-reference#enum) block. For example, a `User` has a `Role`:
+
+
+
+
+```prisma highlight=5,8-11;normal
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ //highlight-next-line
+ role Role @default(USER)
+}
+
+//highlight-start
+enum Role {
+ USER
+ ADMIN
+}
+//highlight-end
+```
+
+
+
+
+```prisma highlight=5,8-11;normal
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ email String @unique
+ name String?
+ //highlight-next-line
+ role Role @default(USER)
+}
+
+//highlight-start
+enum Role {
+ USER
+ ADMIN
+}
+//highlight-end
+```
+
+
+
+
+## Defining composite types
+
+
+
+Composite types were added in version `3.10.0` under the `mongodb` Preview feature flag and are in General Availability since version `3.12.0`.
+
+
+
+
+
+Composite types are currently only available on MongoDB.
+
+
+
+Composite types (known as [embedded documents](https://www.mongodb.com/docs/manual/data-modeling/#embedded-data) in MongoDB) provide support for embedding records inside other records, by allowing you to define new object types. Composite types are structured and typed in a similar way to [models](#defining-models).
+
+To define a composite type, use the `type` block. As an example, take the following schema:
+
+```prisma file=schema.prisma showLineNumbers
+model Product {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ name String
+ photos Photo[]
+}
+
+type Photo {
+ height Int
+ width Int
+ url String
+}
+```
+
+In this case, the `Product` model has a list of `Photo` composite types stored in `photos`.
+
+### Considerations when using composite types
+
+Composite types only support a limited set of [attributes](/orm/reference/prisma-schema-reference#attributes). The following attributes are supported:
+
+- `@default`
+- `@map`
+- [Native types](/orm/reference/prisma-schema-reference#model-field-scalar-types), such as `@db.ObjectId`
+
+The following attributes are not supported inside composite types:
+
+- `@unique`
+- `@id`
+- `@relation`
+- `@ignore`
+- `@updatedAt`
+
+However, unique constraints can still be defined by using the `@@unique` attribute on the level of the model that uses the composite type. For more details, see [Composite type unique constraints](#composite-type-unique-constraints).
+
+Indexes can be defined by using the `@@index` attribute on the level of the model that uses the composite type. For more details, see [Composite type indexes](#defining-composite-type-indexes).
+
+## Using functions
+
+The Prisma schema supports a number of [functions](/orm/reference/prisma-schema-reference#attribute-functions) . These can be used to specify [default values](/orm/reference/prisma-schema-reference#default) on fields of a model.
+
+For example, the default value of `createdAt` is [`now()`](/orm/reference/prisma-schema-reference#now) :
+
+
+
+
+```prisma
+model Post {
+ id Int @id @default(autoincrement())
+ createdAt DateTime @default(now())
+}
+```
+
+
+
+
+```prisma
+model Post {
+ id String @default(auto()) @map("_id") @db.ObjectId
+ createdAt DateTime @default(now())
+}
+```
+
+
+
+
+[`cuid()`](/orm/reference/prisma-schema-reference#cuid) and [`uuid()`](/orm/reference/prisma-schema-reference#uuid) are implemented by Prisma ORM and therefore are not "visible" in the underlying database schema. You can still use them when using [introspection](/orm/prisma-schema/introspection) by [manually changing your Prisma schema](/orm/prisma-client/setup-and-configuration/custom-model-and-field-names) and [generating Prisma Client](/orm/prisma-client/setup-and-configuration/generating-prisma-client), in that case the values will be generated by Prisma Client's [query engine](/orm/more/under-the-hood/engines)
+
+Support for [`autoincrement()`](/orm/reference/prisma-schema-reference#autoincrement), [`now()`](/orm/reference/prisma-schema-reference#now), and [`dbgenerated(...)`](/orm/reference/prisma-schema-reference#dbgenerated) differ between databases.
+
+**Relational database connectors** implement `autoincrement()`, `dbgenerated(...)`, and `now()` at database level. The **MongoDB connector** does not support `autoincrement()` or `dbgenerated(...)`, and `now()` is implemented at the Prisma ORM level. The [`auto()`](/orm/reference/prisma-schema-reference#auto) function is used to generate an `ObjectId`.
+
+## Relations
+
+Refer to the [relations documentation](/orm/prisma-schema/data-model/relations) for more examples and information about relationships between models.
+
+## Models in Prisma Client
+
+### Queries (CRUD)
+
+Every model in the data model definition will result in a number of CRUD queries in the generated [Prisma Client API](/orm/prisma-client):
+
+- [`findMany()`](/6.0/orm/reference/prisma-client-reference#findmany)
+- [`findFirst()`](/6.0/orm/reference/prisma-client-reference#findfirst)
+- [`findFirstOrThrow()`](/6.0/orm/reference/prisma-client-reference#findfirstorthrow)
+- [`findUnique()`](/6.0/orm/reference/prisma-client-reference#findunique)
+- [`findUniqueOrThrow()`](/6.0/orm/reference/prisma-client-reference#finduniqueorthrow)
+- [`create()`](/6.0/orm/reference/prisma-client-reference#create)
+- [`update()`](/6.0/orm/reference/prisma-client-reference#update)
+- [`upsert()`](/6.0/orm/reference/prisma-client-reference#upsert)
+- [`delete()`](/6.0/orm/reference/prisma-client-reference#delete)
+- [`createMany()`](/6.0/orm/reference/prisma-client-reference#createmany)
+- [`createManyAndReturn()`](/6.0/orm/reference/prisma-client-reference#createmanyandreturn)
+- [`updateMany()`](/6.0/orm/reference/prisma-client-reference#updatemany)
+- [`updateManyAndReturn()`](/6.0/orm/reference/prisma-client-reference#updatemanyandreturn)
+- [`deleteMany()`](/6.0/orm/reference/prisma-client-reference#deletemany)
+
+The operations are accessible via a generated property on the Prisma Client instance. By default the name of the property is the lowercase form of the model name, e.g. `user` for a `User` model or `post` for a `Post` model.
+
+Here is an example illustrating the use of a `user` property from the Prisma Client API:
+
+```js
+const newUser = await prisma.user.create({
+ data: {
+ name: 'Alice',
+ },
+})
+const allUsers = await prisma.user.findMany()
+```
+
+### Type definitions
+
+Prisma Client also generates **type definitions** that reflect your model structures. These are part of the generated [`@prisma/client`](/orm/prisma-client/setup-and-configuration/generating-prisma-client#the-prismaclient-npm-package) node module.
+
+When using TypeScript, these type definitions ensure that all your database queries are entirely type safe and validated at compile-time (even partial queries using [`select`](/6.0/orm/reference/prisma-client-reference#select) or [`include`](/6.0/orm/reference/prisma-client-reference#include) ).
+
+Even when using plain JavaScript, the type definitions are still included in the `@prisma/client` node module, enabling features like [IntelliSense](https://code.visualstudio.com/docs/editor/intellisense)/autocompletion in your editor.
+
+> **Note**: The actual types are stored in the `.prisma/client` folder. `@prisma/client/index.d.ts` exports the contents of this folder.
+
+For example, the type definition for the `User` model from above would look as follows:
+
+```ts
+export type User = {
+ id: number
+ email: string
+ name: string | null
+ role: string
+}
+```
+
+Note that the relation fields `posts` and `profile` are not included in the type definition by default. However, if you need variations of the `User` type you can still define them using some of [Prisma Client's generated helper types](/orm/prisma-client/setup-and-configuration/generating-prisma-client) (in this case, these helper types would be called `UserGetIncludePayload` and `UserGetSelectPayload`).
+
+## Limitations
+
+### Records must be uniquely identifiable
+
+Prisma ORM currently only supports models that have at least one unique field or combination of fields. In practice, this means that every Prisma model must have either at least one of the following attributes:
+
+- `@id` or `@@id` for a single- or multi-field primary key constraint (max one per model)
+- `@unique` or `@@unique` for a single- or multi-field unique constraint
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/100-one-to-one-relations.mdx b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/100-one-to-one-relations.mdx
new file mode 100644
index 0000000000..4d92e087ae
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/100-one-to-one-relations.mdx
@@ -0,0 +1,316 @@
+---
+title: One-to-one relations
+metaDescription: How to define and work with one-to-one relations in Prisma.
+tocDepth: 3
+---
+
+
+
+This page introduces one-to-one relations and explains how to use them in your Prisma schema.
+
+
+
+
+Questions answered in this page
+
+- How do I model one-to-one relations?
+- Which side should store the foreign key?
+- How do optional vs required 1-1 work?
+
+
+
+## Overview
+
+One-to-one (1-1) relations refer to relations where at most **one** record can be connected on both sides of the relation. In the example below, there is a one-to-one relation between `User` and `Profile`:
+
+
+
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ profile Profile?
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ user User @relation(fields: [userId], references: [id])
+ userId Int @unique // relation scalar field (used in the `@relation` attribute above)
+}
+```
+
+
+
+
+```prisma
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ profile Profile?
+}
+
+model Profile {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ user User @relation(fields: [userId], references: [id])
+ userId String @unique @db.ObjectId // relation scalar field (used in the `@relation` attribute above)
+}
+```
+
+
+
+
+The `userId` relation scalar is a direct representation of the foreign key in the underlying database. This one-to-one relation expresses the following:
+
+- "a user can have zero profiles or one profile" (because the `profile` field is [optional](/orm/prisma-schema/data-model/models#type-modifiers) on `User`)
+- "a profile must always be connected to one user"
+
+In the previous example, the `user` relation field of the `Profile` model references the `id` field of the `User` model. You can also reference a different field. In this case, you need to mark the field with the `@unique` attribute, to guarantee that there is only a single `User` connected to each `Profile`. In the following example, the `user` field references an `email` field in the `User` model, which is marked with the `@unique` attribute:
+
+
+
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique // <-- add unique attribute
+ profile Profile?
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ user User @relation(fields: [userEmail], references: [email])
+ userEmail String @unique // relation scalar field (used in the `@relation` attribute above)
+}
+```
+
+
+
+
+```prisma
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ email String @unique // <-- add unique attribute
+ profile Profile?
+}
+
+model Profile {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ user User @relation(fields: [userEmail], references: [email])
+ userEmail String @unique @db.ObjectId // relation scalar field (used in the `@relation` attribute above)
+}
+```
+
+
+
+
+
+
+In MySQL, you can create a foreign key with only an index on the referenced side, and not a unique constraint. In Prisma ORM versions 4.0.0 and later, if you introspect a relation of this type it will trigger a validation error. To fix this, you will need to add a `@unique` constraint to the referenced field.
+
+
+
+## Multi-field relations in relational databases
+
+In **relational databases only**, you can also use [multi-field IDs](/orm/reference/prisma-schema-reference#id-1) to define a 1-1 relation:
+
+```prisma
+model User {
+ firstName String
+ lastName String
+ profile Profile?
+
+ @@id([firstName, lastName])
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ user User @relation(fields: [userFirstName, userLastName], references: [firstName, lastName])
+ userFirstName String // relation scalar field (used in the `@relation` attribute above)
+ userLastName String // relation scalar field (used in the `@relation` attribute above)
+
+ @@unique([userFirstName, userLastName])
+}
+```
+
+## 1-1 relations in the database
+
+### Relational databases
+
+The following example demonstrates how to create a 1-1 relation in SQL:
+
+```sql
+CREATE TABLE "User" (
+ id SERIAL PRIMARY KEY
+);
+CREATE TABLE "Profile" (
+ id SERIAL PRIMARY KEY,
+ "userId" INTEGER NOT NULL UNIQUE,
+ FOREIGN KEY ("userId") REFERENCES "User"(id)
+);
+```
+
+Notice that there is a `UNIQUE` constraint on the foreign key `userId`. If this `UNIQUE` constraint was missing, the relation would be considered a [1-n relation](/orm/prisma-schema/data-model/relations/one-to-many-relations).
+
+The following example demonstrates how to create a 1-1 relation in SQL using a composite key (`firstName` and `lastName`):
+
+```sql
+CREATE TABLE "User" (
+ firstName TEXT,
+ lastName TEXT,
+ PRIMARY KEY ("firstName","lastName")
+);
+CREATE TABLE "Profile" (
+ id SERIAL PRIMARY KEY,
+ "userFirstName" TEXT NOT NULL,
+ "userLastName" TEXT NOT NULL,
+ UNIQUE ("userFirstName", "userLastName")
+ FOREIGN KEY ("userFirstName", "userLastName") REFERENCES "User"("firstName", "lastName")
+);
+```
+
+### MongoDB
+
+For MongoDB, Prisma ORM currently uses a [normalized data model design](https://www.mongodb.com/docs/manual/data-modeling/), which means that documents reference each other by ID in a similar way to relational databases.
+
+The following MongoDB document represents a `User`:
+
+```json
+{ "_id": { "$oid": "60d58e130011041800d209e1" }, "name": "Bob" }
+```
+
+The following MongoDB document represents a `Profile` - notice the `userId` field, which references the `User` document's `$oid`:
+
+```json
+{
+ "_id": { "$oid": "60d58e140011041800d209e2" },
+ "bio": "I'm Bob, and I like drawing.",
+ "userId": { "$oid": "60d58e130011041800d209e1" }
+}
+```
+
+## Required and optional 1-1 relation fields
+
+In a one-to-one relation, the side of the relation _without_ a relation scalar (the field representing the foreign key in the database) _must_ be optional:
+
+```prisma highlight=3;normal
+model User {
+ id Int @id @default(autoincrement())
+ //highlight-next-line
+ profile Profile? // No relation scalar - must be optional
+}
+```
+
+This restriction was introduced in 2.12.0.
+
+However, you can choose if the side of the relation _with_ a relation scalar should be optional or mandatory.
+
+### Mandatory 1-1 relation
+
+In the following example, `profile` and `profileId` are mandatory. This means that you cannot create a `User` without connecting or creating a `Profile`:
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ profile Profile @relation(fields: [profileId], references: [id]) // references `id` of `Profile`
+ profileId Int @unique // relation scalar field (used in the `@relation` attribute above)
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ user User?
+}
+```
+
+### Optional 1-1 relation
+
+In the following example, `profile` and `profileId` are optional. This means that you can create a user without connecting or creating a `Profile`:
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ profile Profile? @relation(fields: [profileId], references: [id]) // references `id` of `Profile`
+ profileId Int? @unique // relation scalar field (used in the `@relation` attribute above)
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ user User?
+}
+```
+
+## Choosing which side should store the foreign key in a 1-1 relation
+
+In **1-1 relations**, you can decide yourself which side of the relation you want to annotate with the `@relation` attribute (and therefore holds the foreign key).
+
+In the following example, the relation field on the `Profile` model is annotated with the `@relation` attribute. `userId` is a direct representation of the foreign key in the underlying database:
+
+
+
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ profile Profile?
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ user User @relation(fields: [userId], references: [id])
+ userId Int @unique // relation scalar field (used in the `@relation` attribute above)
+}
+```
+
+
+
+
+```prisma
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ profile Profile?
+}
+
+model Profile {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ user User @relation(fields: [userId], references: [id])
+ userId String @unique @db.ObjectId
+}
+```
+
+
+
+
+You can also annotate the other side of the relation with the `@relation` attribute. The following example annotates the relation field on the `User` model. `profileId` is a direct representation of the foreign key in the underlying database:
+
+
+
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ profile Profile? @relation(fields: [profileId], references: [id])
+ profileId Int? @unique // relation scalar field (used in the `@relation` attribute above)
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ user User?
+}
+```
+
+
+
+
+```prisma
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ profile Profile? @relation(fields: [profileId], references: [id])
+ profileId String? @unique @db.ObjectId // relation scalar field (used in the `@relation` attribute above)
+}
+
+model Profile {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ user User?
+}
+```
+
+
+
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/200-one-to-many-relations.mdx b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/200-one-to-many-relations.mdx
new file mode 100644
index 0000000000..3472d120d9
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/200-one-to-many-relations.mdx
@@ -0,0 +1,285 @@
+---
+title: One-to-many relations
+metaDescription: How to define and work with one-to-many relations in Prisma.
+tocDepth: 3
+---
+
+This page introduces one-to-many relations and explains how to use them in your Prisma schema.
+
+
+Questions answered in this page
+
+- How do I model one-to-many relations?
+- Which side holds the foreign key in 1-n?
+- How do optional vs required 1-n work?
+
+
+
+## Overview
+
+One-to-many (1-n) relations refer to relations where one record on one side of the relation can be connected to zero or more records on the other side. In the following example, there is one one-to-many relation between the `User` and `Post` models:
+
+
+
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ posts Post[]
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+}
+```
+
+
+
+
+```prisma
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ posts Post[]
+}
+
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ author User @relation(fields: [authorId], references: [id])
+ authorId String @db.ObjectId
+}
+```
+
+
+
+
+> **Note** The `posts` field does not "manifest" in the underlying database schema. On the other side of the relation, the [annotated relation field](/orm/prisma-schema/data-model/relations#relation-fields) `author` and its relation scalar `authorId` represent the side of the relation that stores the foreign key in the underlying database.
+
+This one-to-many relation expresses the following:
+
+- "a user can have zero or more posts"
+- "a post must always have an author"
+
+In the previous example, the `author` relation field of the `Post` model references the `id` field of the `User` model. You can also reference a different field. In this case, you need to mark the field with the `@unique` attribute, to guarantee that there is only a single `User` connected to each `Post`. In the following example, the `author` field references an `email` field in the `User` model, which is marked with the `@unique` attribute:
+
+
+
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique // <-- add unique attribute
+ posts Post[]
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ authorEmail String
+ author User @relation(fields: [authorEmail], references: [email])
+}
+```
+
+
+
+
+```prisma
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ email String @unique // <-- add unique attribute
+ posts Post[]
+}
+
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ authorEmail String
+ author User @relation(fields: [authorEmail], references: [email])
+}
+```
+
+
+
+
+
+
+In MySQL, you can create a foreign key with only an index on the referenced side, and not a unique constraint. In Prisma ORM versions 4.0.0 and later, if you introspect a relation of this type it will trigger a validation error. To fix this, you will need to add a `@unique` constraint to the referenced field.
+
+
+
+## Multi-field relations in relational databases
+
+In **relational databases only**, you can also define this relation using [multi-field IDs](/orm/reference/prisma-schema-reference#id-1)/composite key:
+
+```prisma
+model User {
+ firstName String
+ lastName String
+ post Post[]
+
+ @@id([firstName, lastName])
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ author User @relation(fields: [authorFirstName, authorLastName], references: [firstName, lastName])
+ authorFirstName String // relation scalar field (used in the `@relation` attribute above)
+ authorLastName String // relation scalar field (used in the `@relation` attribute above)
+}
+```
+
+## 1-n relations in the database
+
+### Relational databases
+
+The following example demonstrates how to create a 1-n relation in SQL:
+
+```sql
+CREATE TABLE "User" (
+ id SERIAL PRIMARY KEY
+);
+CREATE TABLE "Post" (
+ id SERIAL PRIMARY KEY,
+ "authorId" integer NOT NULL,
+ FOREIGN KEY ("authorId") REFERENCES "User"(id)
+);
+```
+
+Since there's no `UNIQUE` constraint on the `authorId` column (the foreign key), you can create **multiple `Post` records that point to the same `User` record**. This makes the relation a one-to-many rather than a one-to-one.
+
+The following example demonstrates how to create a 1-n relation in SQL using a composite key (`firstName` and `lastName`):
+
+```sql
+CREATE TABLE "User" (
+ firstName TEXT,
+ lastName TEXT,
+ PRIMARY KEY ("firstName","lastName")
+);
+CREATE TABLE "Post" (
+ id SERIAL PRIMARY KEY,
+ "authorFirstName" TEXT NOT NULL,
+ "authorLastName" TEXT NOT NULL,
+ FOREIGN KEY ("authorFirstName", "authorLastName") REFERENCES "User"("firstName", "lastName")
+);
+```
+
+#### Comparing one-to-one and one-to-many relations
+
+In relational databases, the main difference between a 1-1 and a 1-n-relation is that in a 1-1-relation the foreign key must have a `UNIQUE` constraint defined on it.
+
+### MongoDB
+
+For MongoDB, Prisma ORM currently uses a [normalized data model design](https://www.mongodb.com/docs/manual/data-modeling/), which means that documents reference each other by ID in a similar way to relational databases.
+
+The following MongoDB document represents a `User`:
+
+```json
+{ "_id": { "$oid": "60d5922d00581b8f0062e3a8" }, "name": "Ella" }
+```
+
+Each of the following `Post` MongoDB documents has an `authorId` field which references the same user:
+
+```json
+[
+ {
+ "_id": { "$oid": "60d5922e00581b8f0062e3a9" },
+ "title": "How to make sushi",
+ "authorId": { "$oid": "60d5922d00581b8f0062e3a8" }
+ },
+ {
+ "_id": { "$oid": "60d5922e00581b8f0062e3aa" },
+ "title": "How to re-install Windows",
+ "authorId": { "$oid": "60d5922d00581b8f0062e3a8" }
+ }
+]
+```
+
+#### Comparing one-to-one and one-to-many relations
+
+In MongoDB, the only difference between a 1-1 and a 1-n is the number of documents referencing another document in the database - there are no constraints.
+
+## Required and optional relation fields in one-to-many relations
+
+A 1-n-relation always has two relation fields:
+
+- a [list](/orm/prisma-schema/data-model/models#type-modifiers) relation field which is _not_ annotated with `@relation`
+- the [annotated relation field](/orm/prisma-schema/data-model/relations#annotated-relation-fields) (including its relation scalar)
+
+The annotated relation field and relation scalar of a 1-n relation can either _both_ be optional, or _both_ be mandatory. On the other side of the relation, the list is **always mandatory**.
+
+### Optional one-to-many relation
+
+In the following example, you can create a `Post` without assigning a `User`:
+
+
+
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ posts Post[]
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ author User? @relation(fields: [authorId], references: [id])
+ authorId Int?
+}
+```
+
+
+
+
+```prisma
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ posts Post[]
+}
+
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ author User? @relation(fields: [authorId], references: [id])
+ authorId String? @db.ObjectId
+}
+```
+
+
+
+
+### Mandatory one-to-many relation
+
+In the following example, you must assign a `User` when you create a `Post`:
+
+
+
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ posts Post[]
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+}
+```
+
+
+
+
+```prisma
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ posts Post[]
+}
+
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ author User @relation(fields: [authorId], references: [id])
+ authorId String @db.ObjectId
+}
+```
+
+
+
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/300-many-to-many-relations.mdx b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/300-many-to-many-relations.mdx
new file mode 100644
index 0000000000..587c78fbbe
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/300-many-to-many-relations.mdx
@@ -0,0 +1,556 @@
+---
+title: Many-to-many relations
+metaDescription: How to define and work with many-to-many relations in Prisma.
+tocDepth: 3
+---
+
+
+
+Many-to-many (m-n) relations refer to relations where zero or more records on one side of the relation can be connected to zero or more records on the other side.
+
+Prisma schema syntax and the implementation in the underlying database differs between [relational databases](#relational-databases) and [MongoDB](#mongodb).
+
+
+
+
+Questions answered in this page
+
+- How do I model many-to-many in Prisma?
+- When to use implicit vs explicit m-n?
+- How do I query m-n relations?
+
+
+
+## Relational databases
+
+In relational databases, m-n-relations are typically modelled via [relation tables](/orm/prisma-schema/data-model/relations/many-to-many-relations#relation-tables). m-n-relations can be either [explicit](#explicit-many-to-many-relations) or [implicit](#implicit-many-to-many-relations) in the Prisma schema. We recommend using [implicit](#implicit-many-to-many-relations) m-n-relations if you do not need to store any additional meta-data in the relation table itself. You can always migrate to an [explicit](#explicit-many-to-many-relations) m-n-relation later if needed.
+
+### Explicit many-to-many relations
+
+In an explicit m-n relation, the **relation table is represented as a model in the Prisma schema** and can be used in queries. Explicit m-n relations define three models:
+
+- Two models with m-n relation, such as `Category` and `Post`.
+- One model that represents the [relation table](#relation-tables), such as `CategoriesOnPosts` (also sometimes called _JOIN_, _link_ or _pivot_ table) in the underlying database. The fields of a relation table model are both annotated relation fields (`post` and `category`) with a corresponding relation scalar field (`postId` and `categoryId`).
+
+The relation table `CategoriesOnPosts` connects related `Post` and `Category` records. In this example, the model representing the relation table also **defines additional fields** that describe the `Post`/`Category` relationship - who assigned the category (`assignedBy`), and when the category was assigned (`assignedAt`):
+
+```prisma
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ categories CategoriesOnPosts[]
+}
+
+model Category {
+ id Int @id @default(autoincrement())
+ name String
+ posts CategoriesOnPosts[]
+}
+
+model CategoriesOnPosts {
+ post Post @relation(fields: [postId], references: [id])
+ postId Int // relation scalar field (used in the `@relation` attribute above)
+ category Category @relation(fields: [categoryId], references: [id])
+ categoryId Int // relation scalar field (used in the `@relation` attribute above)
+ assignedAt DateTime @default(now())
+ assignedBy String
+
+ @@id([postId, categoryId])
+}
+```
+
+The underlying SQL looks like this:
+
+```sql
+CREATE TABLE "Post" (
+ "id" SERIAL NOT NULL,
+ "title" TEXT NOT NULL,
+
+ CONSTRAINT "Post_pkey" PRIMARY KEY ("id")
+);
+
+CREATE TABLE "Category" (
+ "id" SERIAL NOT NULL,
+ "name" TEXT NOT NULL,
+
+ CONSTRAINT "Category_pkey" PRIMARY KEY ("id")
+);
+
+
+-- Relation table + indexes --
+
+CREATE TABLE "CategoriesOnPosts" (
+ "postId" INTEGER NOT NULL,
+ "categoryId" INTEGER NOT NULL,
+ "assignedAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
+ "assignedBy" TEXT NOT NULL,
+
+ CONSTRAINT "CategoriesOnPosts_pkey" PRIMARY KEY ("postId","categoryId")
+);
+
+ALTER TABLE "CategoriesOnPosts" ADD CONSTRAINT "CategoriesOnPosts_postId_fkey" FOREIGN KEY ("postId") REFERENCES "Post"("id") ON DELETE RESTRICT ON UPDATE CASCADE;
+ALTER TABLE "CategoriesOnPosts" ADD CONSTRAINT "CategoriesOnPosts_categoryId_fkey" FOREIGN KEY ("categoryId") REFERENCES "Category"("id") ON DELETE RESTRICT ON UPDATE CASCADE;
+```
+
+Note that the same rules as for [1-n relations](/orm/prisma-schema/data-model/relations/one-to-many-relations) apply (because `Post`↔ `CategoriesOnPosts` and `Category` ↔ `CategoriesOnPosts` are both in fact 1-n relations), which means one side of the relation needs to be annotated with the `@relation` attribute.
+
+When you don't need to attach additional information to the relation, you can model m-n-relations as [implicit m-n-relations](#implicit-many-to-many-relations). If you're not using Prisma Migrate but obtain your data model from [introspection](/orm/prisma-schema/introspection), you can still make use of implicit m-n-relations by following Prisma ORM's [conventions for relation tables](#conventions-for-relation-tables-in-implicit-m-n-relations).
+
+#### Querying an explicit many-to-many
+
+The following section demonstrates how to query an explicit m-n-relation. You can query the relation model directly (`prisma.categoriesOnPosts(...)`), or use nested queries to go from `Post` -> `CategoriesOnPosts` -> `Category` or the other way.
+
+The following query does three things:
+
+1. Creates a `Post`
+2. Creates a new record in the relation table `CategoriesOnPosts`
+3. Creates a new `Category` that is associated with the newly created `Post` record
+
+```ts
+const createCategory = await prisma.post.create({
+ data: {
+ title: 'How to be Bob',
+ categories: {
+ create: [
+ {
+ assignedBy: 'Bob',
+ assignedAt: new Date(),
+ category: {
+ create: {
+ name: 'New category',
+ },
+ },
+ },
+ ],
+ },
+ },
+})
+```
+
+The following query:
+
+- Creates a new `Post`
+- Creates a new record in the relation table `CategoriesOnPosts`
+- Connects the category assignment to existing categories (with IDs `9` and `22`)
+
+```ts
+const assignCategories = await prisma.post.create({
+ data: {
+ title: 'How to be Bob',
+ categories: {
+ create: [
+ {
+ assignedBy: 'Bob',
+ assignedAt: new Date(),
+ category: {
+ connect: {
+ id: 9,
+ },
+ },
+ },
+ {
+ assignedBy: 'Bob',
+ assignedAt: new Date(),
+ category: {
+ connect: {
+ id: 22,
+ },
+ },
+ },
+ ],
+ },
+ },
+})
+```
+
+Sometimes you might not know if a `Category` record exists. If the `Category` record exists, you want to connect a new `Post` record to that category. If the `Category` record does not exist, you want to create the record first and then connect it to the new `Post` record. The following query:
+
+1. Creates a new `Post`
+2. Creates a new record in the relation table `CategoriesOnPosts`
+3. Connects the category assignment to an existing category (with ID `9`), or creates a new category first if it does not exist
+
+```ts
+const assignCategories = await prisma.post.create({
+ data: {
+ title: 'How to be Bob',
+ categories: {
+ create: [
+ {
+ assignedBy: 'Bob',
+ assignedAt: new Date(),
+ category: {
+ connectOrCreate: {
+ where: {
+ id: 9,
+ },
+ create: {
+ name: 'New Category',
+ id: 9,
+ },
+ },
+ },
+ },
+ ],
+ },
+ },
+})
+```
+
+The following query returns all `Post` records where at least one (`some`) category assignment (`categories`) refers to a category named `"New category"`:
+
+```ts
+const getPosts = await prisma.post.findMany({
+ where: {
+ categories: {
+ some: {
+ category: {
+ name: 'New Category',
+ },
+ },
+ },
+ },
+})
+```
+
+The following query returns all categories where at least one (`some`) related `Post` record titles contain the words `"Cool stuff"` _and_ the category was assigned by Bob.
+
+```ts
+const getAssignments = await prisma.category.findMany({
+ where: {
+ posts: {
+ some: {
+ assignedBy: 'Bob',
+ post: {
+ title: {
+ contains: 'Cool stuff',
+ },
+ },
+ },
+ },
+ },
+})
+```
+
+The following query gets all category assignments (`CategoriesOnPosts`) records that were assigned by `"Bob"` to one of 5 posts:
+
+```ts
+const getAssignments = await prisma.categoriesOnPosts.findMany({
+ where: {
+ assignedBy: 'Bob',
+ post: {
+ id: {
+ in: [9, 4, 10, 12, 22],
+ },
+ },
+ },
+})
+```
+
+### Implicit many-to-many relations
+
+Implicit m-n relations define relation fields as lists on both sides of the relation. Although the relation table exists in the underlying database, **it is managed by Prisma ORM and does not manifest in the Prisma schema**. Implicit relation tables follow a [specific convention](#conventions-for-relation-tables-in-implicit-m-n-relations).
+
+Implicit m-n-relations makes the [Prisma Client API](/orm/prisma-client) for m-n-relations a bit simpler (since you have one fewer level of nesting inside of [nested writes](/orm/prisma-client/queries/relation-queries#nested-writes)).
+
+In the example below, there's one _implicit_ m-n-relation between `Post` and `Category`:
+
+
+
+
+```prisma
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ categories Category[]
+}
+
+model Category {
+ id Int @id @default(autoincrement())
+ name String
+ posts Post[]
+}
+```
+
+
+
+
+```prisma
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ categoryIDs String[] @db.ObjectId
+ categories Category[] @relation(fields: [categoryIDs], references: [id])
+}
+
+model Category {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ name String
+ postIDs String[] @db.ObjectId
+ posts Post[] @relation(fields: [postIDs], references: [id])
+}
+```
+
+
+
+
+#### Querying an implicit many-to-many
+
+The following section demonstrates how to query an [implicit m-n](#implicit-many-to-many-relations) relation. The queries require less nesting than [explicit m-n queries](#querying-an-explicit-many-to-many).
+
+The following query creates a single `Post` and multiple `Category` records:
+
+```ts
+const createPostAndCategory = await prisma.post.create({
+ data: {
+ title: 'How to become a butterfly',
+ categories: {
+ create: [{ name: 'Magic' }, { name: 'Butterflies' }],
+ },
+ },
+})
+```
+
+The following query creates a single `Category` and multiple `Post` records:
+
+```ts
+const createCategoryAndPosts = await prisma.category.create({
+ data: {
+ name: 'Stories',
+ posts: {
+ create: [
+ { title: 'That one time with the stuff' },
+ { title: 'The story of planet Earth' },
+ ],
+ },
+ },
+})
+```
+
+The following query returns all `Post` records with a list of that post's assigned categories:
+
+```ts
+const getPostsAndCategories = await prisma.post.findMany({
+ include: {
+ categories: true,
+ },
+})
+```
+
+#### Rules for defining an implicit m-n relation
+
+Implicit m-n relations:
+
+- Use a specific [convention for relation tables](#conventions-for-relation-tables-in-implicit-m-n-relations)
+- Do **not** require the `@relation` attribute unless you need to [disambiguate relations](/orm/prisma-schema/data-model/relations#disambiguating-relations) with a name, e.g. `@relation("MyRelation")` or `@relation(name: "MyRelation")`.
+- If you do use the `@relation` attribute, you cannot use the `references`, `fields`, `onUpdate` or `onDelete` arguments. This is because these take a fixed value for implicit m-n-relations and cannot be changed.
+- Require both models to have a single `@id`. Be aware that:
+
+ - You cannot use a [multi-field ID](/orm/reference/prisma-schema-reference#id-1)
+ - You cannot use a `@unique` in place of an `@id`
+
+
+
+ To use either of these features, you must use an [explicit m-n instead](#explicit-many-to-many-relations).
+
+
+
+#### Conventions for relation tables in implicit m-n relations
+
+If you obtain your data model from [introspection](/orm/prisma-schema/introspection), you can still use implicit m-n-relations by following Prisma ORM's [conventions for relation tables](#conventions-for-relation-tables-in-implicit-m-n-relations). The following example assumes you want to create a relation table to get an implicit m-n-relation for two models called `Post` and `Category`.
+
+##### Relation table
+
+If you want a relation table to be picked up by introspection as an implicit m-n-relation, the name must follow this exact structure:
+
+- It must start with an underscore `_`
+- Then the name of the first model in alphabetical order (in this case `Category`)
+- Then the relationship (in this case `To`)
+- Then the name of the second model in alphabetical order (in this case `Post`)
+
+In the example, the correct table name is `_CategoryToPost`.
+
+When creating an implicit m-n-relation yourself in the Prisma schema file, you can [configure the relation](#configuring-the-name-of-the-relation-table-in-implicit-many-to-many-relations) to have a different name. This will change the name given to the relation table in the database. For example, for a relation named `"MyRelation"` the corresponding table will be called `_MyRelation`.
+
+###### Multi-schema
+
+If your implicit many-to-many relationship spans multiple database schemas (using the [`multiSchema` feature](/orm/prisma-schema/data-model/multi-schema)), the relation table (with the name defined directly above, in the example `_CategoryToPost`) must be present in the same database schema as the first model in alphabetical order (in this case `Category`).
+
+##### Columns
+
+A relation table for an implicit m-n-relation must have exactly two columns:
+
+- A foreign key column that points to `Category` called `A`
+- A foreign key column that points to `Post` called `B`
+
+The columns must be called `A` and `B` where `A` points to the model that comes first in the alphabet and `B` points to the model which comes last in the alphabet.
+
+##### Indexes
+
+There further must be:
+
+- A unique index defined on both foreign key columns:
+
+ ```sql
+ CREATE UNIQUE INDEX "_CategoryToPost_AB_unique" ON "_CategoryToPost"("A" int4_ops,"B" int4_ops);
+ ```
+
+- A non-unique index defined on B:
+
+ ```sql
+ CREATE INDEX "_CategoryToPost_B_index" ON "_CategoryToPost"("B" int4_ops);
+ ```
+
+##### Example
+
+This is a sample SQL statement that would create the three tables including indexes (in PostgreSQL dialect) that are picked up as a implicit m-n-relation by Prisma Introspection:
+
+```sql
+CREATE TABLE "_CategoryToPost" (
+ "A" integer NOT NULL REFERENCES "Category"(id) ,
+ "B" integer NOT NULL REFERENCES "Post"(id)
+);
+CREATE UNIQUE INDEX "_CategoryToPost_AB_unique" ON "_CategoryToPost"("A" int4_ops,"B" int4_ops);
+CREATE INDEX "_CategoryToPost_B_index" ON "_CategoryToPost"("B" int4_ops);
+
+CREATE TABLE "Category" (
+ id integer SERIAL PRIMARY KEY
+);
+
+CREATE TABLE "Post" (
+ id integer SERIAL PRIMARY KEY
+);
+```
+
+And you can define multiple many-to-many relations between two tables by using the different relationship name. This example shows how the Prisma introspection works under such case:
+
+```sql
+CREATE TABLE IF NOT EXISTS "User" (
+ "id" SERIAL PRIMARY KEY
+);
+CREATE TABLE IF NOT EXISTS "Video" (
+ "id" SERIAL PRIMARY KEY
+);
+CREATE TABLE IF NOT EXISTS "_UserLikedVideos" (
+ "A" SERIAL NOT NULL,
+ "B" SERIAL NOT NULL,
+ CONSTRAINT "_UserLikedVideos_A_fkey" FOREIGN KEY ("A") REFERENCES "User" ("id") ON DELETE CASCADE ON UPDATE CASCADE,
+ CONSTRAINT "_UserLikedVideos_B_fkey" FOREIGN KEY ("B") REFERENCES "Video" ("id") ON DELETE CASCADE ON UPDATE CASCADE
+);
+CREATE TABLE IF NOT EXISTS "_UserDislikedVideos" (
+ "A" SERIAL NOT NULL,
+ "B" SERIAL NOT NULL,
+ CONSTRAINT "_UserDislikedVideos_A_fkey" FOREIGN KEY ("A") REFERENCES "User" ("id") ON DELETE CASCADE ON UPDATE CASCADE,
+ CONSTRAINT "_UserDislikedVideos_B_fkey" FOREIGN KEY ("B") REFERENCES "Video" ("id") ON DELETE CASCADE ON UPDATE CASCADE
+);
+CREATE UNIQUE INDEX "_UserLikedVideos_AB_unique" ON "_UserLikedVideos"("A", "B");
+CREATE INDEX "_UserLikedVideos_B_index" ON "_UserLikedVideos"("B");
+CREATE UNIQUE INDEX "_UserDislikedVideos_AB_unique" ON "_UserDislikedVideos"("A", "B");
+CREATE INDEX "_UserDislikedVideos_B_index" ON "_UserDislikedVideos"("B");
+```
+
+If you run `prisma db pull` on this database, the Prisma CLI will generate the following schema through introspection:
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ Video_UserDislikedVideos Video[] @relation("UserDislikedVideos")
+ Video_UserLikedVideos Video[] @relation("UserLikedVideos")
+}
+
+model Video {
+ id Int @id @default(autoincrement())
+ User_UserDislikedVideos User[] @relation("UserDislikedVideos")
+ User_UserLikedVideos User[] @relation("UserLikedVideos")
+}
+```
+
+#### Configuring the name of the relation table in implicit many-to-many relations
+
+When using Prisma Migrate, you can configure the name of the relation table that's managed by Prisma ORM using the `@relation` attribute. For example, if you want the relation table to be called `_MyRelationTable` instead of the default name `_CategoryToPost`, you can specify it as follows:
+
+```prisma
+model Post {
+ id Int @id @default(autoincrement())
+ categories Category[] @relation("MyRelationTable")
+}
+
+model Category {
+ id Int @id @default(autoincrement())
+ posts Post[] @relation("MyRelationTable")
+}
+```
+
+### Relation tables
+
+A relation table (also sometimes called a _JOIN_, _link_ or _pivot_ table) connects two or more other tables and therefore creates a _relation_ between them. Creating relation tables is a common data modelling practice in SQL to represent relationships between different entities. In essence it means that "one m-n relation is modeled as two 1-n relations in the database".
+
+We recommend using [implicit](#implicit-many-to-many-relations) m-n-relations, where Prisma ORM automatically generates the relation table in the underlying database. [Explicit](#explicit-many-to-many-relations) m-n-relations should be used when you need to store additional data in the relations, such as the date the relation was created.
+
+## MongoDB
+
+In MongoDB, m-n-relations are represented by:
+
+- relation fields on both sides, that each have a `@relation` attribute, with mandatory `fields` and `references` arguments
+- a scalar list of referenced IDs on each side, with a type that matches the ID field on the other side
+
+The following example demonstrates a m-n-relation between posts and categories:
+
+```prisma
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ categoryIDs String[] @db.ObjectId
+ categories Category[] @relation(fields: [categoryIDs], references: [id])
+}
+
+model Category {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ name String
+ postIDs String[] @db.ObjectId
+ posts Post[] @relation(fields: [postIDs], references: [id])
+}
+```
+
+Prisma ORM validates m-n-relations in MongoDB with the following rules:
+
+- The fields on both sides of the relation must have a list type (in the example above, `categories` have a type of `Category[]` and `posts` have a type of `Post[]`)
+- The `@relation` attribute must define `fields` and `references` arguments on both sides
+- The `fields` argument must have only one scalar field defined, which must be of a list type
+- The `references` argument must have only one scalar field defined. This scalar field must exist on the referenced model and must be of the same type as the scalar field in the `fields` argument, but singular (no list)
+- The scalar field to which `references` points must have the `@id` attribute
+- No [referential actions](/orm/prisma-schema/data-model/relations/referential-actions) are allowed in `@relation`
+
+The implicit m-n-relations [used in relational databases](/orm/prisma-schema/data-model/relations/many-to-many-relations#implicit-many-to-many-relations) are not supported on MongoDB.
+
+### Querying MongoDB many-to-many relations
+
+This section demonstrates how to query m-n-relations in MongoDB, using the example schema above.
+
+The following query finds posts with specific matching category IDs:
+
+```ts
+const newId1 = new ObjectId()
+const newId2 = new ObjectId()
+
+const posts = await prisma.post.findMany({
+ where: {
+ categoryIDs: {
+ hasSome: [newId1.toHexString(), newId2.toHexString()],
+ },
+ },
+})
+```
+
+The following query finds posts where the category name contains the string `'Servers'`:
+
+```ts
+const posts = await prisma.post.findMany({
+ where: {
+ categories: {
+ some: {
+ name: {
+ contains: 'Servers',
+ },
+ },
+ },
+ },
+})
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/400-self-relations.mdx b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/400-self-relations.mdx
new file mode 100644
index 0000000000..d06f36df6f
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/400-self-relations.mdx
@@ -0,0 +1,447 @@
+---
+title: Self-relations
+metaDescription: How to define and work with self-relations in Prisma.
+---
+
+A relation field can also reference its own model, in this case the relation is called a _self-relation_. Self-relations can be of any cardinality, 1-1, 1-n and m-n.
+
+
+Questions answered in this page
+
+- How do I model self-relations?
+- Do self-relations always require @relation?
+- How do 1-1 vs 1-n self-relations differ?
+
+
+
+Note that self-relations always require the `@relation` attribute.
+
+## One-to-one self-relations
+
+The following example models a one-to-one self-relation:
+
+
+
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ name String?
+ successorId Int? @unique
+ successor User? @relation("BlogOwnerHistory", fields: [successorId], references: [id])
+ predecessor User? @relation("BlogOwnerHistory")
+}
+```
+
+
+
+
+```prisma
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ name String?
+ successorId String? @unique @db.ObjectId
+ successor User? @relation("BlogOwnerHistory", fields: [successorId], references: [id])
+ predecessor User? @relation("BlogOwnerHistory")
+}
+```
+
+
+
+
+This relation expresses the following:
+
+- "a user can have one or zero predecessors" (for example, Sarah is Mary's predecessor as blog owner)
+- "a user can have one or zero successors" (for example, Mary is Sarah's successor as blog owner)
+
+> **Note**: One-to-one self-relations cannot be made required on both sides. One or both sides must be optional, otherwise it becomes impossible to create the first `User` record.
+
+To create a one-to-one self-relation:
+
+- Both sides of the relation must define a `@relation` attribute that share the same name - in this case, **BlogOwnerHistory**.
+- One relation field must be a [fully annotated](/orm/prisma-schema/data-model/relations#relation-fields). In this example, the `successor` field defines both the `field` and `references` arguments.
+- One relation field must be backed by a foreign key. The `successor` field is backed by the `successorId` foreign key, which references a value in the `id` field. The `successorId` scalar relation field also requires a `@unique` attribute to guarantee a one-to-one relation.
+
+> **Note**: One-to-one self relations require two sides even if both sides are equal in the relationship. For example, to model a 'best friends' relation, you would need to create two relation fields: `bestfriend1` and a `bestfriend2`.
+
+Either side of the relation can be backed by a foreign key. In the previous example, repeated below, `successor` is backed by `successorId`:
+
+
+
+
+```prisma highlight=4;normal
+model User {
+ id Int @id @default(autoincrement())
+ name String?
+ //highlight-next-line
+ successorId Int? @unique
+ successor User? @relation("BlogOwnerHistory", fields: [successorId], references: [id])
+ predecessor User? @relation("BlogOwnerHistory")
+}
+```
+
+
+
+
+```prisma
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ name String?
+ //highlight-next-line
+ successorId String? @unique @db.ObjectId
+ successor User? @relation("BlogOwnerHistory", fields: [successorId], references: [id])
+ predecessor User? @relation("BlogOwnerHistory")
+}
+```
+
+
+
+
+Alternatively, you could rewrite this so that `predecessor` is backed by `predecessorId`:
+
+
+
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ name String?
+ successor User? @relation("BlogOwnerHistory")
+ //highlight-start
+ predecessorId Int? @unique
+ predecessor User? @relation("BlogOwnerHistory", fields: [predecessorId], references: [id])
+ //highlight-end
+}
+```
+
+
+
+
+```prisma
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ name String?
+ successor User? @relation("BlogOwnerHistory")
+ //highlight-start
+ predecessorId String? @unique @db.ObjectId
+ predecessor User? @relation("BlogOwnerHistory", fields: [predecessorId], references: [id])
+ //highlight-end
+}
+```
+
+
+
+
+No matter which side is backed by a foreign key, Prisma Client surfaces both the `predecessor` and `successor` fields:
+
+```ts showLineNumbers
+const x = await prisma.user.create({
+ data: {
+ name: "Bob McBob",
+ //highlight-next-line
+ successor: {
+ connect: {
+ id: 2,
+ },
+ },
+ //highlight-next-line
+ predecessor: {
+ connect: {
+ id: 4,
+ },
+ },
+ },
+});
+```
+
+### One-to-one self relations in the database
+
+### Relational databases
+
+In **relational databases only**, a one-to-one self-relation is represented by the following SQL:
+
+```sql
+CREATE TABLE "User" (
+ id SERIAL PRIMARY KEY,
+ "name" TEXT,
+ "successorId" INTEGER
+);
+
+ALTER TABLE "User" ADD CONSTRAINT fk_successor_user FOREIGN KEY ("successorId") REFERENCES "User" (id);
+
+ALTER TABLE "User" ADD CONSTRAINT successor_unique UNIQUE ("successorId");
+```
+
+### MongoDB
+
+For MongoDB, Prisma ORM currently uses a [normalized data model design](https://www.mongodb.com/docs/manual/data-modeling/), which means that documents reference each other by ID in a similar way to relational databases.
+
+The following MongoDB documents represent a one-to-one self-relation between two users:
+
+```json
+{ "_id": { "$oid": "60d97df70080618f000e3ca9" }, "name": "Elsa the Elder" }
+```
+
+```json
+{
+ "_id": { "$oid": "60d97df70080618f000e3caa" },
+ "name": "Elsa",
+ "successorId": { "$oid": "60d97df70080618f000e3ca9" }
+}
+```
+
+## One-to-many self relations
+
+A one-to-many self-relation looks as follows:
+
+
+
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ name String?
+ teacherId Int?
+ teacher User? @relation("TeacherStudents", fields: [teacherId], references: [id])
+ students User[] @relation("TeacherStudents")
+}
+```
+
+
+
+
+```prisma
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ name String?
+ teacherId String? @db.ObjectId
+ teacher User? @relation("TeacherStudents", fields: [teacherId], references: [id])
+ students User[] @relation("TeacherStudents")
+}
+```
+
+
+
+
+This relation expresses the following:
+
+- "a user has zero or one _teachers_ "
+- "a user can have zero or more _students_"
+
+Note that you can also require each user to have a teacher by making the `teacher` field [required](/orm/prisma-schema/data-model/models#optional-and-mandatory-fields).
+
+### One-to-many self-relations in the database
+
+### Relational databases
+
+In relational databases, a one-to-many self-relation is represented by the following SQL:
+
+```sql
+CREATE TABLE "User" (
+ id SERIAL PRIMARY KEY,
+ "name" TEXT,
+ "teacherId" INTEGER
+);
+
+ALTER TABLE "User" ADD CONSTRAINT fk_teacherid_user FOREIGN KEY ("teacherId") REFERENCES "User" (id);
+```
+
+Notice the lack of `UNIQUE` constraint on `teacherId` - multiple students can have the same teacher.
+
+### MongoDB
+
+For MongoDB, Prisma ORM currently uses a [normalized data model design](https://www.mongodb.com/docs/manual/data-modeling/), which means that documents reference each other by ID in a similar way to relational databases.
+
+The following MongoDB documents represent a one-to-many self-relation between three users - one teacher and two students with the same `teacherId`:
+
+```json
+{
+ "_id": { "$oid": "60d9b9e600fe3d470079d6f9" },
+ "name": "Ms. Roberts"
+}
+```
+
+```json
+{
+ "_id": { "$oid": "60d9b9e600fe3d470079d6fa" },
+ "name": "Student 8",
+ "teacherId": { "$oid": "60d9b9e600fe3d470079d6f9" }
+}
+```
+
+```json
+{
+ "_id": { "$oid": "60d9b9e600fe3d470079d6fb" },
+ "name": "Student 9",
+ "teacherId": { "$oid": "60d9b9e600fe3d470079d6f9" }
+}
+```
+
+## Many-to-many self relations
+
+A many-to-many self-relation looks as follows:
+
+
+
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ name String?
+ followedBy User[] @relation("UserFollows")
+ following User[] @relation("UserFollows")
+}
+```
+
+
+
+
+```prisma
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ name String?
+ followedBy User[] @relation("UserFollows", fields: [followedByIDs], references: [id])
+ followedByIDs String[] @db.ObjectId
+ following User[] @relation("UserFollows", fields: [followingIDs], references: [id])
+ followingIDs String[] @db.ObjectId
+}
+```
+
+
+
+
+This relation expresses the following:
+
+- "a user can be followed by zero or more users"
+- "a user can follow zero or more users"
+
+Note that for relational databases, this many-to-many-relation is [implicit](/orm/prisma-schema/data-model/relations/many-to-many-relations#implicit-many-to-many-relations). This means Prisma ORM maintains a [relation table](/orm/prisma-schema/data-model/relations/many-to-many-relations#relation-tables) for it in the underlying database.
+
+If you need the relation to hold other fields, you can create an [explicit](/orm/prisma-schema/data-model/relations/many-to-many-relations#explicit-many-to-many-relations) many-to-many self relation as well. The explicit version of the self relation shown previously is as follows:
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ name String?
+ followedBy Follows[] @relation("followedBy")
+ following Follows[] @relation("following")
+}
+
+model Follows {
+ followedBy User @relation("followedBy", fields: [followedById], references: [id])
+ followedById Int
+ following User @relation("following", fields: [followingId], references: [id])
+ followingId Int
+
+ @@id([followingId, followedById])
+}
+```
+
+### Many-to-many self-relations in the database
+
+### Relational databases
+
+In relational databases, a many-to-many self-relation (implicit) is represented by the following SQL:
+
+```sql
+CREATE TABLE "User" (
+ id integer DEFAULT nextval('"User_id_seq"'::regclass) PRIMARY KEY,
+ name text
+);
+CREATE TABLE "_UserFollows" (
+ "A" integer NOT NULL REFERENCES "User"(id) ON DELETE CASCADE ON UPDATE CASCADE,
+ "B" integer NOT NULL REFERENCES "User"(id) ON DELETE CASCADE ON UPDATE CASCADE
+);
+```
+
+### MongoDB
+
+For MongoDB, Prisma ORM currently uses a [normalized data model design](https://www.mongodb.com/docs/manual/data-modeling/), which means that documents reference each other by ID in a similar way to relational databases.
+
+The following MongoDB documents represent a many-to-many self-relation between five users - two users that follow `"Bob"`, and two users that follow him:
+
+```json
+{
+ "_id": { "$oid": "60d9866f00a3e930009a6cdd" },
+ "name": "Bob",
+ "followedByIDs": [
+ { "$oid": "60d9866f00a3e930009a6cde" },
+ { "$oid": "60d9867000a3e930009a6cdf" }
+ ],
+ "followingIDs": [
+ { "$oid": "60d9867000a3e930009a6ce0" },
+ { "$oid": "60d9867000a3e930009a6ce1" }
+ ]
+}
+```
+
+```json
+{
+ "_id": { "$oid": "60d9866f00a3e930009a6cde" },
+ "name": "Follower1",
+ "followingIDs": [{ "$oid": "60d9866f00a3e930009a6cdd" }]
+}
+```
+
+```json
+{
+ "_id": { "$oid": "60d9867000a3e930009a6cdf" },
+ "name": "Follower2",
+ "followingIDs": [{ "$oid": "60d9866f00a3e930009a6cdd" }]
+}
+```
+
+```json
+{
+ "_id": { "$oid": "60d9867000a3e930009a6ce0" },
+ "name": "CoolPerson1",
+ "followedByIDs": [{ "$oid": "60d9866f00a3e930009a6cdd" }]
+}
+```
+
+```json
+{
+ "_id": { "$oid": "60d9867000a3e930009a6ce1" },
+ "name": "CoolPerson2",
+ "followedByIDs": [{ "$oid": "60d9866f00a3e930009a6cdd" }]
+}
+```
+
+## Defining multiple self-relations on the same model
+
+You can also define multiple self-relations on the same model at once. Taking all relations from the previous sections as example, you could define a `User` model as follows:
+
+
+
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ name String?
+ teacherId Int?
+ teacher User? @relation("TeacherStudents", fields: [teacherId], references: [id])
+ students User[] @relation("TeacherStudents")
+ followedBy User[] @relation("UserFollows")
+ following User[] @relation("UserFollows")
+}
+```
+
+
+
+
+```prisma
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ name String?
+ teacherId String? @db.ObjectId
+ teacher User? @relation("TeacherStudents", fields: [teacherId], references: [id])
+ students User[] @relation("TeacherStudents")
+ followedBy User[] @relation("UserFollows", fields: [followedByIDs])
+ followedByIDs String[] @db.ObjectId
+ following User[] @relation("UserFollows", fields: [followingIDs])
+ followingIDs String[] @db.ObjectId
+}
+```
+
+
+
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/410-referential-actions/100-special-rules-for-referential-actions.mdx b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/410-referential-actions/100-special-rules-for-referential-actions.mdx
new file mode 100644
index 0000000000..15634236d5
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/410-referential-actions/100-special-rules-for-referential-actions.mdx
@@ -0,0 +1,264 @@
+---
+title: 'Special rules for referential actions in SQL Server and MongoDB'
+metaTitle: 'Special rules for referential actions in SQL Server and MongoDB'
+metaDescription: 'Circular references or multiple cascade paths can cause validation errors on Microsoft SQL Server and MongoDB. Since the database does not handle these situations out of the box, learn how to solve this problem.'
+tocDepth: 3
+---
+
+
+
+Some databases have specific requirements that you should consider if you are using referential actions.
+
+- Microsoft SQL Server doesn't allow cascading referential actions on a foreign key, if the relation chain causes a cycle or multiple cascade paths. If the referential actions on the foreign key are set to something other than `NO ACTION` (or `NoAction` if Prisma ORM is managing referential integrity), the server will check for cycles or multiple cascade paths and return an error when executing the SQL.
+
+- With MongoDB, using referential actions in Prisma ORM requires that for any data model with self-referential relations or cycles between three models, you must set the referential action of `NoAction` to prevent the referential action emulations from looping infinitely. Be aware that by default, the `relationMode = "prisma"` mode is used for MongoDB, which means that Prisma ORM manages [referential integrity](/orm/prisma-schema/data-model/relations/relation-mode).
+
+Given the SQL:
+
+```sql
+CREATE TABLE [dbo].[Employee] (
+ [id] INT NOT NULL IDENTITY(1,1),
+ [managerId] INT,
+ CONSTRAINT [PK__Employee__id] PRIMARY KEY ([id])
+);
+
+ALTER TABLE [dbo].[Employee]
+ ADD CONSTRAINT [FK__Employee__managerId]
+ FOREIGN KEY ([managerId]) REFERENCES [dbo].[Employee]([id])
+ ON DELETE CASCADE ON UPDATE CASCADE;
+```
+
+When the SQL is run, the database would throw the following error:
+
+```terminal wrap
+Introducing FOREIGN KEY constraint 'FK__Employee__managerId' on table 'Employee' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints.
+```
+
+In more complicated data models, finding the cascade paths can get complex. Therefore in Prisma ORM, the data model is validated _before_ generating any SQL to be run during any migrations, highlighting relations that are part of the paths. This makes it much easier to find and break these action chains.
+
+
+
+
+Questions answered in this page
+
+- How do I fix cascade cycles on SQL Server?
+- Do MongoDB self-relations require NoAction?
+- How do I handle multiple cascade paths?
+
+
+
+## Self-relation (SQL Server and MongoDB)
+
+The following model describes a self-relation where an `Employee` can have a manager and managees, referencing entries of the same model.
+
+```prisma
+model Employee {
+ id Int @id @default(autoincrement())
+ manager Employee? @relation(name: "management", fields: [managerId], references: [id])
+ managees Employee[] @relation(name: "management")
+ managerId Int?
+}
+```
+
+This will result in the following error:
+
+```terminal wrap
+Error parsing attribute "@relation": A self-relation must have `onDelete` and `onUpdate` referential actions set to `NoAction` in one of the @relation attributes. (Implicit default `onDelete`: `SetNull`, and `onUpdate`: `Cascade`)
+```
+
+By not defining any actions, Prisma ORM will use the following default values depending if the underlying [scalar fields](/orm/prisma-schema/data-model/models#scalar-fields) are set to be optional or required.
+
+| Clause | All of the scalar fields are optional | At least one scalar field is required |
+| :--------- | :------------------------------------ | :------------------------------------ |
+| `onDelete` | `SetNull` | `NoAction` |
+| `onUpdate` | `Cascade` | `Cascade` |
+
+Since the default referential action for `onUpdate` in the above relation would be `Cascade` and for `onDelete` it would be `SetNull`, it creates a cycle and the solution is to explicitly set the `onUpdate` and `onDelete` values to `NoAction`.
+
+```prisma highlight=3;delete|4;add
+model Employee {
+ id Int @id @default(autoincrement())
+ //delete-next-line
+ manager Employee @relation(name: "management", fields: [managerId], references: [id])
+ //add-next-line
+ manager Employee @relation(name: "management", fields: [managerId], references: [id], onDelete: NoAction, onUpdate: NoAction)
+ managees Employee[] @relation(name: "management")
+ managerId Int
+}
+```
+
+## Cyclic relation between three tables (SQL Server and MongoDB)
+
+The following models describe a cyclic relation between a `Chicken`, an `Egg` and a `Fox`, where each model references the other.
+
+```prisma
+model Chicken {
+ id Int @id @default(autoincrement())
+ egg Egg @relation(fields: [eggId], references: [id])
+ eggId Int
+ predators Fox[]
+}
+
+model Egg {
+ id Int @id @default(autoincrement())
+ predator Fox @relation(fields: [predatorId], references: [id])
+ predatorId Int
+ parents Chicken[]
+}
+
+model Fox {
+ id Int @id @default(autoincrement())
+ meal Chicken @relation(fields: [mealId], references: [id])
+ mealId Int
+ foodStore Egg[]
+}
+```
+
+This will result in three validation errors in every relation field that is part of the cycle.
+
+The first one is in the relation `egg` in the `Chicken` model:
+
+```terminal wrap
+Error parsing attribute "@relation": Reference causes a cycle. One of the @relation attributes in this cycle must have `onDelete` and `onUpdate` referential actions set to `NoAction`. Cycle path: Chicken.egg → Egg.predator → Fox.meal. (Implicit default `onUpdate`: `Cascade`)
+```
+
+The second one is in the relation `predator` in the `Egg` model:
+
+```terminal wrap
+Error parsing attribute "@relation": Reference causes a cycle. One of the @relation attributes in this cycle must have `onDelete` and `onUpdate` referential actions set to `NoAction`. Cycle path: Egg.predator → Fox.meal → Chicken.egg. (Implicit default `onUpdate`: `Cascade`)
+```
+
+And the third one is in the relation `meal` in the `Fox` model:
+
+```terminal wrap
+Error parsing attribute "@relation": Reference causes a cycle. One of the @relation attributes in this cycle must have `onDelete` and `onUpdate` referential actions set to `NoAction`. Cycle path: Fox.meal → Chicken.egg → Egg.predator. (Implicit default `onUpdate`: `Cascade`)
+```
+
+As the relation fields are required, the default referential action for `onDelete` is `NoAction` but for `onUpdate` it is `Cascade`, which causes a referential action cycle. The solution is to set the `onUpdate` value to `NoAction` in any one of the relations.
+
+```prisma highlight=3;delete|4;add
+model Chicken {
+ id Int @id @default(autoincrement())
+ //delete-next-line
+ egg Egg @relation(fields: [eggId], references: [id])
+ //add-next-line
+ egg Egg @relation(fields: [eggId], references: [id], onUpdate: NoAction)
+ eggId Int
+ predators Fox[]
+}
+```
+
+or
+
+```prisma highlight=3;delete|4;add
+model Egg {
+ id Int @id @default(autoincrement())
+ //delete-next-line
+ predator Fox @relation(fields: [predatorId], references: [id])
+ //add-next-line
+ predator Fox @relation(fields: [predatorId], references: [id], onUpdate: NoAction)
+ predatorId Int
+ parents Chicken[]
+}
+```
+
+or
+
+```prisma highlight=3;delete|4;add
+model Fox {
+ id Int @id @default(autoincrement())
+ //delete-next-line
+ meal Chicken @relation(fields: [mealId], references: [id])
+ //add-next-line
+ meal Chicken @relation(fields: [mealId], references: [id], onUpdate: NoAction)
+ mealId Int
+ foodStore Egg[]
+}
+```
+
+## Multiple cascade paths between two models (SQL Server only)
+
+The data model describes two different paths between same models, with both relations triggering cascading referential actions.
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ comments Comment[]
+ posts Post[]
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ authorId Int
+ author User @relation(fields: [authorId], references: [id])
+ comments Comment[]
+}
+
+model Comment {
+ id Int @id @default(autoincrement())
+ writtenById Int
+ postId Int
+ writtenBy User @relation(fields: [writtenById], references: [id])
+ post Post @relation(fields: [postId], references: [id])
+}
+```
+
+The problem in this data model is how there are two paths from `Comment` to the `User`, and how the default `onUpdate` action in both relations is `Cascade`. This leads into two validation errors:
+
+The first one is in the relation `writtenBy`:
+
+```terminal wrap
+Error parsing attribute "@relation": When any of the records in model `User` is updated or deleted, the referential actions on the relations cascade to model `Comment` through multiple paths. Please break one of these paths by setting the `onUpdate` and `onDelete` to `NoAction`. (Implicit default `onUpdate`: `Cascade`)
+```
+
+The second one is in the relation `post`:
+
+```terminal wrap
+Error parsing attribute "@relation": When any of the records in model `User` is updated or deleted, the referential actions on the relations cascade to model `Comment` through multiple paths. Please break one of these paths by setting the `onUpdate` and `onDelete` to `NoAction`. (Implicit default `onUpdate`: `Cascade`)
+```
+
+The error means that by updating a primary key in a record in the `User` model, the update will cascade once between the `Comment` and `User` through the `writtenBy` relation, and again through the `Post` model from the `post` relation due to `Post` being related with the `Comment` model.
+
+The fix is to set the `onUpdate` referential action to `NoAction` in the `writtenBy` or `post` relation fields, or from the `Post` model by changing the actions in the `author` relation:
+
+```prisma highlight=5;delete|6;add
+model Comment {
+ id Int @id @default(autoincrement())
+ writtenById Int
+ postId Int
+ //delete-next-line
+ writtenBy User @relation(fields: [writtenById], references: [id])
+ //add-next-line
+ writtenBy User @relation(fields: [writtenById], references: [id], onUpdate: NoAction)
+ post Post @relation(fields: [postId], references: [id])
+}
+```
+
+or
+
+```prisma highlight=6;delete|7;add
+model Comment {
+ id Int @id @default(autoincrement())
+ writtenById Int
+ postId Int
+ writtenBy User @relation(fields: [writtenById], references: [id])
+ //delete-next-line
+ post Post @relation(fields: [postId], references: [id])
+ //add-next-line
+ post Post @relation(fields: [postId], references: [id], onUpdate: NoAction)
+}
+```
+
+or
+
+```prisma highlight=4;delete|5;add
+model Post {
+ id Int @id @default(autoincrement())
+ authorId Int
+ //delete-next-line
+ author User @relation(fields: [authorId], references: [id])
+ //add-next-line
+ author User @relation(fields: [authorId], references: [id], onUpdate: NoAction)
+ comments Comment[]
+}
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/410-referential-actions/index.mdx b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/410-referential-actions/index.mdx
new file mode 100644
index 0000000000..bbef7dc445
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/410-referential-actions/index.mdx
@@ -0,0 +1,527 @@
+---
+title: 'Referential actions'
+metaTitle: 'Referential actions'
+metaDescription: 'Referential actions let you define the update and delete behavior of related models on the database level'
+tocDepth: 3
+---
+
+
+
+Referential actions determine what happens to a record when your application deletes or updates a related record.
+
+From version 2.26.0, you can define referential actions on the relation fields in your Prisma schema. This allows you to define referential actions like cascading deletes and cascading updates at a Prisma ORM level.
+
+
+
+**Version differences**
+
+- If you use version 3.0.1 or later, you can use referential actions as described on this page.
+- If you use a version between 2.26.0 and 3.0.0, you can use referential actions as described on this page, but you must [enable the preview feature flag](/orm/reference/preview-features/client-preview-features#enabling-a-prisma-client-preview-feature) `referentialActions`.
+- If you use version 2.25.0 or earlier, you can configure cascading deletes manually in your database.
+
+
+
+In the following example, adding `onDelete: Cascade` to the `author` field on the `Post` model means that deleting the `User` record will also delete all related `Post` records.
+
+```prisma file=schema.prisma highlight=4;normal showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ author User @relation(fields: [authorId], references: [id], onDelete: Cascade)
+ authorId Int
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ posts Post[]
+}
+```
+
+If you do not specify a referential action, Prisma ORM [uses a default](#referential-action-defaults).
+
+
+
+
+Questions answered in this page
+
+- What do referential actions do?
+- Which defaults apply if none are set?
+- How do actions map to my database?
+
+
+
+
+
+If you upgrade from a version earlier than 2.26.0:
+It is extremely important that you check the [upgrade paths for referential actions](/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-3/referential-actions) section. Prisma ORM's support of referential actions **removes the safety net in Prisma Client that prevents cascading deletes at runtime**. If you use the feature _without upgrading your database_, the [old default action](/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-3/referential-actions#prisma-orm-2x-default-referential-actions) - `ON DELETE CASCADE` - becomes active. This might result in cascading deletes that you did not expect.
+
+
+
+## What are referential actions?
+
+Referential actions are policies that define how a referenced record is handled by the database when you run an [`update`](/orm/prisma-client/queries/crud#update) or [`delete`](/orm/prisma-client/queries/crud#delete) query.
+
+
+
+Referential actions on the database level
+
+Referential actions are features of foreign key constraints that exist to preserve referential integrity in your database.
+
+When you define relationships between data models in your Prisma schema, you use [relation fields](/orm/prisma-schema/data-model/relations#relation-fields), **which do not exist on the database**, and [scalar fields](/orm/prisma-schema/data-model/models#scalar-fields), **which do exist on the database**. These foreign keys connect the models on the database level.
+
+Referential integrity states that these foreign keys must reference an existing primary key value in the related database table. In your Prisma schema, this is generally represented by the `id` field on the related model.
+
+By default a database will reject any operation that violates the referential integrity, for example, by deleting referenced records.
+
+
+
+### How to use referential actions
+
+Referential actions are defined in the [`@relation`](/orm/reference/prisma-schema-reference#relation) attribute and map to the actions on the **foreign key constraint** in the underlying database. If you do not specify a referential action, [Prisma ORM falls back to a default](#referential-action-defaults).
+
+The following model defines a one-to-many relation between `User` and `Post` and a many-to-many relation between `Post` and `Tag`, with explicitly defined referential actions:
+
+```prisma file=schema.prisma highlight=10,16-17;normal showLineNumbers
+model User {
+ id Int @id @default(autoincrement())
+ posts Post[]
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ tags TagOnPosts[]
+ User User? @relation(fields: [userId], references: [id], onDelete: SetNull, onUpdate: Cascade)
+ userId Int?
+}
+
+model TagOnPosts {
+ id Int @id @default(autoincrement())
+ post Post? @relation(fields: [postId], references: [id], onUpdate: Cascade, onDelete: Cascade)
+ tag Tag? @relation(fields: [tagId], references: [id], onUpdate: Cascade, onDelete: Cascade)
+ postId Int?
+ tagId Int?
+}
+
+model Tag {
+ id Int @id @default(autoincrement())
+ name String @unique
+ posts TagOnPosts[]
+}
+```
+
+This model explicitly defines the following referential actions:
+
+- If you delete a `Tag`, the corresponding tag assignment is also deleted in `TagOnPosts`, using the `Cascade` referential action
+- If you delete a `User`, the author is removed from all posts by setting the field value to `Null`, because of the `SetNull` referential action. To allow this, `User` and `userId` must be optional fields in `Post`.
+
+Prisma ORM supports the following referential actions:
+
+- [`Cascade`](#cascade)
+- [`Restrict`](#restrict)
+- [`NoAction`](#noaction)
+- [`SetNull`](#setnull)
+- [`SetDefault`](#setdefault)
+
+### Referential action defaults
+
+If you do not specify a referential action, Prisma ORM uses the following defaults:
+
+| Clause | Optional relations | Mandatory relations |
+| :--------- | :----------------- | :------------------ |
+| `onDelete` | `SetNull` | `Restrict` |
+| `onUpdate` | `Cascade` | `Cascade` |
+
+For example, in the following schema all `Post` records must be connected to a `User` via the `author` relation:
+
+```prisma highlight=4;normal
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ //highlight-next-line
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ posts Post[]
+}
+```
+
+The schema does not explicitly define referential actions on the mandatory `author` relation field, which means that the default referential actions of `Restrict` for `onDelete` and `Cascade` for `onUpdate` apply.
+
+## Caveats
+
+The following caveats apply:
+
+- Referential actions are **not** supported on [implicit many-to-many relations](/orm/prisma-schema/data-model/relations/many-to-many-relations#implicit-many-to-many-relations). To use referential actions, you must define an explicit many-to-many relation and define your referential actions on the [join table](/orm/prisma-schema/data-model/relations/troubleshooting-relations#how-to-use-a-relation-table-with-a-many-to-many-relationship).
+- Certain combinations of referential actions and required/optional relations are incompatible. For example, using `SetNull` on a required relation will lead to database errors when deleting referenced records because the non-nullable constraint would be violated. See [this GitHub issue](https://github.com/prisma/prisma/issues/7909) for more information.
+
+## Types of referential actions
+
+The following table shows which referential action each database supports.
+
+| Database | Cascade | Restrict | NoAction | SetNull | SetDefault |
+| :------------ | :------ | :------- | :------- | :------ | :--------- |
+| PostgreSQL | ✔️ | ✔️ | ✔️ | ✔️⌘ | ✔️ |
+| MySQL/MariaDB | ✔️ | ✔️ | ✔️ | ✔️ | ❌ (✔️†) |
+| SQLite | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
+| SQL Server | ✔️ | ❌‡ | ✔️ | ✔️ | ✔️ |
+| CockroachDB | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
+| MongoDB†† | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
+
+- † See [special cases for MySQL](#mysqlmariadb).
+- ⌘ See [special cases for PostgreSQL](#postgresql).
+- ‡ See [special cases for SQL Server](#sql-server).
+- †† Referential actions for MongoDB are available in Prisma ORM versions 3.7.0 and later.
+
+### Special cases for referential actions
+
+Referential actions are part of the ANSI SQL standard. However, there are special cases where some relational databases diverge from the standard.
+
+#### MySQL/MariaDB
+
+MySQL/MariaDB, and the underlying InnoDB storage engine, does not support `SetDefault`. The exact behavior depends on the database version:
+
+- In MySQL versions 8 and later, and MariaDB versions 10.5 and later, `SetDefault` effectively acts as an alias for `NoAction`. You can define tables using the `SET DEFAULT` referential action, but a foreign key constraint error is triggered at runtime.
+- In MySQL versions 5.6 and later, and MariaDB versions before 10.5, attempting to create a table definition with the `SET DEFAULT` referential action fails with a syntax error.
+
+For this reason, when you set `mysql` as the database provider, Prisma ORM warns users to replace `SetDefault` referential actions in the Prisma schema with another action.
+
+#### PostgreSQL
+
+PostgreSQL is the only database supported by Prisma ORM that allows you to define a `SetNull` referential action that refers to a non-nullable field. However, this raises a foreign key constraint error when the action is triggered at runtime.
+
+For this reason, when you set `postgres` as the database provider in the (default) `foreignKeys` relation mode, Prisma ORM warns users to mark as optional any fields that are included in a `@relation` attribute with a `SetNull` referential action. For all other database providers, Prisma ORM rejects the schema with a validation error.
+
+#### SQL Server
+
+[`Restrict`](#restrict) is not available for SQL Server databases, but you can use [`NoAction`](#noaction) instead.
+
+### `Cascade`
+
+- `onDelete: Cascade` Deleting a referenced record will trigger the deletion of referencing record.
+- `onUpdate: Cascade` Updates the relation scalar fields if the referenced scalar fields of the dependent record are updated.
+
+#### Example usage
+
+```prisma file=schema.prisma highlight=4;add showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ //add-next-line
+ author User @relation(fields: [authorId], references: [id], onDelete: Cascade, onUpdate: Cascade)
+ authorId Int
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ posts Post[]
+}
+```
+
+##### Result of using `Cascade`
+
+If a `User` record is deleted, then their posts are deleted too. If the user's `id` is updated, then the corresponding `authorId` is also updated.
+
+##### How to use cascading deletes
+
+
+
+
+
+### `Restrict`
+
+- `onDelete: Restrict` Prevents the deletion if any referencing records exist.
+- `onUpdate: Restrict` Prevents the identifier of a referenced record from being changed.
+
+#### Example usage
+
+```prisma file=schema.prisma highlight=4;add showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ //add-next-line
+ author User @relation(fields: [authorId], references: [id], onDelete: Restrict, onUpdate: Restrict)
+ authorId Int
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ posts Post[]
+}
+```
+
+##### Result of using `Restrict`
+
+`User`s with posts **cannot** be deleted. The `User`'s `id` **cannot** be changed.
+
+
+
+The `Restrict` action is **not** available on [Microsoft SQL Server](/orm/overview/databases/sql-server) and triggers a schema validation error. Instead, you can use [`NoAction`](#noaction), which produces the same result and is compatible with SQL Server.
+
+
+
+### `NoAction`
+
+The `NoAction` action is similar to `Restrict`, the difference between the two is dependent on the database being used:
+
+- **PostgreSQL**: `NoAction` allows the check (if a referenced row on the table exists) to be deferred until later in the transaction. See [the PostgreSQL docs](https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-FK) for more information.
+- **MySQL**: `NoAction` behaves exactly the same as `Restrict`. See [the MySQL docs](https://dev.mysql.com/doc/refman/8.0/en/create-table-foreign-keys.html#foreign-key-referential-actions) for more information.
+- **SQLite**: When a related primary key is modified or deleted, no action is taken. See [the SQLite docs](https://www.sqlite.org/foreignkeys.html#fk_actions) for more information.
+- **SQL Server**: When a referenced record is deleted or modified, an error is raised. See [the SQL Server docs](https://learn.microsoft.com/en-us/sql/relational-databases/tables/graph-edge-constraints?view=sql-server-ver15#on-delete-referential-actions-on-edge-constraints) for more information.
+- **MongoDB** (in preview from version 3.6.0): When a record is modified or deleted, nothing is done to any related records.
+
+
+
+If you are [managing relations in Prisma Client](/orm/prisma-schema/data-model/relations/relation-mode#emulate-relations-in-prisma-orm-with-the-prisma-relation-mode) rather than using foreign keys in the database, you should be aware that currently Prisma ORM only implements the referential actions. Foreign keys also create constraints, which make it impossible to manipulate data in a way that would violate these constraints: instead of executing the query, the database responds with an error. These constraints will not be created if you emulate referential integrity in Prisma Client, so if you set the referential action to `NoAction` there will be no checks to prevent you from breaking the referential integrity.
+
+
+
+#### Example usage
+
+```prisma file=schema.prisma highlight=4;add showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ //add-next-line
+ author User @relation(fields: [authorId], references: [id], onDelete: NoAction, onUpdate: NoAction)
+ authorId Int
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ posts Post[]
+}
+```
+
+##### Result of using `NoAction`
+
+`User`'s with posts **cannot** be deleted. The `User`'s `id` **cannot** be changed.
+
+### `SetNull`
+
+- `onDelete: SetNull` The scalar field of the referencing object will be set to `NULL`.
+
+- `onUpdate: SetNull` When updating the identifier of a referenced object, the scalar fields of the referencing objects will be set to `NULL`.
+
+`SetNull` will only work on optional relations. On required relations, a runtime error will be thrown since the scalar fields cannot be null.
+
+```prisma file=schema.prisma highlight=4;add showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ //add-next-line
+ author User? @relation(fields: [authorId], references: [id], onDelete: SetNull, onUpdate: SetNull)
+ authorId Int?
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ posts Post[]
+}
+```
+
+##### Result of using `SetNull`
+
+When deleting a `User`, the `authorId` will be set to `NULL` for all its authored posts.
+
+When changing a `User`'s `id`, the `authorId` will be set to `NULL` for all its authored posts.
+
+### `SetDefault`
+
+- `onDelete: SetDefault` The scalar field of the referencing object will be set to the fields default value.
+
+- `onUpdate: SetDefault` The scalar field of the referencing object will be set to the fields default value.
+
+These require setting a default for the relation scalar field with [`@default`](/orm/reference/prisma-schema-reference#default). If no defaults are provided for any of the scalar fields, a runtime error will be thrown.
+
+```prisma file=schema.prisma highlight=4,5;add showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ //add-start
+ authorUsername String? @default("anonymous")
+ author User? @relation(fields: [authorUsername], references: [username], onDelete: SetDefault, onUpdate: SetDefault)
+ //add-end
+}
+
+model User {
+ username String @id
+ posts Post[]
+}
+```
+
+##### Result of using `SetDefault`
+
+When deleting a `User`, its existing posts' `authorUsername` field values will be set to 'anonymous'.
+
+When the `username` of a `User` changes, its existing posts' `authorUsername` field values will be set to 'anonymous'.
+
+### Database-specific requirements
+
+MongoDB and SQL Server have specific requirements for referential actions if you have [self-relations](/orm/prisma-schema/data-model/relations/referential-actions/special-rules-for-referential-actions#self-relation-sql-server-and-mongodb) or [cyclic relations](/orm/prisma-schema/data-model/relations/referential-actions/special-rules-for-referential-actions#cyclic-relation-between-three-tables-sql-server-and-mongodb) in your data model. SQL Server also has specific requirements if you have relations with [multiple cascade paths](/orm/prisma-schema/data-model/relations/referential-actions/special-rules-for-referential-actions#multiple-cascade-paths-between-two-models-sql-server-only).
+
+## Upgrade paths from versions 2.25.0 and earlier
+
+There are a couple of paths you can take when upgrading which will give different results depending on the desired outcome.
+
+If you currently use the migration workflow, you can run an introspection to check how the defaults are reflected in your schema. You can then manually update your database if you need to.
+
+You can also decide to skip checking the defaults and run a migration to update your database with the [new default values](#referential-action-defaults).
+
+The following assumes you have upgraded to 2.26.0 or newer and enabled the preview feature flag, or upgraded to 3.0.0 or newer:
+
+### Using Introspection
+
+If you [Introspect](/orm/prisma-schema/introspection) your database, the referential actions configured at the database level will be reflected in your Prisma Schema. If you have been using Prisma Migrate or `prisma db push` to manage the database schema, these are likely to be the [default values](#referential-action-defaults) from 2.25.0 and earlier.
+
+When you run an Introspection, Prisma ORM compares all the foreign keys in the database with the schema, if the SQL statements `ON DELETE` and `ON UPDATE` do **not** match the default values, they will be explicitly set in the schema file.
+
+After introspecting, you can review the non-default clauses in your schema. The most important clause to review is `onDelete`, which defaults to `Cascade` in 2.25.0 and earlier.
+
+
+
+If you are using either the [`delete()`](/orm/prisma-client/queries/crud#delete-a-single-record) or [`deleteMany()`](/orm/prisma-client/queries/crud#delete-all-records) methods, **[cascading deletes](#how-to-use-cascading-deletes) will now be performed** as the `referentialActions` preview feature **removed the safety net in Prisma Client that previously prevented cascading deletes at runtime**. Be sure to check your code and make any adjustments accordingly.
+
+
+
+Make sure you are happy with every case of `onDelete: Cascade` in your schema. If not, either:
+
+- Modify your Prisma schema and `db push` or `dev migrate` to change the database
+
+_or_
+
+- Manually update the underlying database if you use an introspection-only workflow
+
+The following example would result in a cascading delete, if the `User` is deleted then all of their `Post`'s will be deleted too.
+
+#### A blog schema example
+
+```prisma showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ //add-next-line
+ author User @relation(fields: [authorId], references: [id], onDelete: Cascade)
+ authorId Int
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ posts Post[]
+}
+```
+
+### Using Migration
+
+When running a [Migration](/orm/prisma-migrate) (or the [`prisma db push`](/orm/prisma-migrate/workflows/prototyping-your-schema) command) the [new defaults](#referential-action-defaults) will be applied to your database.
+
+
+
+Unlike when you run an Introspect for the first time, the new referential actions clause and property, will **not** automatically be added to your prisma schema by the Prisma VSCode extension.
+You will have to manually add them if you wish to use anything other than the new defaults.
+
+
+
+Explicitly defining referential actions in your Prisma schema is optional. If you do not explicitly define a referential action for a relation, Prisma ORM uses the [new defaults](#referential-action-defaults).
+
+Note that referential actions can be added on a case by case basis. This means that you can add them to one single relation and leave the rest set to the defaults by not manually specifying anything.
+
+### Checking for errors
+
+**Before** upgrading to 2.26.0 and enabling the referential actions **preview feature**, Prisma ORM prevented the deletion of records while using `delete()` or `deleteMany()` to preserve referential integrity. A custom runtime error would be thrown by Prisma Client with the error code `P2014`.
+
+**After** upgrading and enabling the referential actions **preview feature**, Prisma ORM no longer performs runtime checks. You can instead specify a custom referential action to preserve the referential integrity between relations.
+
+When you use [`NoAction`](#noaction) or [`Restrict`](#restrict) to prevent the deletion of records, the error messages will be different post 2.26.0 compared to pre 2.26.0. This is because they are now triggered by the database and **not** Prisma Client. The new error code that can be expected is `P2003`.
+
+To make sure you catch these new errors you can adjust your code accordingly.
+
+#### Example of catching errors
+
+The following example uses the below blog schema with a one-to-many relationship between `Post` and `User` and sets a [`Restrict`](#restrict) referential actions on the `author` field.
+
+This means that if a user has a post, that user (and their posts) **cannot** be deleted.
+
+```prisma file=schema.prisma showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ author User @relation(fields: [authorId], references: [id], onDelete: Restrict)
+ authorId String
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ posts Post[]
+}
+```
+
+Prior to upgrading and enabling the referential actions **preview feature**, the error code you would receive when trying to delete a user which has posts would be `P2014` and it's message:
+
+> "The change you are trying to make would violate the required relation '\{relation_name}' between the \{model_a_name\} and \{model_b_name\} models."
+
+```ts
+import { PrismaClient } from '@prisma/client'
+
+const prisma = new PrismaClient()
+
+async function main() {
+ try {
+ await prisma.user.delete({
+ where: {
+ id: 'some-long-id',
+ },
+ })
+ } catch (error) {
+ if (error instanceof Prisma.PrismaClientKnownRequestError) {
+ if (error.code === 'P2014') {
+ console.log(error.message)
+ }
+ }
+ }
+}
+
+main()
+```
+
+To make sure you are checking for the correct errors in your code, modify your check to look for `P2003`, which will deliver the message:
+
+> "Foreign key constraint failed on the field: \{field_name\}"
+
+```ts highlight=14;delete|15;add
+import { PrismaClient } from '@prisma/client'
+
+const prisma = new PrismaClient()
+
+async function main() {
+ try {
+ await prisma.user.delete({
+ where: {
+ id: 'some-long-id'
+ }
+ })
+ } catch (error) {
+ if (error instanceof Prisma.PrismaClientKnownRequestError) {
+ //delete-next-line
+ if (error.code === 'P2014') {
+ //add-next-line
+ if (error.code === 'P2003') {
+ console.log(error.message)
+ }
+ }
+ }
+}
+
+main()
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/420-relation-mode.mdx b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/420-relation-mode.mdx
new file mode 100644
index 0000000000..99aa146c36
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/420-relation-mode.mdx
@@ -0,0 +1,269 @@
+---
+title: 'Relation mode'
+metaTitle: 'Manage relations between records with relation modes in Prisma'
+metaDescription: 'Manage relations between records with relation modes in Prisma'
+tocDepth: 3
+---
+
+
+Questions answered in this page
+
+- What is `relationMode` in Prisma?
+- When should I use `prisma` vs `foreignKeys`?
+- How does relation emulation affect constraints?
+
+
+
+In Prisma schema, relations between records are defined with the [`@relation`](/orm/reference/prisma-schema-reference#relation) attribute. For example, in the following schema there is a one-to-many relation between the `User` and `Post` models:
+
+```prisma file=schema.prisma highlight=4,5,10;normal showLineNumbers
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ //highlight-start
+ author User @relation(fields: [authorId], references: [id], onDelete: Cascade, onUpdate: Cascade)
+ authorId Int
+ //highlight-end
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ //highlight-next-line
+ posts Post[]
+}
+```
+
+Prisma ORM has two _relation modes_, `foreignKeys` and `prisma`, that specify how relations between records are enforced.
+
+If you use Prisma ORM with a relational database, then by default Prisma ORM uses the [`foreignKeys` relation mode](#handle-relations-in-your-relational-database-with-the-foreignkeys-relation-mode), which enforces relations between records at the database level with foreign keys. A foreign key is a column or group of columns in one table that take values based on the primary key in another table. Foreign keys allow you to:
+
+- set constraints that prevent you from making changes that break references
+- set [referential actions](/orm/prisma-schema/data-model/relations/referential-actions) that define how changes to records are handled
+
+Together these constraints and referential actions guarantee the _referential integrity_ of the data.
+
+For the example schema above, Prisma Migrate will generate the following SQL by default if you use the PostgreSQL connector:
+
+```sql highlight=19-22;normal
+
+-- CreateTable
+CREATE TABLE "Post" (
+ "id" SERIAL NOT NULL,
+ "title" TEXT NOT NULL,
+ "authorId" INTEGER NOT NULL,
+
+ CONSTRAINT "Post_pkey" PRIMARY KEY ("id")
+);
+
+-- CreateTable
+CREATE TABLE "User" (
+ "id" SERIAL NOT NULL,
+
+ CONSTRAINT "User_pkey" PRIMARY KEY ("id")
+);
+
+-- AddForeignKey
+//highlight-start
+ALTER TABLE "Post"
+ ADD CONSTRAINT "Post_authorId_fkey"
+ FOREIGN KEY ("authorId")
+ REFERENCES "User"("id") ON DELETE CASCADE ON UPDATE CASCADE;
+//highlight-end
+```
+
+In this case, the foreign key constraint on the `authorId` column of the `Post` table references the `id` column of the `User` table, and guarantees that a post must have an author that exists. If you update or delete a user then the `ON DELETE` and `ON UPDATE` referential actions specify the `CASCADE` option, which will also delete or update all posts belonging to the user.
+
+Some databases, such as MongoDB or [PlanetScale](/orm/overview/databases/planetscale#differences-to-consider), do not support foreign keys. Additionally, in some cases developers may prefer not to use foreign keys in their relational database that usually does support foreign keys. For these situations, Prisma ORM offers [the `prisma` relation mode](#emulate-relations-in-prisma-orm-with-the-prisma-relation-mode), which emulates some properties of relations in relational databases. When you use Prisma Client with the `prisma` relation mode enabled, the behavior of queries is identical or similar, but referential actions and some constraints are handled by the Prisma engine rather than in the database.
+
+
+ There are performance implications to emulation of referential integrity and
+ referential actions in Prisma Client. In cases where the underlying database
+ supports foreign keys, it is usually the preferred choice.
+
+
+## How to set the relation mode in your Prisma schema
+
+To set the relation mode, add the `relationMode` field in the `datasource` block:
+
+```prisma file=schema.prisma highlight=4,9;add showLineNumbers
+datasource db {
+ provider = "mysql"
+ url = env("DATABASE_URL")
+ //add-next-line
+ relationMode = "prisma"
+}
+```
+
+
+
+The ability to set the relation mode was introduced as part of the `referentialIntegrity` preview feature in Prisma ORM version 3.1.1, and is generally available in Prisma ORM versions 4.8.0 and later.
The `relationMode` field was renamed in Prisma ORM version 4.5.0, and was previously named `referentialIntegrity`.
+
+
+
+For relational databases, the available options are:
+
+- `foreignKeys`: this handles relations in the database with foreign keys. This is the default option for all relational database connectors and is active if no `relationMode` is explicitly set in the `datasource` block.
+- `prisma`: this emulates relations in Prisma Client. You should also [enable this option](/orm/overview/databases/planetscale#option-1-emulate-relations-in-prisma-client) when you use the MySQL connector with a PlanetScale database and don't have native foreign key constraints enabled in your PlanetScale database settings.
+
+For MongoDB, the only available option is the `prisma` relation mode. This mode is also active if no `relationMode` is explicitly set in the `datasource` block.
+
+
+
+If you switch between relation modes, Prisma ORM will add or remove foreign keys to your database next time you apply changes to your schema with Prisma Migrate or `db push`. See [Switch between relation modes](#switch-between-relation-modes) for more information.
+
+
+
+## Handle relations in your relational database with the `foreignKeys` relation mode
+
+The `foreignKeys` relation mode handles relations in your relational database with foreign keys. This is the default option when you use a relational database connector (PostgreSQL, MySQL, SQLite, SQL Server, CockroachDB).
+
+The `foreignKeys` relation mode is not available when you use the MongoDB connector. Some relational databases, [such as PlanetScale](/orm/overview/databases/planetscale#option-1-emulate-relations-in-prisma-client), also forbid the use of foreign keys. In these cases, you should instead [emulate relations in Prisma ORM with the `prisma` relation mode](#emulate-relations-in-prisma-orm-with-the-prisma-relation-mode).
+
+### Referential integrity
+
+The `foreignKeys` relation mode maintains referential integrity at the database level with foreign key constraints and referential actions.
+
+#### Foreign key constraints
+
+When you _create_ or _update_ a record with a relation to another record, the related record needs to exist. Foreign key constraints enforce this behavior in the database. If the record does not exist, the database will return an error message.
+
+#### Referential actions
+
+When you _update_ or _delete_ a record with a relation to another record, referential actions are triggered in the database. To maintain referential integrity in related records, referential actions prevent changes that would break referential integrity, cascade changes through to related records, or set the value of fields that reference the updated or deleted records to a `null` or default value.
+
+For more information, see the [referential actions](/orm/prisma-schema/data-model/relations/referential-actions) page.
+
+### Introspection
+
+When you introspect a relational database with the `db pull` command with the `foreignKeys` relation mode enabled, a `@relation` attribute will be added to your Prisma schema for relations where foreign keys exist.
+
+### Prisma Migrate and `db push`
+
+When you apply changes to your Prisma schema with Prisma Migrate or `db push` with the `foreignKeys` relation mode enabled, foreign keys will be created in your database for all `@relation` attributes in your schema.
+
+## Emulate relations in Prisma ORM with the `prisma` relation mode
+
+The `prisma` relation mode emulates some foreign key constraints and referential actions for each Prisma Client query to maintain referential integrity, using some additional database queries and logic.
+
+The `prisma` relation mode is the default option for the MongoDB connector. It should also be set if you use a relational database that does not support foreign keys. For example, [if you use PlanetScale](/orm/overview/databases/planetscale#option-1-emulate-relations-in-prisma-client) without foreign key constraints, you should use the `prisma` relation mode.
+
+
+ There are performance implications to emulation of referential integrity in
+ Prisma Client, because it uses additional database queries to maintain
+ referential integrity. In cases where the underlying database can handle
+ referential integrity with foreign keys, it is usually the preferred choice.
+
+
+Emulation of relations is only available for Prisma Client queries and does not apply to raw queries.
+
+### Which foreign key constraints are emulated?
+
+When you _update_ a record, Prisma ORM will emulate foreign key constraints. This means that when you update a record with a relation to another record, the related record needs to exist. If the record does not exist, Prisma Client will return an error message.
+
+However, when you _create_ a record, Prisma ORM does not emulate any foreign key constraints. You will be able to create invalid data.
+
+### Which referential actions are emulated?
+
+When you _update_ or _delete_ a record with related records, Prisma ORM will emulate referential actions.
+
+The following table shows which emulated referential actions are available for each database connector:
+
+| Database | Cascade | Restrict | NoAction | SetNull | SetDefault |
+| :---------- | :------ | :------- | :------- | :------ | :--------- |
+| PostgreSQL | **✔️** | **✔️** | **❌**‡ | **✔️** | **❌**† |
+| MySQL | **✔️** | **✔️** | **✔️** | **✔️** | **❌**† |
+| SQLite | **✔️** | **✔️** | **❌**‡ | **✔️** | **❌**† |
+| SQL Server | **✔️** | **✔️** | **✔️** | **✔️** | **❌**† |
+| CockroachDB | **✔️** | **✔️** | **✔️** | **✔️** | **❌**† |
+| MongoDB | **✔️** | **✔️** | **✔️** | **✔️** | **❌**† |
+
+- † The `SetDefault` referential action is not supported in the `prisma` relation mode.
+- ‡ The `NoAction` referential action is not supported in the `prisma` relation mode for PostgreSQL and SQLite. Instead, use the `Restrict` action.
+
+### Error messages
+
+Error messages returned by emulated constraints and referential actions in the `prisma` relation mode are generated by Prisma Client and differ slightly from the error messages in the `foreignKeys` relation mode:
+
+```jsx
+Example:
+// foreignKeys:
+... Foreign key constraint failed on the field: `ProfileOneToOne_userId_fkey (index)`
+// prisma:
+... The change you are trying to make would violate the required relation 'ProfileOneToOneToUserOneToOne' between the `ProfileOneToOne` and `UserOneToOne` models.
+```
+
+### Introspection
+
+When you introspect a database with the `db pull` command with the `prisma` relation mode enabled, relations will not be automatically added to your schema. You will instead need to add any relations manually with the `@relation` attribute. This only needs to be done once – next time you introspect your database, Prisma ORM will keep your added `@relation` attributes.
+
+### Prisma Migrate and `db push`
+
+When you apply changes to your Prisma schema with Prisma Migrate or `db push` with the `prisma` relation mode enabled, Prisma ORM will not use foreign keys in your database.
+
+### Indexes
+
+In relational databases that use foreign key constraints, the database usually also implicitly creates an index for the foreign key columns. For example, [MySQL will create an index on all foreign key columns](https://dev.mysql.com/doc/refman/8.0/en/constraint-foreign-key.html#:~:text=MySQL%20requires%20that%20foreign%20key%20columns%20be%20indexed%3B%20if%20you%20create%20a%20table%20with%20a%20foreign%20key%20constraint%20but%20no%20index%20on%20a%20given%20column%2C%20an%20index%20is%20created.). This is to allow foreign key checks to run fast and not require a table scan.
+
+The `prisma` relation mode does not use foreign keys, so no indexes are created when you use Prisma Migrate or `db push` to apply changes to your database. You instead need to manually add an index on your relation scalar fields with the [`@@index`](/orm/reference/prisma-schema-reference#index) attribute (or the [`@unique`](/orm/reference/prisma-schema-reference#unique), [`@@unique`](/orm/reference/prisma-schema-reference#unique-1) or [`@@id`](/orm/reference/prisma-schema-reference#id-1) attributes, if applicable).
+
+#### Index validation
+
+If you do not add the index manually, queries might require full table scans. This can be slow, and also expensive on database providers that bill per accessed row. To help avoid this, Prisma ORM warns you when your schema contains fields that are used in a `@relation` that does not have an index defined. For example, take the following schema with a relation between the `User` and `Post` models:
+
+```prisma file=schema.prisma showLineNumbers
+datasource db {
+ provider = "mysql"
+ url = env("DATABASE_URL")
+ relationMode = "prisma"
+}
+
+model User {
+ id Int @id
+ posts Post[]
+}
+
+model Post {
+ id Int @id
+ userId Int
+ user User @relation(fields: [userId], references: [id])
+}
+```
+
+Prisma ORM displays the following warning when you run `prisma format` or `prisma validate`:
+
+```terminal wrap
+With `relationMode = "prisma"`, no foreign keys are used, so relation fields will not benefit from the index usually created by the relational database under the hood. This can lead to poor performance when querying these fields. We recommend adding an index manually.
+```
+
+To fix this, add an index to your `Post` model:
+
+```prisma file=schema.prisma highlight=6;add showLineNumbers
+model Post {
+ id Int @id
+ userId Int
+ user User @relation(fields: [userId], references: [id])
+
+ //add-next-line
+ @@index([userId])
+}
+```
+
+If you use the [Prisma VS Code extension](https://marketplace.visualstudio.com/items?itemName=Prisma.prisma) (or our [language server in another editor](/orm/more/development-environment/editor-setup)), the warning is augmented with a Quick Fix that adds the required index for you:
+
+
+
+## Switch between relation modes
+
+It is only possible to switch between relation modes when you use a relational database connector (PostgreSQL, MySQL, SQLite, SQL Server, CockroachDB).
+
+### Switch from `foreignKeys` to `prisma`
+
+The default relation mode if you use a relational database and do not include the `relationMode` field in your `datasource` block is `foreignKeys`. To switch to the `prisma` relation mode, add the `relationMode` field with a value of `prisma`, or update the `relationMode` field value to `prisma` if it already exists.
+
+When you switch the relation mode from `foreignKeys` to `prisma`, after you first apply changes to your schema with Prisma Migrate or `db push` Prisma ORM will remove all previously created foreign keys in the next migration.
+
+If you keep the same database, you can then continue to work as normal. If you switch to a database that does not support foreign keys at all, your existing migration history contains SQL DDL that creates foreign keys, which might trigger errors if you ever have to rerun these migrations. In this case, we recommend that you delete the `migrations` directory. (If you use PlanetScale, which does not support foreign keys, we generally recommend that you [use `db push` rather than Prisma Migrate](/orm/overview/databases/planetscale#differences-to-consider).)
+
+### Switch from `prisma` to `foreignKeys`
+
+To switch from the `prisma` relation mode to the `foreignKeys` relation mode, update the `relationMode` field value from `prisma` to `foreignKeys`. To do this, the database must support foreign keys. When you apply changes to your schema with Prisma Migrate or `db push` for the first time after you switch relation modes, Prisma ORM will create foreign keys for all relations in the next migration.
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/500-troubleshooting-relations.mdx b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/500-troubleshooting-relations.mdx
new file mode 100644
index 0000000000..ad6ed08cbe
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/500-troubleshooting-relations.mdx
@@ -0,0 +1,283 @@
+---
+title: Troubleshooting relations
+metaDescriptions: Common problems and solutions when defining relations in the Prisma schema.
+---
+
+
+
+Modelling your schema can sometimes offer up some unexpected results. This section aims to cover the most prominent of those.
+
+
+
+## Implicit many-to-many self-relations return incorrect data if order of relation fields change
+
+### Problem
+
+In the following implicit many-to-many self-relation, the lexicographic order of relation fields in `a_eats` (1) and `b_eatenBy` (2):
+
+```prisma highlight=4,5;normal
+model Animal {
+ id Int @id @default(autoincrement())
+ name String
+ //highlight-start
+ a_eats Animal[] @relation(name: "FoodChain")
+ b_eatenBy Animal[] @relation(name: "FoodChain")
+ //highlight-end
+}
+```
+
+The resulting relation table in SQL looks as follows, where `A` represents prey (`a_eats`) and `B` represents predators (`b_eatenBy`):
+
+| A | B |
+| :----------- | :--------- |
+| 8 (Plankton) | 7 (Salmon) |
+| 7 (Salmon) | 9 (Bear) |
+
+The following query returns a salmon's prey and predators:
+
+
+
+
+```ts
+const getAnimals = await prisma.animal.findMany({
+ where: {
+ name: 'Salmon',
+ },
+ include: {
+ b_eats: true,
+ a_eatenBy: true,
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ "id": 7,
+ "name": "Salmon",
+ "b_eats": [
+ {
+ "id": 8,
+ "name": "Plankton"
+ }
+ ],
+ "a_eatenBy": [
+ {
+ "id": 9,
+ "name": "Bear"
+ }
+ ]
+}
+```
+
+
+
+
+Now change the order of the relation fields:
+
+```prisma highlight=4,5;normal
+model Animal {
+ id Int @id @default(autoincrement())
+ name String
+ //highlight-start
+ b_eats Animal[] @relation(name: "FoodChain")
+ a_eatenBy Animal[] @relation(name: "FoodChain")
+ //highlight-end
+}
+```
+
+Migrate your changes and re-generate Prisma Client. When you run the same query with the updated field names, Prisma Client returns incorrect data (salmon now eats bears and gets eaten by plankton):
+
+
+
+
+```ts
+const getAnimals = await prisma.animal.findMany({
+ where: {
+ name: 'Salmon',
+ },
+ include: {
+ b_eats: true,
+ a_eatenBy: true,
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ "id": 1,
+ "name": "Salmon",
+ "b_eats": [
+ {
+ "id": 3,
+ "name": "Bear"
+ }
+ ],
+ "a_eatenBy": [
+ {
+ "id": 2,
+ "name": "Plankton"
+ }
+ ]
+}
+```
+
+
+
+
+Although the lexicographic order of the relation fields in the Prisma schema changed, columns `A` and `B` in the database **did not change** (they were not renamed and data was not moved). Therefore, `A` now represents predators (`a_eatenBy`) and `B` represents prey (`b_eats`):
+
+| A | B |
+| :----------- | :--------- |
+| 8 (Plankton) | 7 (Salmon) |
+| 7 (Salmon) | 9 (Bear) |
+
+### Solution
+
+If you rename relation fields in an implicit many-to-many self-relations, make sure that you maintain the alphabetic order of the fields - for example, by prefixing with `a_` and `b_`.
+
+## How to use a relation table with a many-to-many relationship
+
+There are a couple of ways to define an m-n relationship, implicitly or explicitly. Implicitly means letting Prisma ORM handle the relation table (JOIN table) under the hood, all you have to do is define an array/list for the non scalar types on each model, see [implicit many-to-many relations](/orm/prisma-schema/data-model/relations/many-to-many-relations#implicit-many-to-many-relations).
+
+Where you might run into trouble is when creating an [explicit m-n relationship](/orm/prisma-schema/data-model/relations/many-to-many-relations#explicit-many-to-many-relations), that is, to create and handle the relation table yourself. **It can be overlooked that Prisma ORM requires both sides of the relation to be present**.
+
+Take the following example, here a relation table is created to act as the JOIN between the `Post` and `Category` tables. This will not work however as the relation table (`PostCategories`) must form a 1-to-many relationship with the other two models respectively.
+
+The back relation fields are missing from the `Post` to `PostCategories` and `Category` to `PostCategories` models.
+
+
+```prisma
+// This example schema shows how NOT to define an explicit m-n relation
+
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ categories Category[] // This should refer to PostCategories
+}
+
+model PostCategories {
+ post Post @relation(fields: [postId], references: [id])
+ postId Int
+ category Category @relation(fields: [categoryId], references: [id])
+ categoryId Int
+ @@id([postId, categoryId])
+}
+
+model Category {
+ id Int @id @default(autoincrement())
+ name String
+ posts Post[] // This should refer to PostCategories
+}
+```
+
+
+To fix this the `Post` model needs to have a many relation field defined with the relation table `PostCategories`. The same applies to the `Category` model.
+
+This is because the relation model forms a 1-to-many relationship with the other two models its joining.
+
+```prisma highlight=5,21;add|4,20;delete
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ //delete-next-line
+ categories Category[]
+ //add-next-line
+ postCategories PostCategories[]
+}
+
+model PostCategories {
+ post Post @relation(fields: [postId], references: [id])
+ postId Int
+ category Category @relation(fields: [categoryId], references: [id])
+ categoryId Int
+
+ @@id([postId, categoryId])
+}
+
+model Category {
+ id Int @id @default(autoincrement())
+ name String
+ //delete-next-line
+ posts Post[]
+ //add-next-line
+ postCategories PostCategories[]
+}
+```
+
+## Using the `@relation` attribute with a many-to-many relationship
+
+It might seem logical to add a `@relation("Post")` annotation to a relation field on your model when composing an implicit many-to-many relationship.
+
+```prisma
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ categories Category[] @relation("Category")
+ Category Category? @relation("Post", fields: [categoryId], references: [id])
+ categoryId Int?
+}
+
+model Category {
+ id Int @id @default(autoincrement())
+ name String
+ posts Post[] @relation("Post")
+ Post Post? @relation("Category", fields: [postId], references: [id])
+ postId Int?
+}
+```
+
+This however tells Prisma ORM to expect **two** separate one-to-many relationships. See [disambiguating relations](/orm/prisma-schema/data-model/relations#disambiguating-relations) for more information on using the `@relation` attribute.
+
+The following example is the correct way to define an implicit many-to-many relationship.
+
+```prisma highlight=4,11;delete|5,12;add
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ //delete-next-line
+ categories Category[] @relation("Category")
+ //add-next-line
+ categories Category[]
+}
+
+model Category {
+ id Int @id @default(autoincrement())
+ name String
+ //delete-next-line
+ posts Post[] @relation("Post")
+ //add-next-line
+ posts Post[]
+}
+```
+
+The `@relation` annotation can also be used to [name the underlying relation table](/orm/prisma-schema/data-model/relations/many-to-many-relations#configuring-the-name-of-the-relation-table-in-implicit-many-to-many-relations) created on a implicit many-to-many relationship.
+
+```prisma
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ categories Category[] @relation("CategoryPostRelation")
+}
+
+model Category {
+ id Int @id @default(autoincrement())
+ name String
+ posts Post[] @relation("CategoryPostRelation")
+}
+```
+
+## Using m-n relations in databases with enforced primary keys
+
+### Problem
+
+Some cloud providers enforce the existence of primary keys in all tables. However, any relation tables (JOIN tables) created by Prisma ORM (expressed via `@relation`) for many-to-many relations using implicit syntax do not have primary keys.
+
+### Solution
+
+You need to use [explicit relation syntax](/orm/prisma-schema/data-model/relations/many-to-many-relations#explicit-many-to-many-relations), manually create the join model, and verify that this join model has a primary key.
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/index.mdx b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/index.mdx
new file mode 100644
index 0000000000..7816b465d2
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/index.mdx
@@ -0,0 +1,572 @@
+---
+title: 'Relations'
+metaTitle: 'Relations'
+metaDescription: 'A relation is a connection between two models in the Prisma schema. This page explains how you can define one-to-one, one-to-many and many-to-many relations in Prisma.'
+tocDepth: 3
+---
+
+
+
+A relation is a _connection_ between two models in the Prisma schema. For example, there is a one-to-many relation between `User` and `Post` because one user can have many blog posts.
+
+The following Prisma schema defines a one-to-many relation between the `User` and `Post` models. The fields involved in defining the relation are highlighted:
+
+
+
+
+```prisma highlight=3,8,9;normal
+model User {
+ id Int @id @default(autoincrement())
+ //highlight-next-line
+ posts Post[]
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ //highlight-start
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int // relation scalar field (used in the `@relation` attribute above)
+ //highlight-end
+
+ title String
+}
+```
+
+
+
+
+```prisma highlight=3,8,9;normal
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ //highlight-next-line
+ posts Post[]
+}
+
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ //highlight-start
+ author User @relation(fields: [authorId], references: [id])
+ authorId String @db.ObjectId // relation scalar field (used in the `@relation` attribute above)
+ //highlight-end
+
+ title String
+}
+```
+
+
+
+
+At a Prisma ORM level, the `User` / `Post` relation is made up of:
+
+- Two [relation fields](#relation-fields): `author` and `posts`. Relation fields define connections between models at the Prisma ORM level and **do not exist in the database**. These fields are used to generate Prisma Client.
+- The scalar `authorId` field, which is referenced by the `@relation` attribute. This field **does exist in the database** - it is the foreign key that connects `Post` and `User`.
+
+At a Prisma ORM level, a connection between two models is **always** represented by a [relation field](#relation-fields) on **each side** of the relation.
+
+
+
+
+
+
+
+
+
+## Relations in the database
+
+### Relational databases
+
+The following entity relationship diagram defines the same one-to-many relation between the `User` and `Post` tables in a **relational database**:
+
+
+
+In SQL, you use a _foreign key_ to create a relation between two tables. Foreign keys are stored on **one side** of the relation. Our example is made up of:
+
+- A foreign key column in the `Post` table named `authorId`.
+- A primary key column in the `User` table named `id`. The `authorId` column in the `Post` table references the `id` column in the `User` table.
+
+In the Prisma schema, the foreign key / primary key relationship is represented by the `@relation` attribute on the `author` field:
+
+```prisma
+author User @relation(fields: [authorId], references: [id])
+```
+
+> **Note**: Relations in the Prisma schema represent relationships that exist between tables in the database. If the relationship does not exist in the database, it does not exist in the Prisma schema.
+
+### MongoDB
+
+For MongoDB, Prisma ORM currently uses a [normalized data model design](https://www.mongodb.com/docs/manual/data-modeling/), which means that documents reference each other by ID in a similar way to relational databases.
+
+The following document represents a `User` (in the `User` collection):
+
+```json
+{ "_id": { "$oid": "60d5922d00581b8f0062e3a8" }, "name": "Ella" }
+```
+
+The following list of `Post` documents (in the `Post` collection) each have a `authorId` field which reference the same user:
+
+```json
+[
+ {
+ "_id": { "$oid": "60d5922e00581b8f0062e3a9" },
+ "title": "How to make sushi",
+ "authorId": { "$oid": "60d5922d00581b8f0062e3a8" }
+ },
+ {
+ "_id": { "$oid": "60d5922e00581b8f0062e3aa" },
+ "title": "How to re-install Windows",
+ "authorId": { "$oid": "60d5922d00581b8f0062e3a8" }
+ }
+]
+```
+
+This data structure represents a one-to-many relation because multiple `Post` documents refer to the same `User` document.
+
+#### `@db.ObjectId` on IDs and relation scalar fields
+
+If your model's ID is an `ObjectId` (represented by a `String` field), you must add `@db.ObjectId` to the model's ID _and_ the relation scalar field on the other side of the relation:
+
+```prisma highlight=3,9;normal
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ //highlight-next-line
+ posts Post[]
+}
+
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ author User @relation(fields: [authorId], references: [id])
+ //highlight-next-line
+ authorId String @db.ObjectId // relation scalar field (used in the `@relation` attribute above)
+
+ title String
+}
+```
+
+## Relations in Prisma Client
+
+Prisma Client is generated from the Prisma schema. The following examples demonstrate how relations manifest when you use Prisma Client to get, create, and update records.
+
+### Create a record and nested records
+
+The following query creates a `User` record and two connected `Post` records:
+
+```ts
+const userAndPosts = await prisma.user.create({
+ data: {
+ posts: {
+ create: [
+ { title: 'Prisma Day 2020' }, // Populates authorId with user's id
+ { title: 'How to write a Prisma schema' }, // Populates authorId with user's id
+ ],
+ },
+ },
+})
+```
+
+In the underlying database, this query:
+
+1. Creates a `User` with an auto-generated `id` (for example, `20`)
+2. Creates two new `Post` records and sets the `authorId` of both records to `20`
+
+### Retrieve a record and include related records
+
+The following query retrieves a `User` by `id` and includes any related `Post` records:
+
+```ts
+const getAuthor = await prisma.user.findUnique({
+ where: {
+ id: "20",
+ },
+ include: {
+ //highlight-next-line
+ posts: true, // All posts where authorId == 20
+ },
+});
+```
+
+In the underlying database, this query:
+
+1. Retrieves the `User` record with an `id` of `20`
+2. Retrieves all `Post` records with an `authorId` of `20`
+
+### Associate an existing record to another existing record
+
+The following query associates an existing `Post` record with an existing `User` record:
+
+```ts
+const updateAuthor = await prisma.user.update({
+ where: {
+ id: 20,
+ },
+ data: {
+ posts: {
+ connect: {
+ id: 4,
+ },
+ },
+ },
+})
+```
+
+In the underlying database, this query uses a [nested `connect` query](/6.0/orm/reference/prisma-client-reference#connect) to link the post with an `id` of 4 to the user with an `id` of 20. The query does this with the following steps:
+
+- The query first looks for the user with an `id` of `20`.
+- The query then sets the `authorID` foreign key to `20`. This links the post with an `id` of `4` to the user with an `id` of `20`.
+
+In this query, the current value of `authorID` does not matter. The query changes `authorID` to `20`, no matter its current value.
+
+## Types of relations
+
+There are three different types (or [cardinalities]()) of relations in Prisma ORM:
+
+- [One-to-one](/orm/prisma-schema/data-model/relations/one-to-one-relations) (also called 1-1 relations)
+- [One-to-many](/orm/prisma-schema/data-model/relations/one-to-many-relations) (also called 1-n relations)
+- [Many-to-many](/orm/prisma-schema/data-model/relations/many-to-many-relations) (also called m-n relations)
+
+The following Prisma schema includes every type of relation:
+
+- one-to-one: `User` ↔ `Profile`
+- one-to-many: `User` ↔ `Post`
+- many-to-many: `Post` ↔ `Category`
+
+
+
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ posts Post[]
+ profile Profile?
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ user User @relation(fields: [userId], references: [id])
+ userId Int @unique // relation scalar field (used in the `@relation` attribute above)
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int // relation scalar field (used in the `@relation` attribute above)
+ categories Category[]
+}
+
+model Category {
+ id Int @id @default(autoincrement())
+ posts Post[]
+}
+```
+
+
+
+
+```prisma
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ posts Post[]
+ profile Profile?
+}
+
+model Profile {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ user User @relation(fields: [userId], references: [id])
+ userId String @unique @db.ObjectId // relation scalar field (used in the `@relation` attribute above)
+}
+
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ author User @relation(fields: [authorId], references: [id])
+ authorId String @db.ObjectId // relation scalar field (used in the `@relation` attribute above)
+ categories Category[] @relation(fields: [categoryIds], references: [id])
+ categoryIds String[] @db.ObjectId
+}
+
+model Category {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ posts Post[] @relation(fields: [postIds], references: [id])
+ postIds String[] @db.ObjectId
+}
+```
+
+
+
+
+
+
+This schema is the same as the [example data model](/orm/prisma-schema/data-model/models) but has all [scalar fields](/orm/prisma-schema/data-model/models#scalar-fields) removed (except for the required [relation scalar fields](/orm/prisma-schema/data-model/relations#relation-scalar-fields)) so you can focus on the [relation fields](#relation-fields).
+
+
+
+
+
+This example uses [implicit many-to-many relations](/orm/prisma-schema/data-model/relations/many-to-many-relations#implicit-many-to-many-relations). These relations do not require the `@relation` attribute unless you need to [disambiguate relations](#disambiguating-relations).
+
+
+
+Notice that the syntax is slightly different between relational databases and MongoDB - particularly for [many-to-many relations](/orm/prisma-schema/data-model/relations/many-to-many-relations).
+
+For relational databases, the following entity relationship diagram represents the database that corresponds to the sample Prisma schema:
+
+
+
+For MongoDB, Prisma ORM uses a [normalized data model design](https://www.mongodb.com/docs/manual/data-modeling/), which means that documents reference each other by ID in a similar way to relational databases. See [the MongoDB section](#mongodb) for more details.
+
+### Implicit and explicit many-to-many relations
+
+Many-to-many relations in relational databases can be modelled in two ways:
+
+- [explicit many-to-many relations](/orm/prisma-schema/data-model/relations/many-to-many-relations#explicit-many-to-many-relations), where the relation table is represented as an explicit model in your Prisma schema
+- [implicit many-to-many relations](/orm/prisma-schema/data-model/relations/many-to-many-relations#implicit-many-to-many-relations), where Prisma ORM manages the relation table and it does not appear in the Prisma schema.
+
+Implicit many-to-many relations require both models to have a single `@id`. Be aware of the following:
+
+- You cannot use a [multi-field ID](/orm/reference/prisma-schema-reference#id-1)
+- You cannot use a `@unique` in place of an `@id`
+
+To use either of these features, you must set up an explicit many-to-many instead.
+
+The implicit many-to-many relation still manifests in a relation table in the underlying database. However, Prisma ORM manages this relation table.
+
+If you use an implicit many-to-many relation instead of an explicit one, it makes the [Prisma Client API](/orm/prisma-client) simpler (because, for example, you have one fewer level of nesting inside of [nested writes](/orm/prisma-client/queries/relation-queries#nested-writes)).
+
+If you're not using Prisma Migrate but obtain your data model from [introspection](/orm/prisma-schema/introspection), you can still make use of implicit many-to-many relations by following Prisma ORM's [conventions for relation tables](/orm/prisma-schema/data-model/relations/many-to-many-relations#conventions-for-relation-tables-in-implicit-m-n-relations).
+
+## Relation fields
+
+Relation [fields](/orm/prisma-schema/data-model/models#defining-fields) are fields on a Prisma [model](/orm/prisma-schema/data-model/models#defining-models) that do _not_ have a [scalar type](/orm/prisma-schema/data-model/models#scalar-fields). Instead, their type is another model.
+
+Every relation must have exactly two relation fields, one on each model. In the case of one-to-one and one-to-many relations, an additional _relation scalar field_ is required which gets linked by one of the two relation fields in the `@relation` attribute. This relation scalar field is the direct representation of the _foreign key_ in the underlying database.
+
+
+
+
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ role Role @default(USER)
+ posts Post[] // relation field (defined only at the Prisma ORM level)
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ author User @relation(fields: [authorId], references: [id]) // relation field (uses the relation scalar field `authorId` below)
+ authorId Int // relation scalar field (used in the `@relation` attribute above)
+}
+```
+
+
+
+
+```prisma
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ email String @unique
+ role Role @default(USER)
+ posts Post[] // relation field (defined only at the Prisma ORM level)
+}
+
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ title String
+ author User @relation(fields: [authorId], references: [id]) // relation field (uses the relation scalar field `authorId` below)
+ authorId String @db.ObjectId // relation scalar field (used in the `@relation` attribute above)
+}
+```
+
+
+
+
+Both `posts` and `author` are relation fields because their types are not scalar types but other models.
+
+Also note that the [annotated relation field](#annotated-relation-fields) `author` needs to link the relation scalar field `authorId` on the `Post` model inside the `@relation` attribute. The relation scalar field represents the foreign key in the underlying database.
+
+Both the relation fields (i.e. `posts` and `author`) are defined purely on a Prisma ORM-level, they don't manifest in the database.
+
+### Annotated relation fields
+
+Relations that require one side of the relation to be _annotated_ with the `@relation` attribute are referred to as _annotated relation fields_. This includes:
+
+- one-to-one relations
+- one-to-many relations
+- many-to-many relations for MongoDB only
+
+The side of the relation which is annotated with the `@relation` attribute represents the side that **stores the foreign key in the underlying database**. The "actual" field that represents the foreign key is required on that side of the relation as well, it's called _relation scalar field_, and is referenced inside `@relation` attribute:
+
+
+
+
+```prisma
+author User @relation(fields: [authorId], references: [id])
+authorId Int
+```
+
+
+
+
+```prisma
+author User @relation(fields: [authorId], references: [id])
+authorId String @db.ObjectId
+```
+
+
+
+
+A scalar field _becomes_ a relation scalar field when it's used in the `fields` of a `@relation` attribute.
+
+### Relation scalar fields
+
+#### Relation scalar field naming conventions
+
+Because a relation scalar field always _belongs_ to a relation field, the following naming convention is common:
+
+- Relation field: `author`
+- Relation scalar field: `authorId` (relation field name + `Id`)
+
+## The `@relation` attribute
+
+The [`@relation`](/orm/reference/prisma-schema-reference#relation) attribute can only be applied to the [relation fields](#relation-fields), not to [scalar fields](/orm/prisma-schema/data-model/models#scalar-fields).
+
+The `@relation` attribute is required when:
+
+- you define a one-to-one or one-to-many relation, it is required on _one side_ of the relation (with the corresponding relation scalar field)
+- you need to disambiguate a relation (that's e.g. the case when you have two relations between the same models)
+- you define a [self-relation](/orm/prisma-schema/data-model/relations/self-relations)
+- you define [a many-to-many relation for MongoDB](/orm/prisma-schema/data-model/relations/many-to-many-relations#mongodb)
+- you need to control how the relation table is represented in the underlying database (e.g. use a specific name for a relation table)
+
+> **Note**: [Implicit many-to-many relations](/orm/prisma-schema/data-model/relations/many-to-many-relations#implicit-many-to-many-relations) in relational databases do not require the `@relation` attribute.
+
+## Disambiguating relations
+
+When you define two relations between the same two models, you need to add the `name` argument in the `@relation` attribute to disambiguate them. As an example for why that's needed, consider the following models:
+
+
+
+
+```prisma highlight=6,7,13,15;normal no-copy
+// NOTE: This schema is intentionally incorrect. See below for a working solution.
+
+model User {
+ id Int @id @default(autoincrement())
+ name String?
+ //highlight-start
+ writtenPosts Post[]
+ pinnedPost Post?
+ //highlight-end
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ title String?
+ //highlight-next-line
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+ //highlight-next-line
+ pinnedBy User? @relation(fields: [pinnedById], references: [id])
+ pinnedById Int?
+}
+```
+
+
+
+
+```prisma highlight=6,7,13,15;normal no-copy
+// NOTE: This schema is intentionally incorrect. See below for a working solution.
+
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ name String?
+ //highlight-start
+ writtenPosts Post[]
+ pinnedPost Post?
+ //highlight-end
+}
+
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ title String?
+ //highlight-next-line
+ author User @relation(fields: [authorId], references: [id])
+ authorId String @db.ObjectId
+ //highlight-next-line
+ pinnedBy User? @relation(fields: [pinnedById], references: [id])
+ pinnedById String? @db.ObjectId
+}
+```
+
+
+
+
+In that case, the relations are ambiguous, there are four different ways to interpret them:
+
+- `User.writtenPosts` ↔ `Post.author` + `Post.authorId`
+- `User.writtenPosts` ↔ `Post.pinnedBy` + `Post.pinnedById`
+- `User.pinnedPost` ↔ `Post.author` + `Post.authorId`
+- `User.pinnedPost` ↔ `Post.pinnedBy` + `Post.pinnedById`
+
+To disambiguate these relations, you need to annotate the relation fields with the `@relation` attribute and provide the `name` argument. You can set any `name` (except for the empty string `""`), but it must be the same on both sides of the relation:
+
+
+
+
+```prisma highlight=4,5,11,13;normal
+model User {
+ id Int @id @default(autoincrement())
+ name String?
+ //highlight-start
+ writtenPosts Post[] @relation("WrittenPosts")
+ pinnedPost Post? @relation("PinnedPost")
+ //highlight-end
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ title String?
+ //highlight-next-line
+ author User @relation("WrittenPosts", fields: [authorId], references: [id])
+ authorId Int
+ //highlight-next-line
+ pinnedBy User? @relation("PinnedPost", fields: [pinnedById], references: [id])
+ pinnedById Int? @unique
+}
+```
+
+
+
+
+```prisma highlight=4,5,11,13;normal
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ name String?
+ //highlight-start
+ writtenPosts Post[] @relation("WrittenPosts")
+ pinnedPost Post? @relation("PinnedPost")
+ //highlight-end
+}
+
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ title String?
+ //highlight-next-line
+ author User @relation("WrittenPosts", fields: [authorId], references: [id])
+ authorId String @db.ObjectId
+ //highlight-next-line
+ pinnedBy User? @relation("PinnedPost", fields: [pinnedById], references: [id])
+ pinnedById String? @unique @db.ObjectId
+}
+```
+
+
+
+
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/one-to-many.png b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/one-to-many.png
new file mode 100644
index 0000000000..e0f44cd37a
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/one-to-many.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/quick-fix-index.png b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/quick-fix-index.png
new file mode 100644
index 0000000000..c82ed1a7ac
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/quick-fix-index.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/quick-fix-index.snagx b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/quick-fix-index.snagx
new file mode 100644
index 0000000000..c8ab225559
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/quick-fix-index.snagx differ
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/relations-intro.png b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/relations-intro.png
new file mode 100644
index 0000000000..47bb895580
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/relations-intro.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/sample-schema.png b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/sample-schema.png
new file mode 100644
index 0000000000..b7cef69941
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/20-relations/sample-schema.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/30-indexes.mdx b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/30-indexes.mdx
new file mode 100644
index 0000000000..66ac00544d
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/30-indexes.mdx
@@ -0,0 +1,543 @@
+---
+title: 'Indexes'
+metaDescription: 'How to configure index functionality and add full text indexes'
+hidePage: false
+tocDepth: 3
+---
+
+
+
+Prisma ORM allows configuration of database indexes, unique constraints and primary key constraints. This is in General Availability in versions `4.0.0` and later. You can enable this with the `extendedIndexes` Preview feature in versions `3.5.0` and later.
+
+Version `3.6.0` also introduces support for introspection and migration of full text indexes in MySQL and MongoDB through a new `@@fulltext` attribute, available through the `fullTextIndex` Preview feature.
+
+
+
+If you are upgrading from a version earlier than 4.0.0, these changes to index configuration and full text indexes might be **breaking changes** if you have a database that already uses these features. See [Upgrading from previous versions](#upgrading-from-previous-versions) for more information on how to upgrade.
+
+
+
+
+
+## Index configuration
+
+You can configure indexes, unique constraints, and primary key constraints with the following attribute arguments:
+
+- The [`length` argument](#configuring-the-length-of-indexes-with-length-mysql) allows you to specify a maximum length for the subpart of the value to be indexed on `String` and `Bytes` types
+
+ - Available on the `@id`, `@@id`, `@unique`, `@@unique` and `@@index` attributes
+ - MySQL only
+
+- The [`sort` argument](#configuring-the-index-sort-order-with-sort) allows you to specify the order that the entries of the constraint or index are stored in the database
+
+ - Available on the `@unique`, `@@unique` and `@@index` attributes in all databases, and on the `@id` and `@@id` attributes in SQL Server
+
+- The [`type` argument](#configuring-the-access-type-of-indexes-with-type-postgresql) allows you to support index access methods other than PostgreSQL's default `BTree` access method
+
+ - Available on the `@@index` attribute
+ - PostgreSQL only
+ - Supported index access methods: `Hash`, `Gist`, `Gin`, `SpGist` and `Brin`
+
+- The [`clustered` argument](#configuring-if-indexes-are-clustered-or-non-clustered-with-clustered-sql-server) allows you to configure whether a constraint or index is clustered or non-clustered
+ - Available on the `@id`, `@@id`, `@unique`, `@@unique` and `@@index` attributes
+ - SQL Server only
+
+See the linked sections for details of which version each feature was first introduced in.
+
+### Configuring the length of indexes with `length` (MySQL)
+
+The `length` argument is specific to MySQL and allows you to define indexes and constraints on columns of `String` and `Byte` types. For these types, MySQL requires you to specify a maximum length for the subpart of the value to be indexed in cases where the full value would exceed MySQL's limits for index sizes. See [the MySQL documentation](https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html) for more details.
+
+The `length` argument is available on the `@id`, `@@id`, `@unique`, `@@unique` and `@@index` attributes. It is generally available in versions 4.0.0 and later, and available as part of the `extendedIndexes` preview feature in versions 3.5.0 and later.
+
+As an example, the following data model declares an `id` field with a maximum length of 3000 characters:
+
+```prisma file=schema.prisma showLineNumbers
+model Id {
+ id String @id @db.VarChar(3000)
+}
+```
+
+This is not valid in MySQL because it exceeds MySQL's index storage limit and therefore Prisma ORM rejects the data model. The generated SQL would be rejected by the database.
+
+```sql
+CREATE TABLE `Id` (
+ `id` VARCHAR(3000) PRIMARY KEY
+)
+```
+
+The `length` argument allows you to specify that only a subpart of the `id` value represents the primary key. In the example below, the first 100 characters are used:
+
+```prisma file=schema.prisma showLineNumbers
+model Id {
+ id String @id(length: 100) @db.VarChar(3000)
+}
+```
+
+Prisma Migrate is able to create constraints and indexes with the `length` argument if specified in your data model. This means that you can create indexes and constraints on values of Prisma schema type `Byte` and `String`. If you don't specify the argument the index is treated as covering the full value as before.
+
+Introspection will fetch these limits where they are present in your existing database. This allows Prisma ORM to support indexes and constraints that were previously suppressed and results in better support of MySQL databases utilizing this feature.
+
+The `length` argument can also be used on compound primary keys, using the `@@id` attribute, as in the example below:
+
+```prisma file=schema.prisma showLineNumbers
+model CompoundId {
+ id_1 String @db.VarChar(3000)
+ id_2 String @db.VarChar(3000)
+
+ @@id([id_1(length: 100), id_2(length: 10)])
+}
+```
+
+A similar syntax can be used for the `@@unique` and `@@index` attributes.
+
+### Configuring the index sort order with `sort`
+
+The `sort` argument allows you to specify the order that the entries of the index or constraint are stored in the database. This can have an effect on whether the database is able to use an index for specific queries. The behavior and support varies by database:
+
+- In MySQL/MariaDB, you can specify sort order (`ASC`/`DESC`) directly in unique constraints and indexes
+- In PostgreSQL, sort order can only be specified on indexes, not on unique constraints
+- In SQL Server, sort order is supported on all constraints and indexes including `@id` and `@@id`
+
+The `sort` argument is generally available in versions 4.0.0 and later, and available as part of the `extendedIndexes` preview feature in versions 3.5.0 and later.
+
+For example, in MySQL/MariaDB, the following table using a descending unique constraint:
+
+```sql
+CREATE TABLE `Unique` (
+ `unique` INT,
+ CONSTRAINT `Unique_unique_key` UNIQUE (`unique` DESC)
+)
+```
+
+would be introspected as
+
+```prisma file=schema.prisma showLineNumbers
+model Unique {
+ unique Int @unique(sort: Desc)
+}
+```
+
+Note that in PostgreSQL, while you cannot specify sort order on unique constraints directly, you can create a unique index with a sort order that will enforce uniqueness:
+
+```sql
+-- PostgreSQL approach
+CREATE UNIQUE INDEX "unique_index_desc" ON "Unique" ("unique" DESC);
+```
+
+The `sort` argument can also be used on compound indexes:
+
+```prisma file=schema.prisma showLineNumbers
+model CompoundUnique {
+ unique_1 Int
+ unique_2 Int
+
+ @@unique([unique_1(sort: Desc), unique_2])
+}
+```
+
+### Example: using `sort` and `length` together
+
+The following example demonstrates the use of the `sort` and `length` arguments to configure indexes and constraints for a `Post` model:
+
+```prisma file=schema.prisma showLineNumbers
+model Post {
+ title String @db.VarChar(300)
+ abstract String @db.VarChar(3000)
+ slug String @unique(sort: Desc, length: 42) @db.VarChar(3000)
+ author String
+ created_at DateTime
+
+ @@id([title(length: 100, sort: Desc), abstract(length: 10)])
+ @@index([author, created_at(sort: Desc)])
+}
+```
+
+### Configuring the access type of indexes with `type` (PostgreSQL)
+
+The `type` argument is available for configuring the index type in PostgreSQL with the `@@index` attribute. The index access methods available are `Hash`, `Gist`, `Gin`, `SpGist` and `Brin`, as well as the default `BTree` index access method. The `type` argument is generally available in versions 4.0.0 and later. The `Hash` index access method is available as part of the `extendedIndexes` preview feature in versions 3.6.0 and later, and the `Gist`, `Gin`, `SpGist` and `Brin` index access methods are available in preview in versions 3.14.0 and later.
+
+#### Hash
+
+The `Hash` type will store the index data in a format that is much faster to search and insert, and that will use less disk space. However, only the `=` and `<>` comparisons can use the index, so other comparison operators such as `<` and `>` will be much slower with `Hash` than when using the default `BTree` type.
+
+As an example, the following model adds an index with a `type` of `Hash` to the `value` field:
+
+```prisma file=schema.prisma showLineNumbers
+model Example {
+ id Int @id
+ value Int
+
+ @@index([value], type: Hash)
+}
+```
+
+This translates to the following SQL commands:
+
+```sql
+CREATE TABLE "Example" (
+ id INT PRIMARY KEY,
+ value INT NOT NULL
+);
+
+CREATE INDEX "Example_value_idx" ON "Example" USING HASH (value);
+```
+
+#### Generalized Inverted Index (GIN)
+
+The GIN index stores composite values, such as arrays or `JsonB` data. This is useful for speeding up querying whether one object is part of another object. It is commonly used for full-text searches.
+
+An indexed field can define the operator class, which defines the operators handled by the index.
+
+
+
+Indexes using a function (such as `to_tsvector`) to determine the indexed value are not yet supported by Prisma ORM. Indexes defined in this way will not be visible with `prisma db pull`.
+
+
+
+As an example, the following model adds a `Gin` index to the `value` field, with `JsonbPathOps` as the class of operators allowed to use the index:
+
+```prisma file=schema.prisma showLineNumbers
+model Example {
+ id Int @id
+ value Json
+ // ^ field type matching the operator class
+ // ^ operator class ^ index type
+
+ @@index([value(ops: JsonbPathOps)], type: Gin)
+}
+```
+
+This translates to the following SQL commands:
+
+```sql
+CREATE TABLE "Example" (
+ id INT PRIMARY KEY,
+ value JSONB NOT NULL
+);
+
+CREATE INDEX "Example_value_idx" ON "Example" USING GIN (value jsonb_path_ops);
+```
+
+As part of the `JsonbPathOps` the `@>` operator is handled by the index, speeding up queries such as `value @> '{"foo": 2}'`.
+
+##### Supported Operator Classes for GIN
+
+Prisma ORM generally supports operator classes provided by PostgreSQL in versions 10 and later. If the operator class requires the field type to be of a type Prisma ORM does not yet support, using the `raw` function with a string input allows you to use these operator classes without validation.
+
+The default operator class (marked with ✅) can be omitted from the index definition.
+
+| Operator class | Allowed field type (native types) | Default | Other |
+| -------------- | --------------------------------- | ------- | ----------------------------- |
+| `ArrayOps` | Any array | ✅ | Also available in CockroachDB |
+| `JsonbOps` | `Json` (`@db.JsonB`) | ✅ | Also available in CockroachDB |
+| `JsonbPathOps` | `Json` (`@db.JsonB`) | | |
+| `raw("other")` | | | |
+
+Read more about built-in operator classes in the [official PostgreSQL documentation](https://www.postgresql.org/docs/14/gin-builtin-opclasses.html).
+
+##### CockroachDB
+
+GIN and BTree are the only index types supported by CockroachDB. The operator classes marked to work with CockroachDB are the only ones allowed on that database and supported by Prisma ORM. The operator class cannot be defined in the Prisma Schema Language: the `ops` argument is not necessary or allowed on CockroachDB.
+
+#### Generalized Search Tree (GiST)
+
+The GiST index type is used for implementing indexing schemes for user-defined types. By default there are not many direct uses for GiST indexes, but for example the B-Tree index type is built using a GiST index.
+
+As an example, the following model adds a `Gist` index to the `value` field with `InetOps` as the operators that will be using the index:
+
+```prisma file=schema.prisma showLineNumbers
+model Example {
+ id Int @id
+ value String @db.Inet
+ // ^ native type matching the operator class
+ // ^ index type
+ // ^ operator class
+
+ @@index([value(ops: InetOps)], type: Gist)
+}
+```
+
+This translates to the following SQL commands:
+
+```sql
+CREATE TABLE "Example" (
+ id INT PRIMARY KEY,
+ value INET NOT NULL
+);
+
+CREATE INDEX "Example_value_idx" ON "Example" USING GIST (value inet_ops);
+```
+
+Queries comparing IP addresses, such as `value > '10.0.0.2'`, will use the index.
+
+##### Supported Operator Classes for GiST
+
+Prisma ORM generally supports operator classes provided by PostgreSQL in versions 10 and later. If the operator class requires the field type to be of a type Prisma ORM does not yet support, using the `raw` function with a string input allows you to use these operator classes without validation.
+
+| Operator class | Allowed field type (allowed native types) |
+| -------------- | ----------------------------------------- |
+| `InetOps` | `String` (`@db.Inet`) |
+| `raw("other")` | |
+
+Read more about built-in operator classes in the [official PostgreSQL documentation](https://www.postgresql.org/docs/14/gist-builtin-opclasses.html).
+
+#### Space-Partitioned GiST (SP-GiST)
+
+The SP-GiST index is a good choice for many different non-balanced data structures. If the query matches the partitioning rule, it can be very fast.
+
+As with GiST, SP-GiST is important as a building block for user-defined types, allowing implementation of custom search operators directly with the database.
+
+As an example, the following model adds a `SpGist` index to the `value` field with `TextOps` as the operators using the index:
+
+```prisma file=schema.prisma showLineNumbers
+model Example {
+ id Int @id
+ value String
+ // ^ field type matching the operator class
+
+ @@index([value], type: SpGist)
+ // ^ index type
+ // ^ using the default ops: TextOps
+}
+```
+
+This translates to the following SQL commands:
+
+```sql
+CREATE TABLE "Example" (
+ id INT PRIMARY KEY,
+ value TEXT NOT NULL
+);
+
+CREATE INDEX "Example_value_idx" ON "Example" USING SPGIST (value);
+```
+
+Queries such as `value LIKE 'something%'` will be sped up by the index.
+
+##### Supported Operator Classes for SP-GiST
+
+Prisma ORM generally supports operator classes provided by PostgreSQL in versions 10 and later. If the operator class requires the field type to be of a type Prisma ORM does not yet support, using the `raw` function with a string input allows you to use these operator classes without validation.
+
+The default operator class (marked with ✅) can be omitted from the index definition.
+
+| Operator class | Allowed field type (native types) | Default | Supported PostgreSQL versions |
+| -------------- | ------------------------------------ | ------- | ----------------------------- |
+| `InetOps` | `String` (`@db.Inet`) | ✅ | 10+ |
+| `TextOps` | `String` (`@db.Text`, `@db.VarChar`) | ✅ | |
+| `raw("other")` | | | |
+
+Read more about built-in operator classes from [official PostgreSQL documentation](https://www.postgresql.org/docs/14/spgist-builtin-opclasses.html).
+
+#### Block Range Index (BRIN)
+
+The BRIN index type is useful if you have lots of data that does not change after it is inserted, such as date and time values. If your data is a good fit for the index, it can store large datasets in a minimal space.
+
+As an example, the following model adds a `Brin` index to the `value` field with `Int4BloomOps` as the operators that will be using the index:
+
+```prisma file=schema.prisma showLineNumbers
+model Example {
+ id Int @id
+ value Int
+ // ^ field type matching the operator class
+ // ^ operator class ^ index type
+
+ @@index([value(ops: Int4BloomOps)], type: Brin)
+}
+```
+
+This translates to the following SQL commands:
+
+```sql
+CREATE TABLE "Example" (
+ id INT PRIMARY KEY,
+ value INT4 NOT NULL
+);
+
+CREATE INDEX "Example_value_idx" ON "Example" USING BRIN (value int4_bloom_ops);
+```
+
+Queries like `value = 2` will now use the index, which uses a fraction of the space used by the `BTree` or `Hash` indexes.
+
+##### Supported Operator Classes for BRIN
+
+Prisma ORM generally supports operator classes provided by PostgreSQL in versions 10 and later, and some supported operators are only available from PostgreSQL versions 14 and later. If the operator class requires the field type to be of a type Prisma ORM does not yet support, using the `raw` function with a string input allows you to use these operator classes without validation.
+
+The default operator class (marked with ✅) can be omitted from the index definition.
+
+| Operator class | Allowed field type (native types) | Default | Supported PostgreSQL versions |
+| --------------------------- | ------------------------------------ | ------- | ----------------------------- |
+| `BitMinMaxOps` | `String` (`@db.Bit`) | ✅ | |
+| `VarBitMinMaxOps` | `String` (`@db.VarBit`) | ✅ | |
+| `BpcharBloomOps` | `String` (`@db.Char`) | | 14+ |
+| `BpcharMinMaxOps` | `String` (`@db.Char`) | ✅ | |
+| `ByteaBloomOps` | `Bytes` (`@db.Bytea`) | | 14+ |
+| `ByteaMinMaxOps` | `Bytes` (`@db.Bytea`) | ✅ | |
+| `DateBloomOps` | `DateTime` (`@db.Date`) | | 14+ |
+| `DateMinMaxOps` | `DateTime` (`@db.Date`) | ✅ | |
+| `DateMinMaxMultiOps` | `DateTime` (`@db.Date`) | | 14+ |
+| `Float4BloomOps` | `Float` (`@db.Real`) | | 14+ |
+| `Float4MinMaxOps` | `Float` (`@db.Real`) | ✅ | |
+| `Float4MinMaxMultiOps` | `Float` (`@db.Real`) | | 14+ |
+| `Float8BloomOps` | `Float` (`@db.DoublePrecision`) | | 14+ |
+| `Float8MinMaxOps` | `Float` (`@db.DoublePrecision`) | ✅ | |
+| `Float8MinMaxMultiOps` | `Float` (`@db.DoublePrecision`) | | 14+ |
+| `InetInclusionOps` | `String` (`@db.Inet`) | ✅ | 14+ |
+| `InetBloomOps` | `String` (`@db.Inet`) | | 14+ |
+| `InetMinMaxOps` | `String` (`@db.Inet`) | | |
+| `InetMinMaxMultiOps` | `String` (`@db.Inet`) | | 14+ |
+| `Int2BloomOps` | `Int` (`@db.SmallInt`) | | 14+ |
+| `Int2MinMaxOps` | `Int` (`@db.SmallInt`) | ✅ | |
+| `Int2MinMaxMultiOps` | `Int` (`@db.SmallInt`) | | 14+ |
+| `Int4BloomOps` | `Int` (`@db.Integer`) | | 14+ |
+| `Int4MinMaxOps` | `Int` (`@db.Integer`) | ✅ | |
+| `Int4MinMaxMultiOps` | `Int` (`@db.Integer`) | | 14+ |
+| `Int8BloomOps` | `BigInt` (`@db.BigInt`) | | 14+ |
+| `Int8MinMaxOps` | `BigInt` (`@db.BigInt`) | ✅ | |
+| `Int8MinMaxMultiOps` | `BigInt` (`@db.BigInt`) | | 14+ |
+| `NumericBloomOps` | `Decimal` (`@db.Decimal`) | | 14+ |
+| `NumericMinMaxOps` | `Decimal` (`@db.Decimal`) | ✅ | |
+| `NumericMinMaxMultiOps` | `Decimal` (`@db.Decimal`) | | 14+ |
+| `OidBloomOps` | `Int` (`@db.Oid`) | | 14+ |
+| `OidMinMaxOps` | `Int` (`@db.Oid`) | ✅ | |
+| `OidMinMaxMultiOps` | `Int` (`@db.Oid`) | | 14+ |
+| `TextBloomOps` | `String` (`@db.Text`, `@db.VarChar`) | | 14+ |
+| `TextMinMaxOps` | `String` (`@db.Text`, `@db.VarChar`) | ✅ | |
+| `TextMinMaxMultiOps` | `String` (`@db.Text`, `@db.VarChar`) | | 14+ |
+| `TimestampBloomOps` | `DateTime` (`@db.Timestamp`) | | 14+ |
+| `TimestampMinMaxOps` | `DateTime` (`@db.Timestamp`) | ✅ | |
+| `TimestampMinMaxMultiOps` | `DateTime` (`@db.Timestamp`) | | 14+ |
+| `TimestampTzBloomOps` | `DateTime` (`@db.Timestamptz`) | | 14+ |
+| `TimestampTzMinMaxOps` | `DateTime` (`@db.Timestamptz`) | ✅ | |
+| `TimestampTzMinMaxMultiOps` | `DateTime` (`@db.Timestamptz`) | | 14+ |
+| `TimeBloomOps` | `DateTime` (`@db.Time`) | | 14+ |
+| `TimeMinMaxOps` | `DateTime` (`@db.Time`) | ✅ | |
+| `TimeMinMaxMultiOps` | `DateTime` (`@db.Time`) | | 14+ |
+| `TimeTzBloomOps` | `DateTime` (`@db.Timetz`) | | 14+ |
+| `TimeTzMinMaxOps` | `DateTime` (`@db.Timetz`) | ✅ | |
+| `TimeTzMinMaxMultiOps` | `DateTime` (`@db.Timetz`) | | 14+ |
+| `UuidBloomOps` | `String` (`@db.Uuid`) | | 14+ |
+| `UuidMinMaxOps` | `String` (`@db.Uuid`) | ✅ | |
+| `UuidMinMaxMultiOps` | `String` (`@db.Uuid`) | | 14+ |
+| `raw("other")` | | | |
+
+Read more about built-in operator classes in the [official PostgreSQL documentation](https://www.postgresql.org/docs/14/brin-builtin-opclasses.html).
+
+### Configuring if indexes are clustered or non-clustered with `clustered` (SQL Server)
+
+The `clustered` argument is available to configure (non)clustered indexes in SQL Server. It can be used on the `@id`, `@@id`, `@unique`, `@@unique` and `@@index` attributes. It is generally available in versions 4.0.0 and later, and available as part of the `extendedIndexes` preview feature in versions 3.13.0 and later.
+
+As an example, the following model configures the `@id` to be non-clustered (instead of the clustered default):
+
+```prisma file=schema.prisma showLineNumbers
+model Example {
+ id Int @id(clustered: false)
+ value Int
+}
+```
+
+This translates to the following SQL commands:
+
+```sql
+CREATE TABLE [Example] (
+ id INT NOT NULL,
+ value INT,
+ CONSTRAINT [Example_pkey] PRIMARY KEY NONCLUSTERED (id)
+)
+```
+
+The default value of `clustered` for each attribute is as follows:
+
+| Attribute | Value |
+| ---------- | ------- |
+| `@id` | `true` |
+| `@@id` | `true` |
+| `@unique` | `false` |
+| `@@unique` | `false` |
+| `@@index` | `false` |
+
+A table can have at most one clustered index.
+
+### Upgrading from previous versions
+
+
+
+These index configuration changes can be **breaking changes** when activating the functionality for certain, existing Prisma schemas for existing databases. After enabling the preview features required to use them, run `prisma db pull` to introspect the existing database to update your Prisma schema before using Prisma Migrate again.
+
+
+
+A breaking change can occur in the following situations:
+
+- **Existing sort constraints and indexes:** earlier versions of Prisma ORM will assume that the desired sort order is _ascending_ if no order is specified explicitly. This means that this is a breaking change if you have existing constraints or indexes that are using descending sort order and migrate your database without first specifying this in your data model.
+- **Existing length constraints and indexes:** in earlier versions of Prisma ORM, indexes and constraints that were length constrained in MySQL could not be represented in the Prisma schema. Therefore `prisma db pull` was not fetching these and you could not manually specify them. When you ran `prisma db push` or `prisma migrate dev` they were ignored if already present in your database. Since you are now able to specify these, migrate commands will now drop them if they are missing from your data model but present in the database.
+- **Existing indexes other than `BTree` (PostgreSQL):** earlier versions of Prisma ORM only supported the default `BTree` index type. Other supported indexes (`Hash`, `Gist`, `Gin`, `SpGist` and `Brin`) need to be added before migrating your database.
+- **Existing (non-)clustered indexes (SQL Server):** earlier versions of Prisma ORM did not support configuring an index as clustered or non-clustered. For indexes that do not use the default, these need to be added before migrating your database.
+
+In each of the cases above unwanted changes to your database can be prevented by properly specifying these properties in your data model where necessary. **The easiest way to do this is to use `prisma db pull` to retrieve any existing constraints or configuration.** Alternatively, you could also add these arguments manually. This should be done before using `prisma db push` or `prisma migrate dev` the first time after the upgrade.
+
+## Full text indexes (MySQL and MongoDB)
+
+The `fullTextIndex` preview feature provides support for introspection and migration of full text indexes in MySQL and MongoDB in version 3.6.0 and later. This can be configured using the `@@fulltext` attribute. Existing full text indexes in the database are added to your Prisma schema after introspecting with `db pull`, and new full text indexes added in the Prisma schema are created in the database when using Prisma Migrate. This also prevents validation errors in some database schemas that were not working before.
+
+
+
+For now we do not enable the full text search commands in Prisma Client for MongoDB; the progress can be followed in the [MongoDB](https://github.com/prisma/prisma/issues/9413) issue.
+
+
+
+### Enabling the `fullTextIndex` preview feature
+
+To enable the `fullTextIndex` preview feature, add the `fullTextIndex` feature flag to the `generator` block of the `schema.prisma` file:
+
+```prisma file=schema.prisma showLineNumbers
+generator client {
+ provider = "prisma-client-js"
+ previewFeatures = ["fullTextIndex"]
+}
+```
+
+### Examples
+
+The following example demonstrates adding a `@@fulltext` index to the `title` and `content` fields of a `Post` model:
+
+```prisma file=schema.prisma showLineNumbers
+model Post {
+ id Int @id
+ title String @db.VarChar(255)
+ content String @db.Text
+
+ @@fulltext([title, content])
+}
+```
+
+On MongoDB, you can use the `@@fulltext` index attribute (via the `fullTextIndex` preview feature) with the `sort` argument to add fields to your full-text index in ascending or descending order. The following example adds a `@@fulltext` index to the `title` and `content` fields of the `Post` model, and sorts the `title` field in descending order:
+
+```prisma file=schema.prisma showLineNumbers
+generator js {
+ provider = "prisma-client-js"
+ previewFeatures = ["fullTextIndex"]
+}
+
+datasource db {
+ provider = "mongodb"
+ url = env("DATABASE_URL")
+}
+
+model Post {
+ id String @id @map("_id") @db.ObjectId
+ title String
+ content String
+
+ @@fulltext([title(sort: Desc), content])
+}
+```
+
+### Upgrading from previous versions
+
+
+
+This can be a **breaking change** when activating the functionality for certain, existing Prisma schemas for existing databases. After enabling the preview features required to use them, run `prisma db pull` to introspect the existing database to update your Prisma schema before using Prisma Migrate again.
+
+
+
+Earlier versions of Prisma ORM converted full text indexes using the `@@index` attribute rather than the `@@fulltext` attribute. After enabling the `fullTextIndex` preview feature, run `prisma db pull` to convert these indexes to `@@fulltext` before migrating again with Prisma Migrate. If you do not do this, the existing indexes will be dropped instead and normal indexes will be created in their place.
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/40-views.mdx b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/40-views.mdx
new file mode 100644
index 0000000000..ab3467c8dd
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/40-views.mdx
@@ -0,0 +1,341 @@
+---
+title: 'Views'
+metaTitle: 'How to include views in your Prisma schema'
+metaDescription: 'How to include views in your Prisma schema'
+hidePage: false
+sidebar_class_name: preview-badge
+tocDepth: 3
+---
+
+
+Database views allow you to name and store queries. In relational databases, views are [stored SQL queries](https://www.postgresql.org/docs/current/sql-createview.html) that might include columns in multiple tables, or calculated values such as aggregates. In MongoDB, views are queryable objects where the contents are defined by an [aggregation pipeline](https://www.mongodb.com/docs/manual/core/aggregation-pipeline) on other collections.
+
+The `views` preview feature allows you to represent views in your Prisma schema with the `view` keyword. To use views in Prisma ORM, follow these steps:
+
+1. [Enable the `views` preview feature](#enable-the-views-preview-feature)
+1. [Create a view in the underlying database](#create-a-view-in-the-underlying-database), either directly or as a [manual addition to a Prisma Migrate migration file](#use-views-with-prisma-migrate-and-db-push), or use an existing view
+1. [Represent the view in your Prisma schema](#add-views-to-your-prisma-schema)
+1. [Query the view in Prisma Client](#query-views-in-prisma-client)
+
+
+:::warning
+
+Support for views is currently a [Preview](/orm/more/releases#preview) feature. You can add a view to your Prisma schema with the `view` keyword or introspect the views in your database schema with `db pull`. You cannot yet apply views in your schema to your database with Prisma Migrate and `db push` unless the changes are added manually to your migration file using the `--create-only` flag.
For updates on progress with this feature, follow [our GitHub issue](https://github.com/prisma/prisma/issues/17335).
+
+:::
+
+## Enable the `views` preview feature
+
+Support for views is currently in an early preview. To enable the `views` preview feature, add the `views` feature flag to the `previewFeatures` field of the `generator` block in your Prisma Schema:
+
+```prisma file=schema.prisma highlight=3;add showLineNumbers
+generator client {
+ provider = "prisma-client"
+ //add-next-line
+ previewFeatures = ["views"]
+}
+```
+
+Please leave feedback about this preview feature in our dedicated preview feature [feedback issue](https://github.com/prisma/prisma/issues/17335) for `views`.
+
+## Create a view in the underlying database
+
+Currently, you cannot apply views that you define in your Prisma schema to your database with Prisma Migrate or `db push`. Instead, you must first create the view in the underlying database, either manually or [as part of a migration](#use-views-with-prisma-migrate-and-db-push).
+
+For example, take the following Prisma schema with a `User` model and a related `Profile` model:
+
+
+
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ profile Profile?
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String
+ user User @relation(fields: [userId], references: [id])
+ userId Int @unique
+}
+```
+
+
+
+
+```prisma
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ email String @unique
+ name String?
+ profile Profile?
+}
+
+model Profile {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ bio String
+ User User @relation(fields: [userId], references: [id])
+ userId String @unique @db.ObjectId
+}
+```
+
+
+
+
+Next, take a `UserInfo` view in the underlying database that combines the `email` and `name` fields from the `User` model and the `bio` field from the `Profile` model.
+
+For a relational database, the SQL statement to create this view is:
+
+```sql
+CREATE VIEW "UserInfo" AS
+ SELECT u.id, email, name, bio
+ FROM "User" u
+ LEFT JOIN "Profile" p ON u.id = p."userId";
+```
+
+For MongoDB, you can [create a view](https://www.mongodb.com/docs/manual/core/views/join-collections-with-view/) with the following command:
+
+```ts
+db.createView('UserInfo', 'User', [
+ {
+ $lookup: {
+ from: 'Profile',
+ localField: '_id',
+ foreignField: 'userId',
+ as: 'ProfileData',
+ },
+ },
+ {
+ $project: {
+ _id: 1,
+ email: 1,
+ name: 1,
+ bio: '$ProfileData.bio',
+ },
+ },
+ { $unwind: '$bio' },
+])
+```
+
+## Use views with Prisma Migrate and `db push`
+
+If you apply changes to your Prisma schema with Prisma Migrate or `db push`, Prisma ORM does not create or run any SQL related to views.
+
+To include views in a migration, run `migrate dev --create-only` and then manually add the SQL for views to your migration file. Alternatively, you can create views manually in the database.
+
+## Add views to your Prisma schema
+
+To add a view to your Prisma schema, use the `view` keyword.
+
+You can represent the `UserInfo` view from the example above in your Prisma schema as follows:
+
+
+
+
+```prisma
+view UserInfo {
+ id Int
+ email String
+ name String
+ bio String
+}
+```
+
+
+
+
+```prisma
+view UserInfo {
+ id String @map("_id") @db.ObjectId
+ email String
+ name String
+ bio String
+}
+```
+
+
+
+
+### Write by hand
+
+A `view` block is comprised of two main pieces:
+
+- The `view` block definition
+- The view's field definitions
+
+These two pieces allow you to define the name of your view in the generated Prisma Client and the columns present in your view's query results.
+
+#### Define a `view` block
+
+To define the `UserInfo` view from the example above, begin by using the `view` keyword to define a `view` block in your schema named `UserInfo`:
+
+```prisma
+view UserInfo {
+ // Fields
+}
+```
+
+#### Define fields
+
+The properties of a view are called _fields_, which consist of:
+
+- A field name
+- A field type
+
+The fields of the `UserInfo` example view can be defined as follows:
+
+
+
+
+```prisma highlight=2-5;normal
+view UserInfo {
+ //highlight-start
+ id Int
+ email String
+ name String
+ bio String
+ //highlight-end
+}
+```
+
+
+
+
+```prisma highlight=2-5;normal
+view UserInfo {
+ //highlight-start
+ id String @map("_id") @db.ObjectId
+ email String
+ name String
+ bio String
+ //highlight-end
+}
+```
+
+
+
+
+Each _field_ of a `view` block represents a column in the query results of the view in the underlying database.
+
+### Use introspection
+
+:::warning
+Currently views can only be introspected with PostgreSQL, MySQL, SQL Server and CockroachDB databases. If you are using another database provider, your views must be added manually.
+:::
+
+
+If you have an existing view or views defined in your database, [introspection](/orm/prisma-schema/introspection) will automatically generate `view` blocks in your Prisma schema that represent those views.
+
+Assuming the example `UserInfo` view exists in your underlying database, running the following command will generate a `view` block in your Prisma schema representing that view:
+
+```terminal copy
+npx prisma db pull
+```
+
+The resulting `view` block will be defined as follows:
+
+```prisma
+view UserInfo {
+ id Int?
+ email String?
+ name String?
+ bio String?
+}
+```
+
+:::warning
+Please note for now `db pull` will only introspect views in your schema when using PostgreSQL, MySQL, SQL Server or CockroachDB. Support for this workflow will be extended to other database providers.
+:::
+
+#### The `views` directory
+
+Introspection of a database with one or more existing views will also create a new `views` directory within your `prisma` directory (starting with Prisma version 4.12.0). This directory will contain a subdirectory named after your database's schema which contains a `.sql` file for each view that was introspected in that schema. Each file will be named after an individual view and will contain the query the related view defines.
+
+For example, after introspecting a database with the default `public` schema using the model used above you will find a `prisma/views/public/UserInfo.sql` file was created with the following contents:
+
+```sql
+SELECT
+ u.id,
+ u.email,
+ u.name,
+ p.bio
+FROM
+ (
+ "User" u
+ LEFT JOIN "Profile" p ON ((u.id = p."userId"))
+ );
+```
+
+## Query views in Prisma Client
+
+:::note
+
+Be sure to run `prisma generate` after updating your Prisma schema so that the `view` definitions become part of your Prisma Client API.
+
+:::
+
+You can query views in Prisma Client in the same way that you query models. For example, the following query finds all users with a `name` of `'Alice'` in the `UserInfo` view defined above.
+
+```ts
+const userinfo = await prisma.userInfo.findMany({
+ where: {
+ name: 'Alice',
+ },
+})
+```
+
+:::note
+
+Write-queries (create/update/delete) are not supported on `views`.
+
+:::
+
+
+## Special types of views
+
+This section describes how to use Prisma ORM with updatable and materialized views in your database.
+
+### Updatable views
+
+Some databases support _updatable views_ (e.g. [PostgreSQL](https://www.postgresql.org/docs/current/sql-createview.html#SQL-CREATEVIEW-UPDATABLE-VIEWS), [MySQL](https://dev.mysql.com/doc/refman/8.0/en/view-updatability.html), and [SQL Server](https://learn.microsoft.com/en-us/sql/t-sql/statements/create-view-transact-sql?view=sql-server-ver16#updatable-views)). Updatable views allow creating, updating, or deleting entries if the underlying database supports such operations.
+
+Prisma ORM does not allow any mutations (create, update, delete) on views, regardless of the database's capabilities. This change provides guardrails to ensure that views are treated consistently as read-only entities within Prisma Client. As a result, methods to perform writes such as `create`, `update`, `delete`, or `upsert` are not generated for `view` blocks in your Prisma Client API.
+
+If you need to modify data represented by a view, you must perform the write operations directly on the underlying tables or use raw SQL queries.
+
+### Materialized views
+
+Some databases support materialized views, e.g. [PostgreSQL](https://www.postgresql.org/docs/current/rules-materializedviews.html), [CockroachDB](https://www.cockroachlabs.com/docs/stable/views.html#materialized-views), [MongoDB](https://www.mongodb.com/docs/manual/core/materialized-views/), and [SQL Server](https://learn.microsoft.com/en-us/sql/relational-databases/views/create-indexed-views?view=sql-server-ver16) (where they're called "indexed views").
+
+Materialized views persist the result of the view query for faster access and only update it on demand.
+
+Currently, Prisma ORM does not support materialized views. However, when you [manually create a view](#create-a-view-in-the-underlying-database), you can also create a materialized view with the corresponding command in the underlying database. You can then use Prisma Client's [TypedSQL functionality](/orm/prisma-client/using-raw-sql) to execute the command and refresh the view manually.
+
+In the future Prisma Client might support marking individual views as materialized and add a Prisma Client method to refresh the materialized view. Please comment on our [`views` feedback issue](https://github.com/prisma/prisma/issues/17335) with your use case.
+
+## Limitations
+
+Prisma ORM treats all `view` blocks as _read-only_ representations of database queries rather than true tables. Because of this, several limitations apply to ensure Prisma Client remains consistent with the behavior of the underlying database.
+
+### No identifiers
+
+Views are virtual tables and do not have inherent primary keys. Hence, you cannot define `@id`, `@@id` attributes on a `view` block.
+
+### No indexes
+
+Because views are virtual tables, they cannot have indexes. Therefore, `@index` and `@@index` cannot be defined on `view` blocks.
+
+### Unsafe `@unique` attributes
+
+While Prisma ORM lets you place `@unique` and `@@unique` attributes on views, the underlying database and Prisma do not enforce those constraints. Multiple rows can therefore share the same value for a supposedly unique field.
+
+Neither the database nor Prisma ORM enforce the unique constraint expressed by that attribute.
+
+The purpose of the `@unique` attribute in this case is only to enable relationships across views as well as `findUnique` queries and cursor-based pagination in Prisma Client.
+
+### Disabled write queries
+
+All write operations (`create`, `update`, `delete`, `upsert`) are disabled and not generated in the Prisma Client.
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/50-database-mapping.mdx b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/50-database-mapping.mdx
new file mode 100644
index 0000000000..0bd8d6550c
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/50-database-mapping.mdx
@@ -0,0 +1,230 @@
+---
+title: 'Database mapping'
+metaTitle: 'Database mapping'
+metaDescription: 'Database mapping in Prisma schema'
+tocDepth: 3
+---
+
+The [Prisma schema](/orm/prisma-schema) includes mechanisms that allow you to define names of certain database objects. You can:
+
+- [Map model and field names to different collection/table and field/column names](#mapping-collectiontable-and-fieldcolumn-names)
+- [Define constraint and index names](#constraint-and-index-names)
+
+## Mapping collection/table and field/column names
+
+Sometimes the names used to describe entities in your database might not match the names you would prefer in your generated API. Mapping names in the Prisma schema allows you to influence the naming in your Client API without having to change the underlying database names.
+
+A common approach for naming tables/collections in databases for example is to use plural form and [snake_case](https://en.wikipedia.org/wiki/Snake_case) notation. However, we recommended a different [naming convention (singular form, PascalCase)](/orm/reference/prisma-schema-reference#naming-conventions).
+
+`@map` and `@@map` allow you to [tune the shape of your Prisma Client API](/orm/prisma-client/setup-and-configuration/custom-model-and-field-names) by decoupling model and field names from table and column names in the underlying database.
+
+### Map collection / table names
+
+As an example, when you [introspect](/orm/prisma-schema/introspection) a database with a table named `comments`, the resulting Prisma model will look like this:
+
+```prisma
+model comments {
+ // Fields
+}
+```
+
+However, you can still choose `Comment` as the name of the model (e.g. to follow the naming convention) without renaming the underlying `comments` table in the database by using the [`@@map`](/orm/reference/prisma-schema-reference#map-1) attribute:
+
+```prisma highlight=4;normal
+model Comment {
+ // Fields
+
+ //highlight-next-line
+ @@map("comments")
+}
+```
+
+With this modified model definition, Prisma Client automatically maps the `Comment` model to the `comments` table in the underlying database.
+
+### Map field / column names
+
+You can also [`@map`](/orm/reference/prisma-schema-reference#map) a column/field name:
+
+```prisma highlight=2-4;normal
+model Comment {
+ //highlight-start
+ content String @map("comment_text")
+ email String @map("commenter_email")
+ type Enum @map("comment_type")
+ //highlight-end
+
+ @@map("comments")
+}
+```
+
+This way the `comment_text` column is not available under `prisma.comment.comment_text` in the Prisma Client API, but can be accessed via `prisma.comment.content`.
+
+### Map enum names and values
+
+You can also `@map` an enum value, or `@@map` an enum:
+
+```prisma highlight=3,5;normal
+enum Type {
+ Blog,
+ //highlight-next-line
+ Twitter @map("comment_twitter")
+
+ //highlight-next-line
+ @@map("comment_source_enum")
+}
+```
+
+## Constraint and index names
+
+You can optionally use the `map` argument to explicitly define the **underlying constraint and index names** in the Prisma schema for the attributes [`@id`](/orm/reference/prisma-schema-reference#id), [`@@id`](/orm/reference/prisma-schema-reference#id-1), [`@unique`](/orm/reference/prisma-schema-reference#unique), [`@@unique`](/orm/reference/prisma-schema-reference#unique-1), [`@@index`](/orm/reference/prisma-schema-reference#index) and [`@relation`](/orm/reference/prisma-schema-reference#relation). (This is available in Prisma ORM version [2.29.0](https://github.com/prisma/prisma/releases/tag/2.29.0) and later.)
+
+When introspecting a database, the `map` argument will _only_ be rendered in the schema if the name _differs_ from Prisma ORM's [default constraint naming convention for indexes and constraints](#prisma-orms-default-naming-conventions-for-indexes-and-constraints).
+
+
+
+If you use Prisma Migrate in a version earlier than 2.29.0 and want to maintain your existing constraint and index names after upgrading to a newer version, **do not** immediately run `prisma migrate` or `prisma db push`. This will **change any underlying constraint name that does not follow Prisma ORM's convention**. Follow the [upgrade path that allows you to maintain existing constraint and index names](/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-3/named-constraints#option-1-i-want-to-maintain-my-existing-constraint-and-index-names).
+
+
+
+### Use cases for named constraints
+
+Some use cases for explicitly named constraints include:
+
+- Company policy
+- Conventions of other tools
+
+### Prisma ORM's default naming conventions for indexes and constraints
+
+Prisma ORM naming convention was chosen to align with PostgreSQL since it is deterministic. It also helps to maximize the amount of times where names do not need to be rendered because many databases out there they already align with the convention.
+
+Prisma ORM always uses the database names of entities when generating the default index and constraint names. If a model is remapped to a different name in the data model via `@@map` or `@map`, the default name generation will still take the name of the _table_ in the database as input. The same is true for fields and _columns_.
+
+| Entity | Convention | Example |
+| ----------------- | --------------------------------- | ------------------------------ |
+| Primary Key | \{tablename}\_pkey | `User_pkey` |
+| Unique Constraint | \{tablename}\_\{column_names}\_key | `User_firstName_last_Name_key` |
+| Non-Unique Index | \{tablename}\_\{column_names}\_idx | `User_age_idx` |
+| Foreign Key | \{tablename}\_\{column_names}\_fkey | `User_childName_fkey` |
+
+Since most databases have a length limit for entity names, the names will be trimmed if necessary to not violate the database limits. We will shorten the part before the `_suffix` as necessary so that the full name is at most the maximum length permitted.
+
+### Using default constraint names
+
+When no explicit names are provided via `map` arguments Prisma ORM will generate index and constraint names following the [default naming convention](#prisma-orms-default-naming-conventions-for-indexes-and-constraints).
+
+If you introspect a database the names for indexes and constraints will be added to your schema unless they follow Prisma ORM's naming convention. If they do, the names are not rendered to keep the schema more readable. When you migrate such a schema Prisma will infer the default names and persist them in the database.
+
+#### Example
+
+The following schema defines three constraints (`@id`, `@unique`, and `@relation`) and one index (`@@index`):
+
+```prisma highlight=2,8,11,13;normal
+model User {
+ //highlight-next-line
+ id Int @id @default(autoincrement())
+ name String @unique
+ posts Post[]
+}
+
+model Post {
+ //highlight-next-line
+ id Int @id @default(autoincrement())
+ title String
+ authorName String @default("Anonymous")
+ //highlight-next-line
+ author User? @relation(fields: [authorName], references: [name])
+
+ //highlight-next-line
+ @@index([title, authorName])
+}
+```
+
+Since no explicit names are provided via `map` arguments Prisma will assume they follow our default naming convention.
+
+The following table lists the name of each constraint and index in the underlying database:
+| Constraint or index | Follows convention | Underlying constraint or index names |
+| ---------------------------------- | ------------------ | ------------------------------------ |
+| `@id` (on `User` > `id` field) | Yes | `User_pk` |
+| `@@index` (on `Post`) | Yes | `Post_title_authorName_idx` |
+| `@id` (on `Post` > `id` field) | Yes | `Post_pk` |
+| `@relation` (on `Post` > `author`) | Yes | `Post_authorName_fkey` |
+
+### Using custom constraint / index names
+
+You can use the `map` argument to define **custom constraint and index names** in the underlying database.
+
+#### Example
+
+The following example adds custom names to one `@id` and the `@@index`:
+
+```prisma highlight=2,13;normal
+model User {
+ //highlight-next-line
+ id Int @id(map: "Custom_Primary_Key_Constraint_Name") @default(autoincrement())
+ name String @unique
+ posts Post[]
+}
+
+model Post {
+ //highlight-next-line
+ id Int @id @default(autoincrement())
+ title String
+ authorName String @default("Anonymous")
+ //highlight-next-line
+ author User? @relation(fields: [authorName], references: [name])
+
+ //highlight-next-line
+ @@index([title, authorName], map: "My_Custom_Index_Name")
+}
+```
+
+The following table lists the name of each constraint and index in the underlying database:
+
+| Constraint or index | Follows convention | Underlying constraint or index names |
+| ---------------------------------- | ------------------ | ------------------------------------ |
+| `@id` (on `User` > `id` field) | No | `Custom_Primary_Key_Constraint_Name` |
+| `@@index` (on `Post`) | No | `My_Custom_Index_Name` |
+| `@id` (on `Post` > `id` field) | Yes | `Post_pk` |
+| `@relation` (on `Post` > `author`) | Yes | `Post_authorName_fkey` |
+
+### Related: Naming indexes and primary keys for Prisma Client
+
+Additionally to `map`, the `@@id` and `@@unique` attributes take an optional `name` argument that allows you to customize your Prisma Client API.
+
+On a model like:
+
+```prisma
+model User {
+ firstName String
+ lastName String
+
+ @@id([firstName, lastName])
+}
+```
+
+the default API for selecting on that primary key uses a generated combination of the fields:
+
+```ts
+const user = await prisma.user.findUnique({
+ where: {
+ firstName_lastName: {
+ firstName: 'Paul',
+ lastName: 'Panther',
+ },
+ },
+})
+```
+
+Specifying `@@id([firstName, lastName], name: "fullName")` will change the Prisma Client API to this instead:
+
+```ts highlight=3;edit
+const user = await prisma.user.findUnique({
+ where: {
+ //edit-next-line
+ fullName: {
+ firstName: 'Paul',
+ lastName: 'Panther',
+ },
+ },
+})
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/60-multi-schema.mdx b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/60-multi-schema.mdx
new file mode 100644
index 0000000000..213aca8ec7
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/60-multi-schema.mdx
@@ -0,0 +1,175 @@
+---
+title: Multi-schema
+metaTitle: How to use Prisma ORM with multiple database schemas
+metaDescription: How to use Prisma ORM with multiple database schemas
+---
+
+## Overview
+
+PostgreSQL, CockroachDB, and SQL Server allow you to organize database tables into named groups. These groups are known as _schemas_ and act as a _namespace_ for logically grouping tables (e.g. to avoid name collisions or to have clearer domain separation) and let you define foreign key constraints across them. To avoid ambiguity, this page will refer to these namespaces as _database schemas_.
+
+This page explains how to:
+- include multiple database schemas in your Prisma schema
+- apply your schema changes to your database with Prisma Migrate
+- introspect an existing database with multiple database schemas
+- query across multiple database schemas with Prisma Client
+
+:::note
+
+Multi-schema feature is only supported for PostgreSQL, CockroachDB, and SQL Server. It is not available for SQLite and MySQL because these databases don't have the same concept of _schemas as namespaces_.
+
+:::
+
+
+## How to include multiple database schemas in your Prisma schema
+
+To use multiple database schemas in your Prisma schema file, add the names of your database schemas to an array in the `schemas` field, in the `datasource` block. The following example adds a `"base"` and a `"shop"` schema:
+
+```prisma file=schema.prisma
+generator client {
+ provider = "prisma-client"
+}
+
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+ //add-next-line
+ schemas = ["base", "shop"]
+}
+```
+
+You do not need to change your connection string. The `schema` value of your connection string is the default database schema that Prisma Client connects to and uses for raw queries. All other Prisma Client queries use the schema of the model or enum that you are querying.
+
+To designate that a model or enum belongs to a specific database schema, add the `@@schema` attribute with the name of the database schema as a parameter. In the following example, the `User` model is part of the `"base"` schema, and the `Order` model and `Size` enum are part of the `"shop"` schema:
+
+```prisma file=schema.prisma
+model User {
+ id Int @id
+ orders Order[]
+
+ //add-next-line
+ @@schema("base")
+}
+
+model Order {
+ id Int @id
+ user User @relation(fields: [userId], references: [id])
+ userId Int
+
+ //add-next-line
+ @@schema("shop")
+}
+
+enum Size {
+ Small
+ Medium
+ Large
+
+ //add-next-line
+ @@schema("shop")
+}
+```
+
+### Tables with the same name in different database schemas
+
+If you have tables with the same name in different database schemas, you will need to map the table names to unique model names in your Prisma schema. This avoids name conflicts when you query models in Prisma Client.
+
+For example, consider a situation where the `Config` table in the `base` database schema has the same name as the `Config` table in the `users` database schema. To avoid name conflicts, give the models in your Prisma schema unique names (`BaseConfig` and `UserConfig`) and use the `@@map` attribute to map each model to the corresponding table name:
+
+```prisma file=schema.prisma
+model BaseConfig {
+ id Int @id
+
+ @@map("Config")
+ @@schema("base")
+}
+
+model UserConfig {
+ id Int @id
+
+ @@map("Config")
+ @@schema("users")
+}
+```
+
+## How to apply your schema changes with Prisma Migrate
+
+You can use Prisma Migrate (or `prisma db push`) to apply changes to a Prisma schema with multiple database schemas.
+
+As an example, add a `Profile` model to the `base` schema above:
+
+```prisma file=schema.prisma
+model User {
+ id Int @id
+ orders Order[]
+ //add-next-line
+ profile Profile?
+
+ @@schema("base")
+}
+
+//add-start
+model Profile {
+ id Int @id @default(autoincrement())
+ bio String
+ user User @relation(fields: [userId], references: [id])
+ userId Int @unique
+
+ @@schema("base")
+}
+//add-end
+
+model Order {
+ id Int @id
+ user User @relation(fields: [userId], references: [id])
+ userId Int
+
+ @@schema("shop")
+}
+
+enum Size {
+ Small
+ Medium
+ Large
+
+ @@schema("shop")
+}
+```
+
+You can then apply this schema change to your database. For example, you can use `migrate dev` to create and apply your schema changes as a migration:
+
+```terminal
+npx prisma migrate dev --name add_profile
+```
+
+Note that if you move a model or enum from one schema to another, Prisma ORM deletes the model or enum from the source schema and creates a new one in the target schema.
+
+## How to introspect an existing database with multiple database schemas
+
+You can introspect an existing database that has multiple database schemas in the same way that you introspect a database that has a single database schema, using `prisma db pull`:
+
+```terminal
+npx prisma db pull
+```
+
+This updates your Prisma schema to match the current state of the database.
+
+If you have tables with the same name in different database schemas, Prisma ORM shows a validation error pointing out the conflict. To fix this, [rename the introspected models with the `@map` attribute](#tables-with-the-same-name-in-different-database-schemas).
+
+## How to query across multiple database schemas with Prisma Client
+
+You can query models in multiple database schemas without any change to your Prisma Client query syntax. For example, the following query finds all orders for a given user, using the Prisma schema above:
+
+```ts
+const orders = await prisma.order.findMany({
+ where: {
+ user: {
+ id: 42,
+ },
+ },
+})
+```
+
+### Externally managed tables
+
+Sometimes, you might not want Prisma ORM to manage specific tables, such as ones handled by another team or service (e.g., Auth0 or Clerk tables). In such cases, you can mark these as **externally managed tables** using the `tables.external` configuration option in your [Prisma Config file](/orm/reference/prisma-config-reference#tablesexternal-and-enumsexternal). Learn more about [externally managed tables](/orm/prisma-schema/data-model/externally-managed-tables).
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/65-externally-managed-tables.mdx b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/65-externally-managed-tables.mdx
new file mode 100644
index 0000000000..05851a8b33
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/65-externally-managed-tables.mdx
@@ -0,0 +1,298 @@
+---
+title: External tables
+metaTitle: Externally managed tables
+metaDescription: How to declare and use externally managed tables in Prisma ORM
+sidebar_class_name: preview-badge
+---
+
+## Overview
+
+
+_Externally managed tables_ (or _external tables_ for short) in Prisma ORM are tables that can be **queried via Prisma Client** but are **ignored by Prisma Migrate**.
+
+Sometimes, you might not want Prisma ORM to manage specific tables—such as ones handled by another team or service.
+
+Some concrete use cases for this are:
+- auth services like Clerk or Auth0 that manage specific tables with user and session data
+- storage services like Supabase Storage with tables for storing metadata about buckets and objects
+- a microservice-based organization where specific teams own specific tables in the database
+
+There may be many other scenarios based on custom organizational constraints or preferences where you may not want Prisma ORM to manage specific tables.
+
+:::warning
+Externally managed tables are currently in [Preview](/orm/more/releases#preview).
+:::
+
+:::note
+Externally managed tables are frequently used in combination with [multi-schema](/orm/prisma-schema/data-model/multi-schema) database setups. However, this is not a hard requirement. You can have only a single schema in your database and also declare externally managed tables within it.
+:::
+
+:::warning
+Prisma ORM will not verify that the structure of the tables in the database and the structures of the Prisma models actually match.
+On the one hand, it requires the developer to be thorough when updating the Prisma schema (the safest way to do it is by using `prisma db pull`).
+On the other hand, this flexibility enables you to represent only part of the underlying table in the database (and e.g. not expose _all_ its columns).
+:::
+
+## Workflow
+
+If you want to use external tables, here's the main workflow:
+1. Declare the name of the external tables in your [Prisma Config file](/orm/reference/prisma-config-reference)
+1. Update your Prisma schema (e.g. via `npx prisma db pull`)
+1. Re-generate Prisma Client with `npx prisma generate`
+1. You can now query the external table using Prisma Client but it will be ignored by Prisma Migrate
+1. When the table gets changed (by whoever owns it):
+ 1. Re-introspect your database using `npx prisma db pull` or manually update the models in your prisma file
+ 1. Re-generate Prisma Client with `npx prisma generate`
+
+## Prisma Config syntax
+
+You can specify externally managed tables in your [Prisma Config](/orm/reference/prisma-config-reference) file via the `tables.external` property:
+
+```ts file=prisma.config.ts
+export default defineConfig({
+ // required when using unstable features
+ experimental: {
+ // add-next-line
+ externalTables: true
+ },
+ // declare the `users` table and `role` enum as external
+ // add-start
+ tables: {
+ external: [
+ "public.users",
+ ]
+ },
+ enums: {
+ external: [
+ "public.role",
+ ]
+ },
+ // add-end
+})
+```
+
+- Analogous to tables, you can also have externally managed _enums_.
+- On PostgreSQL and SQL Server you have to specify the fully qualified table/enum name including the schema name. For example: `public.products` or `auth.users`.
+- On MySQL and SQLite, you only have to specify the table name.
+
+## Relationships
+
+Prisma can create and update relationships from tables it manages to externally managed tables.
+
+However, for this Prisma needs to be aware of the structure of those externally managed tables during migration creation.
+You can provide a SQL script that Prisma will run on its [shadow database](/orm/prisma-migrate/understanding-prisma-migrate/shadow-database) ahead of all migrations to emulate the external tables and enums during migration creation.
+
+The created placeholder table does not need to have the full structure of the actual table but primary keys need to be present.
+
+If the external table is not referenced by any managed table—that is no managed table contains a foreign key constraint on the external table—you do NOT need to provide any SQL for it in `migrations.initShadowDb`.
+
+
+```ts file=prisma.config.ts
+export default defineConfig({
+ // required when using unstable features
+ experimental: {
+ // add-next-line
+ externalTables: true
+ },
+ // add-start
+ // declare a `users` table
+ tables: {
+ external: [
+ "public.users",
+ ]
+ },
+ migrations: {
+ // setup the users table for the shadow database
+ initShadowDb: `
+ CREATE TABLE public.users (id SERIAL PRIMARY KEY);
+ `
+ },
+ // add-end
+})
+```
+
+Relationships from an external table to a managed table, where the external table contains the foreign key constraint on the managed table, are **NOT** managed by Prisma as that would modify the external table.
+
+## Example
+
+Assume you have the following Prisma schema which only contains the `posts` table:
+
+```prisma
+generator client {
+ provider = "prisma-client-js"
+ // ...
+}
+
+datasource db {
+ provider = "postgresql"
+ // ...
+}
+
+model posts {
+ id Int @id @default(autoincrement())
+ created_at DateTime @default(now())
+ title String
+ content String?
+}
+```
+
+You have created that `posts` table already via a prior migration.
+You now also have a `users` table and `role` enum in your database which you want to treat as externally managed.
+
+So the tables in your PostgreSQL database in the default `public` schema look like this:
+
+```sql
+-- Enum used by users table
+CREATE TYPE role AS ENUM ('customer', 'support', 'admin');
+
+-- Users table
+CREATE TABLE users (
+ id SERIAL PRIMARY KEY,
+ username VARCHAR(50) NOT NULL UNIQUE,
+ email VARCHAR(100) NOT NULL UNIQUE,
+ created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
+ role role
+);
+
+-- Posts table
+CREATE TABLE posts (
+ id SERIAL PRIMARY KEY,
+ created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
+ title VARCHAR(200) NOT NULL,
+ content TEXT
+);
+```
+
+### 1. Declaring externally managed tables in Prisma Config
+
+Enable use of externally managed tables via the `tables.external` property:
+
+```ts file=prisma.config.ts
+export default defineConfig({
+ experimental: {
+ // add-next-line
+ externalTables: true
+ },
+ // declare the `users` table and `role` enum as external
+ // add-start
+ tables: {
+ external: [
+ "public.users",
+ ]
+ },
+ enums: {
+ external: [
+ "public.role",
+ ]
+ },
+ // add-end
+})
+```
+
+### 2. Update the Prisma schema
+
+Next, you need to update your Prisma schema. You can do this either:
+- by manually creating the models
+- or by using [introspection](/orm/prisma-schema/introspection):
+
+```terminal
+npx prisma db pull
+```
+
+The `users` table is now in your Prisma schema:
+
+```prisma
+model posts {
+ id Int @id @default(autoincrement())
+ created_at DateTime? @default(now()) @db.Timestamp(6)
+ title String @db.VarChar(200)
+ content String?
+}
+
+// highlight-start
+model users {
+ id Int @id @default(autoincrement())
+ username String @unique @db.VarChar(50)
+ email String @unique @db.VarChar(100)
+ created_at DateTime? @default(now()) @db.Timestamp(6)
+ role role
+}
+
+enum role {
+ customer
+ support
+ admin
+}
+// highlight-end
+```
+
+### 3. Re-generate Prisma Client
+
+In order to be able to query the `users` table, you need to re-generate Prisma Client:
+
+```terminal
+npx prisma generate
+```
+
+### 4. Query the `users` table using Prisma Client
+
+You can now query the external `users` table with Prisma Client:
+
+```ts
+await prisma.users.findMany()
+```
+
+### 5. Add a relationship
+
+Let's say you now want to add an author relationship from `posts` onto `users`.
+
+First update your Prisma schema.
+
+```prisma
+model posts {
+ id Int @id @default(autoincrement())
+ created_at DateTime? @default(now()) @db.Timestamp(6)
+ title String @db.VarChar(200)
+ content String?
+ // add-start
+ author users @relation(fields: [author_id], references: [id])
+ author_id Int
+ // add-end
+}
+
+model users {
+ id Int @id @default(autoincrement())
+ username String @unique @db.VarChar(50)
+ email String @unique @db.VarChar(100)
+ created_at DateTime? @default(now()) @db.Timestamp(6)
+ role role
+ // add-start
+ posts posts[]
+ // add-end
+}
+
+enum role {
+ customer
+ support
+ admin
+}
+```
+
+Then add a `migrations.initShadowDb` script so Prisma knows about the `users` table during migrations.
+
+```ts
+// prisma.config.ts
+export default defineConfig({
+ // ...
+ // add-start
+ migrations: {
+ // setup the users table for the shadow database
+ initShadowDb: `
+ CREATE TABLE public.users (id SERIAL PRIMARY KEY);
+ `
+ },
+ // add-end
+})
+```
+
+Now you can run `prisma migrate dev` command.
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/70-unsupported-database-features.mdx b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/70-unsupported-database-features.mdx
new file mode 100644
index 0000000000..5c5476d85c
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/70-unsupported-database-features.mdx
@@ -0,0 +1,105 @@
+---
+title: 'Unsupported database features (Prisma Schema)'
+sidebar_label: 'Unsupported database features'
+metaTitle: 'Prisma schema: Unsupported database features'
+metaDescription: 'How to support database features that do not have an equivalent syntax in Prisma Schema Language.'
+tocDepth: 2
+toc_max_heading_level: 2
+---
+
+
+
+Not all database functions and features of Prisma ORM's supported databases have a Prisma Schema Language equivalent. Refer to the [database features matrix](/orm/reference/database-features) for a complete list of supported features.
+
+
+
+## Native database functions
+
+Prisma Schema Language supports several [functions](/orm/reference/prisma-schema-reference#attribute-functions) that you can use to set the default value of a field. The following example uses the Prisma ORM-level `uuid()` function to set the value of the `id` field:
+
+```prisma
+model Post {
+ id String @id @default(uuid())
+}
+```
+
+However, you can also use **native database functions** to define default values with [`dbgenerated(...)`](/orm/reference/prisma-schema-reference#dbgenerated) on relational databases (MongoDB does not have the concept of database-level functions). The following example uses the PostgreSQL `gen_random_uuid()` function to populate the `id` field:
+
+```prisma
+model User {
+ id String @id @default(dbgenerated("gen_random_uuid()")) @db.Uuid
+}
+```
+
+### When to use a database-level function
+
+There are two reasons to use a database-level function:
+
+- There is no equivalent Prisma ORM function (for example, `gen_random_bytes` in PostgreSQL).
+- You cannot or do not want to rely on functions such `uuid()` and `cuid()`, which are only implemented at a Prisma ORM level and do not manifest in the database.
+
+ Consider the following example, which sets the `id` field to a randomly generated `UUID`:
+
+ ```prisma
+ model Post {
+ id String @id @default(uuid())
+ }
+ ```
+
+ The UUID is _only_ generated if you use Prisma Client to create the `Post`. If you create posts in any other way, such as a bulk import script written in plain SQL, you must generate the UUID yourself.
+
+### Enable PostgreSQL extensions for native database functions
+
+In PostgreSQL, some native database functions are part of an extension. For example, in PostgreSQL versions 12.13 and earlier, the `gen_random_uuid()` function is part of the [`pgcrypto`](https://www.postgresql.org/docs/10/pgcrypto.html) extension.
+
+To use a PostgreSQL extension, you must first install it on the file system of your database server.
+
+In Prisma ORM versions 4.5.0 and later, you can then activate the extension by declaring it in your Prisma schema with the [`postgresqlExtensions` preview feature](/orm/prisma-schema/postgresql-extensions):
+
+```prisma file=schema.prisma highlight=3,9;add showLineNumbers
+generator client {
+ provider = "prisma-client-js"
+ //add-next-line
+ previewFeatures = ["postgresqlExtensions"]
+}
+
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+ //add-next-line
+ extensions = [pgcrypto]
+}
+```
+
+In earlier versions of Prisma ORM, you must instead run a SQL command to activate the extension:
+
+```sql
+CREATE EXTENSION IF NOT EXISTS pgcrypto;
+```
+
+If your project uses [Prisma Migrate](/orm/prisma-migrate), you must [install the extension as part of a migration](/orm/prisma-migrate/workflows/native-database-functions) . Do not install the extension manually, because it is also required by the shadow database.
+
+Prisma Migrate returns the following error if the extension is not available:
+
+```
+Migration `20210221102106_failed_migration` failed to apply cleanly to a temporary database.
+Database error: Error querying the database: db error: ERROR: type "pgcrypto" does not exist
+```
+
+## Unsupported field types
+
+Some database types of relational databases, such as `polygon` or `geometry`, do not have a Prisma Schema Language equivalent. Use the [`Unsupported`](/orm/reference/prisma-schema-reference#unsupported) field type to represent the field in your Prisma schema:
+
+```prisma highlight=3;normal
+model Star {
+ id Int @id @default(autoincrement())
+ //highlight-next-line
+ position Unsupported("circle")? @default(dbgenerated("'<(10,4),11>'::circle"))
+}
+```
+
+The `prisma migrate dev` and `prisma db push` command will both create a `position` field of type `circle` in the database. However, the field will not be available in the generated Prisma Client.
+
+## Unsupported database features
+
+Some features, like SQL views or partial indexes, cannot be represented in the Prisma schema. If your project uses [Prisma Migrate](/orm/prisma-migrate), you must [include unsupported features as part of a migration](/orm/prisma-migrate/workflows/unsupported-database-features) .
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/80-table-inheritance.mdx b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/80-table-inheritance.mdx
new file mode 100644
index 0000000000..5824300c6b
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/80-table-inheritance.mdx
@@ -0,0 +1,328 @@
+---
+title: Table inheritance
+metaTitle: Table inheritance
+metaDescription: Learn about the use cases and patterns for table inheritance in Prisma ORM that enable usage of union types or polymorphic structures in your application.
+tocDepth: 3
+---
+
+## Overview
+
+Table inheritance is a software design pattern that allows the modeling of hierarchical relationships between entities. Using table inheritance on the database level can also enable the use of union types in your JavaScript/TypeScript application or share a set of common properties across multiple models.
+
+This page introduces two approaches to table inheritance and explains how to use them with Prisma ORM.
+
+A common use case for table inheritance may be when an application needs to display a _feed_ of some kind of _content activities_. A content activity in this case, could be a _video_ or an _article_. As an example, let's assume that:
+
+- a content activity always has an `id` and a `url`
+- in addition to `id` and a `url`, a video also has a `duration` (modeled as an `Int`)
+- in addition to `id` and a `url`, an article also a `body` (modeled as a `String`)
+
+### Use cases
+
+#### Union types
+
+Union types are a convenient feature in TypeScript that allows developers to work more flexibly with the types in their data model.
+
+In TypeScript, union types look as follows:
+
+```ts no-copy
+type Activity = Video | Article
+```
+
+While [it's currently not possible to model union types in the Prisma schema](https://github.com/prisma/prisma/issues/2505), you can use them with Prisma ORM by using table inheritance and some additional type definitions.
+
+#### Sharing properties across multiple models
+
+If you have a use case where multiple models should share a particular set of properties, you can model this using table inheritance as well.
+
+For example, if both the `Video` and `Article` models from above should have a shared `title` property, you can achieve this with table inheritance as well.
+
+### Example
+
+In a simple Prisma schema, this would look as follows. Note that we're adding a `User` model as well to illustrate how this can work with relations:
+
+```prisma file=schema.prisma showLineNumbers
+model Video {
+ id Int @id
+ url String @unique
+ duration Int
+
+ user User @relation(fields: [userId], references: [id])
+ userId Int
+}
+
+model Article {
+ id Int @id
+ url String @unique
+ body String
+
+ user User @relation(fields: [userId], references: [id])
+ userId Int
+}
+
+model User {
+ id Int @id
+ name String
+ videos Video[]
+ articles Article[]
+}
+```
+
+Let's investigate how we can model this using table inheritance.
+
+### Single-table vs multi-table inheritance
+
+Here is a quick comparison of the two main approaches for table inheritance:
+
+- **Single-table inheritance (STI)**: Uses a _single_ table to store data of _all_ the different entities in one location. In our example, there'd be a single `Activity` table with the `id`, `url` as well as the `duration` and `body` column. It also uses a `type` column that indicates whether an _activity_ is a _video_ or an _article_.
+- **Multi-table inheritance (MTI)**: Uses _multiple_ tables to store the data of the different entities separately and links them via foreign keys. In our example, there'd be an `Activity` table with the `id`, `url` column, a `Video` table with the `duration` and a foreign key to `Activity` as well as an `Article` table with the `body` and a foreign key. There is also a `type` column that acts as a discriminator and indicates whether an _activity_ is a _video_ or an _article_. Note that multi-table inheritance is also sometimes called _delegated types_.
+
+You can learn about the tradeoffs of both approaches [below](#tradeoffs-between-sti-and-mti).
+
+## Single-table inheritance (STI)
+
+### Data model
+
+Using STI, the above scenario can be modeled as follows:
+
+```prisma
+model Activity {
+ id Int @id // shared
+ url String @unique // shared
+ duration Int? // video-only
+ body String? // article-only
+ type ActivityType // discriminator
+
+ owner User @relation(fields: [ownerId], references: [id])
+ ownerId Int
+}
+
+enum ActivityType {
+ Video
+ Article
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ name String?
+ activities Activity[]
+}
+```
+
+A few things to note:
+
+- The model-specific properties `duration` and `body` must be marked as optional (i.e., with `?`). That's because a record in the `Activity` table that represents a _video_ must not have a value for `body`. Conversely, an `Activity` record representing an _article_ can never have a `duration` set.
+- The `type` discriminator column indicates whether each record represents a _video_ or an _article_ item.
+
+### Prisma Client API
+
+Due to how Prisma ORM generates types and an API for the data model, there will only to be an `Activity` type and the CRUD queries that belong to it (`create`, `update`, `delete`, ...) available to you.
+
+#### Querying for videos and articles
+
+You can now query for only _videos_ or _articles_ by filtering on the `type` column. For example:
+
+```ts
+// Query all videos
+const videos = await prisma.activity.findMany({
+ where: { type: 'Video' },
+})
+
+// Query all articles
+const articles = await prisma.activity.findMany({
+ where: { type: 'Article' },
+})
+```
+
+#### Defining dedicated types
+
+When querying for videos and articles like that, TypeScript will still only recognize an `Activity` type. That can be annoying because even the objects in `videos` will have (optional) `body` and the objects in `articles` will have (optional) `duration` fields.
+
+If you want to have type safety for these objects, you need to define dedicated types for them. You can do this, for example, by using the generated `Activity` type and the TypeScript `Omit` utility type to remove properties from it:
+
+```ts
+import { Activity } from '@prisma/client'
+
+type Video = Omit
+type Article = Omit
+```
+
+In addition, it will be helpful to create mapping functions that convert an object of type `Activity` to the `Video` and `Article` types:
+
+```ts
+function activityToVideo(activity: Activity): Video {
+ return {
+ url: activity.url,
+ duration: activity.duration ? activity.duration : -1,
+ ownerId: activity.ownerId,
+ } as Video
+}
+
+function activityToArticle(activity: Activity): Article {
+ return {
+ url: activity.url,
+ body: activity.body ? activity.body : '',
+ ownerId: activity.ownerId,
+ } as Article
+}
+```
+
+Now you can turn an `Activity` into a more specific type (i.e., `Article` or `Video`) after querying:
+
+```ts
+const videoActivities = await prisma.activity.findMany({
+ where: { type: 'Video' },
+})
+const videos: Video[] = videoActivities.map(activityToVideo)
+```
+
+#### Using Prisma Client extension for a more convenient API
+
+You can use [Prisma Client extensions](/orm/prisma-client/client-extensions) to create a more convenient API for the table structures in your database.
+
+## Multi-table inheritance (MTI)
+
+### Data model
+
+Using MTI, the above scenario can be modeled as follows:
+
+```prisma
+model Activity {
+ id Int @id @default(autoincrement())
+ url String // shared
+ type ActivityType // discriminator
+
+ video Video? // model-specific 1-1 relation
+ article Article? // model-specific 1-1 relation
+
+ owner User @relation(fields: [ownerId], references: [id])
+ ownerId Int
+}
+
+model Video {
+ id Int @id @default(autoincrement())
+ duration Int // video-only
+ activityId Int @unique
+ activity Activity @relation(fields: [activityId], references: [id])
+}
+
+model Article {
+ id Int @id @default(autoincrement())
+ body String // article-only
+ activityId Int @unique
+ activity Activity @relation(fields: [activityId], references: [id])
+}
+
+enum ActivityType {
+ Video
+ Article
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ name String?
+ activities Activity[]
+}
+```
+
+A few things to note:
+
+- A 1-1 relation is needed between `Activity` and `Video` as well as `Activity` and `Article`. This relationship is used to fetch the specific information about a record when needed.
+- The model-specific properties `duration` and `body` can be made _required_ with this approach.
+- The `type` discriminator column indicates whether each record represents a _video_ or an _article_ item.
+
+### Prisma Client API
+
+This time, you can query for videos and articles directly via the `video` and `article` properties on your `PrismaClient` instance.
+
+#### Querying for videos and articles
+
+If you want to access the shared properties, you need to use `include` to fetch the relation to `Activity`.
+
+```ts
+// Query all videos
+const videos = await prisma.video.findMany({
+ include: { activity: true },
+})
+
+// Query all articles
+const articles = await prisma.article.findMany({
+ include: { activity: true },
+})
+```
+
+Depending on your needs, you may also query the other way around by filtering on the `type` discriminator column:
+
+```ts
+// Query all videos
+const videoActivities = await prisma.activity.findMany({
+ where: { type: 'Video' }
+ include: { video: true }
+})
+```
+
+#### Defining dedicated types
+
+While a bit more convenient in terms of types compared to STI, the generated typings likely still won't fit all your needs.
+
+Here's how you can define `Video` and `Article` types by combining Prisma ORM's generated `Video` and `Article` types with the `Activity` type. These combinations create a new type with the desired properties. Note that we're also omitting the `type` discriminator column because that's not needed anymore on the specific types:
+
+```ts
+import {
+ Video as VideoDB,
+ Article as ArticleDB,
+ Activity,
+} from '@prisma/client'
+
+type Video = Omit
+type Article = Omit
+```
+
+Once these types are defined, you can define mapping functions to convert the types you receive from the queries above into the desired `Video` and `Article` types. Here's the example for the `Video` type:
+
+```ts
+import { Prisma, Video as VideoDB, Activity } from '@prisma/client'
+
+type Video = Omit
+
+// Create `VideoWithActivity` typings for the objects returned above
+const videoWithActivity = Prisma.validator()({
+ include: { activity: true },
+})
+type VideoWithActivity = Prisma.VideoGetPayload
+
+// Map to `Video` type
+function toVideo(a: VideoWithActivity): Video {
+ return {
+ id: a.id,
+ url: a.activity.url,
+ ownerId: a.activity.ownerId,
+ duration: a.duration,
+ activityId: a.activity.id,
+ }
+}
+```
+
+Now you can take the objects returned by the queries above and transform them using `toVideo`:
+
+```ts
+const videoWithActivities = await prisma.video.findMany({
+ include: { activity: true },
+})
+const videos: Video[] = videoWithActivities.map(toVideo)
+```
+
+#### Using Prisma Client extension for a more convenient API
+
+You can use [Prisma Client extensions](/orm/prisma-client/client-extensions) to create a more convenient API for the table structures in your database.
+
+## Tradeoffs between STI and MTI
+
+- **Data model**: The data model may feel more clean with MTI. With STI, you may end up with very wide rows and lots of columns that have `NULL` values in them.
+- **Performance**: MTI may come with a performance cost because you need to join the parent and child tables to access _all_ properties relevant for a model.
+- **Typings**: With Prisma ORM, MTI gives you proper typings for the specific models (i.e., `Article` and `Video` in the examples above) already, while you need to create these from scratch with STI.
+- **IDs / Primary keys**: With MTI, records have two IDs (one on the parent and another on the child table) that may not match. You need to consider this in the business logic of your application.
+
+## Third-party solutions
+
+While Prisma ORM doesn't natively support union types or polymorphism at the moment, you can check out [Zenstack](https://github.com/zenstackhq/zenstack) which is adding an extra layer of features to the Prisma schema. Read their [blog post about polymorphism in Prisma ORM](https://zenstack.dev/blog/polymorphism) to learn more.
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/index.mdx b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/index.mdx
new file mode 100644
index 0000000000..ba1ec9f4d5
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/20-data-model/index.mdx
@@ -0,0 +1,10 @@
+---
+title: 'Data model'
+metaTitle: 'Data model'
+metaDescription: 'Learn everything you need about the Prisma schema data model.'
+hide_table_of_contents: true
+---
+
+## In this section
+
+
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/50-introspection.mdx b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/50-introspection.mdx
new file mode 100644
index 0000000000..8d64093664
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/50-introspection.mdx
@@ -0,0 +1,394 @@
+---
+title: 'What is introspection?'
+sidebar_label: 'Introspection'
+metaTitle: 'What is introspection? (Reference)'
+metaDescription: 'Learn how you can introspect your database to generate a data model into your Prisma schema.'
+---
+
+You can introspect your database using the Prisma CLI in order to generate the [data model](/orm/prisma-schema/data-model) in your [Prisma schema](/orm/prisma-schema). The data model is needed to [generate Prisma Client](/orm/prisma-client/setup-and-configuration/custom-model-and-field-names).
+
+Introspection is often used to generate an _initial_ version of the data model when [adding Prisma ORM to an existing project](/getting-started/setup-prisma/add-to-existing-project/relational-databases-typescript-postgresql).
+
+However, it can also be [used _repeatedly_ in an application](#introspection-with-an-existing-schema). This is most commonly the case when you're _not_ using [Prisma Migrate](/orm/prisma-migrate) but perform schema migrations using plain SQL or another migration tool. In that case, you also need to re-introspect your database and subsequently re-generate Prisma Client to reflect the schema changes in your [Prisma Client API](/orm/prisma-client).
+
+## What does introspection do?
+
+Introspection has one main function: Populate your Prisma schema with a data model that reflects the current database schema.
+
+
+
+Here's an overview of its main functions on SQL databases:
+
+- Map _tables_ in the database to [Prisma models](/orm/prisma-schema/data-model/models#defining-models)
+- Map _columns_ in the database to the [fields](/orm/prisma-schema/data-model/models#defining-fields) of Prisma models
+- Map _indexes_ in the database to [indexes](/orm/prisma-schema/data-model/models#defining-an-index) in the Prisma schema
+- Map _database constraints_ to [attributes](/orm/prisma-schema/data-model/models#defining-attributes) or [type modifiers](/orm/prisma-schema/data-model/models#type-modifiers) in the Prisma schema
+
+On MongoDB, the main functions are the following:
+
+- Map _collections_ in the database to [Prisma models](/orm/prisma-schema/data-model/models#defining-models). Because a _collection_ in MongoDB doesn't have a predefined structure, Prisma ORM _samples_ the _documents_ in the collection and derives the model structure accordingly (i.e. it maps the fields of the _document_ to the [fields](/orm/prisma-schema/data-model/models#defining-fields) of the Prisma model). If _embedded types_ are detected in a collection, these will be mapped to [composite types](/orm/prisma-schema/data-model/models#defining-composite-types) in the Prisma schema.
+- Map _indexes_ in the database to [indexes](/orm/prisma-schema/data-model/models#defining-an-index) in the Prisma schema, if the collection contains at least one document contains a field included in the index
+
+You can learn more about how Prisma ORM maps types from the database to the types available in the Prisma schema on the respective docs page for the data source connector:
+
+- [PostgreSQL](/orm/overview/databases/postgresql#type-mapping-between-postgresql-and-prisma-schema)
+- [MySQL](/orm/overview/databases/mysql#type-mapping-between-mysql-to-prisma-schema)
+- [SQLite](/orm/overview/databases/sqlite#type-mapping-between-sqlite-to-prisma-schema)
+- [Microsoft SQL Server](/orm/overview/databases/sql-server#type-mapping-between-microsoft-sql-server-to-prisma-schema)
+
+## The `prisma db pull` command
+
+You can introspect your database using the `prisma db pull` command of the [Prisma CLI](/orm/tools/prisma-cli#installation). Note that using this command requires your [connection URL](/orm/reference/connection-urls) to be set in your Prisma schema [`datasource`](/orm/prisma-schema/overview/data-sources).
+
+Here's a high-level overview of the steps that `prisma db pull` performs internally:
+
+1. Read the [connection URL](/orm/reference/connection-urls) from the `datasource` configuration in the Prisma schema
+1. Open a connection to the database
+1. Introspect database schema (i.e. read tables, columns and other structures ...)
+1. Transform database schema into Prisma schema data model
+1. Write data model into Prisma schema or [update existing schema](#introspection-with-an-existing-schema)
+
+## Introspection workflow
+
+The typical workflow for projects that are not using Prisma Migrate, but instead use plain SQL or another migration tool looks as follows:
+
+1. Change the database schema (e.g. using plain SQL)
+1. Run `prisma db pull` to update the Prisma schema
+1. Run `prisma generate` to update Prisma Client
+1. Use the updated Prisma Client in your application
+
+Note that as you evolve the application, [this process can be repeated for an indefinite number of times](#introspection-with-an-existing-schema).
+
+
+
+## Rules and conventions
+
+Prisma ORM employs a number of conventions for translating a database schema into a data model in the Prisma schema:
+
+### Model, field and enum names
+
+Field, model and enum names (identifiers) must start with a letter and generally must only contain underscores, letters and digits. You can find the naming rules and conventions for each of these identifiers on the respective docs page:
+
+- [Naming models](/orm/reference/prisma-schema-reference#naming-conventions)
+- [Naming fields](/orm/reference/prisma-schema-reference#naming-conventions-1)
+- [Naming enums](/orm/reference/prisma-schema-reference#naming-conventions-2)
+
+The general rule for identifiers is that they need to adhere to this regular expression:
+
+```
+[A-Za-z][A-Za-z0-9_]*
+```
+
+#### Sanitization of invalid characters
+
+**Invalid characters** are being sanitized during introspection:
+
+- If they appear _before_ a letter in an identifier, they get dropped.
+- If they appear _after_ the first letter, they get replaced by an underscore.
+
+Additionally, the transformed name is mapped to the database using `@map` or `@@map` to retain the original name.
+
+Consider the following table as an example:
+
+```sql
+CREATE TABLE "42User" (
+ _id SERIAL PRIMARY KEY,
+ _name VARCHAR(255),
+ two$two INTEGER
+);
+```
+
+Because the leading `42` in the table name as well as the leading underscores and the `$` on the columns are forbidden in Prisma ORM, introspection adds the `@map` and `@@map` attributes so that these names adhere to Prisma ORM's naming conventions:
+
+```prisma
+model User {
+ id Int @id @default(autoincrement()) @map("_id")
+ name String? @map("_name")
+ two_two Int? @map("two$two")
+
+ @@map("42User")
+}
+```
+
+#### Duplicate Identifiers after Sanitization
+
+If sanitization results in duplicate identifiers, no immediate error handling is in place. You get the error later and can manually fix it.
+
+Consider the case of the following two tables:
+
+```sql
+CREATE TABLE "42User" (
+ _id SERIAL PRIMARY KEY
+);
+
+CREATE TABLE "24User" (
+ _id SERIAL PRIMARY KEY
+);
+```
+
+This would result in the following introspection result:
+
+```prisma
+model User {
+ id Int @id @default(autoincrement()) @map("_id")
+
+ @@map("42User")
+}
+
+model User {
+ id Int @id @default(autoincrement()) @map("_id")
+
+ @@map("24User")
+}
+```
+
+Trying to generate your Prisma Client with `prisma generate` you would get the following error:
+
+
+
+
+
+```
+npx prisma generate
+```
+
+
+
+
+
+```code no-copy
+$ npx prisma generate
+Error: Schema parsing
+error: The model "User" cannot be defined because a model with that name already exists.
+ --> schema.prisma:17
+ |
+16 | }
+17 | model User {
+ |
+
+Validation Error Count: 1
+```
+
+
+
+
+
+In this case, you must manually change the name of one of the two generated `User` models because duplicate model names are not allowed in the Prisma schema.
+
+### Order of fields
+
+Introspection lists model fields in the same order as the corresponding table columns in the database.
+
+### Order of attributes
+
+Introspection adds attributes in the following order (this order is mirrored by `prisma format`):
+
+- Block level: `@@id`, `@@unique`, `@@index`, `@@map`
+- Field level : `@id`, `@unique`, `@default`, `@updatedAt`, `@map`, `@relation`
+
+### Relations
+
+Prisma ORM translates foreign keys that are defined on your database tables into [relations](/orm/prisma-schema/data-model/relations).
+
+#### One-to-one relations
+
+Prisma ORM adds a [one-to-one](/orm/prisma-schema/data-model/relations/one-to-one-relations) relation to your data model when the foreign key on a table has a `UNIQUE` constraint, e.g.:
+
+```sql
+CREATE TABLE "User" (
+ id SERIAL PRIMARY KEY
+);
+CREATE TABLE "Profile" (
+ id SERIAL PRIMARY KEY,
+ "user" integer NOT NULL UNIQUE,
+ FOREIGN KEY ("user") REFERENCES "User"(id)
+);
+```
+
+Prisma ORM translates this into the following data model:
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ Profile Profile?
+}
+
+model Profile {
+ id Int @id @default(autoincrement())
+ user Int @unique
+ User User @relation(fields: [user], references: [id])
+}
+```
+
+#### One-to-many relations
+
+By default, Prisma ORM adds a [one-to-many](/orm/prisma-schema/data-model/relations/one-to-many-relations) relation to your data model for a foreign key it finds in your database schema:
+
+```sql
+CREATE TABLE "User" (
+ id SERIAL PRIMARY KEY
+);
+CREATE TABLE "Post" (
+ id SERIAL PRIMARY KEY,
+ "author" integer NOT NULL,
+ FOREIGN KEY ("author") REFERENCES "User"(id)
+);
+```
+
+These tables are transformed into the following models:
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ Post Post[]
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ author Int
+ User User @relation(fields: [author], references: [id])
+}
+```
+
+#### Many-to-many relations
+
+[Many-to-many](/orm/prisma-schema/data-model/relations/many-to-many-relations) relations are commonly represented as [relation tables](/orm/prisma-schema/data-model/relations/many-to-many-relations#relation-tables) in relational databases.
+
+Prisma ORM supports two ways for defining many-to-many relations in the Prisma schema:
+
+- [Implicit many-to-many relations](/orm/prisma-schema/data-model/relations/many-to-many-relations#implicit-many-to-many-relations) (Prisma ORM manages the relation table under the hood)
+- [Explicit many-to-many relations](/orm/prisma-schema/data-model/relations/many-to-many-relations#explicit-many-to-many-relations) (the relation table is present as a [model](/orm/prisma-schema/data-model/models#defining-models))
+
+_Implicit_ many-to-many relations are recognized if they adhere to Prisma ORM's [conventions for relation tables](/orm/prisma-schema/data-model/relations/many-to-many-relations#conventions-for-relation-tables-in-implicit-m-n-relations). Otherwise the relation table is rendered in the Prisma schema as a model (therefore making it an _explicit_ many-to-many relation).
+
+This topic is covered extensively on the docs page about [Relations](/orm/prisma-schema/data-model/relations).
+
+#### Disambiguating relations
+
+Prisma ORM generally omits the `name` argument on the [`@relation`](/orm/prisma-schema/data-model/relations#the-relation-attribute) attribute if it's not needed. Consider the `User` ↔ `Post` example from the previous section. The `@relation` attribute only has the `references` argument, `name` is omitted because it's not needed in this case:
+
+```prisma
+model Post {
+ id Int @id @default(autoincrement())
+ author Int
+ User User @relation(fields: [author], references: [id])
+}
+```
+
+It would be needed if there were _two_ foreign keys defined on the `Post` table:
+
+```sql
+CREATE TABLE "User" (
+ id SERIAL PRIMARY KEY
+);
+CREATE TABLE "Post" (
+ id SERIAL PRIMARY KEY,
+ "author" integer NOT NULL,
+ "favoritedBy" INTEGER,
+ FOREIGN KEY ("author") REFERENCES "User"(id),
+ FOREIGN KEY ("favoritedBy") REFERENCES "User"(id)
+);
+```
+
+In this case, Prisma ORM needs to [disambiguate the relation](/orm/prisma-schema/data-model/relations#disambiguating-relations) using a dedicated relation name:
+
+```prisma
+model Post {
+ id Int @id @default(autoincrement())
+ author Int
+ favoritedBy Int?
+ User_Post_authorToUser User @relation("Post_authorToUser", fields: [author], references: [id])
+ User_Post_favoritedByToUser User? @relation("Post_favoritedByToUser", fields: [favoritedBy], references: [id])
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ Post_Post_authorToUser Post[] @relation("Post_authorToUser")
+ Post_Post_favoritedByToUser Post[] @relation("Post_favoritedByToUser")
+}
+```
+
+Note that you can rename the [Prisma-ORM level](/orm/prisma-schema/data-model/relations#relation-fields) relation field to anything you like so that it looks friendlier in the generated Prisma Client API.
+
+## Introspection with an existing schema
+
+Running `prisma db pull` for relational databases with an existing Prisma Schema merges manual changes made to the schema, with changes made in the database. (This functionality has been added for the first time with version 2.6.0.) For MongoDB, Introspection for now is meant to be done only once for the initial data model. Running it repeatedly will lead to loss of custom changes, as the ones listed below.
+
+Introspection for relational databases maintains the following manual changes:
+
+- Order of `model` blocks
+- Order of `enum` blocks
+- Comments
+- `@map` and `@@map` attributes
+- `@updatedAt`
+- `@default(cuid())` (`cuid()` is a Prisma-ORM level function)
+- `@default(uuid())` (`uuid()` is a Prisma-ORM level function)
+- Custom `@relation` names
+
+> **Note**: Only relations between models on the database level will be picked up. This means that there **must be a foreign key set**.
+
+The following properties of the schema are determined by the database:
+
+- Order of fields within `model` blocks
+- Order of values within `enum` blocks
+
+> **Note**: All `enum` blocks are listed below `model` blocks.
+
+### Force overwrite
+
+To overwrite manual changes, and generate a schema based solely on the introspected database and ignore any existing Prisma Schema, add the `--force` flag to the `db pull` command:
+
+```terminal
+npx prisma db pull --force
+```
+
+Use cases include:
+
+- You want to start from scratch with a schema generated from the underlying database
+- You have an invalid schema and must use `--force` to make introspection succeed
+
+## Introspecting only a subset of your database schema
+
+Introspecting only a subset of your database schema is [not yet officially supported](https://github.com/prisma/prisma/issues/807) by Prisma ORM.
+
+However, you can achieve this by creating a new database user that only has access to the tables which you'd like to see represented in your Prisma schema, and then perform the introspection using that user. The introspection will then only include the tables the new user has access to.
+
+If your goal is to exclude certain models from the [Prisma Client generation](/orm/prisma-client/setup-and-configuration/generating-prisma-client), you can add the [`@@ignore` attribute](/orm/reference/prisma-schema-reference#ignore-1) to the model definition in your Prisma schema. Ignored models are excluded from the generated Prisma Client.
+
+## Introspection warnings for unsupported features
+
+The Prisma Schema Language (PSL) can express a majority of the database features of the [target databases](/orm/reference/supported-databases) Prisma ORM supports. However, there are features and functionality the Prisma Schema Language still needs to express.
+
+For these features, the Prisma CLI will surface detect usage of the feature in your database and return a warning. The Prisma CLI will also add a comment in the models and fields the features are in use in the Prisma schema. The warnings will also contain a workaround suggestion.
+
+The `prisma db pull` command will surface the following unsupported features:
+
+- From version [4.13.0](https://github.com/prisma/prisma/releases/tag/4.13.0):
+ - [Partitioned tables](https://github.com/prisma/prisma/issues/1708)
+ - [PostgreSQL Row Level Security](https://github.com/prisma/prisma/issues/12735)
+ - [Index sort order, `NULLS FIRST` / `NULLS LAST`](https://github.com/prisma/prisma/issues/15466)
+ - [CockroachDB row-level TTL](https://github.com/prisma/prisma/issues/13982)
+ - [Comments](https://github.com/prisma/prisma/issues/8703)
+ - [PostgreSQL deferred constraints](https://github.com/prisma/prisma/issues/8807)
+- From version [4.14.0](https://github.com/prisma/prisma/releases/tag/4.14.0):
+ - [Check Constraints](https://github.com/prisma/prisma/issues/3388) (MySQL + PostgreSQL)
+ - [Exclusion Constraints](https://github.com/prisma/prisma/issues/17514)
+ - [MongoDB $jsonSchema](https://github.com/prisma/prisma/issues/8135)
+- From version [4.16.0](https://github.com/prisma/prisma/releases/tag/4.16.0):
+ - [Expression indexes](https://github.com/prisma/prisma/issues/2504)
+
+You can find the list of features we intend to support on [GitHub (labeled with `topic:database-functionality`)](https://github.com/prisma/prisma/issues?q=is%3Aopen+label%3A%22topic%3A+database-functionality%22+label%3Ateam%2Fschema+sort%3Aupdated-desc+).
+
+### Workaround for introspection warnings for unsupported features
+
+If you are using a relational database and either one of the above features listed in the previous section:
+
+1. Create a draft migration:
+ ```terminal
+ npx prisma migrate dev --create-only
+ ```
+2. Add the SQL that adds the feature surfaced in the warnings.
+3. Apply the draft migration to your database:
+ ```terminal
+ npx prisma migrate dev
+ ```
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/80-postgresql-extensions.mdx b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/80-postgresql-extensions.mdx
new file mode 100644
index 0000000000..71042b60e4
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/80-postgresql-extensions.mdx
@@ -0,0 +1,52 @@
+---
+title: 'PostgreSQL extensions'
+metaTitle: 'How to use PostgreSQL extensions with Prisma ORM'
+metaDescription: 'How to install and manage PostgreSQL extensions with Prisma ORM using customized migrations, and how to use them in Prisma Client.'
+tocDepth: 3
+---
+
+This page is about [PostgreSQL extensions](https://www.postgresql.org/docs/current/external-extensions.html) and explains how to use them with Prisma ORM.
+
+:::warning
+
+Between Prisma ORM v4.5.0 and v6.16.0, you could enable extensions in the Prisma schema via the `postgresqlExtensions` preview feature flag. This feature flag has been deprecated in v6.16.0 and the recommended approach for using PostgreSQL extensions now is to install them via [customized migrations](/orm/prisma-migrate/workflows/customizing-migrations).
+
+:::
+
+## What are PostgreSQL extensions?
+
+PostgreSQL allows you to extend your database functionality by installing and activating packages known as _extensions_. For example, the `citext` extension adds a case-insensitive string data type. Some extensions, such as `citext`, are supplied directly by PostgreSQL, while other extensions are developed externally. For more information on extensions, see [the PostgreSQL documentation](https://www.postgresql.org/docs/current/sql-createextension.html).
+
+To use an extension, it must first be _installed_ on the local file system of your database server. You then need to _activate_ the extension, which runs a script file that adds the new functionality.
+
+## Using a PostgreSQL extension with Prisma ORM
+
+Let's walk through an example of installing the `citext` extension.
+
+### 1. Create an empty migration
+
+Run the following command to create an empty migration that you can [customize](/orm/prisma-migrate/workflows/customizing-migrations):
+
+```terminal
+npx prisma migrate dev --create-only
+```
+
+### 2. Add a SQL statement to install the extension
+
+In the new migration file that was created in the `migrations` directory, add the following statement:
+
+```sql
+CREATE EXTENSION IF NOT EXISTS citext;
+```
+
+### 3. Deploy the migration
+
+Run the following command to deploy the migration and apply to your database:
+
+```terminal
+npx prisma migrate deploy
+```
+
+### 4. Use the extension
+
+You can now use the extension in your queries with Prisma Client. If the extension has special data types that currently can't be natively represented in the Prisma schema, you can still define fields of that type on your models using the [`Unsupported`](/orm/prisma-schema/data-model/models#unsupported-types) fallback type.
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/_category_.json b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/_category_.json
new file mode 100644
index 0000000000..9ecbba8efe
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/_category_.json
@@ -0,0 +1,5 @@
+{
+ "label": "Prisma Schema",
+ "collapsible": false,
+ "collapsed": false
+}
diff --git a/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/index.mdx b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/index.mdx
new file mode 100644
index 0000000000..045a1f3687
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/100-prisma-schema/index.mdx
@@ -0,0 +1,11 @@
+---
+title: 'Prisma schema'
+metaTitle: 'Prisma schema'
+metaDescription: 'Learn everything you need to know about the Prisma schema.'
+staticLink: true
+hide_table_of_contents: true
+---
+
+## In this section
+
+
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/005-introduction.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/005-introduction.mdx
new file mode 100644
index 0000000000..7db7a65071
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/005-introduction.mdx
@@ -0,0 +1,170 @@
+---
+title: 'Introduction to Prisma Client'
+sidebar_label: 'Introduction'
+metaTitle: 'Introduction to Prisma Client'
+metaDescription: 'Learn how to set up Prisma Client.'
+---
+
+import {
+ Icon
+} from '@site/src/components/Icon';
+
+
+
+Prisma Client is an auto-generated and type-safe query builder that's _tailored_ to your data. The easiest way to get started with Prisma Client is by following the **[Quickstart](/getting-started/quickstart-sqlite)**.
+
+
+
+ Quickstart (5 min)
+
+
+The setup instructions [below](#set-up) provide a high-level overview of the steps needed to set up Prisma Client. If you want to get started using Prisma Client with your own database, follow one of these guides:
+
+
+
+ Set up a new project from scratch
+
+
+
+
+
+ Add Prisma to an existing project
+
+
+
+
+## Set up
+
+### 1. Prerequisites
+
+In order to set up Prisma Client, you need a [Prisma schema file](/orm/prisma-schema) with your database connection, the Prisma Client generator, and at least one model:
+
+```prisma file=schema.prisma
+datasource db {
+ url = env("DATABASE_URL")
+ provider = "postgresql"
+}
+
+generator client {
+ provider = "prisma-client-js"
+ output = "../src/generated/prisma"
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ createdAt DateTime @default(now())
+ email String @unique
+ name String?
+}
+```
+
+Also make sure to [install the Prisma CLI](/orm/tools/prisma-cli#installation):
+
+```
+npm install prisma --save-dev
+npx prisma
+```
+
+### 2. Installation
+
+Install Prisma Client in your project with the following command:
+
+```
+npm install @prisma/client
+```
+
+### 3. Importing Prisma Client
+
+There are multiple ways to import Prisma Client in your project depending on your use case:
+
+
+
+
+
+```ts
+import { PrismaClient } from './generated/prisma'
+
+const prisma = new PrismaClient()
+// use `prisma` in your application to read and write data in your DB
+```
+
+
+
+
+
+```js
+const { PrismaClient } = require('./generated/prisma')
+
+const prisma = new PrismaClient()
+// use `prisma` in your application to read and write data in your DB
+```
+
+
+
+
+
+For edge environments, you can import Prisma Client as follows:
+
+
+
+
+
+```ts
+import { PrismaClient } from './generated/prisma/edge'
+
+const prisma = new PrismaClient()
+// use `prisma` in your application to read and write data in your DB
+```
+
+
+
+
+
+```js
+const { PrismaClient } = require('./generated/prisma/edge')
+
+const prisma = new PrismaClient()
+// use `prisma` in your application to read and write data in your DB
+```
+
+
+
+
+
+> **Note**: If you're using [driver adapters](/orm/overview/databases/database-drivers#driver-adapters), you can import from the location spefified in your generator's `output` path directly, e.g. `./src/generated/prisma`. No need to import from `./src/generated/prisma/edge`.
+
+### 4. Use Prisma Client to send queries to your database
+
+Once you have instantiated `PrismaClient`, you can start sending queries in your code:
+
+```ts
+// run inside `async` function
+const newUser = await prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ },
+})
+
+const users = await prisma.user.findMany()
+```
+
+
+
+All Prisma Client methods return an instance of [`PrismaPromise`](/6.0/orm/reference/prisma-client-reference#prismapromise-behavior) which only executes when you call `await` or `.then()` or `.catch()`.
+
+
+
+### 5. Evolving your application
+
+Whenever you make changes to your database that are reflected in the Prisma schema, you need to manually re-generate Prisma Client to update the generated code in the `node_modules/.prisma/client` directory:
+
+```
+prisma generate
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/010-generating-prisma-client.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/010-generating-prisma-client.mdx
new file mode 100644
index 0000000000..2f850cf9d5
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/010-generating-prisma-client.mdx
@@ -0,0 +1,150 @@
+---
+title: 'Generating Prisma Client'
+metaTitle: 'Generating Prisma Client'
+metaDescription: 'This page explains how to generate Prisma Client. It also provides additional context on the generated client, typical workflows and Node.js configuration.'
+---
+
+Prisma Client is a generated database client that's tailored to your database schema. By default, Prisma Client is generated into the `node_modules/.prisma/client` folder, but we highly recommend [you specify an output location](#using-a-custom-output-path).
+
+:::warning
+
+In Prisma ORM 7, Prisma Client will no longer be generated in `node_modules` by default and will require an output path to be defined. [Learn more below on how to define an output path](#using-a-custom-output-path).
+
+:::
+
+:::tip Use Prisma ORM without Rust binaries
+
+If Prisma ORM's Rust engine binaries cause large bundle sizes, slow builds, or deployment issues (for example, in serverless or edge environments), you can use it without them using this configuration of your `generator` block:
+
+```prisma
+generator client {
+ provider = "prisma-client-js" // or "prisma-client"
+ engineType = "client"
+}
+```
+
+Prisma ORM without Rust binaries has been [Generally Available](/orm/more/releases#generally-available-ga) since [v6.16.0](https://pris.ly/release/6.16.0).
+
+Note that you need to use a [driver adapter](/orm/overview/databases/database-drivers#driver-adapters) in this case.
+
+When using this architecture:
+
+- No Rust query engine binary is downloaded or shipped.
+- The database connection pool is maintained by the native JS database driver you install (e.g., `@prisma/adapter-pg` for PostgreSQL).
+
+This setup can simplify deployments in serverless or edge runtimes. Learn more in the [docs here](/orm/prisma-client/setup-and-configuration/no-rust-engine).
+
+:::
+
+
+To generate and instantiate Prisma Client:
+
+1. Ensure that you have [Prisma CLI installed on your machine](/orm/tools/prisma-cli#installation).
+
+ ```terminal
+ npm install prisma --save-dev
+ ```
+
+1. Add the following `generator` definition to your Prisma schema:
+
+ ```prisma
+ generator client {
+ provider = "prisma-client-js"
+ output = "app/generated/prisma/client"
+ }
+ ```
+
+ :::note
+
+ Feel free to customize the output location to match your application. Common directories are `app`, `src`, or even the root of your project.
+
+ :::
+
+1. Install the `@prisma/client` npm package:
+
+ ```terminal
+ npm install @prisma/client
+ ```
+
+1. Generate Prisma Client with the following command:
+
+ ```terminal
+ prisma generate
+ ```
+
+1. You can now [instantiate Prisma Client](/orm/prisma-client/setup-and-configuration/instantiate-prisma-client) in your code:
+
+ ```ts
+ import { PrismaClient } from 'app/generated/prisma/client'
+ const prisma = new PrismaClient()
+ // use `prisma` in your application to read and write data in your DB
+ ```
+
+> **Important**: You need to re-run the `prisma generate` command after every change that's made to your Prisma schema to update the generated Prisma Client code.
+
+Here is a graphical illustration of the typical workflow for generation of Prisma Client:
+
+
+
+## The location of Prisma Client
+
+:::warning
+
+We strongly recommend you define a custom `output` path. In Prisma ORM version `6.6.0`, not defining an `output` path will result in a warning. In Prisma ORM 7, the field will be required.
+
+:::
+
+### Using a custom `output` path
+
+You can also specify a custom `output` path on the `generator` configuration, for example (assuming your `schema.prisma` file is located at the default `prisma` subfolder):
+
+```prisma
+generator client {
+ provider = "prisma-client-js"
+ output = "../src/generated/client"
+}
+```
+
+After running `prisma generate` for that schema file, the Prisma Client package will be located in:
+
+```
+./src/generated/client
+```
+
+To import the `PrismaClient` from a custom location (for example, from a file named `./src/script.ts`):
+
+```ts
+import { PrismaClient } from './generated/client'
+```
+
+:::note
+
+
+For improved compatibility with ECMAScript modules (ESM) and to ensure consistent behaviour of Prisma ORM across different Node.js runtimes, you can also use the newer [`prisma-client`](/6.0/orm/prisma-schema/overview/generators#prisma-client) generator. This generator is specifically designed to handle common challenges with module resolution and runtime variations, providing a smoother integration experience and less friction with bundlers.
+
+:::
+
+## The `@prisma/client` npm package
+
+The `@prisma/client` npm package consists of two key parts:
+
+- The `@prisma/client` module itself, which only changes when you re-install the package
+- The `.prisma/client` folder, which is the [default location](#using-a-custom-output-path) for the unique Prisma Client generated from your schema
+
+`@prisma/client/index.d.ts` exports `.prisma/client`:
+
+```ts
+export * from '.prisma/client'
+```
+
+This means that you still import `@prisma/client` in your own `.ts` files:
+
+```ts
+import { PrismaClient } from '@prisma/client'
+```
+
+Prisma Client is generated from your Prisma schema and is unique to your project. Each time you change the schema (for example, by performing a [schema migration](/orm/prisma-migrate)) and run `prisma generate`, Prisma Client's code changes:
+
+
+
+The `.prisma` folder is unaffected by [pruning](https://docs.npmjs.com/cli/prune.html) in Node.js package managers.
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/015-instantiate-prisma-client.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/015-instantiate-prisma-client.mdx
new file mode 100644
index 0000000000..afb94443e5
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/015-instantiate-prisma-client.mdx
@@ -0,0 +1,59 @@
+---
+title: 'Instantiating Prisma Client'
+metaTitle: 'Instantiating Prisma Client'
+metaDescription: 'How to create and use an instance of PrismaClient in your app.'
+tocDepth: 3
+---
+
+The following example demonstrates how to import and instantiate your [generated client](/orm/prisma-client/setup-and-configuration/generating-prisma-client) from the [default path](/orm/prisma-client/setup-and-configuration/generating-prisma-client#using-a-custom-output-path):
+
+
+
+
+
+```ts
+import { PrismaClient } from '@prisma/client'
+
+const prisma = new PrismaClient()
+```
+
+
+
+
+
+```js
+const { PrismaClient } = require('@prisma/client')
+
+const prisma = new PrismaClient()
+```
+
+
+
+
+
+:::tip
+
+You can further customize `PrismaClient` with [constructor parameters](/6.0/orm/reference/prisma-client-reference#prismaclient) — for example, set [logging levels](/orm/prisma-client/observability-and-logging/logging), [transaction options](/orm/prisma-client/queries/transactions#transaction-options) or customize [error formatting](/orm/prisma-client/setup-and-configuration/error-formatting).
+
+:::
+
+## The number of `PrismaClient` instances matters
+
+Your application should generally only create **one instance** of `PrismaClient`. How to achieve this depends on whether you are using Prisma ORM in a [long-running application](/orm/prisma-client/setup-and-configuration/databases-connections#prismaclient-in-long-running-applications) or in a [serverless environment](/orm/prisma-client/setup-and-configuration/databases-connections#prismaclient-in-serverless-environments) .
+
+The reason for this is that each instance of `PrismaClient` manages a connection pool, which means that a large number of clients can **exhaust the database connection limit**. This applies to all database connectors.
+
+If you use the **MongoDB connector**, connections are managed by the MongoDB driver connection pool. If you use a **relational database connector**, connections are managed by Prisma ORM's [connection pool](/orm/prisma-client/setup-and-configuration/databases-connections/connection-pool). Each instance of `PrismaClient` creates its own pool.
+
+1. Each client creates its own instance of the [query engine](/orm/more/under-the-hood/engines).
+1. Each query engine creates a [connection pool](/orm/prisma-client/setup-and-configuration/databases-connections/connection-pool) with a default pool size of:
+
+ - `num_physical_cpus * 2 + 1` for relational databases
+ - [`100` for MongoDB](https://www.mongodb.com/docs/manual/reference/connection-string-options/#mongodb-urioption-urioption.maxPoolSize)
+
+1. Too many connections may start to **slow down your database** and eventually lead to errors such as:
+
+ ```
+ Error in connector: Error querying the database: db error: FATAL: sorry, too many clients already
+ at PrismaClientFetcher.request
+ ```
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/050-databases-connections/100-connection-management.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/050-databases-connections/100-connection-management.mdx
new file mode 100644
index 0000000000..c97604cdec
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/050-databases-connections/100-connection-management.mdx
@@ -0,0 +1,117 @@
+---
+title: 'Connection management'
+metaTitle: 'Connection management'
+metaDescription: 'This page explains how database connections are handled with Prisma Client and how to manually connect and disconnect your database.'
+tocDepth: 3
+---
+
+
+
+`PrismaClient` connects and disconnects from your data source using the following two methods:
+
+- [`$connect()`](/6.0/orm/reference/prisma-client-reference#connect-1)
+- [`$disconnect()`](/6.0/orm/reference/prisma-client-reference#disconnect-1)
+
+In most cases, you **do not need to explicitly call these methods**. `PrismaClient` automatically connects when you run your first query, creates a [connection pool](/orm/prisma-client/setup-and-configuration/databases-connections/connection-pool), and disconnects when the Node.js process ends.
+
+See the [connection management guide](/orm/prisma-client/setup-and-configuration/databases-connections) for information about managing connections for different deployment paradigms (long-running processes and serverless functions).
+
+
+Questions answered in this page
+
+- When should I call $connect and $disconnect?
+- How does Prisma manage connection pools?
+- How to handle connections in serverless?
+
+
+
+
+
+## `$connect()`
+
+It is not necessary to call [`$connect()`](/6.0/orm/reference/prisma-client-reference#connect-1) thanks to the _lazy connect_ behavior: The `PrismaClient` instance connects lazily when the first request is made to the API (`$connect()` is called for you under the hood).
+
+### Calling `$connect()` explicitly
+
+If you need the first request to respond instantly and cannot wait for a lazy connection to be established, you can explicitly call `prisma.$connect()` to establish a connection to the data source:
+
+```ts
+const prisma = new PrismaClient()
+
+// run inside `async` function
+await prisma.$connect()
+```
+
+## `$disconnect()`
+
+When you call [`$disconnect()`](/6.0/orm/reference/prisma-client-reference#disconnect-1) , Prisma Client:
+
+1. Runs the [`beforeExit` hook](#exit-hooks)
+2. Ends the Query Engine child process and closes all connections
+
+In a long-running application such as a GraphQL API, which constantly serves requests, it does not make sense to `$disconnect()` after each request - it takes time to establish a connection, and doing so as part of each request will slow down your application.
+
+:::tip
+
+To avoid too _many_ connections in a long-running application, we recommend that you [use a single instance of `PrismaClient` across your application](/orm/prisma-client/setup-and-configuration/instantiate-prisma-client#the-number-of-prismaclient-instances-matters).
+
+:::
+
+### Calling `$disconnect()` explicitly
+
+One scenario where you should call `$disconnect()` explicitly is where a script:
+
+1. Runs **infrequently** (for example, a scheduled job to send emails each night), which means it does not benefit from a long-running connection to the database _and_
+2. Exists in the context of a **long-running application**, such as a background service. If the application never shuts down, Prisma Client never disconnects.
+
+The following script creates a new instance of `PrismaClient`, performs a task, and then disconnects - which closes the connection pool:
+
+```ts highlight=19;normal
+import { PrismaClient } from '@prisma/client'
+
+const prisma = new PrismaClient()
+const emailService = new EmailService()
+
+async function main() {
+ const allUsers = await prisma.user.findMany()
+ const emails = allUsers.map((x) => x.email)
+
+ await emailService.send(emails, 'Hello!')
+}
+
+main()
+ .then(async () => {
+ await prisma.$disconnect()
+ })
+ .catch(async (e) => {
+ console.error(e)
+ await prisma.$disconnect()
+ process.exit(1)
+ })
+```
+
+If the above script runs multiple times in the context of a long-running application _without_ calling `$disconnect()`, a new connection pool is created with each new instance of `PrismaClient`.
+
+## Exit hooks
+
+
+
+From Prisma ORM 5.0.0, the `beforeExit` hook only applies to the [binary Query Engine](/orm/more/under-the-hood/engines#configuring-the-query-engine).
+
+
+
+The `beforeExit` hook runs when Prisma ORM is triggered externally (e.g. via a `SIGINT` signal) to shut down, and allows you to run code _before_ Prisma Client disconnects - for example, to issue queries as part of a graceful shutdown of a service:
+
+```ts
+const prisma = new PrismaClient()
+
+prisma.$on('beforeExit', async () => {
+ console.log('beforeExit hook')
+ // PrismaClient still available
+ await prisma.message.create({
+ data: {
+ message: 'Shutting down server',
+ },
+ })
+})
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/050-databases-connections/115-connection-pool.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/050-databases-connections/115-connection-pool.mdx
new file mode 100644
index 0000000000..8f759bbc70
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/050-databases-connections/115-connection-pool.mdx
@@ -0,0 +1,244 @@
+---
+title: Connection pool
+metaDescription: Prisma ORM's query engine creates a connection pool to store and manage database connections.
+tocDepth: 4
+toc_max_heading_level: 4
+---
+
+The query engine manages a **connection pool** of database connections. The pool is created when Prisma Client opens the _first_ connection to the database, which can happen in one of two ways:
+
+- By [explicitly calling `$connect()`](/orm/prisma-client/setup-and-configuration/databases-connections/connection-management#connect) _or_
+- By running the first query, which calls `$connect()` under the hood
+
+Relational database connectors use Prisma ORM's own connection pool, and the MongoDB connectors uses the [MongoDB driver connection pool](https://github.com/mongodb/specifications/blob/master/source/connection-monitoring-and-pooling/connection-monitoring-and-pooling.rst).
+
+
+Questions answered in this page
+
+- How do I size Prisma's connection pool?
+- How do I set pool timeouts and limits?
+- When should I use PgBouncer with Prisma?
+
+
+
+:::note
+
+As of [v6.16.0](https://pris.ly/release/6.16.0), Prisma ORM can be used without Rust engines in production applications. Learn more [here](/orm/prisma-client/setup-and-configuration/no-rust-engine).
+
+**When enabled, your Prisma Client will be generated without a Rust-based query engine binary**:
+
+```prisma
+generator client {
+ provider = "prisma-client-js" // or "prisma-client"
+ output = "../src/generated/prisma"
+ engineType = "client" // no Rust engine
+}
+```
+
+Note that [driver adapters](/orm/overview/databases/database-drivers#driver-adapters) are required if you want to use Prisma ORM without Rust engines. In this scenario, the connection pool is maintained by the native JS database driver you're using.
+
+You can [read about the performance and DX improvements](https://www.prisma.io/blog/prisma-orm-without-rust-latest-performance-benchmarks) of this change on our blog.
+
+:::
+
+
+## Relational databases
+
+The relational database connectors use Prisma ORM's connection pool. The connection pool has a **connection limit** and a **pool timeout**, which are controlled by connection URL parameters.
+
+### How the connection pool works
+
+The following steps describe how the query engine uses the connection pool:
+
+1. The query engine instantiates a connection pool with a [configurable pool size](#setting-the-connection-pool-size) and [pool timeout](#setting-the-connection-pool-timeout).
+1. The query engine creates one connection and adds it to the connection pool.
+1. When a query comes in, the query engine reserves a connection from the pool to process query.
+1. If there are no idle connections available in the connection pool, the query engine opens additional database connections and adds them to the connection pool until the number of database connections reaches the limit defined by `connection_limit`.
+1. If the query engine cannot reserve a connection from the pool, queries are added to a FIFO (First In First Out) queue in memory. FIFO means that queries are processed in the order they enter the queue.
+1. If the query engine cannot process a query in the queue for **before the [time limit](#default-pool-timeout)**, it throws an exception with error code `P2024` for that query and moves on to the next one in the queue.
+
+If you consistently experience pool timeout errors, you need to [optimize the connection pool](/orm/prisma-client/setup-and-configuration/databases-connections#optimizing-the-connection-pool) .
+
+### Connection pool size
+
+#### Default connection pool size
+
+The default number of connections (pool size) is calculated with the following formula:
+
+```bash
+num_physical_cpus * 2 + 1
+```
+
+`num_physical_cpus` represents the number of physical CPUs on the machine your application is running on. If your machine has **four** physical CPUs, your connection pool will contain **nine** connections (`4 * 2 + 1 = 9`).
+
+Although the formula represents a good starting point, the [recommended connection limit](/orm/prisma-client/setup-and-configuration/databases-connections#recommended-connection-pool-size) also depends on your deployment paradigm - particularly if you are using serverless.
+
+#### Setting the connection pool size
+
+You can specify the number of connections by explicitly setting the `connection_limit` parameter in your database connection URL. For example, with the following `datasource` configuration in your [Prisma schema](/orm/prisma-schema) the connection pool will have exactly five connections:
+
+```prisma
+datasource db {
+ provider = "postgresql"
+ url = "postgresql://johndoe:mypassword@localhost:5432/mydb?connection_limit=5"
+}
+```
+
+#### Viewing the connection pool size
+
+The number of connections Prisma Client uses can be viewed using [logging](/orm/prisma-client/observability-and-logging/logging) and [metrics](/orm/prisma-client/observability-and-logging/metrics).
+
+Using the `info` [logging level](/6.0/orm/reference/prisma-client-reference#log-levels), you can log the number of connections in a connection pool that are opened when Prisma Client is instantiated.
+
+For example, consider the following Prisma Client instance and invocation:
+
+
+
+
+```ts
+import { PrismaClient } from '@prisma/client'
+
+const prisma = new PrismaClient({
+ log: ['info'],
+})
+
+async function main() {
+ await prisma.user.findMany()
+}
+
+main()
+```
+
+
+
+
+```text no-copy
+prisma:info Starting a postgresql pool with 21 connections.
+```
+
+
+
+
+When the `PrismaClient` class was instantiated, the logging notified `stdout` that a connection pool with 21 connections was started.
+
+
+
+Note that the output generated by `log: ['info']` can change in any release without notice. Be aware of this in case you are relying on the output in your application or a tool that you're building.
+
+
+
+If you need even more insights into the size of your connection pool and the amount of in-use and idle connection, you can use the [metrics](/orm/prisma-client/observability-and-logging/metrics) feature (which is currently in Preview).
+
+Consider the following example:
+
+
+
+
+```ts
+import { PrismaClient } from '@prisma/client'
+
+const prisma = new PrismaClient()
+
+async function main() {
+ await Promise.all([prisma.user.findMany(), prisma.post.findMany()])
+
+ const metrics = await prisma.$metrics.json()
+ console.dir(metrics, { depth: Infinity })
+}
+
+main()
+```
+
+
+
+
+```json no-copy
+{
+ "counters": [
+ // ...
+ {
+ "key": "prisma_pool_connections_open",
+ "labels": {},
+ "value": 2,
+ "description": "Number of currently open Pool Connections"
+ }
+ ],
+ "gauges": [
+ // ...
+ {
+ "key": "prisma_pool_connections_busy",
+ "labels": {},
+ "value": 0,
+ "description": "Number of currently busy Pool Connections (executing a datasource query)"
+ },
+ {
+ "key": "prisma_pool_connections_idle",
+ "labels": {},
+ "value": 21,
+ "description": "Number of currently unused Pool Connections (waiting for the next datasource query to run)"
+ },
+ {
+ "key": "prisma_pool_connections_opened_total",
+ "labels": {},
+ "value": 2,
+ "description": "Total number of Pool Connections opened"
+ }
+ ],
+ "histograms": [
+ /** ... **/
+ ]
+}
+```
+
+
+
+
+
+
+For more details on what is available in the metrics output, see the [About metrics](/orm/prisma-client/observability-and-logging/metrics#about-metrics) section.
+
+
+
+### Connection pool timeout
+
+#### Default pool timeout
+
+The default connection pool timeout is 10 seconds. If the Query Engine does not get a connection from the database connection pool within that time, it throws an exception and moves on to the next query in the queue.
+
+#### Setting the connection pool timeout
+
+You can specify the pool timeout by explicitly setting the `pool_timeout` parameter in your database connection URL. In the following example, the pool times out after `2` seconds:
+
+```prisma
+datasource db {
+ provider = "postgresql"
+ url = "postgresql://johndoe:mypassword@localhost:5432/mydb?connection_limit=5&pool_timeout=2"
+}
+```
+
+#### Disabling the connection pool timeout
+
+You disable the connection pool timeout by setting the `pool_timeout` parameter to `0`:
+
+```prisma
+datasource db {
+ provider = "postgresql"
+ url = "postgresql://johndoe:mypassword@localhost:5432/mydb?connection_limit=5&pool_timeout=0"
+}
+```
+
+You can choose to [disable the connection pool timeout if queries **must** remain in the queue](/orm/prisma-client/setup-and-configuration/databases-connections#disabling-the-pool-timeout) - for example, if you are importing a large number of records in parallel and are confident that the queue will not use up all available RAM before the job is complete.
+
+## MongoDB
+
+The MongoDB connector does not use the Prisma ORM connection pool. The connection pool is managed internally by the MongoDB driver and [configured via connection string parameters](https://www.mongodb.com/docs/manual/reference/connection-string-options/#connection-pool-options).
+
+## External connection poolers
+
+You cannot increase the `connection_limit` beyond what the underlying database can support. This is a particular challenge in serverless environments, where each function manages an instance of `PrismaClient` - and its own connection pool.
+
+Consider introducing [an external connection pooler like PgBouncer](/orm/prisma-client/setup-and-configuration/databases-connections#pgbouncer) to prevent your application or functions from exhausting the database connection limit.
+
+## Manual database connection handling
+
+When using Prisma ORM, the database connections are handled on an [engine](https://github.com/prisma/prisma-engines)-level. This means they're not exposed to the developer and it's not possible to manually access them.
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/050-databases-connections/200-pgbouncer.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/050-databases-connections/200-pgbouncer.mdx
new file mode 100644
index 0000000000..744c8a3b3a
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/050-databases-connections/200-pgbouncer.mdx
@@ -0,0 +1,99 @@
+---
+title: Configure Prisma Client with PgBouncer
+metaTitle: Configure Prisma Client with PgBouncer
+---
+
+An external connection pooler like PgBouncer holds a connection pool to the database, and proxies incoming client connections by sitting between Prisma Client and the database. This reduces the number of processes a database has to handle at any given time.
+
+Usually, this works transparently, but some connection poolers only support a limited set of functionality. One common feature that external connection poolers do not support are named prepared statements, which Prisma ORM uses. For these cases, Prisma ORM can be configured to behave differently.
+
+
+Questions answered in this page
+
+- How do I configure Prisma with PgBouncer?
+- Do I need `pgbouncer=true`, and if so, when?
+- How does Prisma Migrate work with PgBouncer?
+
+
+
+:::info
+
+Looking for an easy, infrastructure-free solution? Try [Prisma Accelerate](https://www.prisma.io/accelerate?utm_source=docs&utm_campaign=pgbouncer-help)! It requires little to no setup and works seamlessly with all databases supported by Prisma ORM.
+
+Ready to begin? Get started with Prisma Accelerate by clicking [here](https://console.prisma.io?utm_source=docs&utm_campaign=pgbouncer-help).
+
+:::
+
+## PgBouncer
+
+### Set PgBouncer to transaction mode
+
+For Prisma Client to work reliably, PgBouncer must run in [**Transaction mode**](https://www.pgbouncer.org/features.html).
+
+Transaction mode offers a connection for every transaction – a requirement for the Prisma Client to work with PgBouncer.
+
+### Add `pgbouncer=true` for PgBouncer versions below `1.21.0`
+
+:::warning
+We recommend **not** setting `pgbouncer=true` in the database connection string if you're using [PgBouncer `1.21.0`](https://github.com/prisma/prisma/issues/21531#issuecomment-1919059472) or later.
+:::
+
+To use Prisma Client with PgBouncer, add the `?pgbouncer=true` flag to the PostgreSQL connection URL:
+
+```shell
+postgresql://USER:PASSWORD@HOST:PORT/DATABASE?pgbouncer=true
+```
+
+:::info
+`PORT` specified for PgBouncer pooling is sometimes different from the default `5432` port. Check your database provider docs for the correct port number.
+:::
+
+### Configure `max_prepared_statements` in PgBouncer to be greater than zero
+
+Prisma uses prepared statements, and setting [`max_prepared_statements`](https://www.pgbouncer.org/config.html) to a value greater than `0` enables PgBouncer to use those prepared statements.
+
+:::info
+`PORT` specified for PgBouncer pooling is sometimes different from the default `5432` port. Check your database provider docs for the correct port number.
+:::
+
+### Prisma Migrate and PgBouncer workaround
+
+Prisma Migrate uses **database transactions** to check out the current state of the database and the migrations table. However, the Schema Engine is designed to use a **single connection to the database**, and does not support connection pooling with PgBouncer. If you attempt to run Prisma Migrate commands in any environment that uses PgBouncer for connection pooling, you might see the following error:
+
+```bash
+Error: undefined: Database error
+Error querying the database: db error: ERROR: prepared statement "s0" already exists
+```
+
+To work around this issue, you must connect directly to the database rather than going through PgBouncer. To achieve this, you can use the [`directUrl`](/orm/reference/prisma-schema-reference#fields) field in your [`datasource`](/orm/reference/prisma-schema-reference#datasource) block.
+
+For example, consider the following `datasource` block:
+
+```prisma
+datasource db {
+ provider = "postgresql"
+ url = "postgres://USER:PASSWORD@HOST:PORT/DATABASE?pgbouncer=true"
+ directUrl = "postgres://USER:PASSWORD@HOST:PORT/DATABASE"
+}
+```
+
+The block above uses a PgBouncer connection string as the primary URL using `url`, allowing Prisma Client to take advantage of the PgBouncer connection pooler.
+
+It also provides a connection string directly to the database, without PgBouncer, using the `directUrl` field. This connection string will be used when commands that require a single connection to the database, such as `prisma migrate dev` or `prisma db push`, are invoked.
+
+### PgBouncer with different database providers
+
+There are sometimes minor differences in how to connect directly to a Postgres database that depend on the provider hosting the database.
+
+Below are links to information on how to set up these connections with providers who have setup steps not covered here in our documentation:
+
+- [Connecting directly to a PostgreSQL database hosted on Digital Ocean](https://github.com/prisma/prisma/issues/6157)
+- [Connecting directly to a PostgreSQL database hosted on ScaleGrid](https://github.com/prisma/prisma/issues/6701#issuecomment-824387959)
+
+## Supabase Supavisor
+
+Supabase's Supavisor behaves similarly to [PgBouncer](#pgbouncer). You can add `?pgbouncer=true` to your connection pooled connection string available via your [Supabase database settings](https://supabase.com/dashboard/project/_/settings/database).
+
+## Other external connection poolers
+
+Although Prisma ORM does not have explicit support for other connection poolers, if the limitations are similar to the ones of [PgBouncer](#pgbouncer) you can usually also use `pgbouncer=true` in your connection string to put Prisma ORM in a mode that works with them as well.
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/050-databases-connections/index.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/050-databases-connections/index.mdx
new file mode 100644
index 0000000000..4f9daf7d74
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/050-databases-connections/index.mdx
@@ -0,0 +1,376 @@
+---
+title: Database connections
+metaTitle: Database connections
+metaDescription: 'Databases connections'
+tocDepth: 3
+---
+
+
+
+Databases can handle a limited number of concurrent connections. Each connection requires RAM, which means that simply increasing the database connection limit without scaling available resources:
+
+- ✔ might allow more processes to connect _but_
+- ✘ significantly affects **database performance**, and can result in the database being **shut down** due to an out of memory error
+
+The way your application **manages connections** also impacts performance. This guide describes how to approach connection management in [serverless environments](#serverless-environments-faas) and [long-running processes](#long-running-processes).
+
+
+
+This guide focuses on **relational databases** and how to configure and tune the Prisma ORM connection pool (MongoDB uses the MongoDB driver connection pool).
+
+
+
+
+
+## Long-running processes
+
+Examples of long-running processes include Node.js applications hosted on a service like Heroku or a virtual machine. Use the following checklist as a guide to connection management in long-running environments:
+
+- Start with the [recommended pool size (`connection_limit`)](#recommended-connection-pool-size) and [tune it](#optimizing-the-connection-pool)
+- Make sure you have [**one** global instance of `PrismaClient`](#prismaclient-in-long-running-applications)
+
+### Recommended connection pool size
+
+The recommended connection pool size (`connection_limit`) to [start with](#optimizing-the-connection-pool) for long-running processes is the **default pool size** (`num_physical_cpus * 2 + 1`) ÷ **number of application instances**.
+
+:::info
+
+`num_physical_cpus` refers to the the number of CPUs of the machine your application is running on.
+
+:::
+
+If you have **one** application instances:
+
+- The default pool size applies by default (`num_physical_cpus * 2 + 1`) - you do not need to set the `connection_limit` parameter.
+- You can optionally [tune the pool size](#optimizing-the-connection-pool).
+
+If you have **multiple** application instances:
+
+- You must **manually** [set the `connection_limit` parameter](/orm/prisma-client/setup-and-configuration/databases-connections/connection-pool#setting-the-connection-pool-size) . For example, if your calculated pool size is _10_ and you have _2_ instances of your app, the `connection_limit` parameter should be **no more than _5_**.
+- You can optionally [tune the pool size](#optimizing-the-connection-pool).
+
+### `PrismaClient` in long-running applications
+
+In **long-running** applications, we recommend that you:
+
+- ✔ Create **one** instance of `PrismaClient` and re-use it across your application
+- ✔ Assign `PrismaClient` to a global variable _in dev environments only_ to [prevent hot reloading from creating new instances](#prevent-hot-reloading-from-creating-new-instances-of-prismaclient)
+
+#### Re-using a single `PrismaClient` instance
+
+To re-use a single instance, create a module that exports a `PrismaClient` object:
+
+```ts file=client.ts
+import { PrismaClient } from '@prisma/client'
+
+let prisma = new PrismaClient()
+
+export default prisma
+```
+
+The object is [cached](https://nodejs.org/api/modules.html#modules_caching) the first time the module is imported. Subsequent requests return the cached object rather than creating a new `PrismaClient`:
+
+```ts file=app.ts
+import prisma from './client'
+
+async function main() {
+ const allUsers = await prisma.user.findMany()
+}
+
+main()
+```
+
+You do not have to replicate the example above exactly - the goal is to make sure `PrismaClient` is cached. For example, you can [instantiate `PrismaClient` in the `context` object](https://github.com/prisma/prisma-examples/blob/9f1a6b9e7c25b9e1851bd59b273046158d748995/typescript/graphql-express/src/context.ts#L9) that you [pass into an Express app](https://github.com/prisma/prisma-examples/blob/9f1a6b9e7c25b9e1851bd59b273046158d748995/typescript/graphql-express/src/server.ts#L12).
+
+#### Do not explicitly `$disconnect()`
+
+You [do not need to explicitly `$disconnect()`](/orm/prisma-client/setup-and-configuration/databases-connections/connection-management#calling-disconnect-explicitly) in the context of a long-running application that is continuously serving requests. Opening a new connection takes time and can slow down your application if you disconnect after each query.
+
+#### Prevent hot reloading from creating new instances of `PrismaClient`
+
+Frameworks like [Next.js](https://nextjs.org/) support hot reloading of changed files, which enables you to see changes to your application without restarting. However, if the framework refreshes the module responsible for exporting `PrismaClient`, this can result in **additional, unwanted instances of `PrismaClient` in a development environment**.
+
+As a workaround, you can store `PrismaClient` as a global variable in development environments only, as global variables are not reloaded:
+
+```ts file=client.ts
+import { PrismaClient } from '@prisma/client'
+
+const globalForPrisma = globalThis as unknown as { prisma: PrismaClient }
+
+export const prisma =
+ globalForPrisma.prisma || new PrismaClient()
+
+if (process.env.NODE_ENV !== 'production') globalForPrisma.prisma = prisma
+```
+
+The way that you import and use Prisma Client does not change:
+
+```ts file=app.ts
+import { prisma } from './client'
+
+async function main() {
+ const allUsers = await prisma.user.findMany()
+}
+
+main()
+```
+
+## Connections Created per CLI Command
+
+In local tests with Postgres, MySQL, and SQLite, each Prisma CLI command typically uses a single connection. The table below shows the ranges observed in these tests. Your environment *may* produce slightly different results.
+
+| Command | Connections | Description |
+|---------|-------------|-------------|
+| [`migrate status`](/orm/reference/prisma-cli-reference#migrate-status) | 1 | Checks the status of migrations |
+| [`migrate dev`](/orm/reference/prisma-cli-reference#migrate-dev) | 1–4 | Applies pending migrations in development |
+| [`migrate diff`](/orm/reference/prisma-cli-reference#migrate-diff) | 1–2 | Compares database schema with migration history |
+| [`migrate reset`](/orm/reference/prisma-cli-reference#migrate-reset) | 1–2 | Resets the database and reapplies migrations |
+| [`migrate deploy`](/orm/reference/prisma-cli-reference#migrate-deploy) | 1–2 | Applies pending migrations in production |
+| [`db pull`](/orm/reference/prisma-cli-reference#db-pull) | 1 | Pulls the database schema into the Prisma schema |
+| [`db push`](/orm/reference/prisma-cli-reference#db-push) | 1–2 | Pushes the Prisma schema to the database |
+| [`db execute`](/orm/reference/prisma-cli-reference#db-execute) | 1 | Executes raw SQL commands |
+| [`db seed`](/orm/reference/prisma-cli-reference#db-seed) | 1 | Seeds the database with initial data |
+
+## Serverless environments (FaaS)
+
+Examples of serverless environments include Node.js functions hosted on AWS Lambda, Vercel or Netlify Functions. Use the following checklist as a guide to connection management in serverless environments:
+
+- Familiarize yourself with the [serverless connection management challenge](#the-serverless-challenge)
+- [Set pool size (`connection_limit`)](#recommended-connection-pool-size-1) based on whether you have an external connection pooler, and optionally [tune the pool size](#optimizing-the-connection-pool)
+- [Instantiate `PrismaClient` outside the handler](#instantiate-prismaclient-outside-the-handler) and do not explicitly `$disconnect()`
+- Configure [function concurrency](#concurrency-limits) and handle [idle connections](#zombie-connections)
+
+### The serverless challenge
+
+In a serverless environment, each function creates **its own instance** of `PrismaClient`, and each client instance has its own connection pool.
+
+Consider the following example, where a single AWS Lambda function uses `PrismaClient` to connect to a database. The `connection_limit` is **3**:
+
+
+
+A traffic spike causes AWS Lambda to spawn two additional lambdas to handle the increased load. Each lambda creates an instance of `PrismaClient`, each with a `connection_limit` of **3**, which results in a maximum of **9** connections to the database:
+
+
+
+200 _concurrent functions_ (and therefore 600 possible connections) responding to a traffic spike 📈 can exhaust the database connection limit very quickly. Furthermore, any functions that are **paused** keep their connections open by default and block them from being used by another function.
+
+1. Start by [setting the `connection_limit` to `1`](#recommended-connection-pool-size-1)
+2. If a smaller pool size is not enough, consider using an [external connection pooler like PgBouncer](#external-connection-poolers)
+
+### Recommended connection pool size
+
+The recommended pool size (`connection_limit`) in serverless environments depends on:
+
+- Whether you are using an [external connection pooler](#external-connection-poolers)
+- Whether your functions are [designed to send queries in parallel](#optimizing-for-parallel-requests)
+
+#### Without an external connection pooler
+
+If you are **not** using an external connection pooler, _start_ by setting the pool size (`connection_limit`) to **1**, then [optimize](#optimizing-for-parallel-requests). Each incoming request starts a short-lived Node.js process, and many concurrent functions with a high `connection_limit` can quickly **exhaust the _database_ connection limit** during a traffic spike.
+
+The following example demonstrates how to set the `connection_limit` to 1 in your connection URL:
+
+
+
+
+```
+postgresql://USER:PASSWORD@HOST:PORT/DATABASE?schema=public&connection_limit=1
+```
+
+
+
+
+```
+mysql://USER:PASSWORD@HOST:PORT/DATABASE?connection_limit=1
+```
+
+
+
+
+:::tip
+
+If you are using AWS Lambda and _not_ configuring a `connection_limit`, refer to the following GitHub issue for information about the expected default pool size: https://github.com/prisma/docs/issues/667
+
+:::
+
+#### With an external connection pooler
+
+If you are using an external connection pooler, use the default pool size (`num_physical_cpus * 2 + 1`) as a starting point and then [tune the pool size](#optimizing-the-connection-pool). The external connection pooler should prevent a traffic spike from overwhelming the database.
+
+#### Optimizing for parallel requests
+
+If you rarely or never exceed the database connection limit with the pool size set to 1, you can further optimize the connection pool size. Consider a function that sends queries in parallel:
+
+```ts
+Promise.all() {
+ query1,
+ query2,
+ query3
+ query4,
+ ...
+}
+```
+
+If the `connection_limit` is 1, this function is forced to send queries **serially** (one after the other) rather than **in parallel**. This slows down the function's ability to process requests, and may result in pool timeout errors. Tune the `connection_limit` parameter until a traffic spike:
+
+- Does not exhaust the database connection limit
+- Does not result in pool timeout errors
+
+### `PrismaClient` in serverless environments
+
+#### Instantiate `PrismaClient` outside the handler
+
+Instantiate `PrismaClient` [outside the scope of the function handler](https://github.com/prisma/e2e-tests/blob/5d1041d3f19245d3d237d959eca94d1d796e3a52/platforms/serverless-lambda/index.ts#L3) to increase the chances of reuse. As long as the handler remains 'warm' (in use), the connection is potentially reusable:
+
+```ts highlight=3;normal
+import { PrismaClient } from '@prisma/client'
+
+const client = new PrismaClient()
+
+export async function handler() {
+ /* ... */
+}
+```
+
+#### Do not explicitly `$disconnect()`
+
+You [do not need to explicitly `$disconnect()`](/orm/prisma-client/setup-and-configuration/databases-connections/connection-management#calling-disconnect-explicitly) at the end of a function, as there is a possibility that the container might be reused. Opening a new connection takes time and slows down your function's ability to process requests.
+
+### Other serverless considerations
+
+#### Container reuse
+
+There is no guarantee that subsequent nearby invocations of a function will hit the same container - for example, AWS can choose to create a new container at any time.
+
+Code should assume the container to be stateless and create a connection only if it does not exist - Prisma Client JS already implements this logic.
+
+#### Zombie connections
+
+Containers that are marked "to be removed" and are not being reused still **keep a connection open** and can stay in that state for some time (unknown and not documented from AWS). This can lead to sub-optimal utilization of the database connections.
+
+A potential solution is to **clean up idle connections** ([`serverless-mysql`](https://github.com/jeremydaly/serverless-mysql) implements this idea, but cannot be used with Prisma ORM).
+
+#### Concurrency limits
+
+Depending on your serverless concurrency limit (the number of serverless functions running in parallel), you might still exhaust your database's connection limit. This can happen when too many functions are invoked concurrently, each with its own connection pool, which eventually exhausts the database connection limit. To prevent this, you can [set your serverless concurrency limit](https://docs.aws.amazon.com/lambda/latest/dg/configuration-concurrency.html) to a number lower than the maximum connection limit of your database divided by the number of connections used by each function invocation (as you might want to be able to connect from another client for other purposes).
+
+## Optimizing the connection pool
+
+If the query engine cannot [process a query in the queue before the time limit](/orm/prisma-client/setup-and-configuration/databases-connections/connection-pool#how-the-connection-pool-works) , you will see connection pool timeout exceptions in your log. A connection pool timeout can occur if:
+
+- Many users are accessing your app simultaneously
+- You send a large number of queries in parallel (for example, using `await Promise.all()`)
+
+If you consistently experience connection pool timeouts after configuring the recommended pool size, you can further tune the `connection_limit` and `pool_timeout` parameters.
+
+### Increasing the pool size
+
+:::note
+
+As of [v6.16.0](https://pris.ly/release/6.16.0), Prisma ORM can be used without Rust engines in production applications. Learn more [here](/orm/prisma-client/setup-and-configuration/no-rust-engine).
+
+**When enabled, your Prisma Client will be generated without a Rust-based query engine binary**:
+
+```prisma
+generator client {
+ provider = "prisma-client-js" // or "prisma-client"
+ output = "../src/generated/prisma"
+ engineType = "client" // no Rust engine
+}
+```
+
+Note that [driver adapters](/orm/overview/databases/database-drivers#driver-adapters) are required if you want to use Prisma ORM without Rust engines. In this scenario, the connection pool size is set via the native JS driver you are using.
+
+You can [read about the performance and DX improvements](https://www.prisma.io/blog/prisma-orm-without-rust-latest-performance-benchmarks) of this change on our blog.
+
+:::
+
+
+Increasing the pool size allows the query engine to process a larger number of queries in parallel. Be aware that your database must be able to support the increased number of concurrent connections, otherwise you will **exhaust the database connection limit**.
+
+To increase the pool size, manually set the `connection_limit` to a higher number:
+
+```prisma
+datasource db {
+ provider = "postgresql"
+ url = "postgresql://johndoe:mypassword@localhost:5432/mydb?schema=public&connection_limit=40"
+}
+```
+
+> **Note**: Setting the `connection_limit` to 1 in serverless environments is a recommended starting point, but [this value can also be tuned](#optimizing-for-parallel-requests).
+
+### Increasing the pool timeout
+
+Increasing the pool timeout gives the query engine more time to process queries in the queue. You might consider this approach in the following scenario:
+
+- You have already increased the `connection_limit`.
+- You are confident that the queue will not grow beyond a certain size, otherwise **you will eventually run out of RAM**.
+
+To increase the pool timeout, set the `pool_timeout` parameter to a value larger than the default (10 seconds):
+
+```prisma
+datasource db {
+ provider = "postgresql"
+ url = "postgresql://johndoe:mypassword@localhost:5432/mydb?connection_limit=5&pool_timeout=20"
+}
+```
+
+### Disabling the pool timeout
+
+Disabling the pool timeout prevents the query engine from throwing an exception after x seconds of waiting for a connection and allows the queue to build up. You might consider this approach in the following scenario:
+
+- You are submitting a large number of queries for a limited time - for example, as part of a job to import or update every customer in your database.
+- You have already increased the `connection_limit`.
+- You are confident that the queue will not grow beyond a certain size, otherwise **you will eventually run out of RAM**.
+
+To disable the pool timeout, set the `pool_timeout` parameter to `0`:
+
+```prisma
+datasource db {
+ provider = "postgresql"
+ url = "postgresql://johndoe:mypassword@localhost:5432/mydb?connection_limit=5&pool_timeout=0"
+}
+```
+
+## External connection poolers
+
+Connection poolers like [Prisma Accelerate](/accelerate) and PgBouncer prevent your application from exhausting the database's connection limit.
+
+If you would like to use the Prisma CLI in order to perform other actions on your database ,e.g. migrations and introspection, you will need to add an environment variable that provides a direct connection to your database in the `datasource.directUrl` property in your Prisma schema:
+
+```env file=.env highlight=4,5;add showLineNumbers
+# Connection URL to your database using PgBouncer.
+DATABASE_URL="postgres://root:password@127.0.0.1:54321/postgres?pgbouncer=true"
+
+//add-start
+# Direct connection URL to the database used for migrations
+DIRECT_URL="postgres://root:password@127.0.0.1:5432/postgres"
+//add-end
+```
+
+You can then update your `schema.prisma` to use the new direct URL:
+
+```prisma file=schema.prisma highlight=4;add showLineNumbers
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+ //add-next-line
+ directUrl = env("DIRECT_URL")
+}
+```
+
+More information about the `directUrl` field can be found [here](/orm/reference/prisma-schema-reference#fields).
+
+### Prisma Accelerate
+
+[Prisma Accelerate](/accelerate) is a managed external connection pooler built by Prisma that is integrated in the [Prisma Data Platform](/platform) and handles connection pooling for you.
+
+### PgBouncer
+
+PostgreSQL only supports a certain amount of concurrent connections, and this limit can be reached quite fast when the service usage goes up – especially in [serverless environments](#serverless-environments-faas).
+
+[PgBouncer](https://www.pgbouncer.org/) holds a connection pool to the database and proxies incoming client connections by sitting between Prisma Client and the database. This reduces the number of processes a database has to handle at any given time. PgBouncer passes on a limited number of connections to the database and queues additional connections for delivery when connections becomes available. To use PgBouncer, see [Configure Prisma Client with PgBouncer](/orm/prisma-client/setup-and-configuration/databases-connections/pgbouncer).
+
+### AWS RDS Proxy
+
+Due to the way AWS RDS Proxy pins connections, [it does not provide any connection pooling benefits](/orm/prisma-client/deployment/caveats-when-deploying-to-aws-platforms#aws-rds-proxy) when used together with Prisma Client.
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/050-databases-connections/serverless-connections-2.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/050-databases-connections/serverless-connections-2.png
new file mode 100644
index 0000000000..a933db1341
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/050-databases-connections/serverless-connections-2.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/050-databases-connections/serverless-connections.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/050-databases-connections/serverless-connections.png
new file mode 100644
index 0000000000..6c4b56ea9b
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/050-databases-connections/serverless-connections.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/100-custom-model-and-field-names.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/100-custom-model-and-field-names.mdx
new file mode 100644
index 0000000000..9f4ed49d8b
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/100-custom-model-and-field-names.mdx
@@ -0,0 +1,319 @@
+---
+title: 'Custom model and field names'
+metaTitle: 'Custom model and field names'
+metaDescription: 'Learn how you can decouple the naming of Prisma models from database tables to improve the ergonomics of the generated Prisma Client API.'
+---
+
+
+
+The Prisma Client API is generated based on the models in your [Prisma schema](/orm/prisma-schema). Models are _typically_ 1:1 mappings of your database tables.
+
+In some cases, especially when using [introspection](/orm/prisma-schema/introspection), it might be useful to _decouple_ the naming of database tables and columns from the names that are used in your Prisma Client API. This can be done via the [`@map` and `@@map`](/orm/prisma-schema/data-model/models#mapping-model-names-to-tables-or-collections) attributes in your Prisma schema.
+
+You can use `@map` and `@@map` to rename MongoDB fields and collections respectively. This page uses a relational database example.
+
+
+
+## Example: Relational database
+
+Assume you have a PostgreSQL relational database schema looking similar to this:
+
+```sql
+CREATE TABLE users (
+ user_id SERIAL PRIMARY KEY NOT NULL,
+ name VARCHAR(256),
+ email VARCHAR(256) UNIQUE NOT NULL
+);
+CREATE TABLE posts (
+ post_id SERIAL PRIMARY KEY NOT NULL,
+ created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
+ title VARCHAR(256) NOT NULL,
+ content TEXT,
+ author_id INTEGER REFERENCES users(user_id)
+);
+CREATE TABLE profiles (
+ profile_id SERIAL PRIMARY KEY NOT NULL,
+ bio TEXT,
+ user_id INTEGER NOT NULL UNIQUE REFERENCES users(user_id)
+);
+CREATE TABLE categories (
+ category_id SERIAL PRIMARY KEY NOT NULL,
+ name VARCHAR(256)
+);
+CREATE TABLE post_in_categories (
+ post_id INTEGER NOT NULL REFERENCES posts(post_id),
+ category_id INTEGER NOT NULL REFERENCES categories(category_id)
+);
+CREATE UNIQUE INDEX post_id_category_id_unique ON post_in_categories(post_id int4_ops,category_id int4_ops);
+```
+
+When introspecting a database with that schema, you'll get a Prisma schema looking similar to this:
+
+```prisma
+model categories {
+ category_id Int @id @default(autoincrement())
+ name String? @db.VarChar(256)
+ post_in_categories post_in_categories[]
+}
+
+model post_in_categories {
+ post_id Int
+ category_id Int
+ categories categories @relation(fields: [category_id], references: [category_id], onDelete: NoAction, onUpdate: NoAction)
+ posts posts @relation(fields: [post_id], references: [post_id], onDelete: NoAction, onUpdate: NoAction)
+
+ @@unique([post_id, category_id], map: "post_id_category_id_unique")
+}
+
+model posts {
+ post_id Int @id @default(autoincrement())
+ created_at DateTime? @default(now()) @db.Timestamptz(6)
+ title String @db.VarChar(256)
+ content String?
+ author_id Int?
+ users users? @relation(fields: [author_id], references: [user_id], onDelete: NoAction, onUpdate: NoAction)
+ post_in_categories post_in_categories[]
+}
+
+model profiles {
+ profile_id Int @id @default(autoincrement())
+ bio String?
+ user_id Int @unique
+ users users @relation(fields: [user_id], references: [user_id], onDelete: NoAction, onUpdate: NoAction)
+}
+
+model users {
+ user_id Int @id @default(autoincrement())
+ name String? @db.VarChar(256)
+ email String @unique @db.VarChar(256)
+ posts posts[]
+ profiles profiles?
+}
+```
+
+There are a few "issues" with this Prisma schema when the Prisma Client API is generated:
+
+**Adhering to Prisma ORM's naming conventions**
+
+Prisma ORM has a [naming convention](/orm/reference/prisma-schema-reference#naming-conventions) of **camelCasing** and using the **singular form** for Prisma models. If these naming conventions are not met, the Prisma schema can become harder to interpret and the generated Prisma Client API will feel less natural. Consider the following, generated model:
+
+```prisma
+model users {
+ user_id Int @id @default(autoincrement())
+ name String? @db.VarChar(256)
+ email String @unique @db.VarChar(256)
+ posts posts[]
+ profiles profiles?
+}
+```
+
+Although `profiles` refers to a 1:1 relation, its type is currently called `profiles` in plural, suggesting that there might be many `profiles` in this relation. With Prisma ORM conventions, the models and fields were _ideally_ named as follows:
+
+```prisma
+model User {
+ user_id Int @id @default(autoincrement())
+ name String? @db.VarChar(256)
+ email String @unique @db.VarChar(256)
+ posts Post[]
+ profile Profile?
+}
+```
+
+Because these fields are "Prisma ORM-level" [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) that do not manifest you can manually rename them in your Prisma schema.
+
+**Naming of annotated relation fields**
+
+Foreign keys are represented as a combination of a [annotated relation fields](/orm/prisma-schema/data-model/relations#relation-fields) and its corresponding relation scalar field in the Prisma schema. Here's how all the relations from the SQL schema are currently represented:
+
+```prisma
+model categories {
+ category_id Int @id @default(autoincrement())
+ name String? @db.VarChar(256)
+ post_in_categories post_in_categories[] // virtual relation field
+}
+
+model post_in_categories {
+ post_id Int // relation scalar field
+ category_id Int // relation scalar field
+ categories categories @relation(fields: [category_id], references: [category_id], onDelete: NoAction, onUpdate: NoAction) // virtual relation field
+ posts posts @relation(fields: [post_id], references: [post_id], onDelete: NoAction, onUpdate: NoAction)
+
+ @@unique([post_id, category_id], map: "post_id_category_id_unique")
+}
+
+model posts {
+ post_id Int @id @default(autoincrement())
+ created_at DateTime? @default(now()) @db.Timestamptz(6)
+ title String @db.VarChar(256)
+ content String?
+ author_id Int?
+ users users? @relation(fields: [author_id], references: [user_id], onDelete: NoAction, onUpdate: NoAction)
+ post_in_categories post_in_categories[]
+}
+
+model profiles {
+ profile_id Int @id @default(autoincrement())
+ bio String?
+ user_id Int @unique
+ users users @relation(fields: [user_id], references: [user_id], onDelete: NoAction, onUpdate: NoAction)
+}
+
+model users {
+ user_id Int @id @default(autoincrement())
+ name String? @db.VarChar(256)
+ email String @unique @db.VarChar(256)
+ posts posts[]
+ profiles profiles?
+}
+```
+
+## Using `@map` and `@@map` to rename fields and models in the Prisma Client API
+
+You can "rename" fields and models that are used in Prisma Client by mapping them to the "original" names in the database using the `@map` and `@@map` attributes. For the example above, you could e.g. annotate your models as follows.
+
+_After_ you introspected your database with `prisma db pull`, you can manually adjust the resulting Prisma schema as follows:
+
+```prisma
+model Category {
+ id Int @id @default(autoincrement()) @map("category_id")
+ name String? @db.VarChar(256)
+ post_in_categories PostInCategories[]
+
+ @@map("categories")
+}
+
+model PostInCategories {
+ post_id Int
+ category_id Int
+ categories Category @relation(fields: [category_id], references: [id], onDelete: NoAction, onUpdate: NoAction)
+ posts Post @relation(fields: [post_id], references: [id], onDelete: NoAction, onUpdate: NoAction)
+
+ @@unique([post_id, category_id], map: "post_id_category_id_unique")
+ @@map("post_in_categories")
+}
+
+model Post {
+ id Int @id @default(autoincrement()) @map("post_id")
+ created_at DateTime? @default(now()) @db.Timestamptz(6)
+ title String @db.VarChar(256)
+ content String?
+ author_id Int?
+ users User? @relation(fields: [author_id], references: [id], onDelete: NoAction, onUpdate: NoAction)
+ post_in_categories PostInCategories[]
+
+ @@map("posts")
+}
+
+model Profile {
+ id Int @id @default(autoincrement()) @map("profile_id")
+ bio String?
+ user_id Int @unique
+ users User @relation(fields: [user_id], references: [id], onDelete: NoAction, onUpdate: NoAction)
+
+ @@map("profiles")
+}
+
+model User {
+ id Int @id @default(autoincrement()) @map("user_id")
+ name String? @db.VarChar(256)
+ email String @unique @db.VarChar(256)
+ posts Post[]
+ profiles Profile?
+
+ @@map("users")
+}
+```
+
+With these changes, you're now adhering to Prisma ORM's naming conventions and the generated Prisma Client API feels more "natural":
+
+```ts
+// Nested writes
+const profile = await prisma.profile.create({
+ data: {
+ bio: 'Hello World',
+ users: {
+ create: {
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ },
+ },
+ },
+})
+
+// Fluent API
+const userByProfile = await prisma.profile
+ .findUnique({
+ where: { id: 1 },
+ })
+ .users()
+```
+
+:::info
+
+`prisma db pull` preserves the custom names you defined via `@map` and `@@map` in your Prisma schema on re-introspecting your database.
+
+:::
+
+
+## Renaming relation fields
+
+Prisma ORM-level [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) (sometimes referred to as "virtual relation fields") only exist in the Prisma schema, but do not actually manifest in the underlying database. You can therefore name these fields whatever you want.
+
+Consider the following example of an ambiguous relation in a SQL database:
+
+```sql
+CREATE TABLE "User" (
+ id SERIAL PRIMARY KEY
+);
+CREATE TABLE "Post" (
+ id SERIAL PRIMARY KEY,
+ "author" integer NOT NULL,
+ "favoritedBy" INTEGER,
+ FOREIGN KEY ("author") REFERENCES "User"(id),
+ FOREIGN KEY ("favoritedBy") REFERENCES "User"(id)
+);
+```
+
+Prisma ORM's introspection will output the following Prisma schema:
+
+```prisma
+model Post {
+ id Int @id @default(autoincrement())
+ author Int
+ favoritedBy Int?
+ User_Post_authorToUser User @relation("Post_authorToUser", fields: [author], references: [id], onDelete: NoAction, onUpdate: NoAction)
+ User_Post_favoritedByToUser User? @relation("Post_favoritedByToUser", fields: [favoritedBy], references: [id], onDelete: NoAction, onUpdate: NoAction)
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ Post_Post_authorToUser Post[] @relation("Post_authorToUser")
+ Post_Post_favoritedByToUser Post[] @relation("Post_favoritedByToUser")
+}
+```
+
+Because the names of the virtual relation fields `Post_Post_authorToUser` and `Post_Post_favoritedByToUser` are based on the generated relation names, they don't look very friendly in the Prisma Client API. In that case, you can rename the relation fields. For example:
+
+```prisma highlight=11-12;edit
+model Post {
+ id Int @id @default(autoincrement())
+ author Int
+ favoritedBy Int?
+ User_Post_authorToUser User @relation("Post_authorToUser", fields: [author], references: [id], onDelete: NoAction, onUpdate: NoAction)
+ User_Post_favoritedByToUser User? @relation("Post_favoritedByToUser", fields: [favoritedBy], references: [id], onDelete: NoAction, onUpdate: NoAction)
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ //edit-start
+ writtenPosts Post[] @relation("Post_authorToUser")
+ favoritedPosts Post[] @relation("Post_favoritedByToUser")
+ //edit-end
+}
+```
+
+:::info
+
+`prisma db pull` preserves custom relation fields defined in your Prisma schema on re-introspecting your database.
+
+:::
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/150-error-formatting.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/150-error-formatting.mdx
new file mode 100644
index 0000000000..ed335f0f31
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/150-error-formatting.mdx
@@ -0,0 +1,41 @@
+---
+title: 'Configuring error formatting'
+metaTitle: 'Configuring error formatting (Concepts)'
+metaDescription: 'This page explains how to configure the formatting of errors when using Prisma Client.'
+---
+
+
+
+By default, Prisma Client uses [ANSI escape characters](https://en.wikipedia.org/wiki/ANSI_escape_code) to pretty print the error stack and give recommendations on how to fix a problem. While this is very useful when using Prisma Client from the terminal, in contexts like a GraphQL API, you only want the minimal error without any additional formatting.
+
+This page explains how error formatting can be configured with Prisma Client.
+
+
+
+## Formatting levels
+
+There are 3 error formatting levels:
+
+1. **Pretty Error** (default): Includes a full stack trace with colors, syntax highlighting of the code and extended error message with a possible solution for the problem.
+2. **Colorless Error**: Same as pretty errors, just without colors.
+3. **Minimal Error**: The raw error message.
+
+In order to configure these different error formatting levels, there are two options:
+
+- Setting the config options via environment variables
+- Providing the config options to the `PrismaClient` constructor
+
+## Formatting via environment variables
+
+- [`NO_COLOR`](/orm/reference/environment-variables-reference#no_color): If this env var is provided, colors are stripped from the error messages. Therefore you end up with a **colorless error**. The `NO_COLOR` environment variable is a standard described [here](https://no-color.org/).
+- `NODE_ENV=production`: If the env var `NODE_ENV` is set to `production`, only the **minimal error** will be printed. This allows for easier digestion of logs in production environments.
+
+### Formatting via the `PrismaClient` constructor
+
+Alternatively, use the `PrismaClient` [`errorFormat`](/6.0/orm/reference/prisma-client-reference#errorformat) parameter to set the error format:
+
+```ts
+const prisma = new PrismaClient({
+ errorFormat: 'pretty',
+})
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/200-read-replicas.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/200-read-replicas.mdx
new file mode 100644
index 0000000000..ef695f72d3
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/200-read-replicas.mdx
@@ -0,0 +1,83 @@
+---
+title: 'Read replicas'
+metaTitle: 'Read replicas'
+metaDescription: 'Learn how to set up and use read replicas with Prisma Client'
+tocDepth: 3
+---
+
+
+
+Read replicas enable you to distribute workloads across database replicas for high-traffic workloads. The [read replicas extension](https://github.com/prisma/extension-read-replicas), `@prisma/extension-read-replicas`, adds support for read-only database replicas to Prisma Client.
+
+The read replicas extension supports Prisma ORM versions [5.2.0](https://github.com/prisma/prisma/releases/tag/5.2.0) and higher. If you run into a bug or have feedback, create a GitHub issue [here](https://github.com/prisma/extension-read-replicas/issues/new).
+
+
+
+## Setup the read replicas extension
+
+Install the extension:
+
+```terminal
+npm install @prisma/extension-read-replicas
+```
+
+Initialize the extension by extending your Prisma Client instance and provide the extension a connection string that points to your read replica in the `url` option of the extension.
+
+
+
+```ts
+import { PrismaClient } from '@prisma/client'
+import { readReplicas } from '@prisma/extension-read-replicas'
+
+const prisma = new PrismaClient().$extends(
+ readReplicas({
+ url: process.env.DATABASE_URL_REPLICA,
+ })
+)
+
+// Query is run against the database replica
+await prisma.post.findMany()
+
+// Query is run against the primary database
+await prisma.post.create({
+ data: {/** */},
+})
+```
+
+
+All read operations, e.g. `findMany`, will be executed against the database replica with the above setup. All write operations — e.g. `create`, `update` — and `$transaction` queries, will be executed against your primary database.
+
+If you run into a bug or have feedback, create a GitHub issue [here](https://github.com/prisma/extension-read-replicas/issues/new).
+
+## Configure multiple database replicas
+
+The `url` property also accepts an array of values, i.e. an array of all your database replicas you would like to configure:
+
+```ts
+const prisma = new PrismaClient().$extends(
+ readReplicas({
+ url: [
+ process.env.DATABASE_URL_REPLICA_1,
+ process.env.DATABASE_URL_REPLICA_2,
+ ],
+ })
+)
+```
+
+If you have more than one read replica configured, a database replica will be randomly selected to execute your query.
+
+## Executing read operations against your primary database
+
+You can use the `$primary()` method to explicitly execute a read operation against your primary database:
+
+```ts
+const posts = await prisma.$primary().post.findMany()
+```
+
+## Executing operations against a database replica
+
+You can use the `$replica()` method to explicitly execute your query against a replica instead of your primary database:
+
+```ts
+const result = await prisma.$replica().user.findFirst(...)
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/220-database-polyfills.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/220-database-polyfills.mdx
new file mode 100644
index 0000000000..56e53b6e50
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/220-database-polyfills.mdx
@@ -0,0 +1,23 @@
+---
+title: 'Database polyfills'
+metaTitle: 'Database polyfills (Concepts)'
+metaDescription: 'Prisma Client provides features that are not achievable with relational databases. These features are referred to as "polyfills" and explained on this page.'
+hide_table_of_contents: true
+---
+
+
+
+Prisma Client provides features that are typically either not achievable with particular databases or require extensions. These features are referred to as _polyfills_. For all databases, this includes:
+
+- Initializing [ID](/orm/prisma-schema/data-model/models#defining-an-id-field) values with `cuid` and `uuid` values
+- Using [`@updatedAt`](/orm/prisma-schema/data-model/models#defining-attributes) to store the time when a record was last updated
+
+For relational databases, this includes:
+
+- [Implicit many-to-many relations](/orm/prisma-schema/data-model/relations/many-to-many-relations#implicit-many-to-many-relations)
+
+For MongoDB, this includes:
+
+- [Relations in general](/orm/prisma-schema/data-model/relations) - foreign key relations between documents are not enforced in MongoDB
+
+
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/300-no-rust-engine.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/300-no-rust-engine.mdx
new file mode 100644
index 0000000000..a23c2016fd
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/300-no-rust-engine.mdx
@@ -0,0 +1,456 @@
+---
+title: "No Rust engine"
+metaTitle: "Use Prisma ORM without Rust engines"
+metaDescription: "Learn how to use Prisma ORM without Rust engines"
+---
+
+As of [v6.16.0](https://pris.ly/release/6.16.0), usage of Prisma ORM without [Rust engine](/orm/more/under-the-hood/engines) binaries on PostgreSQL, CockroachDB, Neon, MySQL, PlanetScale, SQLite, D1 & MS SQL Server databases has been [Generally Available](/orm/more/releases#generally-available-ga).
+
+This page gives an overview of how to use this version of Prisma ORM.
+
+## Prisma ORM without Rust engines
+
+The main technical differences if you're using Prisma ORM without a Rust engine are:
+
+- no `binaryTargets` field on the `generator` block
+- no query engine binary that's downloaded into the directory with your generated Prisma Client
+- `engineType` needs to be set to `"client"` on the `generator` block
+- required usage of [driver adapters](/orm/overview/databases/database-drivers#driver-adapters) for database connection management
+
+:::warning
+The Rust-free version of Prisma ORM has been thoroughly tested with the `prisma-client` generator (see below), not with `prisma-client-js`. Use the old generator at your discretion.
+:::
+
+## Usage
+
+### Prerequisites
+
+- Prisma ORM v6.15.0 (or later)
+
+### 1. Set `engineType` on the `generator` block
+
+```prisma file=schema.prisma
+generator client {
+ provider = "prisma-client" // or `prisma-client-js`
+ output = "../generated/prisma"
+ engineType = "client" // enable Prisma ORM without Rust
+}
+```
+
+### 2. Re-generate Prisma Client
+
+To make the configuration take effect, you need re-generate Prisma Client:
+
+```terminal
+npx prisma generate
+```
+
+### 3. Install the driver adapter
+
+Depending on the database you use, you need to install a different driver adapter library:
+
+
+
+```terminal
+npm install @prisma/adapter-pg
+```
+
+
+```terminal
+npm install @prisma/adapter-better-sqlite3
+```
+
+
+```terminal
+npm install @prisma/adapter-d1
+```
+
+
+```terminal
+npm install @prisma/adapter-mariadb
+```
+
+
+```terminal
+npm install @prisma/adapter-planetscale
+```
+
+
+```terminal
+npm install @prisma/adapter-mssql
+```
+
+
+```terminal
+npm install @prisma/adapter-pg
+```
+
+
+```terminal
+npm install @prisma/adapter-neon
+```
+
+
+
+### 4. Instantiate Prisma Client
+
+Finally, instantiate Prisma Client which you can do using the driver adapter and the connection URL for the database instance you're using:
+
+
+
+```typescript
+import { PrismaPg } from '@prisma/adapter-pg'
+import { PrismaClient } from './generated/prisma'
+
+const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL })
+const prisma = new PrismaClient({ adapter })
+```
+
+
+```typescript
+import { PrismaBetterSQLite3 } from '@prisma/adapter-better-sqlite3';
+import { PrismaClient } from './generated/prisma';
+
+const adapter = new PrismaBetterSQLite3({ url: process.env.DATABASE_URL })
+const prisma = new PrismaClient({ adapter });
+```
+
+
+```typescript
+import { PrismaClient } from './generated/prisma'
+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 })
+ // …
+ // ... query your DB
+ },
+}
+```
+
+
+```typescript
+import { PrismaMariaDb } from '@prisma/adapter-mariadb';
+import { PrismaClient } from './generated/prisma';
+
+const adapter = new PrismaMariaDb({
+ host: "localhost",
+ port: 3306,
+ connectionLimit: 5
+});
+const prisma = new PrismaClient({ adapter });
+```
+
+
+```typescript
+import { PrismaPlanetScale } from '@prisma/adapter-planetscale'
+import { PrismaClient } from './generated/prisma'
+import { fetch as undiciFetch } from 'undici'
+
+const adapter = new PrismaPlanetScale({ url: process.env.DATABASE_URL, fetch: undiciFetch })
+const prisma = new PrismaClient({ adapter })
+```
+
+
+```typescript
+import { PrismaMSSQL } from '@prisma/adapter-mssql';
+import { PrismaClient } from './generated/prisma';
+
+const sqlConfig = {
+ user: process.env.DB_USER,
+ password: process.env.DB_PASSWORD,
+ database: process.env.DB_NAME,
+ server: process.env.HOST,
+ pool: {
+ max: 10,
+ min: 0,
+ idleTimeoutMillis: 30000
+ },
+ options: {
+ encrypt: true, // for azure
+ trustServerCertificate: false // change to true for local dev / self-signed certs
+ }
+}
+
+const adapter = new PrismaMSSQL(sqlConfig)
+const prisma = new PrismaClient({ adapter });
+```
+
+
+```typescript
+import { PrismaPg } from '@prisma/adapter-pg'
+import { PrismaClient } from './generated/prisma'
+
+const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL })
+const prisma = new PrismaClient({ adapter })
+```
+
+
+```typescript
+import { PrismaClient } from './generated/prisma'
+import { PrismaNeon } from '@prisma/adapter-neon'
+import dotenv from 'dotenv'
+
+dotenv.config()
+const connectionString = `${process.env.DATABASE_URL}`
+
+const adapter = new PrismaNeon({ connectionString })
+const prisma = new PrismaClient({ adapter })
+```
+
+
+
+### 5. Query your database
+
+If you went through the previous steps, you can query your database as you're used to with Prisma Client. No other changes are needed.
+
+## Usage with Prisma Accelerate or Prisma Postgres
+
+When using the Rust-free version of Prisma ORM with [Prisma Accelerate](/accelerate) or [Prisma Postgres](/postgres), you **should not** use driver adapters. Instead, you can directly instantiate Prisma Client with the appropriate extension.
+
+### 1. Set `engineType` on the `generator` block
+
+```prisma file=schema.prisma
+generator client {
+ provider = "prisma-client" // or `prisma-client-js`
+ output = "../generated/prisma"
+ engineType = "client" // enable Prisma ORM without Rust
+}
+```
+
+### 2. Re-generate Prisma Client
+
+To make the configuration take effect, you need re-generate Prisma Client:
+
+```terminal
+npx prisma generate
+```
+
+### 3. Instantiate Prisma Client with Accelerate
+
+Import and instantiate Prisma Client with the Accelerate extension:
+
+```typescript
+import { PrismaClient } from "./generated/prisma";
+import { withAccelerate } from "@prisma/extension-accelerate";
+
+const prisma = new PrismaClient().$extends(withAccelerate());
+```
+### 4. Query your database
+
+If you went through the previous steps, you can query your database as you're used to with Prisma Client. No other changes are needed.
+
+## Usage with older versions (Preview)
+
+The Rust-free version of Prisma ORM has been in Preview from versions v6.7.0 to v.6.14.0. Expand below if you're using any of these versions and are unable to upgrade to the latest one.
+
+
+
+Expand to see instructions for Prisma ORM v6.7.0 to v6.14.0
+
+### Prerequisites
+
+- Any Prisma ORM version between 6.7.0 and 6.14.0
+
+### 1. Set feature flags
+
+Usage of the new architecture requires the `driverAdapters` and `queryCompiler` feature flags to be set:
+
+```prisma file=schema.prisma
+generator client {
+ provider = "prisma-client-js" // or `prisma-client`
+ previewFeatures = ["queryCompiler", "driverAdapters"]
+ output = "../generated/prisma"
+}
+```
+
+### 2. Re-generate Prisma Client
+
+To make the feature flags take effect, you need re-generate Prisma Client:
+
+```terminal
+npx prisma generate
+```
+
+### 3. Install the driver adapter
+
+Depending on the database you use, you need to install a different driver adapter library:
+
+
+
+```terminal
+npm install @prisma/adapter-pg
+```
+
+
+```terminal
+npm install @prisma/adapter-better-sqlite3
+```
+
+
+```terminal
+npm install @prisma/adapter-d1
+```
+
+
+```terminal
+npm install @prisma/adapter-mariadb
+```
+
+
+```terminal
+npm install @prisma/adapter-planetscale
+```
+
+
+```terminal
+npm install @prisma/adapter-mssql
+```
+
+
+```terminal
+npm install @prisma/adapter-pg
+```
+
+
+```terminal
+npm install @prisma/adapter-neon
+```
+
+
+
+### 4. Instantiate Prisma Client
+
+Finally, you need to instantiate Prisma Client which you can do using the driver adapter and the connection URL for the database instance you're using.
+
+
+
+```typescript
+import { PrismaPg } from '@prisma/adapter-pg'
+import { PrismaClient } from './generated/prisma'
+
+const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL })
+const prisma = new PrismaClient({ adapter })
+```
+
+
+```typescript
+import { PrismaBetterSQLite3 } from '@prisma/adapter-better-sqlite3';
+import { PrismaClient } from './generated/prisma';
+
+const adapter = new PrismaBetterSQLite3({ url: process.env.DATABASE_URL })
+const prisma = new PrismaClient({ adapter });
+```
+
+
+```typescript
+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 })
+
+ // ... query your DB
+ },
+}
+```
+
+
+```typescript
+import { PrismaMariaDb } from '@prisma/adapter-mariadb';
+import { PrismaClient } from './generated/prisma';
+
+const adapter = new PrismaMariaDb({
+ host: "localhost",
+ port: 3306,
+ connectionLimit: 5
+});
+const prisma = new PrismaClient({ adapter });
+```
+
+
+```typescript
+import { PrismaPlanetScale } from '@prisma/adapter-planetscale'
+import { PrismaClient } from '@prisma/client'
+import { fetch as undiciFetch } from 'undici'
+
+const adapter = new PrismaPlanetScale({ url: process.env.DATABASE_URL, fetch: undiciFetch })
+const prisma = new PrismaClient({ adapter })
+```
+
+
+```typescript
+import { PrismaMSSQL } from '@prisma/adapter-mssql';
+import { PrismaClient } from './generated/prisma';
+
+const sqlConfig = {
+ user: process.env.DB_USER,
+ password: process.env.DB_PASSWORD,
+ database: process.env.DB_NAME,
+ server: process.env.HOST,
+ pool: {
+ max: 10,
+ min: 0,
+ idleTimeoutMillis: 30000
+ },
+ options: {
+ encrypt: true, // for azure
+ trustServerCertificate: false // change to true for local dev / self-signed certs
+ }
+}
+
+const adapter = new PrismaMSSQL(sqlConfig)
+const prisma = new PrismaClient({ adapter });
+```
+
+
+```typescript
+import { PrismaPg } from '@prisma/adapter-pg'
+import { PrismaClient } from './generated/prisma'
+
+const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL })
+const prisma = new PrismaClient({ adapter })
+```
+
+
+```typescript
+import { PrismaClient } from '@prisma/client'
+import { PrismaNeon } from '@prisma/adapter-neon'
+import dotenv from 'dotenv'
+
+dotenv.config()
+const connectionString = `${process.env.DATABASE_URL}`
+
+const adapter = new PrismaNeon({ connectionString })
+const prisma = new PrismaClient({ adapter })
+```
+
+
+
+### 5. Query your database
+
+If you went through the previous steps, you can query your database as you're used to with Prisma Client. No other changes are needed.
+
+
+
+
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/index.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/index.mdx
new file mode 100644
index 0000000000..527d95a3ce
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/index.mdx
@@ -0,0 +1,16 @@
+---
+title: 'Setup & configuration'
+metaTitle: 'Setup & configuration'
+metaDescription: 'This section explains how to generate, configure, and instantiate Prisma Client, as well as when and how to manage database connections.'
+hide_table_of_contents: true
+---
+
+
+
+This section describes how to set up, generate, configure, and instantiate `PrismaClient` , as well as when and how to actively [manage connections](/orm/prisma-client/setup-and-configuration/databases-connections/connection-management).
+
+
+
+## In this section
+
+
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/prisma-client-generation-workflow.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/prisma-client-generation-workflow.png
new file mode 100644
index 0000000000..1faf99964c
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/prisma-client-generation-workflow.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/prisma-client-node-module.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/prisma-client-node-module.png
new file mode 100644
index 0000000000..890f494d68
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/000-setup-and-configuration/prisma-client-node-module.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/030-crud.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/030-crud.mdx
new file mode 100644
index 0000000000..0703638290
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/030-crud.mdx
@@ -0,0 +1,1107 @@
+---
+title: 'CRUD'
+metaTitle: 'CRUD (Reference)'
+metaDescription: 'How to perform CRUD with Prisma Client.'
+toc_max_heading_level: 4
+---
+
+
+
+This page describes how to perform CRUD operations with your generated Prisma Client API. CRUD is an acronym that stands for:
+
+- [Create](#create)
+- [Read](#read)
+- [Update](#update)
+- [Delete](#delete)
+
+Refer to the [Prisma Client API reference documentation](/orm/reference/prisma-client-reference) for detailed explanations of each method.
+
+
+
+## Example schema
+
+All examples are based on the following schema:
+
+
+
+Expand for sample schema
+
+
+
+
+```prisma
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+
+generator client {
+ provider = "prisma-client-js"
+}
+
+model ExtendedProfile {
+ id Int @id @default(autoincrement())
+ biography String
+ user User @relation(fields: [userId], references: [id])
+ userId Int @unique
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ name String?
+ email String @unique
+ profileViews Int @default(0)
+ role Role @default(USER)
+ coinflips Boolean[]
+ posts Post[]
+ profile ExtendedProfile?
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ published Boolean @default(true)
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+ comments Json?
+ views Int @default(0)
+ likes Int @default(0)
+ categories Category[]
+}
+
+model Category {
+ id Int @id @default(autoincrement())
+ name String @unique
+ posts Post[]
+}
+
+enum Role {
+ USER
+ ADMIN
+}
+```
+
+
+
+
+```prisma
+datasource db {
+ provider = "mongodb"
+ url = env("DATABASE_URL")
+}
+
+generator client {
+ provider = "prisma-client-js"
+}
+
+model ExtendedProfile {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ biography String
+ user User @relation(fields: [userId], references: [id])
+ userId String @unique @db.ObjectId
+}
+
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ name String?
+ email String @unique
+ profileViews Int @default(0)
+ role Role @default(USER)
+ coinflips Boolean[]
+ posts Post[]
+ profile ExtendedProfile?
+}
+
+model Post {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ title String
+ published Boolean @default(true)
+ author User @relation(fields: [authorId], references: [id])
+ authorId String @db.ObjectId
+ comments Json?
+ views Int @default(0)
+ likes Int @default(0)
+ categories Category[]
+}
+
+model Category {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ name String @unique
+ posts Post[]
+}
+
+enum Role {
+ USER
+ ADMIN
+}
+```
+
+
+
+
+
+
+For **relational databases**, use `db push` command to push the example schema to your own database
+
+```terminal
+npx prisma db push
+```
+
+For **MongoDB**, ensure your data is in a uniform shape and matches the model defined in the Prisma schema.
+
+## Create
+
+### Create a single record
+
+The following query creates ([`create()`](/6.0/orm/reference/prisma-client-reference#create)) a single user with two fields:
+
+
+
+
+```ts
+const user = await prisma.user.create({
+ data: {
+ email: 'elsa@prisma.io',
+ name: 'Elsa Prisma',
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ id: 22,
+ name: 'Elsa Prisma',
+ email: 'elsa@prisma.io',
+ profileViews: 0,
+ role: 'USER',
+ coinflips: []
+}
+```
+
+
+
+
+The user's `id` is auto-generated, and your schema determines [which fields are mandatory](/orm/prisma-schema/data-model/models#optional-and-mandatory-fields).
+
+#### Create a single record using generated types
+
+The following example produces an identical result, but creates a `UserCreateInput` variable named `user` _outside_ the context of the `create()` query. After completing a simple check ("Should posts be included in this `create()` query?"), the `user` variable is passed into the query:
+
+```ts
+import { PrismaClient, Prisma } from '@prisma/client'
+
+const prisma = new PrismaClient()
+
+async function main() {
+ let includePosts: boolean = false
+ let user: Prisma.UserCreateInput
+
+ // Check if posts should be included in the query
+ if (includePosts) {
+ user = {
+ email: 'elsa@prisma.io',
+ name: 'Elsa Prisma',
+ posts: {
+ create: {
+ title: 'Include this post!',
+ },
+ },
+ }
+ } else {
+ user = {
+ email: 'elsa@prisma.io',
+ name: 'Elsa Prisma',
+ }
+ }
+
+ // Pass 'user' object into query
+ const createUser = await prisma.user.create({ data: user })
+}
+
+main()
+```
+
+For more information about working with generated types, see: [Generated types](/orm/prisma-client/type-safety).
+
+### Create multiple records
+
+Prisma Client supports bulk inserts as a GA feature in [2.20.0](https://github.com/prisma/prisma/releases/2.20.0) and later.
+
+The following [`createMany()`](/6.0/orm/reference/prisma-client-reference#createmany) query creates multiple users and skips any duplicates (`email` must be unique):
+
+
+
+
+```ts
+const createMany = await prisma.user.createMany({
+ data: [
+ { name: 'Bob', email: 'bob@prisma.io' },
+ { name: 'Bobo', email: 'bob@prisma.io' }, // Duplicate unique key!
+ { name: 'Yewande', email: 'yewande@prisma.io' },
+ { name: 'Angelique', email: 'angelique@prisma.io' },
+ ],
+ skipDuplicates: true, // Skip 'Bobo'
+})
+```
+
+
+
+
+```js no-copy
+{
+ count: 3
+}
+```
+
+
+
+
+
+
+
+Note `skipDuplicates` is not supported when using MongoDB, SQLServer, or SQLite.
+
+
+
+`createMany()` uses a single `INSERT INTO` statement with multiple values, which is generally more efficient than a separate `INSERT` per row:
+
+```sql
+BEGIN
+INSERT INTO "public"."User" ("id","name","email","profileViews","role","coinflips","testing","city","country") VALUES (DEFAULT,$1,$2,$3,$4,DEFAULT,DEFAULT,DEFAULT,$5), (DEFAULT,$6,$7,$8,$9,DEFAULT,DEFAULT,DEFAULT,$10), (DEFAULT,$11,$12,$13,$14,DEFAULT,DEFAULT,DEFAULT,$15), (DEFAULT,$16,$17,$18,$19,DEFAULT,DEFAULT,DEFAULT,$20) ON CONFLICT DO NOTHING
+COMMIT
+SELECT "public"."User"."country", "public"."User"."city", "public"."User"."email", SUM("public"."User"."profileViews"), COUNT(*) FROM "public"."User" WHERE 1=1 GROUP BY "public"."User"."country", "public"."User"."city", "public"."User"."email" HAVING AVG("public"."User"."profileViews") >= $1 ORDER BY "public"."User"."country" ASC OFFSET $2
+```
+
+> **Note**: Multiple `create()` statements inside a `$transaction` results in multiple `INSERT` statements.
+
+The following video demonstrates how to use `createMany()` and [faker.js](https://github.com/faker-js/faker/) to seed a database with sample data:
+
+
+
+
+
+### Create records and connect or create related records
+
+See [Working with relations > Nested writes](/orm/prisma-client/queries/relation-queries#nested-writes) for information about creating a record and one or more related records at the same time.
+
+### Create and return multiple records
+
+:::info
+
+This feature is available in Prisma ORM version 5.14.0 and later for PostgreSQL, CockroachDB and SQLite.
+
+:::
+
+You can use `createManyAndReturn()` in order to create many records and return the resulting objects.
+
+
+
+
+```ts
+const users = await prisma.user.createManyAndReturn({
+ data: [
+ { name: 'Alice', email: 'alice@prisma.io' },
+ { name: 'Bob', email: 'bob@prisma.io' },
+ ],
+})
+```
+
+
+
+
+```js no-copy
+[{
+ id: 22,
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ profileViews: 0,
+ role: 'USER',
+ coinflips: []
+}, {
+ id: 23,
+ name: 'Bob',
+ email: 'bob@prisma.io',
+ profileViews: 0,
+ role: 'USER',
+ coinflips: []
+}]
+```
+
+
+
+
+:::warning
+
+`relationLoadStrategy: join` is not available when using `createManyAndReturn()`.
+
+:::
+
+## Read
+
+### Get record by ID or unique identifier
+
+The following queries return a single record ([`findUnique()`](/6.0/orm/reference/prisma-client-reference#findunique)) by unique identifier or ID:
+
+```ts
+// By unique identifier
+const user = await prisma.user.findUnique({
+ where: {
+ email: 'elsa@prisma.io',
+ },
+})
+
+// By ID
+const user = await prisma.user.findUnique({
+ where: {
+ id: 99,
+ },
+})
+```
+
+If you are using the MongoDB connector and your underlying ID type is `ObjectId`, you can use the string representation of that `ObjectId`:
+
+```ts
+// By ID
+const user = await prisma.user.findUnique({
+ where: {
+ id: '60d5922d00581b8f0062e3a8',
+ },
+})
+```
+
+### Get all records
+
+The following [`findMany()`](/6.0/orm/reference/prisma-client-reference#findmany) query returns _all_ `User` records:
+
+```ts
+const users = await prisma.user.findMany()
+```
+
+You can also [paginate your results](/orm/prisma-client/queries/pagination).
+
+### Get the first record that matches a specific criteria
+
+The following [`findFirst()`](/6.0/orm/reference/prisma-client-reference#findfirst) query returns the _most recently created user_ with at least one post that has more than 100 likes:
+
+1. Order users by descending ID (largest first) - the largest ID is the most recent
+2. Return the first user in descending order with at least one post that has more than 100 likes
+
+```ts
+const findUser = await prisma.user.findFirst({
+ where: {
+ posts: {
+ some: {
+ likes: {
+ gt: 100,
+ },
+ },
+ },
+ },
+ orderBy: {
+ id: 'desc',
+ },
+})
+```
+
+### Get a filtered list of records
+
+Prisma Client supports [filtering](/orm/prisma-client/queries/filtering-and-sorting) on record fields and related record fields.
+
+#### Filter by a single field value
+
+The following query returns all `User` records with an email that ends in `"prisma.io"`:
+
+```ts
+const users = await prisma.user.findMany({
+ where: {
+ email: {
+ endsWith: 'prisma.io',
+ },
+ },
+})
+```
+
+#### Filter by multiple field values
+
+The following query uses a combination of [operators](/6.0/orm/reference/prisma-client-reference#filter-conditions-and-operators) to return users whose name start with `E` _or_ administrators with at least 1 profile view:
+
+```ts
+const users = await prisma.user.findMany({
+ where: {
+ OR: [
+ {
+ name: {
+ startsWith: 'E',
+ },
+ },
+ {
+ AND: {
+ profileViews: {
+ gt: 0,
+ },
+ role: {
+ equals: 'ADMIN',
+ },
+ },
+ },
+ ],
+ },
+})
+```
+
+#### Filter by related record field values
+
+The following query returns users with an email that ends with `prisma.io` _and_ have at least _one_ post (`some`) that is not published:
+
+```ts
+const users = await prisma.user.findMany({
+ where: {
+ email: {
+ endsWith: 'prisma.io',
+ },
+ posts: {
+ some: {
+ published: false,
+ },
+ },
+ },
+})
+```
+
+See [Working with relations](/orm/prisma-client/queries/relation-queries) for more examples of filtering on related field values.
+
+### Select a subset of fields
+
+The following `findUnique()` query uses `select` to return the `email` and `name` fields of a specific `User` record:
+
+
+
+
+```ts
+const user = await prisma.user.findUnique({
+ where: {
+ email: 'emma@prisma.io',
+ },
+ select: {
+ email: true,
+ name: true,
+ },
+})
+```
+
+
+
+
+```js no-copy
+{ email: 'emma@prisma.io', name: "Emma" }
+```
+
+
+
+
+For more information about including relations, refer to:
+
+- [Select fields](/orm/prisma-client/queries/select-fields)
+- [Relation queries](/orm/prisma-client/queries/relation-queries)
+
+#### Select a subset of related record fields
+
+The following query uses a nested `select` to return:
+
+- The user's `email`
+- The `likes` field of each post
+
+
+
+
+```ts
+const user = await prisma.user.findUnique({
+ where: {
+ email: 'emma@prisma.io',
+ },
+ select: {
+ email: true,
+ posts: {
+ select: {
+ likes: true,
+ },
+ },
+ },
+})
+```
+
+
+
+
+```js no-copy
+{ email: 'emma@prisma.io', posts: [ { likes: 0 }, { likes: 0 } ] }
+```
+
+
+
+
+For more information about including relations, see [Select fields and include relations](/orm/prisma-client/queries/select-fields).
+
+### Select distinct field values
+
+See [Select `distinct`](/orm/prisma-client/queries/aggregation-grouping-summarizing#select-distinct) for information about selecting distinct field values.
+
+### Include related records
+
+The following query returns all `ADMIN` users and includes each user's posts in the result:
+
+
+
+
+```ts
+const users = await prisma.user.findMany({
+ where: {
+ role: 'ADMIN',
+ },
+ include: {
+ posts: true,
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ "id": 38,
+ "name": "Maria",
+ "email": "maria@prisma.io",
+ "profileViews": 20,
+ "role": "ADMIN",
+ "coinflips": [
+ true,
+ false,
+ false
+ ],
+ "posts": []
+},
+{
+ "id": 39,
+ "name": "Oni",
+ "email": "oni2@prisma.io",
+ "profileViews": 20,
+ "role": "ADMIN",
+ "coinflips": [
+ true,
+ false,
+ false
+ ],
+ "posts": [
+ {
+ "id": 25,
+ "authorId": 39,
+ "title": "My awesome post",
+ "published": true,
+ "comments": null,
+ "views": 0,
+ "likes": 0
+ }
+ ]
+}
+```
+
+
+
+
+For more information about including relations, see [Select fields and include relations](/orm/prisma-client/queries/select-fields).
+
+#### Include a filtered list of relations
+
+See [Working with relations](/orm/prisma-client/queries/relation-queries#filter-a-list-of-relations) to find out how to combine [`include`](/6.0/orm/reference/prisma-client-reference#include) and `where` for a filtered list of relations - for example, only include a user's published posts.
+
+## Update
+
+### Update a single record
+
+The following query uses [`update()`](/6.0/orm/reference/prisma-client-reference#update) to find and update a single `User` record by `email`:
+
+
+
+
+```ts
+const updateUser = await prisma.user.update({
+ where: {
+ email: 'viola@prisma.io',
+ },
+ data: {
+ name: 'Viola the Magnificent',
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ "id": 43,
+ "name": "Viola the Magnificent",
+ "email": "viola@prisma.io",
+ "profileViews": 0,
+ "role": "USER",
+ "coinflips": [],
+}
+```
+
+
+
+
+### Update multiple records
+
+The following query uses [`updateMany()`](/6.0/orm/reference/prisma-client-reference#updatemany) to update all `User` records that contain `prisma.io`:
+
+
+
+
+```ts
+const updateUsers = await prisma.user.updateMany({
+ where: {
+ email: {
+ contains: 'prisma.io',
+ },
+ },
+ data: {
+ role: 'ADMIN',
+ },
+})
+```
+
+
+
+```js no-copy
+{
+ "count": 19
+}
+```
+
+
+
+
+### Update and return multiple records
+
+:::info
+
+This feature is available in Prisma ORM version 6.2.0 and later for PostgreSQL, CockroachDB, and SQLite.
+
+:::
+
+You can use `updateManyAndReturn()` in order to update many records and return the resulting objects.
+
+
+
+
+```ts
+const users = await prisma.user.updateManyAndReturn({
+ where: {
+ email: {
+ contains: 'prisma.io',
+ }
+ },
+ data: {
+ role: 'ADMIN'
+ }
+})
+```
+
+
+
+
+```js no-copy
+[{
+ id: 22,
+ name: 'Alice',
+ email: 'alice@prisma.io',
+ profileViews: 0,
+ role: 'ADMIN',
+ coinflips: []
+}, {
+ id: 23,
+ name: 'Bob',
+ email: 'bob@prisma.io',
+ profileViews: 0,
+ role: 'ADMIN',
+ coinflips: []
+}]
+```
+
+
+
+
+:::warning
+
+`relationLoadStrategy: join` is not available when using `updateManyAndReturn()`.
+
+:::
+
+### Update _or_ create records
+
+The following query uses [`upsert()`](/6.0/orm/reference/prisma-client-reference#upsert) to update a `User` record with a specific email address, or create that `User` record if it does not exist:
+
+
+
+
+```ts
+const upsertUser = await prisma.user.upsert({
+ where: {
+ email: 'viola@prisma.io',
+ },
+ update: {
+ name: 'Viola the Magnificent',
+ },
+ create: {
+ email: 'viola@prisma.io',
+ name: 'Viola the Magnificent',
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ "id": 43,
+ "name": "Viola the Magnificent",
+ "email": "viola@prisma.io",
+ "profileViews": 0,
+ "role": "ADMIN",
+ "coinflips": [],
+}
+```
+
+
+
+
+
+
+From version 4.6.0, Prisma Client carries out upserts with database native SQL commands where possible. [Learn more](/6.0/orm/reference/prisma-client-reference#database-upserts).
+
+
+
+Prisma Client does not have a `findOrCreate()` query. You can use `upsert()` as a workaround. To make `upsert()` behave like a `findOrCreate()` method, provide an empty `update` parameter to `upsert()`.
+
+
+
+A limitation to using `upsert()` as a workaround for `findOrCreate()` is that `upsert()` will only accept unique model fields in the `where` condition. So it's not possible to use `upsert()` to emulate `findOrCreate()` if the `where` condition contains non-unique fields.
+
+
+
+### Update a number field
+
+Use [atomic number operations](/6.0/orm/reference/prisma-client-reference#atomic-number-operations) to update a number field **based on its current value** - for example, increment or multiply. The following query increments the `views` and `likes` fields by `1`:
+
+```ts
+const updatePosts = await prisma.post.updateMany({
+ data: {
+ views: {
+ increment: 1,
+ },
+ likes: {
+ increment: 1,
+ },
+ },
+})
+```
+
+### Connect and disconnect related records
+
+Refer to [Working with relations](/orm/prisma-client/queries/relation-queries) for information about disconnecting ([`disconnect`](/6.0/orm/reference/prisma-client-reference#disconnect)) and connecting ([`connect`](/6.0/orm/reference/prisma-client-reference#connect)) related records.
+
+## Delete
+
+### Delete a single record
+
+The following query uses [`delete()`](/6.0/orm/reference/prisma-client-reference#delete) to delete a single `User` record:
+
+```ts
+const deleteUser = await prisma.user.delete({
+ where: {
+ email: 'bert@prisma.io',
+ },
+})
+```
+
+Attempting to delete a user with one or more posts result in an error, as every `Post` requires an author - see [cascading deletes](#cascading-deletes-deleting-related-records).
+
+### Delete multiple records
+
+The following query uses [`deleteMany()`](/6.0/orm/reference/prisma-client-reference#deletemany) to delete all `User` records where `email` contains `prisma.io`:
+
+```ts
+const deleteUsers = await prisma.user.deleteMany({
+ where: {
+ email: {
+ contains: 'prisma.io',
+ },
+ },
+})
+```
+
+Attempting to delete a user with one or more posts result in an error, as every `Post` requires an author - see [cascading deletes](#cascading-deletes-deleting-related-records).
+
+### Delete all records
+
+The following query uses [`deleteMany()`](/6.0/orm/reference/prisma-client-reference#deletemany) to delete all `User` records:
+
+```ts
+const deleteUsers = await prisma.user.deleteMany({})
+```
+
+Be aware that this query will fail if the user has any related records (such as posts). In this case, you need to [delete the related records first](#cascading-deletes-deleting-related-records).
+
+### Cascading deletes (deleting related records)
+
+
+
+In [2.26.0](https://github.com/prisma/prisma/releases/tag/2.26.0) and later it is possible to do cascading deletes using the **preview feature** [referential actions](/orm/prisma-schema/data-model/relations/referential-actions).
+
+
+
+The following query uses [`delete()`](/6.0/orm/reference/prisma-client-reference#delete) to delete a single `User` record:
+
+```ts
+const deleteUser = await prisma.user.delete({
+ where: {
+ email: 'bert@prisma.io',
+ },
+})
+```
+
+However, the example schema includes a **required relation** between `Post` and `User`, which means that you cannot delete a user with posts:
+
+```
+The change you are trying to make would violate the required relation 'PostToUser' between the `Post` and `User` models.
+```
+
+To resolve this error, you can:
+
+- Make the relation optional:
+
+ ```prisma highlight=3,4;add|5,6;delete
+ model Post {
+ id Int @id @default(autoincrement())
+ //add-start
+ author User? @relation(fields: [authorId], references: [id])
+ authorId Int?
+ //add-end
+ //delete-start
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+ //delete-end
+ }
+ ```
+
+- Change the author of the posts to another user before deleting the user.
+
+- Delete a user and all their posts with two separate queries in a transaction (all queries must succeed):
+
+ ```ts
+ const deletePosts = prisma.post.deleteMany({
+ where: {
+ authorId: 7,
+ },
+ })
+
+ const deleteUser = prisma.user.delete({
+ where: {
+ id: 7,
+ },
+ })
+
+ const transaction = await prisma.$transaction([deletePosts, deleteUser])
+ ```
+
+### Delete all records from all tables
+
+Sometimes you want to remove all data from all tables but keep the actual tables. This can be particularly useful in a development environment and whilst testing.
+
+The following shows how to delete all records from all tables with Prisma Client and with Prisma Migrate.
+
+#### Deleting all data with `deleteMany()`
+
+When you know the order in which your tables should be deleted, you can use the [`deleteMany`](/6.0/orm/reference/prisma-client-reference#deletemany) function. This is executed synchronously in a [`$transaction`](/orm/prisma-client/queries/transactions) and can be used with all types of databases.
+
+```ts
+const deletePosts = prisma.post.deleteMany()
+const deleteProfile = prisma.profile.deleteMany()
+const deleteUsers = prisma.user.deleteMany()
+
+// The transaction runs synchronously so deleteUsers must run last.
+await prisma.$transaction([deleteProfile, deletePosts, deleteUsers])
+```
+
+✅ **Pros**:
+
+- Works well when you know the structure of your schema ahead of time
+- Synchronously deletes each tables data
+
+❌ **Cons**:
+
+- When working with relational databases, this function doesn't scale as well as having a more generic solution which looks up and `TRUNCATE`s your tables regardless of their relational constraints. Note that this scaling issue does not apply when using the MongoDB connector.
+
+> **Note**: The `$transaction` performs a cascading delete on each models table so they have to be called in order.
+
+#### Deleting all data with raw SQL / `TRUNCATE`
+
+If you are comfortable working with raw SQL, you can perform a `TRUNCATE` query on a table using [`$executeRawUnsafe`](/orm/prisma-client/using-raw-sql/raw-queries#executerawunsafe).
+
+In the following examples, the first tab shows how to perform a `TRUNCATE` on a Postgres database by using a `$queryRaw` look up that maps over the table and `TRUNCATES` all tables in a single query.
+
+The second tab shows performing the same function but with a MySQL database. In this instance the constraints must be removed before the `TRUNCATE` can be executed, before being reinstated once finished. The whole process is run as a `$transaction`
+
+
+
+
+
+```ts
+const tablenames = await prisma.$queryRaw<
+ Array<{ tablename: string }>
+>`SELECT tablename FROM pg_tables WHERE schemaname='public'`
+
+const tables = tablenames
+ .map(({ tablename }) => tablename)
+ .filter((name) => name !== '_prisma_migrations')
+ .map((name) => `"public"."${name}"`)
+ .join(', ')
+
+try {
+ await prisma.$executeRawUnsafe(`TRUNCATE TABLE ${tables} CASCADE;`)
+} catch (error) {
+ console.log({ error })
+}
+```
+
+
+
+
+
+```ts
+const transactions: PrismaPromise[] = []
+transactions.push(prisma.$executeRaw`SET FOREIGN_KEY_CHECKS = 0;`)
+
+const tablenames = await prisma.$queryRaw<
+ Array<{ TABLE_NAME: string }>
+>`SELECT TABLE_NAME from information_schema.TABLES WHERE TABLE_SCHEMA = 'tests';`
+
+for (const { TABLE_NAME } of tablenames) {
+ if (TABLE_NAME !== '_prisma_migrations') {
+ try {
+ transactions.push(prisma.$executeRawUnsafe(`TRUNCATE ${TABLE_NAME};`))
+ } catch (error) {
+ console.log({ error })
+ }
+ }
+}
+
+transactions.push(prisma.$executeRaw`SET FOREIGN_KEY_CHECKS = 1;`)
+
+try {
+ await prisma.$transaction(transactions)
+} catch (error) {
+ console.log({ error })
+}
+```
+
+
+
+
+
+✅ **Pros**:
+
+- Scalable
+- Very fast
+
+❌ **Cons**:
+
+- Can't undo the operation
+- Using reserved SQL key words as tables names can cause issues when trying to run a raw query
+
+#### Deleting all records with Prisma Migrate
+
+If you use Prisma Migrate, you can use `migrate reset`, this will:
+
+1. Drop the database
+2. Create a new database
+3. Apply migrations
+4. Seed the database with data
+
+## Advanced query examples
+
+### Create a deeply nested tree of records
+
+- A single `User`
+- Two new, related `Post` records
+- Connect or create `Category` per post
+
+```ts
+const u = await prisma.user.create({
+ include: {
+ posts: {
+ include: {
+ categories: true,
+ },
+ },
+ },
+ data: {
+ email: 'emma@prisma.io',
+ posts: {
+ create: [
+ {
+ title: 'My first post',
+ categories: {
+ connectOrCreate: [
+ {
+ create: { name: 'Introductions' },
+ where: {
+ name: 'Introductions',
+ },
+ },
+ {
+ create: { name: 'Social' },
+ where: {
+ name: 'Social',
+ },
+ },
+ ],
+ },
+ },
+ {
+ title: 'How to make cookies',
+ categories: {
+ connectOrCreate: [
+ {
+ create: { name: 'Social' },
+ where: {
+ name: 'Social',
+ },
+ },
+ {
+ create: { name: 'Cooking' },
+ where: {
+ name: 'Cooking',
+ },
+ },
+ ],
+ },
+ },
+ ],
+ },
+ },
+})
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/035-select-fields.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/035-select-fields.mdx
new file mode 100644
index 0000000000..27c78266e6
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/035-select-fields.mdx
@@ -0,0 +1,335 @@
+---
+title: 'Select fields'
+metaTitle: 'Select fields'
+metaDescription: 'This page explains how to select only a subset of a model''s fields and/or include relations ("eager loading") in a Prisma Client query.'
+tocDepth: 3
+---
+
+## Overview
+
+By default, when a query returns records (as opposed to a count), the result includes:
+
+- **All scalar fields** of a model (including enums)
+- **No relations** defined on a model
+
+As an example, consider this schema:
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ role Role @default(USER)
+ posts Post[]
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ published Boolean @default(false)
+ title String
+ author User? @relation(fields: [authorId], references: [id])
+ authorId Int?
+}
+
+enum Role {
+ USER
+ ADMIN
+}
+```
+
+A query to the `User` model will include the `id`, `email`, `name` and `role` fields (because these are _scalar_ fields), but not the `posts` field (because that's a _relation_ field):
+
+
+
+
+```ts
+const users = await prisma.user.findFirst()
+```
+
+
+
+
+```js no-copy
+{
+ id: 42,
+ name: "Sabelle",
+ email: "sabelle@prisma.io",
+ role: "ADMIN"
+}
+```
+
+
+
+
+If you want to customize the result and have a different combination of fields returned, you can:
+
+- Use [`select`](/6.0/orm/reference/prisma-client-reference#select) to return specific fields. You can also use a [nested `select`](/orm/prisma-client/queries/relation-queries#select-specific-fields-of-included-relations) by selecting relation fields.
+- Use [`omit`](/6.0/orm/reference/prisma-client-reference#omit) to exclude specific fields from the result. `omit` can be seen as the "opposite" to `select`.
+- Use [`include`](/6.0/orm/reference/prisma-client-reference#include) to additionally [include relations](/orm/prisma-client/queries/relation-queries#nested-reads).
+
+In all cases, the query result will be statically typed, ensuring that you don't accidentally access any fields that you did not actually query from the database.
+
+Selecting only the fields and relations that you require rather than relying on the default selection set can reduce the size of the response and improve query speed.
+
+Since version [5.9.0](https://github.com/prisma/prisma/releases/tag/5.9.0), when doing a relation query with `include` or by using `select` on a relation field, you can also specify the `relationLoadStrategy` to decide whether you want to use a database-level join or perform multiple queries and merge the data on the application level. This feature is currently in [Preview](/orm/more/releases#preview), you can learn more about it [here](/orm/prisma-client/queries/relation-queries#relation-load-strategies-preview).
+
+## Example schema
+
+All following examples on this page are based on the following schema:
+
+```prisma
+model User {
+ id Int @id
+ name String?
+ email String @unique
+ password String
+ role Role @default(USER)
+ coinflips Boolean[]
+ posts Post[]
+ profile Profile?
+}
+
+model Post {
+ id Int @id
+ title String
+ published Boolean @default(true)
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+}
+
+model Profile {
+ id Int @id
+ biography String
+ user User @relation(fields: [userId], references: [id])
+ userId Int @unique
+}
+
+enum Role {
+ USER
+ ADMIN
+}
+```
+
+
+## Return the default fields
+
+The following query returns the default fields (all scalar fields, no relations):
+
+
+
+
+```ts
+const user = await prisma.user.findFirst()
+```
+
+
+
+
+```js no-copy
+{
+ id: 22,
+ name: "Alice",
+ email: "alice@prisma.io",
+ password: "mySecretPassword42"
+ role: "ADMIN",
+ coinflips: [true, false],
+}
+```
+
+
+
+
+## Select specific fields
+
+Use `select` to return a _subset_ of fields instead of _all_ fields. The following example returns the `email` and `name` fields only:
+
+
+
+
+```ts
+const user = await prisma.user.findFirst({
+ select: {
+ email: true,
+ name: true,
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ name: "Alice",
+ email: "alice@prisma.io",
+}
+```
+
+
+
+
+## Return nested objects by selecting relation fields
+
+You can also return relations by nesting `select` multiple times on [relation fields](/orm/prisma-schema/data-model/relations#relation-fields).
+
+The following query uses a nested `select` to select each user's `name` and the `title` of each related post:
+
+
+
+
+```ts highlight=normal;2,5
+const usersWithPostTitles = await prisma.user.findFirst({
+ select: {
+ name: true,
+ posts: {
+ select: { title: true },
+ },
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ "name":"Sabelle",
+ "posts":[
+ { "title":"Getting started with Azure Functions" },
+ { "title":"All about databases" }
+ ]
+}
+```
+
+
+
+
+The following query uses `select` within an `include`, and returns _all_ user fields and each post's `title` field:
+
+
+
+
+```ts highlight=normal;2,5
+const usersWithPostTitles = await prisma.user.findFirst({
+ include: {
+ posts: {
+ select: { title: true },
+ },
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ id: 9
+ name: "Sabelle",
+ email: "sabelle@prisma.io",
+ password: "mySecretPassword42",
+ role: "USER",
+ coinflips: [],
+ posts:[
+ { title:"Getting started with Azure Functions" },
+ { title:"All about databases" }
+ ]
+}
+```
+
+
+
+
+You can nest your queries arbitrarily deep. The following query fetches:
+- the `title` of a `Post`
+- the `name` of the related `User`
+- the `biography` of the related `Profile`
+
+
+
+
+```ts highlight=normal;2,5
+const postsWithAuthorsAndProfiles = await prisma.post.findFirst({
+ select: {
+ title: true,
+ author: {
+ select: {
+ name: true,
+ profile: {
+ select: { biography: true }
+ }
+ },
+ },
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ id: 9
+ title:"All about databases",
+ author: {
+ name: "Sabelle",.
+ profile: {
+ biography: "I like turtles"
+ }
+ }
+}
+```
+
+
+
+
+:::note
+
+Be careful when deeply nesting relations because the underlying database query may become slow due it needing to access a lot of different tables. To ensure your queries always have optimal speed, consider adding a caching layer with [Prisma Accelerate](/accelerate) or use [Prisma Optimize](/optimize/) to get query insights and recommendations for performance optimizations.
+
+:::
+
+For more information about querying relations, refer to the following documentation:
+
+- [Include a relation (including all fields)](/orm/prisma-client/queries/relation-queries#include-all-fields-for-a-specific-relation)
+- [Select specific relation fields](/orm/prisma-client/queries/relation-queries#select-specific-fields-of-included-relations)
+
+## Omit specific fields
+
+There may be situations when you want to return _most_ fields of a model, excluding only a _small_ subset. A common example for this is when you query a `User` but want to exclude the `password` field for security reasons.
+
+In these cases, you can use `omit`, which can be seen as the counterpart to `select`:
+
+
+
+
+```ts
+const users = await prisma.user.findFirst({
+ omit: {
+ password: true
+ }
+})
+```
+
+
+
+
+```js no-copy
+{
+ id: 9
+ name: "Sabelle",
+ email: "sabelle@prisma.io",
+ profileViews: 90,
+ role: "USER",
+ coinflips: [],
+}
+```
+
+
+
+
+Notice how the returned object does _not_ contain the `password` field.
+
+## Relation count
+
+In [3.0.1](https://github.com/prisma/prisma/releases/3.0.1) and later, you can `include` or `select` a [count of relations](/orm/prisma-client/queries/aggregation-grouping-summarizing#count-relations) alongside fields. For example, a user's post count.
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/037-relation-queries.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/037-relation-queries.mdx
new file mode 100644
index 0000000000..f707e5624e
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/037-relation-queries.mdx
@@ -0,0 +1,1394 @@
+---
+title: 'Relation queries'
+metaTitle: 'Relation queries (Concepts)'
+metaDescription: 'Prisma Client provides convenient queries for working with relations, such as a fluent API, nested writes (transactions), nested reads and relation filters.'
+toc_max_heading_level: 4
+---
+
+A key feature of Prisma Client is the ability to query [relations](/orm/prisma-schema/data-model/relations) between two or more models. Relation queries include:
+
+- [Nested reads](#nested-reads) (sometimes referred to as _eager loading_) via [`select`](/6.0/orm/reference/prisma-client-reference#select) and [`include`](/6.0/orm/reference/prisma-client-reference#include)
+- [Nested writes](#nested-writes) with [transactional](/orm/prisma-client/queries/transactions) guarantees
+- [Filtering on related records](#relation-filters)
+
+Prisma Client also has a [fluent API for traversing relations](#fluent-api).
+
+## Nested reads
+
+Nested reads allow you to read related data from multiple tables in your database - such as a user and that user's posts. You can:
+
+- Use [`include`](/6.0/orm/reference/prisma-client-reference#include) to include related records, such as a user's posts or profile, in the query response.
+- Use a nested [`select`](/6.0/orm/reference/prisma-client-reference#select) to include specific fields from a related record. You can also nest `select` inside an `include`.
+
+### Relation load strategies (Preview)
+
+Since version [5.8.0](https://github.com/prisma/prisma/releases/tag/5.8.0), you can decide on a per-query-level _how_ you want Prisma Client to execute a relation query (i.e. what _load strategy_ should be applied) via the `relationLoadStrategy` option for PostgreSQL databases.
+
+Since version [5.10.0](https://github.com/prisma/prisma/releases/tag/5.10.0), this feature is also available for MySQL.
+
+Because the `relationLoadStrategy` option is currently in Preview, you need to enable it via the `relationJoins` preview feature flag in your Prisma schema file:
+
+```prisma file=schema.prisma showLineNumbers
+generator client {
+ provider = "prisma-client-js"
+ previewFeatures = ["relationJoins"]
+}
+```
+
+After adding this flag, you need to run `prisma generate` again to re-generate Prisma Client. The `relationJoins` feature is currently available on PostgreSQL, CockroachDB and MySQL.
+
+Prisma Client supports two load strategies for relations:
+
+- `join` (default): Uses a database-level `LATERAL JOIN` (PostgreSQL) or correlated subqueries (MySQL) and fetches all data with a single query to the database.
+- `query`: Sends multiple queries to the database (one per table) and joins them on the application level.
+
+Another important difference between these two options is that the `join` strategy uses JSON aggregation on the database level. That means that it creates the JSON structures returned by Prisma Client already in the database which saves computation resources on the application level.
+
+> **Note**: Once `relationLoadStrategy` moves from [Preview](/orm/more/releases#preview) into [General Availability](/orm/more/releases/#generally-available-ga), `join` will universally become the default for all relation queries.
+
+#### Examples
+
+You can use the `relationLoadStrategy` option on the top-level in any query that supports `include` or `select`.
+
+Here is an example with `include`:
+
+```ts
+const users = await prisma.user.findMany({
+ relationLoadStrategy: 'join', // or 'query'
+ include: {
+ posts: true,
+ },
+})
+```
+
+And here is another example with `select`:
+
+```ts
+const users = await prisma.user.findMany({
+ relationLoadStrategy: 'join', // or 'query'
+ select: {
+ posts: true,
+ },
+})
+```
+
+#### When to use which load strategy?
+
+- The `join` strategy (default) will be more effective in most scenarios. On PostgreSQL, it uses a combination of `LATERAL JOINs` and JSON aggregation to reduce redundancy in result sets and delegate the work of transforming the query results into the expected JSON structures on the database server. On MySQL, it uses correlated subqueries to fetch the results with a single query.
+- There may be edge cases where `query` could be more performant depending on the characteristics of the dataset and query. We recommend that you profile your database queries to identify these situations.
+- Use `query` if you want to save resources on the database server and do heavy-lifting of merging and transforming data in the application server which might be easier to scale.
+
+### Include a relation
+
+The following example returns a single user and that user's posts:
+
+
+
+
+```ts
+const user = await prisma.user.findFirst({
+ include: {
+ posts: true,
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ id: 19,
+ name: null,
+ email: 'emma@prisma.io',
+ profileViews: 0,
+ role: 'USER',
+ coinflips: [],
+ posts: [
+ {
+ id: 20,
+ title: 'My first post',
+ published: true,
+ authorId: 19,
+ comments: null,
+ views: 0,
+ likes: 0
+ },
+ {
+ id: 21,
+ title: 'How to make cookies',
+ published: true,
+ authorId: 19,
+ comments: null,
+ views: 0,
+ likes: 0
+ }
+ ]
+}
+```
+
+
+
+
+### Include all fields for a specific relation
+
+The following example returns a post and its author:
+
+
+
+
+```ts
+const post = await prisma.post.findFirst({
+ include: {
+ author: true,
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ id: 17,
+ title: 'How to make cookies',
+ published: true,
+ authorId: 16,
+ comments: null,
+ views: 0,
+ likes: 0,
+ author: {
+ id: 16,
+ name: null,
+ email: 'orla@prisma.io',
+ profileViews: 0,
+ role: 'USER',
+ coinflips: [],
+ },
+}
+```
+
+
+
+
+### Include deeply nested relations
+
+You can nest `include` options to include relations of relations. The following example returns a user's posts, and each post's categories:
+
+
+
+
+```ts
+const user = await prisma.user.findFirst({
+ include: {
+ posts: {
+ include: {
+ categories: true,
+ },
+ },
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ "id": 40,
+ "name": "Yvette",
+ "email": "yvette@prisma.io",
+ "profileViews": 0,
+ "role": "USER",
+ "coinflips": [],
+ "testing": [],
+ "city": null,
+ "country": "Sweden",
+ "posts": [
+ {
+ "id": 66,
+ "title": "How to make an omelette",
+ "published": true,
+ "authorId": 40,
+ "comments": null,
+ "views": 0,
+ "likes": 0,
+ "categories": [
+ {
+ "id": 3,
+ "name": "Easy cooking"
+ }
+ ]
+ },
+ {
+ "id": 67,
+ "title": "How to eat an omelette",
+ "published": true,
+ "authorId": 40,
+ "comments": null,
+ "views": 0,
+ "likes": 0,
+ "categories": []
+ }
+ ]
+}
+```
+
+
+
+
+
+### Select specific fields of included relations
+
+You can use a nested `select` to choose a subset of fields of relations to return. For example, the following query returns the user's `name` and the `title` of each related post:
+
+
+
+
+```ts
+const user = await prisma.user.findFirst({
+ select: {
+ name: true,
+ posts: {
+ select: {
+ title: true,
+ },
+ },
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ name: "Elsa",
+ posts: [ { title: 'My first post' }, { title: 'How to make cookies' } ]
+}
+```
+
+
+
+
+You can also nest a `select` inside an `include` - the following example returns _all_ `User` fields and the `title` field of each post:
+
+
+
+
+```ts
+const user = await prisma.user.findFirst({
+ include: {
+ posts: {
+ select: {
+ title: true,
+ },
+ },
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ "id": 1,
+ "name": null,
+ "email": "martina@prisma.io",
+ "profileViews": 0,
+ "role": "USER",
+ "coinflips": [],
+ "posts": [
+ { "title": "How to grow salad" },
+ { "title": "How to ride a horse" }
+ ]
+}
+```
+
+
+
+
+Note that you **cannot** use `select` and `include` _on the same level_. This means that if you choose to `include` a user's post and `select` each post's title, you cannot `select` only the users' `email`:
+
+
+
+
+```ts highlight=3,6;delete
+// The following query returns an exception
+const user = await prisma.user.findFirst({
+ //delete-next-line
+ select: { // This won't work!
+ email: true
+ }
+ //delete-next-line
+ include: { // This won't work!
+ posts: {
+ select: {
+ title: true
+ }
+ }
+ },
+})
+```
+
+
+
+
+```code no-copy
+Invalid `prisma.user.findUnique()` invocation:
+
+{
+ where: {
+ id: 19
+ },
+ select: {
+ ~~~~~~
+ email: true
+ },
+ include: {
+ ~~~~~~~
+ posts: {
+ select: {
+ title: true
+ }
+ }
+ }
+}
+
+
+Please either use `include` or `select`, but not both at the same time.
+```
+
+
+
+
+Instead, use nested `select` options:
+
+```ts
+const user = await prisma.user.findFirst({
+ select: {
+ // This will work!
+ email: true,
+ posts: {
+ select: {
+ title: true,
+ },
+ },
+ },
+})
+```
+
+## Relation count
+
+In [3.0.1](https://github.com/prisma/prisma/releases/3.0.1) and later, you can [`include` or `select` a count of relations](/orm/prisma-client/queries/aggregation-grouping-summarizing#count-relations) alongside fields - for example, a user's post count.
+
+
+
+
+```ts
+const relationCount = await prisma.user.findMany({
+ include: {
+ _count: {
+ select: { posts: true },
+ },
+ },
+})
+```
+
+
+
+
+```code no-copy
+{ id: 1, _count: { posts: 3 } },
+{ id: 2, _count: { posts: 2 } },
+{ id: 3, _count: { posts: 2 } },
+{ id: 4, _count: { posts: 0 } },
+{ id: 5, _count: { posts: 0 } }
+```
+
+
+
+
+## Filter a list of relations
+
+When you use `select` or `include` to return a subset of the related data, you can **filter and sort the list of relations** inside the `select` or `include`.
+
+For example, the following query returns list of titles of the unpublished posts associated with the user:
+
+```ts
+const result = await prisma.user.findFirst({
+ select: {
+ posts: {
+ where: {
+ published: false,
+ },
+ orderBy: {
+ title: 'asc',
+ },
+ select: {
+ title: true,
+ },
+ },
+ },
+})
+```
+
+You can also write the same query using `include` as follows:
+
+```ts
+const result = await prisma.user.findFirst({
+ include: {
+ posts: {
+ where: {
+ published: false,
+ },
+ orderBy: {
+ title: 'asc',
+ },
+ },
+ },
+})
+```
+
+## Nested writes
+
+A nested write allows you to write **relational data** to your database in **a single transaction**.
+
+Nested writes:
+
+- Provide **transactional guarantees** for creating, updating or deleting data across multiple tables in a single Prisma Client query. If any part of the query fails (for example, creating a user succeeds but creating posts fails), Prisma Client rolls back all changes.
+- Support any level of nesting supported by the data model.
+- Are available for [relation fields](/orm/prisma-schema/data-model/relations#relation-fields) when using the model's create or update query. The following section shows the nested write options that are available per query.
+
+### Create a related record
+
+You can create a record and one or more related records at the same time. The following query creates a `User` record and two related `Post` records:
+
+
+
+
+```ts highlight=5-10;normal
+const result = await prisma.user.create({
+ data: {
+ email: 'elsa@prisma.io',
+ name: 'Elsa Prisma',
+ //highlight-start
+ posts: {
+ create: [
+ { title: 'How to make an omelette' },
+ { title: 'How to eat an omelette' },
+ ],
+ },
+ //highlight-end
+ },
+ include: {
+ posts: true, // Include all posts in the returned object
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ id: 29,
+ name: 'Elsa',
+ email: 'elsa@prisma.io',
+ profileViews: 0,
+ role: 'USER',
+ coinflips: [],
+ posts: [
+ {
+ id: 22,
+ title: 'How to make an omelette',
+ published: true,
+ authorId: 29,
+ comments: null,
+ views: 0,
+ likes: 0
+ },
+ {
+ id: 23,
+ title: 'How to eat an omelette',
+ published: true,
+ authorId: 29,
+ comments: null,
+ views: 0,
+ likes: 0
+ }
+ ]
+}
+```
+
+
+
+
+### Create a single record and multiple related records
+
+There are two ways to create or update a single record and multiple related records - for example, a user with multiple posts:
+
+- Use a nested [`create`](/6.0/orm/reference/prisma-client-reference#create-1) query
+- Use a nested [`createMany`](/6.0/orm/reference/prisma-client-reference#createmany-1) query
+
+In most cases, a nested `create` will be preferable unless the [`skipDuplicates` query option](/6.0/orm/reference/prisma-client-reference#nested-createmany-options) is required. Here's a quick table describing the differences between the two options:
+
+| Feature | `create` | `createMany` | Notes |
+| :------------------------------------ | :------- | :----------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Supports nesting additional relations | ✔ | ✘ \* | For example, you can create a user, several posts, and several comments per post in one query. \* You can manually set a foreign key in a has-one relation - for example: `{ authorId: 9}` |
+| Supports 1-n relations | ✔ | ✔ | For example, you can create a user and multiple posts (one user has many posts) |
+| Supports m-n relations | ✔ | ✘ | For example, you can create a post and several categories (one post can have many categories, and one category can have many posts) |
+| Supports skipping duplicate records | ✘ | ✔ | Use `skipDuplicates` query option. |
+
+#### Using nested `create`
+
+The following query uses nested [`create`](/6.0/orm/reference/prisma-client-reference#create-1) to create:
+
+- One user
+- Two posts
+- One post category
+
+The example also uses a nested `include` to include all posts and post categories in the returned data.
+
+
+
+
+```ts highlight=5-17;normal
+const result = await prisma.user.create({
+ data: {
+ email: 'yvette@prisma.io',
+ name: 'Yvette',
+ //highlight-start
+ posts: {
+ create: [
+ {
+ title: 'How to make an omelette',
+ categories: {
+ create: {
+ name: 'Easy cooking',
+ },
+ },
+ },
+ { title: 'How to eat an omelette' },
+ ],
+ },
+ //highlight-end
+ },
+ include: {
+ // Include posts
+ posts: {
+ include: {
+ categories: true, // Include post categories
+ },
+ },
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ "id": 40,
+ "name": "Yvette",
+ "email": "yvette@prisma.io",
+ "profileViews": 0,
+ "role": "USER",
+ "coinflips": [],
+ "testing": [],
+ "city": null,
+ "country": "Sweden",
+ "posts": [
+ {
+ "id": 66,
+ "title": "How to make an omelette",
+ "published": true,
+ "authorId": 40,
+ "comments": null,
+ "views": 0,
+ "likes": 0,
+ "categories": [
+ {
+ "id": 3,
+ "name": "Easy cooking"
+ }
+ ]
+ },
+ {
+ "id": 67,
+ "title": "How to eat an omelette",
+ "published": true,
+ "authorId": 40,
+ "comments": null,
+ "views": 0,
+ "likes": 0,
+ "categories": []
+ }
+ ]
+}
+```
+
+
+
+
+Here's a visual representation of how a nested create operation can write to several tables in the database as once:
+
+
+
+#### Using nested `createMany`
+
+The following query uses a nested [`createMany`](/6.0/orm/reference/prisma-client-reference#create-1) to create:
+
+- One user
+- Two posts
+
+The example also uses a nested `include` to include all posts in the returned data.
+
+
+
+
+```ts highlight=4-8;normal
+const result = await prisma.user.create({
+ data: {
+ email: 'saanvi@prisma.io',
+ //highlight-start
+ posts: {
+ createMany: {
+ data: [{ title: 'My first post' }, { title: 'My second post' }],
+ },
+ },
+ //highlight-end
+ },
+ include: {
+ posts: true,
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ "id": 43,
+ "name": null,
+ "email": "saanvi@prisma.io",
+ "profileViews": 0,
+ "role": "USER",
+ "coinflips": [],
+ "testing": [],
+ "city": null,
+ "country": "India",
+ "posts": [
+ {
+ "id": 70,
+ "title": "My first post",
+ "published": true,
+ "authorId": 43,
+ "comments": null,
+ "views": 0,
+ "likes": 0
+ },
+ {
+ "id": 71,
+ "title": "My second post",
+ "published": true,
+ "authorId": 43,
+ "comments": null,
+ "views": 0,
+ "likes": 0
+ }
+ ]
+}
+```
+
+
+
+
+Note that it is **not possible** to nest an additional `create` or `createMany` inside the highlighted query, which means that you cannot create a user, posts, and post categories at the same time.
+
+As a workaround, you can send a query to create the records that will be connected first, and then create the actual records. For example:
+
+```ts
+const categories = await prisma.category.createManyAndReturn({
+ data: [
+ { name: 'Fun', },
+ { name: 'Technology', },
+ { name: 'Sports', }
+ ],
+ select: {
+ id: true
+ }
+});
+
+const posts = await prisma.post.createManyAndReturn({
+ data: [{
+ title: "Funniest moments in 2024",
+ categoryId: categories.find(category => category.name === 'Fun')!.id
+ }, {
+ title: "Linux or macOS — what's better?",
+ categoryId: categories.find(category => category.name === 'Technology')!.id
+ },
+ {
+ title: "Who will win the next soccer championship?",
+ categoryId: categories.find(category => category.name === 'Sports')!.id
+ }]
+});
+```
+
+If you want to create _all_ records in a single database query, consider using a [`$transaction`](/orm/prisma-client/queries/transactions#the-transaction-api) or [type-safe, raw SQL](/orm/prisma-client/using-raw-sql/typedsql).
+
+
+### Create multiple records and multiple related records
+
+You cannot access relations in a `createMany()` or `createManyAndReturn()` query, which means that you cannot create multiple users and multiple posts in a single nested write. The following is **not** possible:
+
+```ts highlight=6-8,13-15;delete
+const createMany = await prisma.user.createMany({
+ data: [
+ {
+ name: 'Yewande',
+ email: 'yewande@prisma.io',
+ //delete-start
+ posts: {
+ // Not possible to create posts!
+ },
+ //delete-end
+ },
+ {
+ name: 'Noor',
+ email: 'noor@prisma.io',
+ //delete-start
+ posts: {
+ // Not possible to create posts!
+ },
+ //delete-end
+ },
+ ],
+})
+```
+
+### Connect multiple records
+
+The following query creates ([`create`](/6.0/orm/reference/prisma-client-reference#create) ) a new `User` record and connects that record ([`connect`](/6.0/orm/reference/prisma-client-reference#connect) ) to three existing posts:
+
+
+
+
+```ts highlight=4-6;normal
+const result = await prisma.user.create({
+ data: {
+ email: 'vlad@prisma.io',
+ //highlight-start
+ posts: {
+ connect: [{ id: 8 }, { id: 9 }, { id: 10 }],
+ },
+ //highlight-end
+ },
+ include: {
+ posts: true, // Include all posts in the returned object
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ id: 27,
+ name: null,
+ email: 'vlad@prisma.io',
+ profileViews: 0,
+ role: 'USER',
+ coinflips: [],
+ posts: [
+ {
+ id: 10,
+ title: 'An existing post',
+ published: true,
+ authorId: 27,
+ comments: {},
+ views: 0,
+ likes: 0
+ }
+ ]
+}
+```
+
+
+
+
+> **Note**: Prisma Client throws an exception if any of the post records cannot be found: `connect: [{ id: 8 }, { id: 9 }, { id: 10 }]`
+
+### Connect a single record
+
+You can [`connect`](/6.0/orm/reference/prisma-client-reference#connect) an existing record to a new or existing user. The following query connects an existing post (`id: 11`) to an existing user (`id: 9`)
+
+```ts highlight=6-9;normal
+const result = await prisma.user.update({
+ where: {
+ id: 9,
+ },
+ data: {
+ //highlight-start
+ posts: {
+ connect: {
+ id: 11,
+ },
+ //highlight-end
+ },
+ },
+ include: {
+ posts: true,
+ },
+})
+```
+
+### Connect _or_ create a record
+
+If a related record may or may not already exist, use [`connectOrCreate`](/6.0/orm/reference/prisma-client-reference#connectorcreate) to connect the related record:
+
+- Connect a `User` with the email address `viola@prisma.io` _or_
+- Create a new `User` with the email address `viola@prisma.io` if the user does not already exist
+
+
+
+
+```ts highlight=4-14;normal
+const result = await prisma.post.create({
+ data: {
+ title: 'How to make croissants',
+ //highlight-start
+ author: {
+ connectOrCreate: {
+ where: {
+ email: 'viola@prisma.io',
+ },
+ create: {
+ email: 'viola@prisma.io',
+ name: 'Viola',
+ },
+ },
+ },
+ //highlight-end
+ },
+ include: {
+ author: true,
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ id: 26,
+ title: 'How to make croissants',
+ published: true,
+ authorId: 43,
+ views: 0,
+ likes: 0,
+ author: {
+ id: 43,
+ name: 'Viola',
+ email: 'viola@prisma.io',
+ profileViews: 0,
+ role: 'USER',
+ coinflips: []
+ }
+}
+```
+
+
+
+
+### Disconnect a related record
+
+To `disconnect` one out of a list of records (for example, a specific blog post) provide the ID or unique identifier of the record(s) to disconnect:
+
+
+
+
+```ts highlight=6-8;normal
+const result = await prisma.user.update({
+ where: {
+ id: 16,
+ },
+ data: {
+ //highlight-start
+ posts: {
+ disconnect: [{ id: 12 }, { id: 19 }],
+ },
+ //highlight-end
+ },
+ include: {
+ posts: true,
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ id: 16,
+ name: null,
+ email: 'orla@prisma.io',
+ profileViews: 0,
+ role: 'USER',
+ coinflips: [],
+ posts: []
+}
+```
+
+
+
+
+To `disconnect` _one_ record (for example, a post's author), use `disconnect: true`:
+
+
+
+
+```ts highlight=6-8;normal
+const result = await prisma.post.update({
+ where: {
+ id: 23,
+ },
+ data: {
+ //highlight-start
+ author: {
+ disconnect: true,
+ },
+ //highlight-end
+ },
+ include: {
+ author: true,
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ id: 23,
+ title: 'How to eat an omelette',
+ published: true,
+ authorId: null,
+ comments: null,
+ views: 0,
+ likes: 0,
+ author: null
+}
+```
+
+
+
+
+### Disconnect all related records
+
+To [`disconnect`](/6.0/orm/reference/prisma-client-reference#disconnect) _all_ related records in a one-to-many relation (a user has many posts), `set` the relation to an empty list as shown:
+
+
+
+
+```ts highlight=6-8;normal
+const result = await prisma.user.update({
+ where: {
+ id: 16,
+ },
+ data: {
+ //highlight-start
+ posts: {
+ set: [],
+ },
+ //highlight-end
+ },
+ include: {
+ posts: true,
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ id: 16,
+ name: null,
+ email: 'orla@prisma.io',
+ profileViews: 0,
+ role: 'USER',
+ coinflips: [],
+ posts: []
+}
+```
+
+
+
+
+### Delete all related records
+
+Delete all related `Post` records:
+
+```ts highlight=6-8;normal
+const result = await prisma.user.update({
+ where: {
+ id: 11,
+ },
+ data: {
+ //highlight-start
+ posts: {
+ deleteMany: {},
+ },
+ //highlight-end
+ },
+ include: {
+ posts: true,
+ },
+})
+```
+
+### Delete specific related records
+
+Update a user by deleting all unpublished posts:
+
+```ts highlight=6-10;normal
+const result = await prisma.user.update({
+ where: {
+ id: 11,
+ },
+ data: {
+ //highlight-start
+ posts: {
+ deleteMany: {
+ published: false,
+ },
+ },
+ //highlight-end
+ },
+ include: {
+ posts: true,
+ },
+})
+```
+
+Update a user by deleting specific posts:
+
+```ts highlight=6-8;normal
+const result = await prisma.user.update({
+ where: {
+ id: 6,
+ },
+ data: {
+ //highlight-start
+ posts: {
+ deleteMany: [{ id: 7 }],
+ },
+ //highlight-end
+ },
+ include: {
+ posts: true,
+ },
+})
+```
+
+### Update all related records (or filter)
+
+You can use a nested `updateMany` to update _all_ related records for a particular user. The following query unpublishes all posts for a specific user:
+
+```ts highlight=6-15;normal
+const result = await prisma.user.update({
+ where: {
+ id: 6,
+ },
+ data: {
+ //highlight-start
+ posts: {
+ updateMany: {
+ where: {
+ published: true,
+ },
+ data: {
+ published: false,
+ },
+ },
+ },
+ //highlight-end
+ },
+ include: {
+ posts: true,
+ },
+})
+```
+
+### Update a specific related record
+
+```ts highlight=6-15;normal
+const result = await prisma.user.update({
+ where: {
+ id: 6,
+ },
+ data: {
+ //highlight-start
+ posts: {
+ update: {
+ where: {
+ id: 9,
+ },
+ data: {
+ title: 'My updated title',
+ },
+ },
+ },
+ //highlight-end
+ },
+ include: {
+ posts: true,
+ },
+})
+```
+
+### Update _or_ create a related record
+
+The following query uses a nested `upsert` to update `"bob@prisma.io"` if that user exists, or create the user if they do not exist:
+
+```ts highlight=6-17;normal
+const result = await prisma.post.update({
+ where: {
+ id: 6,
+ },
+ data: {
+ //highlight-start
+ author: {
+ upsert: {
+ create: {
+ email: 'bob@prisma.io',
+ name: 'Bob the New User',
+ },
+ update: {
+ email: 'bob@prisma.io',
+ name: 'Bob the existing user',
+ },
+ },
+ },
+ //highlight-end
+ },
+ include: {
+ author: true,
+ },
+})
+```
+
+### Add new related records to an existing record
+
+You can nest `create` or `createMany` inside an `update` to add new related records to an existing record. The following query adds two posts to a user with an `id` of 9:
+
+```ts highlight=6-10;normal
+const result = await prisma.user.update({
+ where: {
+ id: 9,
+ },
+ data: {
+ //highlight-start
+ posts: {
+ createMany: {
+ data: [{ title: 'My first post' }, { title: 'My second post' }],
+ },
+ },
+ //highlight-end
+ },
+ include: {
+ posts: true,
+ },
+})
+```
+
+## Relation filters
+
+### Filter on "-to-many" relations
+
+Prisma Client provides the [`some`](/6.0/orm/reference/prisma-client-reference#some), [`every`](/6.0/orm/reference/prisma-client-reference#every), and [`none`](/6.0/orm/reference/prisma-client-reference#none) options to filter records by the properties of related records on the "-to-many" side of the relation. For example, filtering users based on properties of their posts.
+
+For example:
+
+| Requirement | Query option to use |
+| --------------------------------------------------------------------------------- | ----------------------------------- |
+| "I want a list of every `User` that has _at least one_ unpublished `Post` record" | `some` posts are unpublished |
+| "I want a list of every `User` that has _no_ unpublished `Post` records" | `none` of the posts are unpublished |
+| "I want a list of every `User` that has _only_ unpublished `Post` records" | `every` post is unpublished |
+
+For example, the following query returns `User` that meet the following criteria:
+
+- No posts with more than 100 views
+- All posts have less than, or equal to 50 likes
+
+```ts
+const users = await prisma.user.findMany({
+ where: {
+ //highlight-start
+ posts: {
+ none: {
+ views: {
+ gt: 100,
+ },
+ },
+ every: {
+ likes: {
+ lte: 50,
+ },
+ },
+ },
+ //highlight-end
+ },
+ include: {
+ posts: true,
+ },
+})
+```
+
+### Filter on "-to-one" relations
+
+Prisma Client provides the [`is`](/6.0/orm/reference/prisma-client-reference#is) and [`isNot`](/6.0/orm/reference/prisma-client-reference#isnot) options to filter records by the properties of related records on the "-to-one" side of the relation. For example, filtering posts based on properties of their author.
+
+For example, the following query returns `Post` records that meet the following criteria:
+
+- Author's name is not Bob
+- Author is older than 40
+
+```ts highlight=3-13;normal
+const users = await prisma.post.findMany({
+ where: {
+ //highlight-start
+ author: {
+ isNot: {
+ name: 'Bob',
+ },
+ is: {
+ age: {
+ gt: 40,
+ },
+ },
+ },
+ },
+ //highlight-end
+ include: {
+ author: true,
+ },
+})
+```
+
+### Filter on absence of "-to-many" records
+
+For example, the following query uses `none` to return all users that have zero posts:
+
+```ts highlight=3-5;normal
+const usersWithZeroPosts = await prisma.user.findMany({
+ where: {
+ //highlight-start
+ posts: {
+ none: {},
+ },
+ //highlight-end
+ },
+ include: {
+ posts: true,
+ },
+})
+```
+
+### Filter on absence of "-to-one" relations
+
+The following query returns all posts that don't have an author relation:
+
+```js highlight=3;normal
+const postsWithNoAuthor = await prisma.post.findMany({
+ where: {
+ //highlight-next-line
+ author: null, // or author: { }
+ },
+ include: {
+ author: true,
+ },
+})
+```
+
+### Filter on presence of related records
+
+The following query returns all users with at least one post:
+
+```ts highlight=3-5;normal
+const usersWithSomePosts = await prisma.user.findMany({
+ where: {
+ //highlight-start
+ posts: {
+ some: {},
+ },
+ //highlight-end
+ },
+ include: {
+ posts: true,
+ },
+})
+```
+
+## Fluent API
+
+The fluent API lets you _fluently_ traverse the [relations](/orm/prisma-schema/data-model/relations) of your models via function calls. Note that the _last_ function call determines the return type of the entire query (the respective type annotations are added in the code snippets below to make that explicit).
+
+This query returns all `Post` records by a specific `User`:
+
+```ts
+const postsByUser: Post[] = await prisma.user
+ .findUnique({ where: { email: 'alice@prisma.io' } })
+ .posts()
+```
+
+This is equivalent to the following `findMany` query:
+
+```ts
+const postsByUser = await prisma.post.findMany({
+ where: {
+ author: {
+ email: 'alice@prisma.io',
+ },
+ },
+})
+```
+
+The main difference between the queries is that the fluent API call is translated into two separate database queries while the other one only generates a single query (see this [GitHub issue](https://github.com/prisma/prisma/issues/1984))
+
+> **Note**: You can use the fact that `.findUnique({ where: { email: 'alice@prisma.io' } }).posts()` queries are automatically batched by the Prisma dataloader in Prisma Client to [avoid the n+1 problem in GraphQL resolvers](/orm/prisma-client/queries/query-optimization-performance#solving-n1-in-graphql-with-findunique-and-prisma-clients-dataloader).
+
+This request returns all categories by a specific post:
+
+```ts
+const categoriesOfPost: Category[] = await prisma.post
+ .findUnique({ where: { id: 1 } })
+ .categories()
+```
+
+Note that you can chain as many queries as you like. In this example, the chaining starts at `Profile` and goes over `User` to `Post`:
+
+```ts
+const posts: Post[] = await prisma.profile
+ .findUnique({ where: { id: 1 } })
+ .user()
+ .posts()
+```
+
+The only requirement for chaining is that the previous function call must return only a _single object_ (e.g. as returned by a `findUnique` query or a "to-one relation" like `profile.user()`).
+
+The following query is **not possible** because `findMany` does not return a single object but a _list_:
+
+```ts
+// This query is illegal
+const posts = await prisma.user.findMany().posts()
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/050-filtering-and-sorting.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/050-filtering-and-sorting.mdx
new file mode 100644
index 0000000000..deb7364939
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/050-filtering-and-sorting.mdx
@@ -0,0 +1,470 @@
+---
+title: 'Filtering and Sorting'
+metaTitle: 'Filtering and Sorting (Concepts)'
+metaDescription: 'Use Prisma Client API to filter records by any combination of fields or related record fields, and/or sort query results.'
+tocDepth: 3
+---
+
+Prisma Client supports [filtering](#filtering) with the `where` query option, and [sorting](#sorting) with the `orderBy` query option.
+
+## Filtering
+
+Prisma Client allows you to filter records on any combination of model fields, [including related models](#filter-on-relations), and supports a variety of [filter conditions](#filter-conditions-and-operators).
+
+
+
+Some filter conditions use the SQL operators `LIKE` and `ILIKE` which may cause unexpected behavior in your queries. Please refer to [our filtering FAQs](#filtering-faqs) for more information.
+
+
+
+The following query:
+
+- Returns all `User` records with:
+ - an email address that ends with `prisma.io` _and_
+ - at least one published post (a relation query)
+- Returns all `User` fields
+- Includes all related `Post` records where `published` equals `true`
+
+
+
+
+```ts
+const result = await prisma.user.findMany({
+ where: {
+ email: {
+ endsWith: 'prisma.io',
+ },
+ posts: {
+ some: {
+ published: true,
+ },
+ },
+ },
+ include: {
+ posts: {
+ where: {
+ published: true,
+ },
+ },
+ },
+})
+```
+
+
+
+
+```json5 no-copy
+[
+ {
+ id: 1,
+ name: 'Ellen',
+ email: 'ellen@prisma.io',
+ role: 'USER',
+ posts: [
+ {
+ id: 1,
+ title: 'How to build a house',
+ published: true,
+ authorId: 1,
+ },
+ {
+ id: 2,
+ title: 'How to cook kohlrabi',
+ published: true,
+ authorId: 1,
+ },
+ ],
+ },
+]
+```
+
+
+
+
+### Filter conditions and operators
+
+Refer to Prisma Client's reference documentation for [a full list of operators](/6.0/orm/reference/prisma-client-reference#filter-conditions-and-operators) , such as `startsWith` and `contains`.
+
+#### Combining operators
+
+You can use operators (such as [`NOT`](/6.0/orm/reference/prisma-client-reference#not-1) and [`OR`](/6.0/orm/reference/prisma-client-reference#or) ) to filter by a combination of conditions. The following query returns all users whose `email` ends with `gmail.com` or `company.com`, but excludes any emails ending with `admin.company.com`
+
+
+
+
+```ts
+const result = await prisma.user.findMany({
+ where: {
+ OR: [
+ {
+ email: {
+ endsWith: 'gmail.com',
+ },
+ },
+ { email: { endsWith: 'company.com' } },
+ ],
+ NOT: {
+ email: {
+ endsWith: 'admin.company.com',
+ },
+ },
+ },
+ select: {
+ email: true,
+ },
+})
+```
+
+
+
+
+```json5 no-copy
+[{ email: 'alice@gmail.com' }, { email: 'bob@company.com' }]
+```
+
+
+
+
+### Filter on null fields
+
+The following query returns all posts whose `content` field is `null`:
+
+```ts
+const posts = await prisma.post.findMany({
+ where: {
+ content: null,
+ },
+})
+```
+
+### Filter for non-null fields
+
+The following query returns all posts whose `content` field is **not** `null`:
+
+```ts
+const posts = await prisma.post.findMany({
+ where: {
+ content: { not: null },
+ },
+})
+```
+
+### Filter on relations
+
+Prisma Client supports [filtering on related records](/orm/prisma-client/queries/relation-queries#relation-filters). For example, in the following schema, a user can have many blog posts:
+
+```prisma highlight=5,12-13;normal
+model User {
+ id Int @id @default(autoincrement())
+ name String?
+ email String @unique
+ //highlight-next-line
+ posts Post[] // User can have many posts
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ published Boolean @default(true)
+ //highlight-start
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+ //highlight-end
+}
+```
+
+The one-to-many relation between `User` and `Post` allows you to query users based on their posts - for example, the following query returns all users where _at least one_ post (`some`) has more than 10 views:
+
+```ts
+const result = await prisma.user.findMany({
+ where: {
+ posts: {
+ some: {
+ views: {
+ gt: 10,
+ },
+ },
+ },
+ },
+})
+```
+
+You can also query posts based on the properties of the author. For example, the following query returns all posts where the author's `email` contains `"prisma.io"`:
+
+```ts
+const res = await prisma.post.findMany({
+ where: {
+ author: {
+ email: {
+ contains: 'prisma.io',
+ },
+ },
+ },
+})
+```
+
+### Filter on scalar lists / arrays
+
+Scalar lists (for example, `String[]`) have a special set of [filter conditions](/6.0/orm/reference/prisma-client-reference#scalar-list-filters) - for example, the following query returns all posts where the `tags` array contains `databases`:
+
+```ts
+const posts = await client.post.findMany({
+ where: {
+ tags: {
+ has: 'databases',
+ },
+ },
+})
+```
+
+### Case-insensitive filtering
+
+Case-insensitive filtering [is available as a feature for the PostgreSQL and MongoDB providers](/orm/prisma-client/queries/case-sensitivity#options-for-case-insensitive-filtering). MySQL, MariaDB and Microsoft SQL Server are case-insensitive by default, and do not require a Prisma Client feature to make case-insensitive filtering possible.
+
+To use case-insensitive filtering, add the `mode` property to a particular filter and specify `insensitive`:
+
+```ts highlight=5;normal
+const users = await prisma.user.findMany({
+ where: {
+ email: {
+ endsWith: 'prisma.io',
+ mode: 'insensitive', // Default value: default
+ },
+ name: {
+ equals: 'Archibald', // Default mode
+ },
+ },
+})
+```
+
+See also: [Case sensitivity](/orm/prisma-client/queries/case-sensitivity)
+
+### Filtering FAQs
+
+#### How does filtering work at the database level?
+
+For MySQL and PostgreSQL, Prisma Client utilizes the [`LIKE`](https://www.w3schools.com/sql/sql_like.asp) (and [`ILIKE`](https://www.postgresql.org/docs/current/functions-matching.html#FUNCTIONS-LIKE)) operator to search for a given pattern. The operators have built-in pattern matching using symbols unique to `LIKE`. The pattern-matching symbols include `%` for zero or more characters (similar to `*` in other regex implementations) and `_` for one character (similar to `.`)
+
+To match the literal characters, `%` or `_`, make sure you escape those characters. For example:
+
+
+```ts
+const users = await prisma.user.findMany({
+ where: {
+ name: {
+ startsWith: '_benny',
+ },
+ },
+})
+```
+
+
+The above query will match any user whose name starts with a character followed by `benny` such as `7benny` or `&benny`. If you instead wanted to find any user whose name starts with the literal string `_benny`, you could do:
+
+
+```ts highlight=4
+const users = await prisma.user.findMany({
+ where: {
+ name: {
+ startsWith: '\\_benny', // note that the `_` character is escaped, preceding `\` with `\` when included in a string
+ },
+ },
+})
+```
+
+
+## Sorting
+
+Use [`orderBy`](/6.0/orm/reference/prisma-client-reference#orderby) to sort a list of records or a nested list of records by a particular field or set of fields. For example, the following query returns all `User` records sorted by `role` and `name`, **and** each user's posts sorted by `title`:
+
+
+
+
+
+```ts
+const usersWithPosts = await prisma.user.findMany({
+ orderBy: [
+ {
+ role: 'desc',
+ },
+ {
+ name: 'desc',
+ },
+ ],
+ include: {
+ posts: {
+ orderBy: {
+ title: 'desc',
+ },
+ select: {
+ title: true,
+ },
+ },
+ },
+})
+```
+
+
+
+
+
+```json no-copy
+[
+ {
+ "email": "kwame@prisma.io",
+ "id": 2,
+ "name": "Kwame",
+ "role": "USER",
+ "posts": [
+ {
+ "title": "Prisma in five minutes"
+ },
+ {
+ "title": "Happy Table Friends: Relations in Prisma"
+ }
+ ]
+ },
+ {
+ "email": "emily@prisma.io",
+ "id": 5,
+ "name": "Emily",
+ "role": "USER",
+ "posts": [
+ {
+ "title": "Prisma Day 2020"
+ },
+ {
+ "title": "My first day at Prisma"
+ },
+ {
+ "title": "All about databases"
+ }
+ ]
+ }
+]
+```
+
+
+
+
+
+> **Note**: You can also [sort lists of nested records](/orm/prisma-client/queries/relation-queries#filter-a-list-of-relations)
+> to retrieve a single record by ID.
+
+### Sort by relation
+
+You can also sort by properties of a relation. For example, the following query sorts all posts by the author's email address:
+
+```ts
+const posts = await prisma.post.findMany({
+ orderBy: {
+ author: {
+ email: 'asc',
+ },
+ },
+})
+```
+
+### Sort by relation aggregate value
+
+In [2.19.0](https://github.com/prisma/prisma/releases/2.19.0) and later, you can sort by the **count of related records**.
+
+For example, the following query sorts users by the number of related posts:
+
+```ts
+const getActiveUsers = await prisma.user.findMany({
+ take: 10,
+ orderBy: {
+ posts: {
+ _count: 'desc',
+ },
+ },
+})
+```
+
+> **Note**: It is not currently possible to [return the count of a relation](https://github.com/prisma/prisma/issues/5079).
+
+### Sort by relevance (PostgreSQL and MySQL)
+
+In [3.5.0+](https://github.com/prisma/prisma/releases/3.5.0) for PostgreSQL and [3.8.0+](https://github.com/prisma/prisma/releases/3.8.0) for MySQL, you can sort records by relevance to the query using the `_relevance` keyword. This uses the relevance ranking functions from full text search features.
+
+This feature is further explain in [the PostgreSQL documentation](https://www.postgresql.org/docs/12/textsearch-controls.html) and [the MySQL documentation](https://dev.mysql.com/doc/refman/8.0/en/fulltext-search.html).
+
+**For PostgreSQL**, you need to enable order by relevance with the `fullTextSearchPostgres` [preview feature](/orm/prisma-client/queries/full-text-search):
+
+```prisma
+generator client {
+ provider = "prisma-client-js"
+ previewFeatures = ["fullTextSearchPostgres"]
+}
+```
+
+Ordering by relevance can be used either separately from or together with the `search` filter: `_relevance` is used to order the list, while `search` filters the unordered list.
+
+For example, the following query uses `_relevance` to filter by the term `developer` in the `bio` field, and then sorts the result by relevance in a _descending_ manner:
+
+```ts
+const getUsersByRelevance = await prisma.user.findMany({
+ take: 10,
+ orderBy: {
+ _relevance: {
+ fields: ['bio'],
+ search: 'developer',
+ sort: 'desc',
+ },
+ },
+})
+```
+
+
+
+:::note
+
+Prior to Prisma ORM 5.16.0, enabling the `fullTextSearch` preview feature would rename the `OrderByWithRelationInput` TypeScript types to `OrderByWithRelationAndSearchRelevanceInput`. If you are using the Preview feature, you will need to update your type imports.
+
+:::
+
+
+### Sort with null records first or last
+
+:::info
+
+Notes:
+
+- This feature is generally available in version `4.16.0` and later. To use this feature in versions [`4.1.0`](https://github.com/prisma/prisma/releases/tag/4.1.0) to [`4.15.0`](https://github.com/prisma/prisma/releases/tag/4.15.0) the [Preview feature](/orm/reference/preview-features/client-preview-features#enabling-a-prisma-client-preview-feature) `orderByNulls` will need to be enabled.
+- This feature is not available for MongoDB.
+- You can only sort by nulls on optional [scalar](/orm/prisma-schema/data-model/models#scalar-fields) fields. If you try to sort by nulls on a required or [relation](/orm/prisma-schema/data-model/models#relation-fields) field, Prisma Client throws a [P2009 error](/orm/reference/error-reference#p2009).
+
+:::
+
+You can sort the results so that records with `null` fields appear either first or last.
+
+If `name` is an optional field, then the following query using `last` sorts users by `name`, with `null` records at the end:
+
+```ts
+const users = await prisma.user.findMany({
+ orderBy: {
+ // highlight-next-line
+ updatedAt: { sort: 'asc', nulls: 'last' },
+ },
+})
+```
+
+If you want the records with `null` values to appear at the beginning of the returned array, use `first`:
+
+```ts
+const users = await prisma.user.findMany({
+ orderBy: {
+ // highlight-next-line
+ updatedAt: { sort: 'asc', nulls: 'first' },
+ },
+})
+```
+
+Note that `first` also is the default value, so if you omit the `null` option, `null` values will appear first in the returned array.
+
+### Sorting FAQs
+
+#### Can I perform case-insensitive sorting?
+
+Follow [issue #841 on GitHub](https://github.com/prisma/prisma-client-js/issues/841).
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/055-pagination.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/055-pagination.mdx
new file mode 100644
index 0000000000..02309ac63d
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/055-pagination.mdx
@@ -0,0 +1,231 @@
+---
+title: 'Pagination'
+metaTitle: 'Pagination (Reference)'
+metaDescription: 'Prisma Client supports both offset pagination and cursor-based pagination. Learn more about the pros and cons of different pagination approaches and how to implement them.'
+---
+
+
+
+Prisma Client supports both offset pagination and cursor-based pagination.
+
+
+
+## Offset pagination
+
+Offset pagination uses `skip` and `take` to skip a certain number of results and select a limited range. The following query skips the first 3 `Post` records and returns records 4 - 7:
+
+```ts line-number
+const results = await prisma.post.findMany({
+ skip: 3,
+ take: 4,
+})
+```
+
+
+
+To implement pages of results, you would just `skip` the number of pages multiplied by the number of results you show per page.
+
+### ✔ Pros of offset pagination
+
+- You can jump to any page immediately. For example, you can `skip` 200 records and `take` 10, which simulates jumping straight to page 21 of the result set (the underlying SQL uses `OFFSET`). This is not possible with cursor-based pagination.
+- You can paginate the same result set in any sort order. For example, you can jump to page 21 of a list of `User` records sorted by first name. This is not possible with cursor-based pagination, which requires sorting by a unique, sequential column.
+
+### ✘ Cons of offset pagination
+
+- Offset pagination **does not scale** at a database level. For example, if you skip 200,000 records and take the first 10, the database still has to traverse the first 200,000 records before returning the 10 that you asked for - this negatively affects performance.
+
+### Use cases for offset pagination
+
+- Shallow pagination of a small result set. For example, a blog interface that allows you to filter `Post` records by author and paginate the results.
+
+### Example: Filtering and offset pagination
+
+The following query returns all records where the `email` field contains `prisma.io`. The query skips the first 40 records and returns records 41 - 50.
+
+```ts line-number
+const results = await prisma.post.findMany({
+ skip: 40,
+ take: 10,
+ where: {
+ email: {
+ contains: 'prisma.io',
+ },
+ },
+})
+```
+
+### Example: Sorting and offset pagination
+
+The following query returns all records where the `email` field contains `Prisma`, and sorts the result by the `title` field. The query skips the first 200 records and returns records 201 - 220.
+
+```ts line-number
+const results = await prisma.post.findMany({
+ skip: 200,
+ take: 20,
+ where: {
+ email: {
+ contains: 'Prisma',
+ },
+ },
+ orderBy: {
+ title: 'desc',
+ },
+})
+```
+
+## Cursor-based pagination
+
+Cursor-based pagination uses `cursor` and `take` to return a limited set of results before or after a given **cursor**. A cursor bookmarks your location in a result set and must be a unique, sequential column - such as an ID or a timestamp.
+
+The following example returns the first 4 `Post` records that contain the word `"Prisma"` and saves the ID of the last record as `myCursor`:
+
+> **Note**: Since this is the first query, there is no cursor to pass in.
+
+```ts showLineNumbers
+const firstQueryResults = await prisma.post.findMany({
+ take: 4,
+ where: {
+ title: {
+ contains: 'Prisma' /* Optional filter */,
+ },
+ },
+ orderBy: {
+ id: 'asc',
+ },
+})
+
+// Bookmark your location in the result set - in this
+// case, the ID of the last post in the list of 4.
+
+//highlight-start
+const lastPostInResults = firstQueryResults[3] // Remember: zero-based index! :)
+const myCursor = lastPostInResults.id // Example: 29
+//highlight-end
+```
+
+The following diagram shows the IDs of the first 4 results - or page 1. The cursor for the next query is **29**:
+
+
+
+The second query returns the first 4 `Post` records that contain the word `"Prisma"` **after the supplied cursor** (in other words - IDs that are larger than **29**):
+
+```ts line-number
+const secondQueryResults = await prisma.post.findMany({
+ take: 4,
+ skip: 1, // Skip the cursor
+ //highlight-start
+ cursor: {
+ id: myCursor,
+ },
+ //highlight-end
+ where: {
+ title: {
+ contains: 'Prisma' /* Optional filter */,
+ },
+ },
+ orderBy: {
+ id: 'asc',
+ },
+})
+
+const lastPostInResults = secondQueryResults[3] // Remember: zero-based index! :)
+const myCursor = lastPostInResults.id // Example: 52
+```
+
+The following diagram shows the first 4 `Post` records **after** the record with ID **29**. In this example, the new cursor is **52**:
+
+
+
+### FAQ
+
+#### Do I always have to skip: 1?
+
+If you do not `skip: 1`, your result set will include your previous cursor. The first query returns four results and the cursor is **29**:
+
+
+
+Without `skip: 1`, the second query returns 4 results after (and _including_) the cursor:
+
+
+
+If you `skip: 1`, the cursor is not included:
+
+
+
+You can choose to `skip: 1` or not depending on the pagination behavior that you want.
+
+#### Can I guess the value of the cursor?
+
+If you guess the value of the next cursor, you will page to an unknown location in your result set. Although IDs are sequential, you cannot predict the rate of increment (`2`, `20`, `32` is more likely than `1`, `2`, `3`, particularly in a filtered result set).
+
+#### Does cursor-based pagination use the concept of a cursor in the underlying database?
+
+No, cursor pagination does not use cursors in the underlying database ([e.g. PostgreSQL](https://www.postgresql.org/docs/9.2/plpgsql-cursors.html)).
+
+#### What happens if the cursor value does not exist?
+
+Using a nonexistent cursor returns `null`. Prisma Client does not try to locate adjacent values.
+
+### ✔ Pros of cursor-based pagination
+
+- Cursor-based pagination **scales**. The underlying SQL does not use `OFFSET`, but instead queries all `Post` records with an ID greater than the value of `cursor`.
+
+### ✘ Cons of cursor-based pagination
+
+- You must sort by your cursor, which has to be a unique, sequential column.
+- You cannot jump to a specific page using only a cursor. For example, you cannot accurately predict which cursor represents the start of page 400 (page size 20) without first requesting pages 1 - 399.
+
+### Use cases for cursor-based pagination
+
+- Infinite scroll - for example, sort blog posts by date/time descending and request 10 blog posts at a time.
+- Paging through an entire result set in batches - for example, as part of a long-running data export.
+
+### Example: Filtering and cursor-based pagination
+
+```ts line-number
+const secondQuery = await prisma.post.findMany({
+ take: 4,
+ skip: 1,
+ cursor: {
+ id: myCursor,
+ },
+ //highlight-start
+ where: {
+ title: {
+ contains: 'Prisma' /* Optional filter */,
+ },
+ },
+ //highlight-end
+ orderBy: {
+ id: 'asc',
+ },
+})
+```
+
+### Sorting and cursor-based pagination
+
+Cursor-based pagination requires you to sort by a sequential, unique column such as an ID or a timestamp. This value - known as a cursor - bookmarks your place in the result set and allows you to request the next set.
+
+### Example: Paging backwards with cursor-based pagination
+
+To page backwards, set `take` to a negative value. The following query returns 4 `Post` records with an `id` of less than 200, excluding the cursor:
+
+```ts line-number
+const myOldCursor = 200
+
+const firstQueryResults = await prisma.post.findMany({
+ take: -4,
+ skip: 1,
+ cursor: {
+ id: myOldCursor,
+ },
+ where: {
+ title: {
+ contains: 'Prisma' /* Optional filter */,
+ },
+ },
+ orderBy: {
+ id: 'asc',
+ },
+})
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/056-aggregation-grouping-summarizing.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/056-aggregation-grouping-summarizing.mdx
new file mode 100644
index 0000000000..c0890c177b
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/056-aggregation-grouping-summarizing.mdx
@@ -0,0 +1,735 @@
+---
+title: 'Aggregation, grouping, and summarizing'
+metaTitle: 'Aggregation, grouping, and summarizing (Concepts)'
+metaDescription: 'Use Prisma Client to aggregate, group by, count, and select distinct.'
+tocDepth: 4
+toc_max_heading_level: 4
+---
+
+
+
+Prisma Client allows you to count records, aggregate number fields, and select distinct field values.
+
+
+
+## Aggregate
+
+Prisma Client allows you to [`aggregate`](/6.0/orm/reference/prisma-client-reference#aggregate) on the **number** fields (such as `Int` and `Float`) of a model. The following query returns the average age of all users:
+
+```ts
+const aggregations = await prisma.user.aggregate({
+ _avg: {
+ age: true,
+ },
+})
+
+console.log('Average age:' + aggregations._avg.age)
+```
+
+You can combine aggregation with filtering and ordering. For example, the following query returns the average age of users:
+
+- Ordered by `age` ascending
+- Where `email` contains `prisma.io`
+- Limited to the 10 users
+
+```ts
+const aggregations = await prisma.user.aggregate({
+ _avg: {
+ age: true,
+ },
+ where: {
+ email: {
+ contains: 'prisma.io',
+ },
+ },
+ orderBy: {
+ age: 'asc',
+ },
+ take: 10,
+})
+
+console.log('Average age:' + aggregations._avg.age)
+```
+
+### Aggregate values are nullable
+
+In [2.21.0](https://github.com/prisma/prisma/releases/tag/2.21.0) and later, aggregations on **nullable fields** can return a `number` or `null`. This excludes `count`, which always returns 0 if no records are found.
+
+Consider the following query, where `age` is nullable in the schema:
+
+
+
+
+```ts
+const aggregations = await prisma.user.aggregate({
+ _avg: {
+ age: true,
+ },
+ _count: {
+ age: true,
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ _avg: {
+ age: null
+ },
+ _count: {
+ age: 9
+ }
+}
+```
+
+
+
+
+The query returns `{ _avg: { age: null } }` in either of the following scenarios:
+
+- There are no users
+- The value of every user's `age` field is `null`
+
+This allows you to differentiate between the true aggregate value (which could be zero) and no data.
+
+## Group by
+
+Prisma Client's [`groupBy()`](/6.0/orm/reference/prisma-client-reference#groupby) allows you to **group records** by one or more field values - such as `country`, or `country` and `city` and **perform aggregations** on each group, such as finding the average age of people living in a particular city. `groupBy()` is a GA in [2.20.0](https://github.com/prisma/prisma/releases/2.20.0) and later.
+
+The following video uses `groupBy()` to summarize total COVID-19 cases by continent:
+
+
+
+
+
+
+
+The following example groups all users by the `country` field and returns the total number of profile views for each country:
+
+
+
+
+```ts
+const groupUsers = await prisma.user.groupBy({
+ by: ['country'],
+ _sum: {
+ profileViews: true,
+ },
+})
+```
+
+
+
+
+```js no-copy
+;[
+ { country: 'Germany', _sum: { profileViews: 126 } },
+ { country: 'Sweden', _sum: { profileViews: 0 } },
+]
+```
+
+
+
+
+If you have a single element in the `by` option, you can use the following shorthand syntax to express your query:
+
+```ts
+const groupUsers = await prisma.user.groupBy({
+ by: 'country',
+})
+```
+
+### `groupBy()` and filtering
+
+`groupBy()` supports two levels of filtering: `where` and `having`.
+
+#### Filter records with `where`
+
+Use `where` to filter all records **before grouping**. The following example groups users by country and sums profile views, but only includes users where the email address contains `prisma.io`:
+
+```ts highlight=3-7;normal
+const groupUsers = await prisma.user.groupBy({
+ by: ['country'],
+ //highlight-start
+ where: {
+ email: {
+ contains: 'prisma.io',
+ },
+ },
+ //highlight-end
+ _sum: {
+ profileViews: true,
+ },
+})
+```
+
+#### Filter groups with `having`
+
+Use `having` to filter **entire groups** by an aggregate value such as the sum or average of a field, not individual records - for example, only return groups where the _average_ `profileViews` is greater than 100:
+
+```ts highlight=11-17;normal
+const groupUsers = await prisma.user.groupBy({
+ by: ['country'],
+ where: {
+ email: {
+ contains: 'prisma.io',
+ },
+ },
+ _sum: {
+ profileViews: true,
+ },
+ //highlight-start
+ having: {
+ profileViews: {
+ _avg: {
+ gt: 100,
+ },
+ },
+ },
+ //highlight-end
+})
+```
+
+##### Use case for `having`
+
+The primary use case for `having` is to filter on aggregations. We recommend that you use `where` to reduce the size of your data set as far as possible _before_ grouping, because doing so ✔ reduces the number of records the database has to return and ✔ makes use of indices.
+
+For example, the following query groups all users that are _not_ from Sweden or Ghana:
+
+```ts highlight=4-6;normal
+const fd = await prisma.user.groupBy({
+ by: ['country'],
+ where: {
+ //highlight-start
+ country: {
+ notIn: ['Sweden', 'Ghana'],
+ },
+ //highlight-end
+ },
+ _sum: {
+ profileViews: true,
+ },
+ having: {
+ profileViews: {
+ _min: {
+ gte: 10,
+ },
+ },
+ },
+})
+```
+
+The following query technically achieves the same result, but excludes users from Ghana _after_ grouping. This does not confer any benefit and is not recommended practice.
+
+```ts highlight=4-6,12-14;normal
+const groupUsers = await prisma.user.groupBy({
+ by: ['country'],
+ where: {
+ //highlight-start
+ country: {
+ not: 'Sweden',
+ },
+ //highlight-end
+ },
+ _sum: {
+ profileViews: true,
+ },
+ having: {
+ //highlight-start
+ country: {
+ not: 'Ghana',
+ },
+ //highlight-end
+ profileViews: {
+ _min: {
+ gte: 10,
+ },
+ },
+ },
+})
+```
+
+> **Note**: Within `having`, you can only filter on aggregate values _or_ fields available in `by`.
+
+### `groupBy()` and ordering
+
+The following constraints apply when you combine `groupBy()` and `orderBy`:
+
+- You can `orderBy` fields that are present in `by`
+- You can `orderBy` aggregate (Preview in 2.21.0 and later)
+- If you use `skip` and/or `take` with `groupBy()`, you must also include `orderBy` in the query
+
+#### Order by aggregate group
+
+You can **order by aggregate group**. Prisma ORM added support for using `orderBy` with aggregated groups in relational databases in version [2.21.0](https://github.com/prisma/prisma/releases/2.21.0) and support for MongoDB in [3.4.0](https://github.com/prisma/prisma/releases/3.4.0).
+
+The following example sorts each `city` group by the number of users in that group (largest group first):
+
+
+
+
+```ts
+const groupBy = await prisma.user.groupBy({
+ by: ['city'],
+ _count: {
+ city: true,
+ },
+ orderBy: {
+ _count: {
+ city: 'desc',
+ },
+ },
+})
+```
+
+
+
+
+```js no-copy
+;[
+ { city: 'Berlin', count: { city: 3 } },
+ { city: 'Paris', count: { city: 2 } },
+ { city: 'Amsterdam', count: { city: 1 } },
+]
+```
+
+
+
+
+#### Order by field
+
+The following query orders groups by country, skips the first two groups, and returns the 3rd and 4th group:
+
+```ts
+const groupBy = await prisma.user.groupBy({
+ by: ['country'],
+ _sum: {
+ profileViews: true,
+ },
+ orderBy: {
+ country: 'desc',
+ },
+ skip: 2,
+ take: 2,
+})
+```
+
+### `groupBy()` FAQ
+
+#### Can I use `select` with `groupBy()`?
+
+You cannot use `select` with `groupBy()`. However, all fields included in `by` are automatically returned.
+
+#### What is the difference between using `where` and `having` with `groupBy()`?
+
+`where` filters all records before grouping, and `having` filters entire groups and supports filtering on an aggregate field value, such as the average or sum of a particular field in that group.
+
+#### What is the difference between `groupBy()` and `distinct`?
+
+Both `distinct` and `groupBy()` group records by one or more unique field values. `groupBy()` allows you to aggregate data within each group - for example, return the average number of views on posts from Denmark - whereas distinct does not.
+
+## Count
+
+### Count records
+
+Use [`count()`](/6.0/orm/reference/prisma-client-reference#count) to count the number of records or non-`null` field values. The following example query counts all users:
+
+```ts
+const userCount = await prisma.user.count()
+```
+
+### Count relations
+
+
+
+This feature is generally available in version [3.0.1](https://github.com/prisma/prisma/releases/3.0.1) and later. To use this feature in versions before 3.0.1 the [Preview feature](/orm/reference/preview-features/client-preview-features#enabling-a-prisma-client-preview-feature) `selectRelationCount` will need to be enabled.
+
+
+
+To return a count of relations (for example, a user's post count), use the `_count` parameter with a nested `select` as shown:
+
+
+
+
+```ts
+const usersWithCount = await prisma.user.findMany({
+ include: {
+ _count: {
+ select: { posts: true },
+ },
+ },
+})
+```
+
+
+
+
+```js no-copy
+{ id: 1, _count: { posts: 3 } },
+{ id: 2, _count: { posts: 2 } },
+{ id: 3, _count: { posts: 2 } },
+{ id: 4, _count: { posts: 0 } },
+{ id: 5, _count: { posts: 0 } }
+```
+
+
+
+
+The `_count` parameter:
+
+- Can be used inside a top-level `include` _or_ `select`
+- Can be used with any query that returns records (including `delete`, `update`, and `findFirst`)
+- Can return [multiple relation counts](#return-multiple-relation-counts)
+- Can [filter relation counts](#filter-the-relation-count) (from version 4.3.0)
+
+#### Return a relations count with `include`
+
+The following query includes each user's post count in the results:
+
+
+
+
+```ts
+const usersWithCount = await prisma.user.findMany({
+ include: {
+ _count: {
+ select: { posts: true },
+ },
+ },
+})
+```
+
+
+
+
+```js no-copy
+{ id: 1, _count: { posts: 3 } },
+{ id: 2, _count: { posts: 2 } },
+{ id: 3, _count: { posts: 2 } },
+{ id: 4, _count: { posts: 0 } },
+{ id: 5, _count: { posts: 0 } }
+```
+
+
+
+
+#### Return a relations count with `select`
+
+The following query uses `select` to return each user's post count _and no other fields_:
+
+
+
+
+```ts
+const usersWithCount = await prisma.user.findMany({
+ select: {
+ _count: {
+ select: { posts: true },
+ },
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ _count: {
+ posts: 3
+ }
+}
+```
+
+
+
+
+#### Return multiple relation counts
+
+The following query returns a count of each user's `posts` and `recipes` and no other fields:
+
+
+
+
+```ts
+const usersWithCount = await prisma.user.findMany({
+ select: {
+ _count: {
+ select: {
+ posts: true,
+ recipes: true,
+ },
+ },
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ _count: {
+ posts: 3,
+ recipes: 9
+ }
+}
+```
+
+
+
+
+#### Filter the relation count
+
+
+
+This feature is generally available in version `4.16.0` and later. To use this feature in versions [`4.3.0`](https://github.com/prisma/prisma/releases/tag/4.3.0) to [`4.15.0`](https://github.com/prisma/prisma/releases/tag/4.15.0) the [Preview feature](/orm/reference/preview-features/client-preview-features#enabling-a-prisma-client-preview-feature) `filteredRelationCount` will need to be enabled.
+
+
+
+Use `where` to filter the fields returned by the `_count` output type. You can do this on [scalar fields](/orm/prisma-schema/data-model/models#scalar-fields), [relation fields](/orm/prisma-schema/data-model/models#relation-fields) and fields of a [composite type](/orm/prisma-schema/data-model/models#defining-composite-types).
+
+For example, the following query returns all user posts with the title "Hello!":
+
+```ts
+// Count all user posts with the title "Hello!"
+await prisma.user.findMany({
+ select: {
+ _count: {
+ select: {
+ posts: { where: { title: 'Hello!' } },
+ },
+ },
+ },
+})
+```
+
+The following query finds all user posts with comments from an author named "Alice":
+
+```ts
+// Count all user posts that have comments
+// whose author is named "Alice"
+await prisma.user.findMany({
+ select: {
+ _count: {
+ select: {
+ posts: {
+ where: { comments: { some: { author: { is: { name: 'Alice' } } } } },
+ },
+ },
+ },
+ },
+})
+```
+
+### Count non-`null` field values
+
+In [2.15.0](https://github.com/prisma/prisma/releases/2.15.0) and later, you can count all records as well as all instances of non-`null` field values. The following query returns a count of:
+
+- All `User` records (`_all`)
+- All non-`null` `name` values (not distinct values, just values that are not `null`)
+
+
+
+
+```ts
+const userCount = await prisma.user.count({
+ select: {
+ _all: true, // Count all records
+ name: true, // Count all non-null field values
+ },
+})
+```
+
+
+
+
+```js no-copy
+{ _all: 30, name: 10 }
+```
+
+
+
+
+### Filtered count
+
+`count` supports filtering. The following example query counts all users with more than 100 profile views:
+
+```ts
+const userCount = await prisma.user.count({
+ where: {
+ profileViews: {
+ gte: 100,
+ },
+ },
+})
+```
+
+The following example query counts a particular user's posts:
+
+```ts
+const postCount = await prisma.post.count({
+ where: {
+ authorId: 29,
+ },
+})
+```
+
+## Select distinct
+
+Prisma Client allows you to filter duplicate rows from a Prisma Query response to a [`findMany`](/6.0/orm/reference/prisma-client-reference#findmany) query using [`distinct`](/6.0/orm/reference/prisma-client-reference#distinct) . `distinct` is often used in combination with [`select`](/6.0/orm/reference/prisma-client-reference#select) to identify certain unique combinations of values in the rows of your table.
+
+The following example returns all fields for all `User` records with distinct `name` field values:
+
+```ts
+const result = await prisma.user.findMany({
+ where: {},
+ distinct: ['name'],
+})
+```
+
+The following example returns distinct `role` field values (for example, `ADMIN` and `USER`):
+
+
+
+
+```ts
+const distinctRoles = await prisma.user.findMany({
+ distinct: ['role'],
+ select: {
+ role: true,
+ },
+})
+```
+
+
+
+
+```js no-copy
+;[
+ {
+ role: 'USER',
+ },
+ {
+ role: 'ADMIN',
+ },
+]
+```
+
+
+
+
+### `distinct` under the hood
+
+Prisma Client's `distinct` option does not use SQL `SELECT DISTINCT`. Instead, `distinct` uses:
+
+- A `SELECT` query
+- In-memory post-processing to select distinct
+
+It was designed in this way in order to **support `select` and `include`** as part of `distinct` queries.
+
+The following example selects distinct on `gameId` and `playerId`, ordered by `score`, in order to return **each player's highest score per game**. The query uses `include` and `select` to include additional data:
+
+- Select `score` (field on `Play`)
+- Select related player name (relation between `Play` and `User`)
+- Select related game name (relation between `Play` and `Game`)
+
+
+
+Expand for sample schema
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ name String?
+ play Play[]
+}
+
+model Game {
+ id Int @id @default(autoincrement())
+ name String?
+ play Play[]
+}
+
+model Play {
+ id Int @id @default(autoincrement())
+ score Int? @default(0)
+ playerId Int?
+ player User? @relation(fields: [playerId], references: [id])
+ gameId Int?
+ game Game? @relation(fields: [gameId], references: [id])
+}
+```
+
+
+
+
+
+
+```ts
+const distinctScores = await prisma.play.findMany({
+ distinct: ['playerId', 'gameId'],
+ orderBy: {
+ score: 'desc',
+ },
+ select: {
+ score: true,
+ game: {
+ select: {
+ name: true,
+ },
+ },
+ player: {
+ select: {
+ name: true,
+ },
+ },
+ },
+})
+```
+
+
+
+
+```code no-copy
+[
+ {
+ score: 900,
+ game: { name: 'Pacman' },
+ player: { name: 'Bert Bobberton' }
+ },
+ {
+ score: 400,
+ game: { name: 'Pacman' },
+ player: { name: 'Nellie Bobberton' }
+ }
+]
+```
+
+
+
+
+Without `select` and `distinct`, the query would return:
+
+```
+[
+ {
+ gameId: 2,
+ playerId: 5
+ },
+ {
+ gameId: 2,
+ playerId: 10
+ }
+]
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/058-transactions.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/058-transactions.mdx
new file mode 100644
index 0000000000..5baeeb2aef
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/058-transactions.mdx
@@ -0,0 +1,1392 @@
+---
+title: 'Transactions and batch queries'
+metaTitle: 'Transactions and batch queries (Reference)'
+metaDescription: 'This page explains the transactions API of Prisma Client.'
+tocDepth: 3
+---
+
+
+
+A database transaction refers to a sequence of read/write operations that are _guaranteed_ to either succeed or fail as a whole. This section describes the ways in which the Prisma Client API supports transactions.
+
+
+
+## Transactions overview
+
+
+
+Before Prisma ORM version 4.4.0, you could not set isolation levels on transactions. The isolation level in your database configuration always applied.
+
+
+
+Developers take advantage of the safety guarantees provided by the database by wrapping the operations in a transaction. These guarantees are often summarized using the ACID acronym:
+
+- **Atomic**: Ensures that either _all_ or _none_ operations of the transactions succeed. The transaction is either _committed_ successfully or _aborted_ and _rolled back_.
+- **Consistent**: Ensures that the states of the database before and after the transaction are _valid_ (i.e. any existing invariants about the data are maintained).
+- **Isolated**: Ensures that concurrently running transactions have the same effect as if they were running in serial.
+- **Durability**: Ensures that after the transaction succeeded, any writes are being stored persistently.
+
+While there's a lot of ambiguity and nuance to each of these properties (for example, consistency could actually be considered an _application-level responsibility_ rather than a database property or isolation is typically guaranteed in terms of stronger and weaker _isolation levels_), overall they serve as a good high-level guideline for expectations developers have when thinking about database transactions.
+
+> "Transactions are an abstraction layer that allows an application to pretend that certain concurrency problems and certain kinds of hardware and software faults don’t exist. A large class of errors is reduced down to a simple transaction abort, and the application just needs to try again." [Designing Data-Intensive Applications](https://dataintensive.net/), [Martin Kleppmann](https://bsky.app/profile/martin.kleppmann.com)
+
+Prisma Client supports six different ways of handling transactions for three different scenarios:
+
+| Scenario | Available techniques |
+| :------------------ | :-------------------------------------------------------------------------------------------------------------- |
+| Dependent writes |
Nested writes
|
+| Independent writes |
`$transaction([])` API
Batch operations
|
+| Read, modify, write |
Idempotent operations
Optimistic concurrency control
Interactive transactions
|
+
+The technique you choose depends on your particular use case.
+
+> **Note**: For the purposes of this guide, _writing_ to a database encompasses creating, updating, and deleting data.
+
+## About transactions in Prisma Client
+
+Prisma Client provides the following options for using transactions:
+
+- [Nested writes](#nested-writes): use the Prisma Client API to process multiple operations on one or more related records inside the same transaction.
+- [Batch / bulk transactions](#batchbulk-operations): process one or more operations in bulk with `updateMany`, `deleteMany`, and `createMany`.
+- The `$transaction` API in Prisma Client:
+ - [Sequential operations](#sequential-prisma-client-operations): pass an array of Prisma Client queries to be executed sequentially inside a transaction, using `$transaction(queries: PrismaPromise[]): Promise`.
+ - [Interactive transactions](#interactive-transactions): pass a function that can contain user code including Prisma Client queries, non-Prisma code and other control flow to be executed in a transaction, using `$transaction(fn: (prisma: PrismaClient) => R, options?: object): R`
+
+## Nested writes
+
+A [nested write](/orm/prisma-client/queries/relation-queries#nested-writes) lets you perform a single Prisma Client API call with multiple _operations_ that touch multiple [_related_](/orm/prisma-schema/data-model/relations) records. For example, creating a _user_ together with a _post_ or updating an _order_ together with an _invoice_. Prisma Client ensures that all operations succeed or fail as a whole.
+
+The following example demonstrates a nested write with `create`:
+
+```ts
+// Create a new user with two posts in a
+// single transaction
+const newUser: User = await prisma.user.create({
+ data: {
+ email: 'alice@prisma.io',
+ posts: {
+ create: [
+ { title: 'Join the Prisma Discord at https://pris.ly/discord' },
+ { title: 'Follow @prisma on Twitter' },
+ ],
+ },
+ },
+})
+```
+
+The following example demonstrates a nested write with `update`:
+
+```ts
+// Change the author of a post in a single transaction
+const updatedPost: Post = await prisma.post.update({
+ where: { id: 42 },
+ data: {
+ author: {
+ connect: { email: 'alice@prisma.io' },
+ },
+ },
+})
+```
+
+## Batch/bulk operations
+
+The following bulk operations run as transactions:
+
+- `createMany()`
+- `createManyAndReturn()`
+- `updateMany()`
+- `updateManyAndReturn()`
+- `deleteMany()`
+
+> Refer to the section about [bulk operations](#bulk-operations) for more examples.
+
+## The `$transaction` API
+
+The `$transaction` API can be used in two ways:
+
+- [Sequential operations](#sequential-prisma-client-operations): Pass an array of Prisma Client queries to be executed sequentially inside of a transaction.
+
+ `$transaction(queries: PrismaPromise[]): Promise`
+
+- [Interactive transactions](#interactive-transactions): Pass a function that can contain user code including Prisma Client queries, non-Prisma code and other control flow to be executed in a transaction.
+
+ `$transaction(fn: (prisma: PrismaClient) => R): R`
+
+### Sequential Prisma Client operations
+
+The following query returns all posts that match the provided filter as well as a count of all posts:
+
+```ts
+const [posts, totalPosts] = await prisma.$transaction([
+ prisma.post.findMany({ where: { title: { contains: 'prisma' } } }),
+ prisma.post.count(),
+])
+```
+
+You can also use raw queries inside of a `$transaction`:
+
+
+
+
+
+```ts
+import { selectUserTitles, updateUserName } from '@prisma/client/sql'
+
+const [userList, updateUser] = await prisma.$transaction([
+ prisma.$queryRawTyped(selectUserTitles()),
+ prisma.$queryRawTyped(updateUserName(2)),
+])
+```
+
+
+
+
+
+```ts
+const [findRawData, aggregateRawData, commandRawData] =
+ await prisma.$transaction([
+ prisma.user.findRaw({
+ filter: { age: { $gt: 25 } },
+ }),
+ prisma.user.aggregateRaw({
+ pipeline: [
+ { $match: { status: 'registered' } },
+ { $group: { _id: '$country', total: { $sum: 1 } } },
+ ],
+ }),
+ prisma.$runCommandRaw({
+ aggregate: 'User',
+ pipeline: [
+ { $match: { name: 'Bob' } },
+ { $project: { email: true, _id: false } },
+ ],
+ explain: false,
+ }),
+ ])
+```
+
+
+
+
+
+Instead of immediately awaiting the result of each operation when it's performed, the operation itself is stored in a variable first which later is submitted to the database with a method called `$transaction`. Prisma Client will ensure that either all three `create` operations succeed or none of them succeed.
+
+> **Note**: Operations are executed according to the order they are placed in the transaction. Using a query in a transaction does not influence the order of operations in the query itself.
+>
+> Refer to the section about the [transactions API](#transaction-api) for more examples.
+
+From version 4.4.0, the sequential operations transaction API has a second parameter. You can use the following optional configuration option in this parameter:
+
+- `isolationLevel`: Sets the [transaction isolation level](#transaction-isolation-level). By default this is set to the value currently configured in your database.
+
+For example:
+
+```ts
+await prisma.$transaction(
+ [
+ prisma.resource.deleteMany({ where: { name: 'name' } }),
+ prisma.resource.createMany({ data }),
+ ],
+ {
+ isolationLevel: Prisma.TransactionIsolationLevel.Serializable, // optional, default defined by database configuration
+ }
+)
+```
+
+### Interactive transactions
+
+#### Overview
+
+Sometimes you need more control over what queries execute within a transaction. Interactive transactions are meant to provide you with an escape hatch.
+
+
+
+Interactive transactions have been generally available from version 4.7.0.
+
+If you use interactive transactions in preview from version 2.29.0 to 4.6.1 (inclusive), you need to add the `interactiveTransactions` preview feature to the generator block of your Prisma schema.
+
+
+
+To use interactive transactions, you can pass an async function into [`$transaction`](#transaction-api).
+
+The first argument passed into this async function is an instance of Prisma Client. Below, we will call this instance `tx`. Any Prisma Client call invoked on this `tx` instance is encapsulated into the transaction.
+
+
+
+**Use interactive transactions with caution**. Keeping transactions open for a long time hurts database performance and can even cause deadlocks. Try to avoid performing network requests and executing slow queries inside your transaction functions. We recommend you get in and out as quick as possible!
+
+
+
+#### Example
+
+Let's look at an example:
+
+Imagine that you are building an online banking system. One of the actions to perform is to send money from one person to another.
+
+As experienced developers, we want to make sure that during the transfer,
+
+- the amount doesn't disappear
+- the amount isn't doubled
+
+This is a great use-case for interactive transactions because we need to perform logic in-between the writes to check the balance.
+
+In the example below, Alice and Bob each have $100 in their account. If they try to send more money than they have, the transfer is rejected.
+
+Alice is expected to be able to make 1 transfer for $100 while the other transfer would be rejected. This would result in Alice having $0 and Bob having $200.
+
+```tsx
+import { PrismaClient } from '@prisma/client'
+const prisma = new PrismaClient()
+
+function transfer(from: string, to: string, amount: number) {
+ return prisma.$transaction(async (tx) => {
+ // 1. Decrement amount from the sender.
+ const sender = await tx.account.update({
+ data: {
+ balance: {
+ decrement: amount,
+ },
+ },
+ where: {
+ email: from,
+ },
+ })
+
+ // 2. Verify that the sender's balance didn't go below zero.
+ if (sender.balance < 0) {
+ throw new Error(`${from} doesn't have enough to send ${amount}`)
+ }
+
+ // 3. Increment the recipient's balance by amount
+ const recipient = await tx.account.update({
+ data: {
+ balance: {
+ increment: amount,
+ },
+ },
+ where: {
+ email: to,
+ },
+ })
+
+ return recipient
+ })
+}
+
+async function main() {
+ // This transfer is successful
+ await transfer('alice@prisma.io', 'bob@prisma.io', 100)
+ // This transfer fails because Alice doesn't have enough funds in her account
+ await transfer('alice@prisma.io', 'bob@prisma.io', 100)
+}
+
+main()
+```
+
+In the example above, both `update` queries run within a database transaction. When the application reaches the end of the function, the transaction is **committed** to the database.
+
+If your application encounters an error along the way, the async function will throw an exception and automatically **rollback** the transaction.
+
+To catch the exception, you can wrap `$transaction` in a try-catch block:
+
+```js
+try {
+ await prisma.$transaction(async (tx) => {
+ // Code running in a transaction...
+ })
+} catch (err) {
+ // Handle the rollback...
+}
+```
+
+#### Transaction options
+
+The transaction API has a second parameter. For interactive transactions, you can use the following optional configuration options in this parameter:
+
+- `maxWait`: The maximum amount of time Prisma Client will wait to acquire a transaction from the database. The default value is 2 seconds.
+- `timeout`: The maximum amount of time the interactive transaction can run before being canceled and rolled back. The default value is 5 seconds.
+- `isolationLevel`: Sets the [transaction isolation level](#transaction-isolation-level). By default this is set to the value currently configured in your database.
+
+For example:
+
+```ts
+await prisma.$transaction(
+ async (tx) => {
+ // Code running in a transaction...
+ },
+ {
+ maxWait: 5000, // default: 2000
+ timeout: 10000, // default: 5000
+ isolationLevel: Prisma.TransactionIsolationLevel.Serializable, // optional, default defined by database configuration
+ }
+)
+```
+
+You can also set these globally on the constructor-level:
+
+```ts
+const prisma = new PrismaClient({
+ transactionOptions: {
+ isolationLevel: Prisma.TransactionIsolationLevel.Serializable,
+ maxWait: 5000, // default: 2000
+ timeout: 10000, // default: 5000
+ },
+})
+```
+
+### Transaction isolation level
+
+
+
+This feature is not available on MongoDB, because MongoDB does not support isolation levels.
+
+
+
+You can set the transaction [isolation level](https://www.prisma.io/dataguide/intro/database-glossary#isolation-levels) for transactions.
+
+
+
+This is available in the following Prisma ORM versions for interactive transactions from version 4.2.0, for sequential operations from version 4.4.0.
+
+In versions before 4.2.0 (for interactive transactions), or 4.4.0 (for sequential operations), you cannot configure the transaction isolation level at a Prisma ORM level. Prisma ORM does not explicitly set the isolation level, so the [isolation level configured in your database](#database-specific-information-on-isolation-levels) is used.
+
+
+
+#### Set the isolation level
+
+To set the transaction isolation level, use the `isolationLevel` option in the second parameter of the API.
+
+For sequential operations:
+
+```ts
+await prisma.$transaction(
+ [
+ // Prisma Client operations running in a transaction...
+ ],
+ {
+ isolationLevel: Prisma.TransactionIsolationLevel.Serializable, // optional, default defined by database configuration
+ }
+)
+```
+
+For an interactive transaction:
+
+```jsx
+await prisma.$transaction(
+ async (prisma) => {
+ // Code running in a transaction...
+ },
+ {
+ isolationLevel: Prisma.TransactionIsolationLevel.Serializable, // optional, default defined by database configuration
+ maxWait: 5000, // default: 2000
+ timeout: 10000, // default: 5000
+ }
+)
+```
+
+#### Supported isolation levels
+
+Prisma Client supports the following isolation levels if they are available in the underlying database:
+
+- `ReadUncommitted`
+- `ReadCommitted`
+- `RepeatableRead`
+- `Snapshot`
+- `Serializable`
+
+The isolation levels available for each database connector are as follows:
+
+| Database | `ReadUncommitted` | `ReadCommitted` | `RepeatableRead` | `Snapshot` | `Serializable` |
+| ----------- | ----------------- | --------------- | ---------------- | ---------- | -------------- |
+| PostgreSQL | ✔️ | ✔️ | ✔️ | No | ✔️ |
+| MySQL | ✔️ | ✔️ | ✔️ | No | ✔️ |
+| SQL Server | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
+| CockroachDB | No | No | No | No | ✔️ |
+| SQLite | No | No | No | No | ✔️ |
+
+By default, Prisma Client sets the isolation level to the value currently configured in your database.
+
+The isolation levels configured by default in each database are as follows:
+
+| Database | Default |
+| ----------- | ---------------- |
+| PostgreSQL | `ReadCommitted` |
+| MySQL | `RepeatableRead` |
+| SQL Server | `ReadCommitted` |
+| CockroachDB | `Serializable` |
+| SQLite | `Serializable` |
+
+#### Database-specific information on isolation levels
+
+See the following resources:
+
+- [Transaction isolation levels in PostgreSQL](https://www.postgresql.org/docs/9.3/runtime-config-client.html#GUC-DEFAULT-TRANSACTION-ISOLATION)
+- [Transaction isolation levels in Microsoft SQL Server](https://learn.microsoft.com/en-us/sql/t-sql/statements/set-transaction-isolation-level-transact-sql?view=sql-server-ver15)
+- [Transaction isolation levels in MySQL](https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html)
+
+CockroachDB and SQLite only support the `Serializable` isolation level.
+
+### Transaction timing issues
+
+
+
+- The solution in this section does not apply to MongoDB, because MongoDB does not support [isolation levels](https://www.prisma.io/dataguide/intro/database-glossary#isolation-levels).
+- The timing issues discussed in this section do not apply to CockroachDB and SQLite, because these databases only support the highest `Serializable` isolation level.
+
+
+
+When two or more transactions run concurrently in certain [isolation levels](https://www.prisma.io/dataguide/intro/database-glossary#isolation-levels), timing issues can cause write conflicts or deadlocks, such as the violation of unique constraints. For example, consider the following sequence of events where Transaction A and Transaction B both attempt to execute a `deleteMany` and a `createMany` operation:
+
+1. Transaction B: `createMany` operation creates a new set of rows.
+1. Transaction B: The application commits transaction B.
+1. Transaction A: `createMany` operation.
+1. Transaction A: The application commits transaction A. The new rows conflict with the rows that transaction B added at step 2.
+
+This conflict can occur at the isolation level `ReadCommited`, which is the default isolation level in PostgreSQL and Microsoft SQL Server. To avoid this problem, you can set a higher isolation level (`RepeatableRead` or `Serializable`). You can set the isolation level on a transaction. This overrides your database isolation level for that transaction.
+
+To avoid transaction write conflicts and deadlocks on a transaction:
+
+1. On your transaction, use the `isolationLevel` parameter to `Prisma.TransactionIsolationLevel.Serializable`.
+
+ This ensures that your application commits multiple concurrent or parallel transactions as if they were run serially. When a transaction fails due to a write conflict or deadlock, Prisma Client returns a [P2034 error](/orm/reference/error-reference#p2034).
+
+2. In your application code, add a retry around your transaction to handle any P2034 errors, as shown in this example:
+
+ ```ts
+ import { Prisma, PrismaClient } from '@prisma/client'
+
+ const prisma = new PrismaClient()
+ async function main() {
+ const MAX_RETRIES = 5
+ let retries = 0
+
+ let result
+ while (retries < MAX_RETRIES) {
+ try {
+ result = await prisma.$transaction(
+ [
+ prisma.user.deleteMany({
+ where: {
+ /** args */
+ },
+ }),
+ prisma.post.createMany({
+ data: {
+ /** args */
+ },
+ }),
+ ],
+ {
+ isolationLevel: Prisma.TransactionIsolationLevel.Serializable,
+ }
+ )
+ break
+ } catch (error) {
+ if (error.code === 'P2034') {
+ retries++
+ continue
+ }
+ throw error
+ }
+ }
+ }
+ ```
+
+### Using `$transaction` within `Promise.all()`
+
+If you wrap a `$transaction` inside a call to `Promise.all()`, the queries inside the transaction will be executed _serially_ (i.e. one after another):
+
+```ts
+await prisma.$transaction(async (prisma) => {
+ await Promise.all([
+ prisma.user.findMany(),
+ prisma.user.findMany(),
+ prisma.user.findMany(),
+ prisma.user.findMany(),
+ prisma.user.findMany(),
+ prisma.user.findMany(),
+ prisma.user.findMany(),
+ prisma.user.findMany(),
+ prisma.user.findMany(),
+ prisma.user.findMany(),
+ ])
+})
+```
+
+ This may be counterintuitive because `Promise.all()` usually _parallelizes_ the calls passed into it.
+
+The reason for this behaviour is that:
+- One transaction means that all queries inside it have to be run on the same connection.
+- A database connection can only ever execute one query at a time.
+- As one query blocks the connection while it is doing its work, putting a transaction into `Promise.all` effectively means that queries should be ran one after another.
+
+
+
+## Dependent writes
+
+Writes are considered **dependent** on each other if:
+
+- Operations depend on the result of a preceding operation (for example, the database generating an ID)
+
+The most common scenario is creating a record and using the generated ID to create or update a related record. Examples include:
+
+- Creating a user and two related blog posts (a one-to-many relationship) - the author ID must be known before creating blog posts
+- Creating a team and assigning members (a many-to-many relationship) - the team ID must be known before assigning members
+
+Dependent writes must succeed together in order to maintain data consistency and prevent unexpected behavior, such as blog post without an author or a team without members.
+
+### Nested writes
+
+Prisma Client's solution to dependent writes is the **nested writes** feature, which is supported by `create` and `update`. The following nested write creates one user and two blog posts:
+
+```ts
+const nestedWrite = await prisma.user.create({
+ data: {
+ email: 'imani@prisma.io',
+ posts: {
+ create: [
+ { title: 'My first day at Prisma' },
+ { title: 'How to configure a unique constraint in PostgreSQL' },
+ ],
+ },
+ },
+})
+```
+
+If any operation fails, Prisma Client rolls back the entire transaction. Nested writes are not currently supported by top-level bulk operations like `client.user.deleteMany` and `client.user.updateMany`.
+
+#### When to use nested writes
+
+Consider using nested writes if:
+
+- ✔ You want to create two or more records related by ID at the same time (for example, create a blog post and a user)
+- ✔ You want to update and create records related by ID at the same time (for example, change a user's name and create a new blog post)
+
+:::tip
+
+If you [pre-compute your IDs, you can choose between a nested write or using the `$transaction([])` API](#scenario-pre-computed-ids-and-the-transaction-api).
+
+:::
+
+#### Scenario: Sign-up flow
+
+Consider the Slack sign-up flow, which:
+
+1. Creates a team
+2. Adds one user to that team, which automatically becomes that team's administrator
+
+This scenario can be represented by the following schema - note that users can belong to many teams, and teams can have many users (a many-to-many relationship):
+
+```prisma
+model Team {
+ id Int @id @default(autoincrement())
+ name String
+ members User[] // Many team members
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ teams Team[] // Many teams
+}
+```
+
+The most straightforward approach is to create a team, then create and attach a user to that team:
+
+```ts
+// Create a team
+const team = await prisma.team.create({
+ data: {
+ name: 'Aurora Adventures',
+ },
+})
+
+// Create a user and assign them to the team
+const user = await prisma.user.create({
+ data: {
+ email: 'alice@prisma.io',
+ team: {
+ connect: {
+ id: team.id,
+ },
+ },
+ },
+})
+```
+
+However, this code has a problem - consider the following scenario:
+
+1. Creating the team succeeds - "Aurora Adventures" is now taken
+2. Creating and connecting the user fails - the team "Aurora Adventures" exists, but has no users
+3. Going through the sign-up flow again and attempting to recreate "Aurora Adventures" fails - the team already exists
+
+Creating a team and adding a user should be one atomic operation that **succeeds or fails as a whole**.
+
+To implement atomic writes in a low-level database clients, you must wrap your inserts in `BEGIN`, `COMMIT` and `ROLLBACK` statements. Prisma Client solves the problem with [nested writes](/orm/prisma-client/queries/relation-queries#nested-writes). The following query creates a team, creates a user, and connects the records in a single transaction:
+
+```ts
+const team = await prisma.team.create({
+ data: {
+ name: 'Aurora Adventures',
+ members: {
+ create: {
+ email: 'alice@prisma.io',
+ },
+ },
+ },
+})
+```
+
+Furthermore, if an error occurs at any point, Prisma Client rolls back the entire transaction.
+
+#### Nested writes FAQs
+
+##### Why can't I use the `$transaction([])` API to solve the same problem?
+
+The `$transaction([])` API does not allow you to pass IDs between distinct operations. In the following example, `createUserOperation.id` is not available yet:
+
+```ts highlight=12;delete
+const createUserOperation = prisma.user.create({
+ data: {
+ email: 'ebony@prisma.io',
+ },
+})
+
+const createTeamOperation = prisma.team.create({
+ data: {
+ name: 'Aurora Adventures',
+ members: {
+ connect: {
+ //delete-next-line
+ id: createUserOperation.id, // Not possible, ID not yet available
+ },
+ },
+ },
+})
+
+await prisma.$transaction([createUserOperation, createTeamOperation])
+```
+
+##### Nested writes support nested updates, but updates are not dependent writes - should I use the `$transaction([])` API?
+
+It is correct to say that because you know the ID of the team, you can update the team and its team members independently within a `$transaction([])`. The following example performs both operations in a `$transaction([])`:
+
+```ts
+const updateTeam = prisma.team.update({
+ where: {
+ id: 1,
+ },
+ data: {
+ name: 'Aurora Adventures Ltd',
+ },
+})
+
+const updateUsers = prisma.user.updateMany({
+ where: {
+ teams: {
+ some: {
+ id: 1,
+ },
+ },
+ name: {
+ equals: null,
+ },
+ },
+ data: {
+ name: 'Unknown User',
+ },
+})
+
+await prisma.$transaction([updateUsers, updateTeam])
+```
+
+However, you can achieve the same result with a nested write:
+
+```ts
+const updateTeam = await prisma.team.update({
+ where: {
+ id: 1,
+ },
+ data: {
+ name: 'Aurora Adventures Ltd', // Update team name
+ members: {
+ updateMany: {
+ // Update team members that do not have a name
+ data: {
+ name: 'Unknown User',
+ },
+ where: {
+ name: {
+ equals: null,
+ },
+ },
+ },
+ },
+ },
+})
+```
+
+##### Can I perform multiple nested writes - for example, create two new teams and assign users?
+
+Yes, but this is a combination of scenarios and techniques:
+
+- Creating a team and assigning users is a dependent write - use nested writes
+- Creating all teams and users at the same time is an independent write because team/user combination #1 and team/user combination #2 are unrelated writes - use the `$transaction([])` API
+
+```ts
+// Nested write
+const createOne = prisma.team.create({
+ data: {
+ name: 'Aurora Adventures',
+ members: {
+ create: {
+ email: 'alice@prisma.io',
+ },
+ },
+ },
+})
+
+// Nested write
+const createTwo = prisma.team.create({
+ data: {
+ name: 'Cool Crew',
+ members: {
+ create: {
+ email: 'elsa@prisma.io',
+ },
+ },
+ },
+})
+
+// $transaction([]) API
+await prisma.$transaction([createTwo, createOne])
+```
+
+## Independent writes
+
+Writes are considered **independent** if they do not rely on the result of a previous operation. The following groups of independent writes can occur in any order:
+
+- Updating the status field of a list of orders to "Dispatched"
+- Marking a list of emails as "Read"
+
+> **Note**: Independent writes may have to occur in a specific order if constraints are present - for example, you must delete blog posts before the blog author if the post have a mandatory `authorId` field. However, they are still considered independent writes because no operations depend on the _result_ of a previous operation, such as the database returning a generated ID.
+
+Depending on your requirements, Prisma Client has four options for handling independent writes that should succeed or fail together.
+
+### Bulk operations
+
+Bulk writes allow you to write multiple records of the same type in a single transaction - if any operation fails, Prisma Client rolls back the entire transaction. Prisma Client currently supports:
+
+- `createMany()`
+- `createManyAndReturn()`
+- `updateMany()`
+- `updateManyAndReturn()`
+- `deleteMany()`
+
+
+#### When to use bulk operations
+
+Consider bulk operations as a solution if:
+
+- ✔ You want to update a batch of the _same type_ of record, like a batch of emails
+
+#### Scenario: Marking emails as read
+
+You are building a service like gmail.com, and your customer wants a **"Mark as read"** feature that allows users to mark all emails as read. Each update to the status of an email is an independent write because the emails do not depend on one another - for example, the "Happy Birthday! 🍰" email from your aunt is unrelated to the promotional email from IKEA.
+
+In the following schema, a `User` can have many received emails (a one-to-many relationship):
+
+```ts
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ receivedEmails Email[] // Many emails
+}
+
+model Email {
+ id Int @id @default(autoincrement())
+ user User @relation(fields: [userId], references: [id])
+ userId Int
+ subject String
+ body String
+ unread Boolean
+}
+```
+
+Based on this schema, you can use `updateMany` to mark all unread emails as read:
+
+```ts
+await prisma.email.updateMany({
+ where: {
+ user: {
+ id: 10,
+ },
+ unread: true,
+ },
+ data: {
+ unread: false,
+ },
+})
+```
+
+#### Can I use nested writes with bulk operations?
+
+No - neither `updateMany` nor `deleteMany` currently supports nested writes. For example, you cannot delete multiple teams and all of their members (a cascading delete):
+
+```ts highlight=8;delete
+await prisma.team.deleteMany({
+ where: {
+ id: {
+ in: [2, 99, 2, 11],
+ },
+ },
+ data: {
+ //delete-next-line
+ members: {}, // Cannot access members here
+ },
+})
+```
+
+#### Can I use bulk operations with the `$transaction([])` API?
+
+Yes — for example, you can include multiple `deleteMany` operations inside a `$transaction([])`.
+
+### `$transaction([])` API
+
+The `$transaction([])` API is generic solution to independent writes that allows you to run multiple operations as a single, atomic operation - if any operation fails, Prisma Client rolls back the entire transaction.
+
+Its also worth noting that operations are executed according to the order they are placed in the transaction.
+
+```ts
+await prisma.$transaction([iRunFirst, iRunSecond, iRunThird])
+```
+
+> **Note**: Using a query in a transaction does not influence the order of operations in the query itself.
+
+As Prisma Client evolves, use cases for the `$transaction([])` API will increasingly be replaced by more specialized bulk operations (such as `createMany`) and nested writes.
+
+#### When to use the `$transaction([])` API
+
+Consider the `$transaction([])` API if:
+
+- ✔ You want to update a batch that includes different types of records, such as emails and users. The records do not need to be related in any way.
+- ✔ You want to batch raw SQL queries (`$executeRaw`) - for example, for features that Prisma Client does not yet support.
+
+#### Scenario: Privacy legislation
+
+GDPR and other privacy legislation give users the right to request that an organization deletes all of their personal data. In the following example schema, a `User` can have many posts and private messages:
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ posts Post[]
+ privateMessages PrivateMessage[]
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ user User @relation(fields: [userId], references: [id])
+ userId Int
+ title String
+ content String
+}
+
+model PrivateMessage {
+ id Int @id @default(autoincrement())
+ user User @relation(fields: [userId], references: [id])
+ userId Int
+ message String
+}
+```
+
+If a user invokes the right to be forgotten, we must delete three records: the user record, private messages, and posts. It is critical that _all_ delete operations succeed together or not at all, which makes this a use case for a transaction. However, using a single bulk operation like `deleteMany` is not possible in this scenario because we need to delete across three models. Instead, we can use the `$transaction([])` API to run three operations together - two `deleteMany` and one `delete`:
+
+```ts
+const id = 9 // User to be deleted
+
+const deletePosts = prisma.post.deleteMany({
+ where: {
+ userId: id,
+ },
+})
+
+const deleteMessages = prisma.privateMessage.deleteMany({
+ where: {
+ userId: id,
+ },
+})
+
+const deleteUser = prisma.user.delete({
+ where: {
+ id: id,
+ },
+})
+
+await prisma.$transaction([deletePosts, deleteMessages, deleteUser]) // Operations succeed or fail together
+```
+
+#### Scenario: Pre-computed IDs and the `$transaction([])` API
+
+Dependent writes are not supported by the `$transaction([])` API - if operation A relies on the ID generated by operation B, use [nested writes](#nested-writes). However, if you _pre-computed_ IDs (for example, by generating GUIDs), your writes become independent. Consider the sign-up flow from the nested writes example:
+
+```ts
+await prisma.team.create({
+ data: {
+ name: 'Aurora Adventures',
+ members: {
+ create: {
+ email: 'alice@prisma.io',
+ },
+ },
+ },
+})
+```
+
+Instead of auto-generating IDs, change the `id` fields of `Team` and `User` to a `String` (if you do not provide a value, a UUID is generated automatically). This example uses UUIDs:
+
+```prisma highlight=2,9;delete|3,10;add
+model Team {
+ //delete-next-line
+ id Int @id @default(autoincrement())
+ //add-next-line
+ id String @id @default(uuid())
+ name String
+ members User[]
+}
+
+model User {
+ //delete-next-line
+ id Int @id @default(autoincrement())
+ //add-next-line
+ id String @id @default(uuid())
+ email String @unique
+ teams Team[]
+}
+```
+
+Refactor the sign-up flow example to use the `$transaction([])` API instead of nested writes:
+
+```ts
+import { v4 } from 'uuid'
+
+const teamID = v4()
+const userID = v4()
+
+await prisma.$transaction([
+ prisma.user.create({
+ data: {
+ id: userID,
+ email: 'alice@prisma.io',
+ team: {
+ id: teamID,
+ },
+ },
+ }),
+ prisma.team.create({
+ data: {
+ id: teamID,
+ name: 'Aurora Adventures',
+ },
+ }),
+])
+```
+
+Technically you can still use nested writes with pre-computed APIs if you prefer that syntax:
+
+```ts
+import { v4 } from 'uuid'
+
+const teamID = v4()
+const userID = v4()
+
+await prisma.team.create({
+ data: {
+ id: teamID,
+ name: 'Aurora Adventures',
+ members: {
+ create: {
+ id: userID,
+ email: 'alice@prisma.io',
+ team: {
+ id: teamID,
+ },
+ },
+ },
+ },
+})
+```
+
+There's no compelling reason to switch to manually generated IDs and the `$transaction([])` API if you are already using auto-generated IDs and nested writes.
+
+## Read, modify, write
+
+In some cases you may need to perform custom logic as part of an atomic operation - also known as the [read-modify-write pattern](https://en.wikipedia.org/wiki/Read%E2%80%93modify%E2%80%93write). The following is an example of the read-modify-write pattern:
+
+- Read a value from the database
+- Run some logic to manipulate that value (for example, contacting an external API)
+- Write the value back to the database
+
+All operations should **succeed or fail together** without making unwanted changes to the database, but you do not necessarily need to use an actual database transaction. This section of the guide describes two ways to work with Prisma Client and the read-modify-write pattern:
+
+- Designing idempotent APIs
+- Optimistic concurrency control
+
+### Idempotent APIs
+
+Idempotency is the ability to run the same logic with the same parameters multiple times with the same result: the **effect on the database** is the same whether you run the logic once or one thousand times. For example:
+
+- **NOT IDEMPOTENT**: Upsert (update-or-insert) a user in the database with email address `"letoya@prisma.io"`. The `User` table **does not** enforce unique email addresses. The effect on the database is different if you run the logic once (one user created) or ten times (ten users created).
+- **IDEMPOTENT**: Upsert (update-or-insert) a user in the database with the email address `"letoya@prisma.io"`. The `User` table **does** enforce unique email addresses. The effect on the database is the same if you run the logic once (one user created) or ten times (existing user is updated with the same input).
+
+Idempotency is something you can and should actively design into your application wherever possible.
+
+#### When to design an idempotent API
+
+- ✔ You need to be able to retry the same logic without creating unwanted side-effects in the databases
+
+#### Scenario: Upgrading a Slack team
+
+You are creating an upgrade flow for Slack that allows teams to unlock paid features. Teams can choose between different plans and pay per user, per month. You use Stripe as your payment gateway, and extend your `Team` model to store a `stripeCustomerId`. Subscriptions are managed in Stripe.
+
+```prisma highlight=5;normal
+model Team {
+ id Int @id @default(autoincrement())
+ name String
+ User User[]
+ //highlight-next-line
+ stripeCustomerId String?
+}
+```
+
+The upgrade flow looks like this:
+
+1. Count the number of users
+2. Create a subscription in Stripe that includes the number of users
+3. Associate the team with the Stripe customer ID to unlock paid features
+
+```ts
+const teamId = 9
+const planId = 'plan_id'
+
+// Count team members
+const numTeammates = await prisma.user.count({
+ where: {
+ teams: {
+ some: {
+ id: teamId,
+ },
+ },
+ },
+})
+
+// Create a customer in Stripe for plan-9454549
+const customer = await stripe.customers.create({
+ externalId: teamId,
+ plan: planId,
+ quantity: numTeammates,
+})
+
+// Update the team with the customer id to indicate that they are a customer
+// and support querying this customer in Stripe from our application code.
+await prisma.team.update({
+ data: {
+ customerId: customer.id,
+ },
+ where: {
+ id: teamId,
+ },
+})
+```
+
+This example has a problem: you can only run the logic _once_. Consider the following scenario:
+
+1. Stripe creates a new customer and subscription, and returns a customer ID
+2. Updating the team **fails** - the team is not marked as a customer in the Slack database
+3. The customer is charged by Stripe, but paid features are not unlocked in Slack because the team lacks a valid `customerId`
+4. Running the same code again either:
+
+ - Results in an error because the team (defined by `externalId`) already exists - Stripe never returns a customer ID
+ - If `externalId` is not subject to a unique constraint, Stripe creates yet another subscription (**not idempotent**)
+
+You cannot re-run this code in case of an error and you cannot change to another plan without being charged twice.
+
+The following refactor (highlighted) introduces a mechanism that checks if a subscription already exists, and either creates the description or updates the existing subscription (which will remain unchanged if the input is identical):
+
+```ts highlight=12-27;normal
+// Calculate the number of users times the cost per user
+const numTeammates = await prisma.user.count({
+ where: {
+ teams: {
+ some: {
+ id: teamId,
+ },
+ },
+ },
+})
+
+//highlight-start
+// Find customer in Stripe
+let customer = await stripe.customers.get({ externalId: teamID })
+
+if (customer) {
+ // If team already exists, update
+ customer = await stripe.customers.update({
+ externalId: teamId,
+ plan: 'plan_id',
+ quantity: numTeammates,
+//highlight-end
+ })
+} else {
+ customer = await stripe.customers.create({
+ // If team does not exist, create customer
+ externalId: teamId,
+ plan: 'plan_id',
+ quantity: numTeammates,
+ })
+}
+
+// Update the team with the customer id to indicate that they are a customer
+// and support querying this customer in Stripe from our application code.
+await prisma.team.update({
+ data: {
+ customerId: customer.id,
+ },
+ where: {
+ id: teamId,
+ },
+})
+```
+
+You can now retry the same logic multiple times with the same input without adverse effect. To further enhance this example, you can introduce a mechanism whereby the subscription is cancelled or temporarily deactivated if the update does not succeed after a set number of attempts.
+
+### Optimistic concurrency control
+
+Optimistic concurrency control (OCC) is a model for handling concurrent operations on a single entity that does not rely on 🔒 locking. Instead, we **optimistically** assume that a record will remain unchanged in between reading and writing, and use a concurrency token (a timestamp or version field) to detect changes to a record.
+
+If a ❌ conflict occurs (someone else has changed the record since you read it), you cancel the transaction. Depending on your scenario, you can then:
+
+- Re-try the transaction (book another cinema seat)
+- Throw an error (alert the user that they are about to overwrite changes made by someone else)
+
+This section describes how to build your own optimistic concurrency control. See also: Plans for [application-level optimistic concurrency control on GitHub](https://github.com/prisma/prisma/issues/4988)
+
+
+
+- If you use version 4.4.0 or earlier, you cannot use optimistic concurrency control on `update` operations, because you cannot filter on non-unique fields. The `version` field you need to use with optimistic concurrency control is a non-unique field.
+
+- Since version 5.0.0 you are able to [filter on non-unique fields in `update` operations](/6.0/orm/reference/prisma-client-reference#filter-on-non-unique-fields-with-userwhereuniqueinput) so that optimistic concurrency control is being used. The feature was also available via the Preview flag `extendedWhereUnique` from versions 4.5.0 to 4.16.2.
+
+
+
+#### When to use optimistic concurrency control
+
+- ✔ You anticipate a high number of concurrent requests (multiple people booking cinema seats)
+- ✔ You anticipate that conflicts between those concurrent requests will be rare
+
+Avoiding locks in an application with a high number of concurrent requests makes the application more resilient to load and more scalable overall. Although locking is not inherently bad, locking in a high concurrency environment can lead to unintended consequences - even if you are locking individual rows, and only for a short amount of time. For more information, see:
+
+- [Why ROWLOCK Hints Can Make Queries Slower and Blocking Worse in SQL Server](https://kendralittle.com/2016/02/04/why-rowlock-hints-can-make-queries-slower-and-blocking-worse-in-sql-server/)
+
+#### Scenario: Reserving a seat at the cinema
+
+You are creating a booking system for a cinema. Each movie has a set number of seats. The following schema models movies and seats:
+
+```ts
+model Seat {
+ id Int @id @default(autoincrement())
+ userId Int?
+ claimedBy User? @relation(fields: [userId], references: [id])
+ movieId Int
+ movie Movie @relation(fields: [movieId], references: [id])
+}
+
+model Movie {
+ id Int @id @default(autoincrement())
+ name String @unique
+ seats Seat[]
+}
+```
+
+The following sample code finds the first available seat and assigns that seat to a user:
+
+```ts
+const movieName = 'Hidden Figures'
+
+// Find first available seat
+const availableSeat = await prisma.seat.findFirst({
+ where: {
+ movie: {
+ name: movieName,
+ },
+ claimedBy: null,
+ },
+})
+
+// Throw an error if no seats are available
+if (!availableSeat) {
+ throw new Error(`Oh no! ${movieName} is all booked.`)
+}
+
+// Claim the seat
+await prisma.seat.update({
+ data: {
+ claimedBy: userId,
+ },
+ where: {
+ id: availableSeat.id,
+ },
+})
+```
+
+However, this code suffers from the "double-booking problem" - it is possible for two people to book the same seats:
+
+1. Seat 3A returned to Sorcha (`findFirst`)
+2. Seat 3A returned to Ellen (`findFirst`)
+3. Seat 3A claimed by Sorcha (`update`)
+4. Seat 3A claimed by Ellen (`update` - overwrites Sorcha's claim)
+
+Even though Sorcha has successfully booked the seat, the system ultimately stores Ellen's claim. To solve this problem with optimistic concurrency control, add a `version` field to the seat:
+
+```prisma highlight=7;normal
+model Seat {
+ id Int @id @default(autoincrement())
+ userId Int?
+ claimedBy User? @relation(fields: [userId], references: [id])
+ movieId Int
+ movie Movie @relation(fields: [movieId], references: [id])
+ //highlight-next-line
+ version Int
+}
+```
+
+Next, adjust the code to check the `version` field before updating:
+
+```ts highlight=19-38;normal
+const userEmail = 'alice@prisma.io'
+const movieName = 'Hidden Figures'
+
+// Find the first available seat
+// availableSeat.version might be 0
+const availableSeat = await client.seat.findFirst({
+ where: {
+ Movie: {
+ name: movieName,
+ },
+ claimedBy: null,
+ },
+})
+
+if (!availableSeat) {
+ throw new Error(`Oh no! ${movieName} is all booked.`)
+}
+
+//highlight-start
+// Only mark the seat as claimed if the availableSeat.version
+// matches the version we're updating. Additionally, increment the
+// version when we perform this update so all other clients trying
+// to book this same seat will have an outdated version.
+const seats = await client.seat.updateMany({
+ data: {
+ claimedBy: userEmail,
+ version: {
+ increment: 1,
+ },
+ },
+ where: {
+ id: availableSeat.id,
+ version: availableSeat.version, // This version field is the key; only claim seat if in-memory version matches database version, indicating that the field has not been updated
+ },
+})
+
+if (seats.count === 0) {
+ throw new Error(`That seat is already booked! Please try again.`)
+}
+//highlight-end
+```
+
+It is now impossible for two people to book the same seat:
+
+1. Seat 3A returned to Sorcha (`version` is 0)
+2. Seat 3A returned to Ellen (`version` is 0)
+3. Seat 3A claimed by Sorcha (`version` is incremented to 1, booking succeeds)
+4. Seat 3A claimed by Ellen (in-memory `version` (0) does not match database `version` (1) - booking does not succeed)
+
+### Interactive transactions
+
+If you have an existing application, it can be a significant undertaking to refactor your application to use optimistic concurrency control. Interactive Transactions offers a useful escape hatch for cases like this.
+
+To create an interactive transaction, pass an async function into [$transaction](#transaction-api).
+
+The first argument passed into this async function is an instance of Prisma Client. Below, we will call this instance `tx`. Any Prisma Client call invoked on this `tx` instance is encapsulated into the transaction.
+
+In the example below, Alice and Bob each have $100 in their account. If they try to send more money than they have, the transfer is rejected.
+
+The expected outcome would be for Alice to make 1 transfer for $100 and the other transfer would be rejected. This would result in Alice having $0 and Bob having $200.
+
+```ts
+import { PrismaClient } from '@prisma/client'
+const prisma = new PrismaClient()
+
+async function transfer(from: string, to: string, amount: number) {
+ return await prisma.$transaction(async (tx) => {
+ // 1. Decrement amount from the sender.
+ const sender = await tx.account.update({
+ data: {
+ balance: {
+ decrement: amount,
+ },
+ },
+ where: {
+ email: from,
+ },
+ })
+
+ // 2. Verify that the sender's balance didn't go below zero.
+ if (sender.balance < 0) {
+ throw new Error(`${from} doesn't have enough to send ${amount}`)
+ }
+
+ // 3. Increment the recipient's balance by amount
+ const recipient = tx.account.update({
+ data: {
+ balance: {
+ increment: amount,
+ },
+ },
+ where: {
+ email: to,
+ },
+ })
+
+ return recipient
+ })
+}
+
+async function main() {
+ // This transfer is successful
+ await transfer('alice@prisma.io', 'bob@prisma.io', 100)
+ // This transfer fails because Alice doesn't have enough funds in her account
+ await transfer('alice@prisma.io', 'bob@prisma.io', 100)
+}
+
+main()
+```
+
+In the example above, both `update` queries run within a database transaction. When the application reaches the end of the function, the transaction is **committed** to the database.
+
+If the application encounters an error along the way, the async function will throw an exception and automatically **rollback** the transaction.
+
+You can learn more about interactive transactions in this [section](#interactive-transactions).
+
+
+
+**Use interactive transactions with caution**. Keeping transactions
+open for a long time hurts database performance and can even cause deadlocks.
+Try to avoid performing network requests and executing slow queries inside your
+transaction functions. We recommend you get in and out as quick as possible!
+
+
+
+## Conclusion
+
+Prisma Client supports multiple ways of handling transactions, either directly through the API or by supporting your ability to introduce optimistic concurrency control and idempotency into your application. If you feel like you have use cases in your application that are not covered by any of the suggested options, please open a [GitHub issue](https://github.com/prisma/prisma/issues/new/choose) to start a discussion.
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/060-full-text-search.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/060-full-text-search.mdx
new file mode 100644
index 0000000000..8349ff82f8
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/060-full-text-search.mdx
@@ -0,0 +1,324 @@
+---
+title: 'Full-text search'
+metaTitle: 'Full-text search (Preview)'
+metaDescription: 'This page explains how to search for text within a field.'
+sidebar_class_name: preview-badge
+---
+
+Prisma Client supports full-text search for **PostgreSQL** databases in versions 2.30.0 and later, and **MySQL** databases in versions 3.8.0 and later. With full-text search (FTS) enabled, you can add search functionality to your application by searching for text within a database column.
+
+:::info
+
+In Prisma v6, FTS has been [promoted to General Availability on MySQL](/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-6#fulltextsearch). It still remains in Preview for PostgreSQL and requires using the [`fullTextSearchPostgres`](/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-6#full-text-search-on-postgresql) Preview feature flag.
+
+:::
+
+## Enabling full-text search for PostgreSQL
+
+The full-text search API is currently a Preview feature. To enable this feature, carry out the following steps:
+
+1. Update the [`previewFeatures`](/orm/reference/preview-features) block in your schema to include the `fullTextSearchPostgres` preview feature flag:
+
+ ```prisma file=schema.prisma showLineNumbers
+ generator client {
+ provider = "prisma-client-js"
+ previewFeatures = ["fullTextSearchPostgres"]
+ }
+ ```
+
+
+2. Generate Prisma Client:
+
+ ```terminal copy
+ npx prisma generate
+ ```
+
+After you regenerate your client, a new `search` field will be available on any `String` fields created on your models. For example, the following search will return all posts that contain the word 'cat'.
+
+```ts
+// All posts that contain the word 'cat'.
+const result = await prisma.posts.findMany({
+ where: {
+ body: {
+ search: 'cat',
+ },
+ },
+})
+```
+
+> **Note**: There currently is a [known issue](https://github.com/prisma/prisma/issues/23627) in the full-text search feature for PostgreSQL. If you observe slow search queries, you can [optimize your query with raw SQL](#full-text-search-with-raw-sql).
+
+## Querying the database
+
+The `search` field uses the database's native querying capabilities under the hood. This means that the exact query operators available are also database-specific.
+
+### PostgreSQL
+
+The following examples demonstrate the use of the PostgreSQL 'and' (`&`) and 'or' (`|`) operators:
+
+```ts
+// All posts that contain the words 'cat' or 'dog'.
+const result = await prisma.posts.findMany({
+ where: {
+ body: {
+ search: 'cat | dog',
+ },
+ },
+})
+
+// All drafts that contain the words 'cat' and 'dog'.
+const result = await prisma.posts.findMany({
+ where: {
+ status: 'Draft',
+ body: {
+ search: 'cat & dog',
+ },
+ },
+})
+```
+
+To get a sense of how the query format works, consider the following text:
+
+**"The quick brown fox jumps over the lazy dog"**
+
+Here's how the following queries would match that text:
+
+| Query | Match? | Explanation |
+| :-------------------------------------- | :----- | :-------------------------------------- |
+| `fox & dog` | Yes | The text contains 'fox' and 'dog' |
+| `dog & fox` | Yes | The text contains 'dog' and 'fox' |
+| `dog & cat` | No | The text contains 'dog' but not 'cat' |
+| `!cat` | Yes | 'cat' is not in the text |
+| `fox \| cat` | Yes | The text contains 'fox' or 'cat' |
+| `cat \| pig` | No | The text doesn't contain 'cat' or 'pig' |
+| `fox <-> dog` | Yes | 'dog' follows 'fox' in the text |
+| `dog <-> fox` | No | 'fox' doesn't follow 'dog' in the text |
+
+For the full range of supported operations, see the [PostgreSQL full text search documentation](https://www.postgresql.org/docs/12/functions-textsearch.html).
+
+### MySQL
+
+The following examples demonstrate use of the MySQL 'and' (`+`) and 'not' (`-`) operators:
+
+```ts
+// All posts that contain the words 'cat' or 'dog'.
+const result = await prisma.posts.findMany({
+ where: {
+ body: {
+ search: 'cat dog',
+ },
+ },
+})
+
+// All posts that contain the words 'cat' and not 'dog'.
+const result = await prisma.posts.findMany({
+ where: {
+ body: {
+ search: '+cat -dog',
+ },
+ },
+})
+
+// All drafts that contain the words 'cat' and 'dog'.
+const result = await prisma.posts.findMany({
+ where: {
+ status: 'Draft',
+ body: {
+ search: '+cat +dog',
+ },
+ },
+})
+```
+
+To get a sense of how the query format works, consider the following text:
+
+**"The quick brown fox jumps over the lazy dog"**
+
+Here's how the following queries would match that text:
+
+| Query | Match? | Description |
+| :------------- | :----- | :----------------------------------------------------- |
+| `+fox +dog` | Yes | The text contains 'fox' and 'dog' |
+| `+dog +fox` | Yes | The text contains 'dog' and 'fox' |
+| `+dog -cat` | Yes | The text contains 'dog' but not 'cat' |
+| `-cat` | No | The minus operator cannot be used on its own (see note below) |
+| `fox dog` | Yes | The text contains 'fox' or 'dog' |
+| `quic*` | Yes | The text contains a word starting with 'quic' |
+| `quick fox @2` | Yes | 'fox' starts within a 2 word distance of 'quick' |
+| `fox dog @2` | No | 'dog' does not start within a 2 word distance of 'fox' |
+| `"jumps over"` | Yes | The text contains the whole phrase 'jumps over' |
+
+> **Note**: The - operator acts only to exclude rows that are otherwise matched by other search terms. Thus, a boolean-mode search that contains only terms preceded by - returns an empty result. It does not return “all rows except those containing any of the excluded terms.”
+
+MySQL also has `>`, `<` and `~` operators for altering the ranking order of search results. As an example, consider the following two records:
+
+**1. "The quick brown fox jumps over the lazy dog"**
+
+**2. "The quick brown fox jumps over the lazy cat"**
+
+| Query | Result | Description |
+| :---------------- | :----------------------- | :------------------------------------------------------------------------------------------------------ |
+| `fox ~cat` | Return 1. first, then 2. | Return all records containing 'fox', but rank records containing 'cat' lower |
+| `fox (dog)` | Return 1. first, then 2. | Return all records containing 'fox', but rank records containing 'cat' lower than rows containing 'dog' |
+
+For the full range of supported operations, see the [MySQL full text search documentation](https://dev.mysql.com/doc/refman/8.0/en/fulltext-boolean.html).
+
+## Sorting results by `_relevance`
+
+
+
+Sorting by relevance is only available for PostgreSQL and MySQL.
+
+
+
+In addition to [Prisma Client's default `orderBy` behavior](/6.0/orm/reference/prisma-client-reference#orderby), full-text search also adds sorting by relevance to a given string or strings. As an example, if you wanted to order posts by their relevance to the term `'database'` in their title, you could use the following:
+
+```ts
+const posts = await prisma.post.findMany({
+ orderBy: {
+ _relevance: {
+ fields: ['title'],
+ search: 'database',
+ sort: 'asc'
+ },
+ },
+})
+```
+
+## Adding indexes
+
+### PostgreSQL
+
+Prisma Client does not currently support using indexes to speed up full text search. There is an existing [GitHub Issue](https://github.com/prisma/prisma/issues/8950) for this.
+
+### MySQL
+
+For MySQL, it is necessary to add indexes to any columns you search using the `@@fulltext` argument in the `schema.prisma` file.
+
+In the following example, one full text index is added to the `content` field of the `Blog` model, and another is added to both the `content` and `title` fields together:
+
+```prisma file=schema.prisma showLineNumbers
+generator client {
+ provider = "prisma-client-js"
+}
+
+model Blog {
+ id Int @unique
+ content String
+ title String
+
+ @@fulltext([content])
+ @@fulltext([content, title])
+}
+```
+
+The first index allows searching the `content` field for occurrences of the word 'cat':
+
+```ts
+const result = await prisma.blogs.findMany({
+ where: {
+ content: {
+ search: 'cat',
+ },
+ },
+})
+```
+
+The second index allows searching both the `content` and `title` fields for occurrences of the word 'cat' in the `content` and 'food' in the `title`:
+
+```ts
+const result = await prisma.blogs.findMany({
+ where: {
+ content: {
+ search: 'cat',
+ },
+ title: {
+ search: 'food',
+ },
+ },
+})
+```
+
+However, if you try to search on `title` alone, the search will fail with the error "Cannot find a fulltext index to use for the search" and the message code is `P2030`, because the search requires an index on both fields.
+
+## Full-text search with raw SQL
+
+Full-text search is currently in Preview, and due to a [known issue](https://github.com/prisma/prisma/issues/23627), you might experience slow search queries. If so, you can optimize your query using [TypedSQL](/orm/prisma-client/using-raw-sql).
+
+### PostgreSQL
+
+With [TypedSQL](/orm/prisma-client/using-raw-sql), you can use PostgreSQL's `to_tsvector` and `to_tsquery` to express your search query.
+
+
+
+
+
+ ```sql
+ SELECT * FROM "Blog" WHERE to_tsvector('english', "Blog"."content") @@ to_tsquery('english', ${term});
+ ```
+
+
+
+
+
+ ```ts
+ import { fullTextSearch } from "@prisma/client/sql"
+
+ const term = `cat`
+ const result = await prisma.$queryRawTyped(fullTextSearch(term))
+ ```
+
+
+
+
+
+> **Note**: Depending on your language preferences, you may exchange `english` against another language in the SQL statement.
+
+If you want to include a wildcard in your search term, you can do this as follows:
+
+
+
+
+
+ ```sql
+ SELECT * FROM "Blog" WHERE to_tsvector('english', "Blog"."content") @@ to_tsquery('english', ${term});
+ ```
+
+
+
+
+
+ ```ts
+ //highlight-next-line
+ const term = `cat:*`
+ const result = await prisma.$queryRawTyped(fullTextSearch(term))
+ ```
+
+
+
+
+
+### MySQL
+
+In MySQL, you can express your search query as follows:
+
+
+
+
+
+ ```sql
+ SELECT * FROM Blog WHERE MATCH(content) AGAINST(${term} IN NATURAL LANGUAGE MODE);
+ ```
+
+
+
+
+
+ ```ts
+ const term = `cat`
+ const result = await prisma.$queryRawTyped(fullTextSearch(term))
+ ```
+
+
+
+
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/061-custom-validation.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/061-custom-validation.mdx
new file mode 100644
index 0000000000..ecc05879aa
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/061-custom-validation.mdx
@@ -0,0 +1,190 @@
+---
+title: 'Custom validation'
+metaTitle: 'Custom validation'
+metaDescription: 'This page explains how to add custom validation to Prisma Client'
+---
+
+
+
+You can add runtime validation for your user input for Prisma Client queries in one of the following ways:
+
+- [Prisma Client extensions](/orm/prisma-client/client-extensions)
+- A custom function
+
+You can use any validation library you'd like. The Node.js ecosystem offers a number of high-quality, easy-to-use validation libraries to choose from including: [joi](https://github.com/sideway/joi), [validator.js](https://github.com/validatorjs/validator.js), [Yup](https://github.com/jquense/yup), [Zod](https://github.com/colinhacks/zod) and [Superstruct](https://github.com/ianstormtaylor/superstruct).
+
+
+
+## Input validation with Prisma Client extensions
+
+This example adds runtime validation when creating and updating values using a Zod schema to check that the data passed to Prisma Client is valid.
+
+
+
+Query extensions do not currently work for nested operations. In this example, validations are only run on the top level data object passed to methods such as `prisma.product.create()`. Validations implemented this way do not automatically run for [nested writes](/orm/prisma-client/queries/relation-queries#nested-writes).
+
+
+
+
+
+
+
+```ts copy
+import { PrismaClient, Prisma } from '@prisma/client'
+import { z } from 'zod'
+
+/**
+ * Zod schema
+ */
+export const ProductCreateInput = z.object({
+ slug: z
+ .string()
+ .max(100)
+ .regex(/^[a-z0-9]+(?:-[a-z0-9]+)*$/),
+ name: z.string().max(100),
+ description: z.string().max(1000),
+ price: z
+ .instanceof(Prisma.Decimal)
+ .refine((price) => price.gte('0.01') && price.lt('1000000.00')),
+}) satisfies z.Schema
+
+/**
+ * Prisma Client Extension
+ */
+const prisma = new PrismaClient().$extends({
+ query: {
+ product: {
+ create({ args, query }) {
+ args.data = ProductCreateInput.parse(args.data)
+ return query(args)
+ },
+ update({ args, query }) {
+ args.data = ProductCreateInput.partial().parse(args.data)
+ return query(args)
+ },
+ updateMany({ args, query }) {
+ args.data = ProductCreateInput.partial().parse(args.data)
+ return query(args)
+ },
+ upsert({ args, query }) {
+ args.create = ProductCreateInput.parse(args.create)
+ args.update = ProductCreateInput.partial().parse(args.update)
+ return query(args)
+ },
+ },
+ },
+})
+
+async function main() {
+ /**
+ * Example usage
+ */
+ // Valid product
+ const product = await prisma.product.create({
+ data: {
+ slug: 'example-product',
+ name: 'Example Product',
+ description: 'Lorem ipsum dolor sit amet',
+ price: new Prisma.Decimal('10.95'),
+ },
+ })
+
+ // Invalid product
+ try {
+ await prisma.product.create({
+ data: {
+ slug: 'invalid-product',
+ name: 'Invalid Product',
+ description: 'Lorem ipsum dolor sit amet',
+ price: new Prisma.Decimal('-1.00'),
+ },
+ })
+ } catch (err: any) {
+ console.log(err?.cause?.issues)
+ }
+}
+
+main()
+```
+
+
+
+
+
+```prisma copy
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+
+generator client {
+ provider = "prisma-client-js"
+}
+
+model Product {
+ id String @id @default(cuid())
+ slug String
+ name String
+ description String
+ price Decimal
+ reviews Review[]
+}
+
+model Review {
+ id String @id @default(cuid())
+ body String
+ stars Int
+ product Product @relation(fields: [productId], references: [id], onDelete: Cascade)
+ productId String
+}
+```
+
+
+
+
+
+The above example uses a Zod schema to validate and parse data provided in a query at runtime before a record is written to the database.
+
+## Input validation with a custom validation function
+
+Here's an example using [Superstruct](https://github.com/ianstormtaylor/superstruct) to validate that the data needed to signup a new user is correct:
+
+```tsx
+import { PrismaClient, Prisma, User } from '@prisma/client'
+import { assert, object, string, size, refine } from 'superstruct'
+import isEmail from 'isemail'
+
+const prisma = new PrismaClient()
+
+// Runtime validation
+const Signup = object({
+ // string and a valid email address
+ email: refine(string(), 'email', (v) => isEmail.validate(v)),
+ // password is between 7 and 30 characters long
+ password: size(string(), 7, 30),
+ // first name is between 2 and 50 characters long
+ firstName: size(string(), 2, 50),
+ // last name is between 2 and 50 characters long
+ lastName: size(string(), 2, 50),
+})
+
+type Signup = Omit
+
+// Signup function
+async function signup(input: Signup): Promise {
+ // Assert that input conforms to Signup, throwing with a helpful
+ // error message if input is invalid.
+ assert(input, Signup)
+ return prisma.user.create({
+ data: input.user,
+ })
+}
+```
+
+The example above shows how you can create a custom type-safe `signup` function that ensures the input is valid before creating a user.
+
+## Going further
+
+- Learn how you can use [Prisma Client extensions](/orm/prisma-client/client-extensions) to add input validation for your queries — [example](https://github.com/prisma/prisma-client-extensions/tree/main/input-validation).
+- Learn how you can organize your code better by moving the `signup` function into [a custom model](/orm/prisma-client/queries/custom-models).
+- There's an [outstanding feature request](https://github.com/prisma/prisma/issues/3528) to bake user validation into Prisma Client. If you'd like to see that happen, make sure to upvote that issue and share your use case!
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/062-computed-fields.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/062-computed-fields.mdx
new file mode 100644
index 0000000000..a923a0aff8
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/062-computed-fields.mdx
@@ -0,0 +1,180 @@
+---
+title: 'Computed fields'
+metaTitle: 'Computed fields'
+metaDescription: 'This page explains how to use client extensions to add computed fields to Prisma models.'
+---
+
+Computed fields allow you to derive a new field based on existing data. A common example is when you want to compute a full name. In your database, you may only store the first and last name, but you can define a function that computes a full name by combining the first and last name. Computed fields are read-only and stored in your application's memory, not in your database.
+
+## Using a Prisma Client extension
+
+The following example illustrates how to create a [Prisma Client extension](/orm/prisma-client/client-extensions) that adds a `fullName` computed field at runtime to the `User` model in a Prisma schema.
+
+
+
+
+
+
+
+
+
+```ts
+import { PrismaClient } from '@prisma/client'
+
+const prisma = new PrismaClient().$extends({
+ result: {
+ user: {
+ fullName: {
+ needs: { firstName: true, lastName: true },
+ compute(user) {
+ return `${user.firstName} ${user.lastName}`
+ },
+ },
+ },
+ },
+})
+
+async function main() {
+ /**
+ * Example query containing the `fullName` computed field in the response
+ */
+ const user = await prisma.user.findFirst()
+}
+
+main()
+```
+
+
+
+
+```js no-copy
+{
+ id: 1,
+ firstName: 'Aurelia',
+ lastName: 'Schneider',
+ email: 'Jalen_Berge40@hotmail.com',
+ fullName: 'Aurelia Schneider',
+}
+```
+
+
+
+
+
+
+
+
+
+```prisma copy
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+
+generator client {
+ provider = "prisma-client-js"
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ firstName String
+ lastName String
+ posts Post[]
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ published Boolean @default(true)
+ content String?
+ authorId Int?
+ author User? @relation(fields: [authorId], references: [id])
+}
+```
+
+
+
+
+
+The computed fields are type-safe and can return anything from a concatenated value to complex objects or functions that can act as an instance method for your models.
+
+
+
+Instructions prior to Prisma ORM 4.16.0
+
+:::warning
+
+With Prisma Client extensions Generally Available as of Prisma ORM version 4.16.0, the following steps are not recommended. Please use [a client extension](#using-a-prisma-client-extension) to accomplish this.
+
+:::
+
+Prisma Client does not yet natively support computed fields, but, you can define a function that accepts a generic type as an input then extend that generic to ensure it conforms to a specific structure. Finally, you can return that generic with additional computed fields. Let's see how that might look:
+
+
+
+
+
+```tsx
+// Define a type that needs a first and last name
+type FirstLastName = {
+ firstName: string
+ lastName: string
+}
+
+// Extend the T generic with the fullName attribute
+type WithFullName = T & {
+ fullName: string
+}
+
+// Take objects that satisfy FirstLastName and computes a full name
+function computeFullName(
+ user: User
+): WithFullName {
+ return {
+ ...user,
+ fullName: user.firstName + ' ' + user.lastName,
+ }
+}
+
+async function main() {
+ const user = await prisma.user.findUnique({ where: 1 })
+ const userWithFullName = computeFullName(user)
+}
+```
+
+
+
+
+
+```js
+function computeFullName(user) {
+ return {
+ ...user,
+ fullName: user.firstName + ' ' + user.lastName,
+ }
+}
+
+async function main() {
+ const user = await prisma.user.findUnique({ where: 1 })
+ const userWithFullName = computeFullName(user)
+}
+```
+
+
+
+
+
+In the TypeScript example above, a `User` generic has been defined that extends the `FirstLastName` type. This means that whatever you pass into `computeFullName` must contain `firstName` and `lastName` keys.
+
+A `WithFullName` return type has also been defined, which takes whatever `User` is and tacks on a `fullName` string attribute.
+
+With this function, any object that contains `firstName` and `lastName` keys can compute a `fullName`. Pretty neat, right?
+
+
+
+### Going further
+
+- Learn how you can use [Prisma Client extensions](/orm/prisma-client/client-extensions) to add a computed field to your schema — [example](https://github.com/prisma/prisma-client-extensions/tree/main/computed-fields).
+- Learn how you can move the `computeFullName` function into [a custom model](/orm/prisma-client/queries/custom-models).
+- There's an [open feature request](https://github.com/prisma/prisma/issues/3394) to add native support to Prisma Client. If you'd like to see that happen, make sure to upvote that issue and share your use case!
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/063-excluding-fields.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/063-excluding-fields.mdx
new file mode 100644
index 0000000000..6a7fb66b1a
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/063-excluding-fields.mdx
@@ -0,0 +1,187 @@
+---
+title: 'Excluding fields'
+metaTitle: 'Excluding fields'
+metaDescription: 'This page explains how to exclude sensitive fields from Prisma Client'
+---
+
+By default Prisma Client returns all fields from a model. You can use [`select`](/orm/prisma-client/queries/select-fields) to narrow the result set, but that can be unwieldy if you have a large model and you only want to exclude a small number of fields.
+
+:::info
+
+As of Prisma ORM 6.2.0, excluding fields is supported via the `omit` option that you can pass to Prisma Client. From versions 5.16.0 through 6.1.0, you must use the `omitApi` Preview feature to access this option.
+
+:::
+
+## Excluding a field globally using `omit`
+
+The following is a type-safe way to exclude a field _globally_ (i.e. for _all_ queries against a given model):
+
+
+
+
+
+```ts
+const prisma = new PrismaClient({
+ omit: {
+ user: {
+ password: true
+ }
+ }
+})
+
+// The password field is excluded in all queries, including this one
+const user = await prisma.user.findUnique({ where: { id: 1 } })
+```
+
+
+
+
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ createdAt DateTime @default(now())
+ updatedAt DateTime @updatedAt
+ firstName String
+ lastName String
+ email String @unique
+ password String
+}
+```
+
+
+
+
+
+## Excluding a field locally using `omit`
+
+The following is a type-safe way to exclude a field _locally_ (i.e. for a _single_ query):
+
+
+
+
+
+```ts
+const prisma = new PrismaClient()
+
+// The password field is excluded only in this query
+const user = await prisma.user.findUnique({
+ omit: {
+ password: true
+ },
+ where: {
+ id: 1
+ }
+})
+```
+
+
+
+
+
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ createdAt DateTime @default(now())
+ updatedAt DateTime @updatedAt
+ firstName String
+ lastName String
+ email String @unique
+ password String
+}
+```
+
+
+
+
+
+## How to omit multiple fields
+
+Omitting multiple fields works the same as selecting multiple fields: add multiple key-value pairs to the omit option.
+Using the same schema as before, you could omit password and email with the following:
+
+```tsx
+const prisma = new PrismaClient()
+
+// password and email are excluded
+const user = await prisma.user.findUnique({
+ omit: {
+ email: true,
+ password: true,
+ },
+ where: {
+ id: 1,
+ },
+})
+```
+
+Multiple fields can be omitted locally and globally.
+
+## How to select a previously omitted field
+
+If you [omit a field globally](#excluding-a-field-globally-using-omit), you can "override" by either selecting the field specifically or by setting `omit` to `false` in a query.
+
+
+
+
+
+```tsx
+const user = await prisma.user.findUnique({
+ select: {
+ firstName: true,
+ lastName: true,
+ password: true // The password field is now selected.
+ },
+ where: {
+ id: 1
+ }
+})
+```
+
+
+
+
+
+```tsx
+const user = await prisma.user.findUnique({
+ omit: {
+ password: false // The password field is now selected.
+ },
+ where: {
+ id: 1
+ }
+})
+```
+
+
+
+
+
+## Ensuring excluded fields don't appear in TypeScript types
+
+While the `omit` option correctly removes fields from the runtime result, TypeScript sometimes does not reflect these omissions in the inferred types, especially when the omit configuration is not strictly typed.
+
+If you define your omit config in a separate variable and do not use `as const`, TypeScript infers the type as `{ [key: string]: boolean }`, which is too broad for Prisma to know which fields are truly omitted. This results in the omitted fields still appearing in the type system, even though they are not present at runtime.
+
+The recommended fix is to use `as const` to ensure the type is exact:
+
+```tsx
+const omitConfig = {
+ profile: { email: true },
+ user: { password: true },
+} as const;
+
+const prisma = new PrismaClient({ omit: omitConfig });
+```
+
+This ensures TypeScript knows exactly which fields are omitted and will reflect that in the types.
+
+## When to use `omit` globally or locally
+
+It's important to understand when to omit a field globally or locally:
+
+- If you are omitting a field in order to prevent it from accidentally being included in a query, it's best to omit it _globally_. For example: Globally omitting the `password` field from a `User` model so that sensitive information doesn't accidentally get exposed.
+- If you are omitting a field because it's not needed in a query, it's best to omit it _locally_.
+
+Local omit (when an `omit` option is provided in a query) only applies to the query it is defined in, while a global omit applies to every query made with the same Prisma Client instance, [unless a specific select is used or the omit is overridden](#how-to-select-a-previously-omitted-field).
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/064-custom-models.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/064-custom-models.mdx
new file mode 100644
index 0000000000..4d5a576e1f
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/064-custom-models.mdx
@@ -0,0 +1,176 @@
+---
+title: 'Custom models'
+metaTitle: 'Custom models'
+metaDescription: 'This page explains how to wrap Prisma Client in custom models'
+---
+
+
+
+As your application grows, you may find the need to group related logic together. We suggest either:
+
+- Creating static methods using a [Prisma Client extension](/orm/prisma-client/client-extensions)
+- Wrapping a model in a class
+- Extending Prisma Client model object
+
+
+
+## Static methods with Prisma Client extensions
+
+The following example demonstrates how to create a Prisma Client extension that adds a `signUp` and `findManyByDomain` methods to a User model.
+
+
+
+
+
+```tsx
+import bcrypt from 'bcryptjs'
+import { PrismaClient } from '@prisma/client'
+
+const prisma = new PrismaClient().$extends({
+ model: {
+ user: {
+ async signUp(email: string, password: string) {
+ const hash = await bcrypt.hash(password, 10)
+ return prisma.user.create({
+ data: {
+ email,
+ password: {
+ create: {
+ hash,
+ },
+ },
+ },
+ })
+ },
+
+ async findManyByDomain(domain: string) {
+ return prisma.user.findMany({
+ where: { email: { endsWith: `@${domain}` } },
+ })
+ },
+ },
+ },
+})
+
+async function main() {
+ // Example usage
+ await prisma.user.signUp('user2@example2.com', 's3cret')
+
+ await prisma.user.findManyByDomain('example2.com')
+}
+```
+
+
+
+
+
+```prisma file="prisma/schema.prisma" copy
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+
+generator client {
+ provider = "prisma-client-js"
+}
+
+model User {
+ id String @id @default(cuid())
+ email String
+ password Password?
+}
+
+model Password {
+ hash String
+ user User @relation(fields: [userId], references: [id], onDelete: Cascade)
+ userId String @unique
+}
+```
+
+
+
+
+
+## Wrap a model in a class
+
+In the example below, you'll see how you can wrap the `user` model in the Prisma Client within a `Users` class.
+
+```tsx
+import { PrismaClient, User } from '@prisma/client'
+
+type Signup = {
+ email: string
+ firstName: string
+ lastName: string
+}
+
+class Users {
+ constructor(private readonly prismaUser: PrismaClient['user']) {}
+
+ // Signup a new user
+ async signup(data: Signup): Promise {
+ // do some custom validation...
+ return this.prismaUser.create({ data })
+ }
+}
+
+async function main() {
+ const prisma = new PrismaClient()
+ const users = new Users(prisma.user)
+ const user = await users.signup({
+ email: 'alice@prisma.io',
+ firstName: 'Alice',
+ lastName: 'Prisma',
+ })
+}
+```
+
+With this new `Users` class, you can define custom functions like `signup`:
+
+Note that in the example above, you're only exposing a `signup` method from Prisma Client. The Prisma Client is hidden within the `Users` class, so you're no longer be able to call methods like `findMany` and `upsert`.
+
+This approach works well when you have a large application and you want to intentionally limit what your models can do.
+
+## Extending Prisma Client model object
+
+But what if you don't want to hide existing functionality but still want to group custom functions together? In this case, you can use `Object.assign` to extend Prisma Client without limiting its functionality:
+
+```tsx
+import { PrismaClient, User } from '@prisma/client'
+
+type Signup = {
+ email: string
+ firstName: string
+ lastName: string
+}
+
+function Users(prismaUser: PrismaClient['user']) {
+ return Object.assign(prismaUser, {
+ /**
+ * Signup the first user and create a new team of one. Return the User with
+ * a full name and without a password
+ */
+ async signup(data: Signup): Promise {
+ return prismaUser.create({ data })
+ },
+ })
+}
+
+async function main() {
+ const prisma = new PrismaClient()
+ const users = Users(prisma.user)
+ const user = await users.signup({
+ email: 'alice@prisma.io',
+ firstName: 'Alice',
+ lastName: 'Prisma',
+ })
+ const numUsers = await users.count()
+ console.log(user, numUsers)
+}
+```
+
+Now you can use your custom `signup` method alongside `count`, `updateMany`, `groupBy()` and all of the other wonderful methods that Prisma Client provides. Best of all, it's all type-safe!
+
+## Going further
+
+We recommend using [Prisma Client extensions](/orm/prisma-client/client-extensions) to extend your models with [custom model methods](https://github.com/prisma/prisma-client-extensions/tree/main/instance-methods).
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/070-case-sensitivity.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/070-case-sensitivity.mdx
new file mode 100644
index 0000000000..c1bc22a362
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/070-case-sensitivity.mdx
@@ -0,0 +1,245 @@
+---
+title: 'Case sensitivity'
+metaTitle: 'Case sensitivity (Reference)'
+metaDescription: 'How Prisma Client handles case sensitivity when filtering and sorting.'
+preview: false
+---
+
+
+
+Case sensitivity affects **filtering** and **sorting** of data, and is determined by your [database collation](#database-collation-and-case-sensitivity). Sorting and filtering data yields different results depending on your settings:
+
+| Action | Case sensitive | Case insensitive |
+| --------------- | -------------------------------------------- | -------------------------------------------- |
+| Sort ascending | `Apple`, `Banana`, `apple pie`, `banana pie` | `Apple`, `apple pie`, `Banana`, `banana pie` |
+| Match `"apple"` | `apple` | `Apple`, `apple` |
+
+If you use a **relational database connector**, [Prisma Client](/orm/prisma-client) respects your database collation. Options and recommendations for supporting **case-insensitive** filtering and sorting with Prisma Client depend on your [database provider](#options-for-case-insensitive-filtering).
+
+If you use the MongoDB connector, [Prisma Client](/orm/prisma-client/queries) uses RegEx rules to enable case-insensitive filtering. The connector _does not_ use [MongoDB collation](https://www.mongodb.com/docs/manual/reference/collation/).
+
+> **Note**: Follow the progress of [case-insensitive sorting on GitHub](https://github.com/prisma/prisma-client-js/issues/841).
+
+
+
+## Database collation and case sensitivity
+
+
+
+In the context of Prisma Client, the following section refers to relational database connectors only.
+
+
+
+Collation specifies how data is **sorted and compared** in a database, which includes casing. Collation is something you choose when you set up a database.
+
+The following example demonstrates how to view the collation of a MySQL database:
+
+
+
+
+
+```sql no-lines
+SELECT @@character_set_database, @@collation_database;
+```
+
+
+
+
+
+```no-lines no-copy
+ +--------------------------+----------------------+
+ | @@character_set_database | @@collation_database |
+ +--------------------------+----------------------+
+ | utf8mb4 | utf8mb4_0900_ai_ci |
+ +--------------------------+----------------------+
+```
+
+
+
+
+
+The example collation, [`utf8mb4_0900_ai_ci`](https://dev.mysql.com/doc/refman/8.0/en/charset-collation-names.html), is:
+
+- Accent-insensitive (`ai`)
+- Case-insensitive (`ci`).
+
+This means that `prisMa` will match `prisma`, `PRISMA`, `priSMA`, and so on:
+
+
+
+
+
+```sql no-lines
+SELECT id, email FROM User WHERE email LIKE "%prisMa%"
+```
+
+
+
+
+
+```no-lines no-copy
+ +----+-----------------------------------+
+ | id | email |
+ +----+-----------------------------------+
+ | 61 | alice@prisma.io |
+ | 49 | birgitte@prisma.io |
+ +----+-----------------------------------+
+```
+
+
+
+
+
+The same query with Prisma Client:
+
+```ts
+const users = await prisma.user.findMany({
+ where: {
+ email: {
+ contains: 'prisMa',
+ },
+ },
+ select: {
+ id: true,
+ name: true,
+ },
+})
+```
+
+## Options for case-insensitive filtering
+
+The recommended way to support case-insensitive filtering with Prisma Client depends on your underlying provider.
+
+### PostgreSQL provider
+
+PostgreSQL uses [deterministic collation](https://www.postgresql.org/docs/current/collation.html#COLLATION-NONDETERMINISTIC) by default, which means that filtering is **case-sensitive**. To support case-insensitive filtering, use the `mode: 'insensitive'` property on a per-field basis.
+
+Use the `mode` property on a filter as shown:
+
+```ts highlight=5;normal
+const users = await prisma.user.findMany({
+ where: {
+ email: {
+ endsWith: 'prisma.io',
+ mode: 'insensitive', // Default value: default
+ },
+ },
+})
+```
+
+See also: [Filtering (Case-insensitive filtering)](/orm/prisma-client/queries/filtering-and-sorting#case-insensitive-filtering)
+
+#### Caveats
+
+- You cannot use case-insensitive filtering with C collation
+- [`citext`](https://www.postgresql.org/docs/12/citext.html) columns are always case-insensitive and are not affected by `mode`
+
+#### Performance
+
+If you rely heavily on case-insensitive filtering, consider [creating indexes in the PostgreSQL database](https://www.postgresql.org/docs/current/indexes.html) to improve performance:
+
+- [Create an expression index](https://www.postgresql.org/docs/current/indexes-expressional.html) for Prisma Client queries that use `equals` or `not`
+- Use the `pg_trgm` module to [create a trigram-based index](https://www.postgresql.org/docs/12/pgtrgm.html#id-1.11.7.40.7) for Prisma Client queries that use `startsWith`, `endsWith`, `contains` (maps to`LIKE` / `ILIKE` in PostgreSQL)
+
+### MySQL provider
+
+MySQL uses **case-insensitive collation** by default. Therefore, filtering with Prisma Client and MySQL is case-insensitive by default.
+
+`mode: 'insensitive'` property is not required and therefore not available in the generated Prisma Client API.
+
+#### Caveats
+
+- You _must_ use a case-insensitive (`_ci`) collation in order to support case-insensitive filtering. Prisma Client does no support the `mode` filter property for the MySQL provider.
+
+### MongoDB provider
+
+To support case-insensitive filtering, use the `mode: 'insensitive'` property on a per-field basis:
+
+```ts highlight=5;normal
+const users = await prisma.user.findMany({
+ where: {
+ email: {
+ endsWith: 'prisma.io',
+ mode: 'insensitive', // Default value: default
+ },
+ },
+})
+```
+
+The MongoDB uses a RegEx rule for case-insensitive filtering.
+
+### SQLite provider
+
+By default, text fields created by Prisma Client in SQLite databases do not support case-insensitive filtering. In SQLite, only [case-insensitive comparisons of ASCII characters](https://www.sqlite.org/faq.html#q18) are possible.
+
+To enable limited support (ASCII only) for case-insensitive filtering on a per-column basis, you will need to add `COLLATE NOCASE` when you define a text column.
+
+#### Adding case-insensitive filtering to a new column.
+
+To add case-insensitive filtering to a new column, you will need to modify the migration file that is created by Prisma Client.
+
+Taking the following Prisma Schema model:
+
+```prisma
+model User {
+ id Int @id
+ email String
+}
+```
+
+and using `prisma migrate dev --create-only` to create the following migration file:
+
+```sql
+-- CreateTable
+CREATE TABLE "User" (
+ "id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
+ "email" TEXT NOT NULL
+);
+```
+
+You would need to add `COLLATE NOCASE` to the `email` column in order to make case-insensitive filtering possible:
+
+```sql
+-- CreateTable
+CREATE TABLE "User" (
+ "id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
+ //highlight-next-line
+ "email" TEXT NOT NULL COLLATE NOCASE
+);
+```
+
+#### Adding case-insensitive filtering to an existing column.
+
+Since columns cannot be updated in SQLite, `COLLATE NOCASE` can only be added to an existing column by creating a blank migration file and migrating data to a new table.
+
+Taking the following Prisma Schema model:
+
+```prisma
+model User {
+ id Int @id
+ email String
+}
+```
+
+and using `prisma migrate dev --create-only` to create an empty migration file, you will need to rename the current `User` table and create a new `User` table with `COLLATE NOCASE`.
+
+```sql
+-- UpdateTable
+ALTER TABLE "User" RENAME TO "User_old";
+
+CREATE TABLE "User" (
+ "id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
+ "email" TEXT NOT NULL COLLATE NOCASE
+);
+
+INSERT INTO "User" (id, email)
+SELECT id, email FROM "User_old";
+
+DROP TABLE "User_old";
+```
+
+### Microsoft SQL Server provider
+
+Microsoft SQL Server uses **case-insensitive collation** by default. Therefore, filtering with Prisma Client and Microsoft SQL Server is case-insensitive by default.
+
+`mode: 'insensitive'` property is not required and therefore not available in the generated Prisma Client API.
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/100-query-optimization-performance.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/100-query-optimization-performance.mdx
new file mode 100644
index 0000000000..d264df2e58
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/100-query-optimization-performance.mdx
@@ -0,0 +1,459 @@
+---
+title: 'Query optimization using Prisma Optimize'
+sidebar_label: 'Query optimization'
+metaTitle: 'Query optimization using Prisma Optimize'
+metaDescription: 'How Prisma optimizes queries under the hood'
+tocDepth: 3
+---
+
+This guide shows how to identify and optimize query performance, debug performance issues, and address common challenges.
+
+## Debugging performance issues
+
+Several common practices can lead to slow queries and performance problems, such as:
+
+- Over-fetching data
+- Missing indexes
+- Not caching repeated queries
+- Performing full table scans
+
+:::info
+
+For more potential causes of performance issues, visit [this page](/optimize/recommendations).
+
+:::
+
+[Prisma Optimize](/optimize) offers [recommendations](/optimize/recommendations) to identify and address the inefficiencies listed above and more, helping to improve query performance.
+
+To get started, follow the [integration guide](/optimize/getting-started) and add Prisma Optimize to your project to begin diagnosing slow queries.
+
+
+
+
+
+:::tip
+
+You can also [log query events at the client level](/orm/prisma-client/observability-and-logging/logging#event-based-logging) to view the generated queries, their parameters, and execution times.
+
+If you are particularly focused on monitoring query duration, consider using [logging middleware](/6.0/orm/prisma-client/client-extensions/middleware/logging-middleware).
+
+:::
+
+## Using bulk queries
+
+It is generally more performant to read and write large amounts of data in bulk - for example, inserting `50,000` records in batches of `1000` rather than as `50,000` separate inserts. `PrismaClient` supports the following bulk queries:
+
+- [`createMany()`](/6.0/orm/reference/prisma-client-reference#createmany)
+- [`createManyAndReturn()`](/6.0/orm/reference/prisma-client-reference#createmanyandreturn)
+- [`deleteMany()`](/6.0/orm/reference/prisma-client-reference#deletemany)
+- [`updateMany()`](/6.0/orm/reference/prisma-client-reference#updatemany)
+- [`updateManyAndReturn()`](/6.0/orm/reference/prisma-client-reference#updatemanyandreturn)
+- [`findMany()`](/6.0/orm/reference/prisma-client-reference#findmany)
+
+## Reuse `PrismaClient` or use connection pooling to avoid database connection pool exhaustion
+
+Creating multiple instances of `PrismaClient` can exhaust your database connection pool, especially in serverless or edge environments, potentially slowing down other queries. Learn more in the [serverless challenge](/orm/prisma-client/setup-and-configuration/databases-connections#the-serverless-challenge).
+
+For applications with a traditional server, instantiate `PrismaClient` once and reuse it throughout your app instead of creating multiple instances. For example, instead of:
+
+```ts file=query.ts
+async function getPosts() {
+ const prisma = new PrismaClient()
+ await prisma.post.findMany()
+}
+
+async function getUsers() {
+ const prisma = new PrismaClient()
+ await prisma.user.findMany()
+}
+```
+
+Define a single `PrismaClient` instance in a dedicated file and re-export it for reuse:
+
+```ts file=db.ts
+export const prisma = new PrismaClient()
+```
+
+Then import the shared instance:
+
+```ts file=query.ts
+import { prisma } from "db.ts"
+
+async function getPosts() {
+ await prisma.post.findMany()
+}
+
+async function getUsers() {
+ await prisma.user.findMany()
+}
+```
+
+For serverless development environments with frameworks that use HMR (Hot Module Replacement), ensure you properly handle a [single instance of Prisma in development](/orm/more/help-and-troubleshooting/nextjs-help#best-practices-for-using-prisma-client-in-development).
+
+## Solving the n+1 problem
+
+The n+1 problem occurs when you loop through the results of a query and perform one additional query **per result**, resulting in `n` number of queries plus the original (n+1). This is a common problem with ORMs, particularly in combination with GraphQL, because it is not always immediately obvious that your code is generating inefficient queries.
+
+### Solving n+1 in GraphQL with `findUnique()` and Prisma Client's dataloader
+
+
+
+
+
+
+
+The Prisma Client dataloader automatically _batches_ `findUnique()` queries that occur in the same [tick](https://nodejs.org/en/learn/asynchronous-work/event-loop-timers-and-nexttick#processnexttick) and have the same `where` and `include` parameters if:
+
+- All criteria of the `where` filter are on scalar fields (unique or non-unique) of the same model you're querying.
+- All criteria use the `equal` filter, whether that's via the shorthand or explicit syntax `(where: { field: , field1: { equals: } })`.
+- No boolean operators or relation filters are present.
+
+Automatic batching of `findUnique()` is particularly useful in a **GraphQL context**. GraphQL runs a separate resolver function for every field, which can make it difficult to optimize a nested query.
+
+For example - the following GraphQL runs the `allUsers` resolver to get all users, and the `posts` resolver **once per user** to get each user's posts (n+1):
+
+```js
+query {
+ allUsers {
+ id,
+ posts {
+ id
+ }
+ }
+}
+```
+
+The `allUsers` query uses `user.findMany(..)` to return all users:
+
+```ts highlight=7;normal
+const Query = objectType({
+ name: 'Query',
+ definition(t) {
+ t.nonNull.list.nonNull.field('allUsers', {
+ type: 'User',
+ resolve: (_parent, _args, context) => {
+ return context.prisma.user.findMany()
+ },
+ })
+ },
+})
+```
+
+This results in a single SQL query:
+
+```js
+{
+ timestamp: 2021-02-19T09:43:06.332Z,
+ query: 'SELECT `dev`.`User`.`id`, `dev`.`User`.`email`, `dev`.`User`.`name` FROM `dev`.`User` WHERE 1=1 LIMIT ? OFFSET ?',
+ params: '[-1,0]',
+ duration: 0,
+ target: 'quaint::connector::metrics'
+}
+```
+
+However, the resolver function for `posts` is then invoked **once per user**. This results in a `findMany()` query **✘ per user** rather than a single `findMany()` to return all posts by all users (expand CLI output to see queries).
+
+
+
+
+```ts highlight=10-13;normal;
+const User = objectType({
+ name: 'User',
+ definition(t) {
+ t.nonNull.int('id')
+ t.string('name')
+ t.nonNull.string('email')
+ t.nonNull.list.nonNull.field('posts', {
+ type: 'Post',
+ resolve: (parent, _, context) => {
+ return context.prisma.post.findMany({
+ where: { authorId: parent.id || undefined },
+ })
+ },
+ })
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ timestamp: 2021-02-19T09:43:06.343Z,
+ query: 'SELECT `dev`.`Post`.`id`, `dev`.`Post`.`createdAt`, `dev`.`Post`.`updatedAt`, `dev`.`Post`.`title`, `dev`.`Post`.`content`, `dev`.`Post`.`published`, `dev`.`Post`.`viewCount`, `dev`.`Post`.`authorId` FROM `dev`.`Post` WHERE `dev`.`Post`.`authorId` = ? LIMIT ? OFFSET ?',
+ params: '[1,-1,0]',
+ duration: 0,
+ target: 'quaint::connector::metrics'
+}
+{
+ timestamp: 2021-02-19T09:43:06.347Z,
+ query: 'SELECT `dev`.`Post`.`id`, `dev`.`Post`.`createdAt`, `dev`.`Post`.`updatedAt`, `dev`.`Post`.`title`, `dev`.`Post`.`content`, `dev`.`Post`.`published`, `dev`.`Post`.`viewCount`, `dev`.`Post`.`authorId` FROM `dev`.`Post` WHERE `dev`.`Post`.`authorId` = ? LIMIT ? OFFSET ?',
+ params: '[3,-1,0]',
+ duration: 0,
+ target: 'quaint::connector::metrics'
+}
+{
+ timestamp: 2021-02-19T09:43:06.348Z,
+ query: 'SELECT `dev`.`Post`.`id`, `dev`.`Post`.`createdAt`, `dev`.`Post`.`updatedAt`, `dev`.`Post`.`title`, `dev`.`Post`.`content`, `dev`.`Post`.`published`, `dev`.`Post`.`viewCount`, `dev`.`Post`.`authorId` FROM `dev`.`Post` WHERE `dev`.`Post`.`authorId` = ? LIMIT ? OFFSET ?',
+ params: '[2,-1,0]',
+ duration: 0,
+ target: 'quaint::connector::metrics'
+}
+{
+ timestamp: 2021-02-19T09:43:06.348Z,
+ query: 'SELECT `dev`.`Post`.`id`, `dev`.`Post`.`createdAt`, `dev`.`Post`.`updatedAt`, `dev`.`Post`.`title`, `dev`.`Post`.`content`, `dev`.`Post`.`published`, `dev`.`Post`.`viewCount`, `dev`.`Post`.`authorId` FROM `dev`.`Post` WHERE `dev`.`Post`.`authorId` = ? LIMIT ? OFFSET ?',
+ params: '[4,-1,0]',
+ duration: 0,
+ target: 'quaint::connector::metrics'
+}
+{
+ timestamp: 2021-02-19T09:43:06.348Z,
+ query: 'SELECT `dev`.`Post`.`id`, `dev`.`Post`.`createdAt`, `dev`.`Post`.`updatedAt`, `dev`.`Post`.`title`, `dev`.`Post`.`content`, `dev`.`Post`.`published`, `dev`.`Post`.`viewCount`, `dev`.`Post`.`authorId` FROM `dev`.`Post` WHERE `dev`.`Post`.`authorId` = ? LIMIT ? OFFSET ?',
+ params: '[5,-1,0]',
+ duration: 0,
+ target: 'quaint::connector::metrics'
+}
+// And so on
+```
+
+
+
+
+#### Solution 1: Batching queries with the fluent API
+
+Use `findUnique()` in combination with [the fluent API](/orm/prisma-client/queries/relation-queries#fluent-api) (`.posts()`) as shown to return a user's posts. Even though the resolver is called once per user, the Prisma dataloader in Prisma Client **✔ batches the `findUnique()` queries**.
+
+:::info
+
+It may seem counterintitive to use a `prisma.user.findUnique(...).posts()` query to return posts instead of `prisma.posts.findMany()` - particularly as the former results in two queries rather than one.
+
+The **only** reason you need to use the fluent API (`user.findUnique(...).posts()`) to return posts is that the dataloader in Prisma Client batches `findUnique()` queries and does not currently [batch `findMany()` queries](https://github.com/prisma/prisma/issues/1477).
+
+When the dataloader batches `findMany()` queries or your query has the `relationStrategy` set to `join`, you no longer need to use `findUnique()` with the fluent API in this way.
+
+:::
+
+
+
+
+```ts highlight=13-18;add|10-12;delete
+const User = objectType({
+ name: 'User',
+ definition(t) {
+ t.nonNull.int('id')
+ t.string('name')
+ t.nonNull.string('email')
+ t.nonNull.list.nonNull.field('posts', {
+ type: 'Post',
+ resolve: (parent, _, context) => {
+ //delete-start
+ return context.prisma.post.findMany({
+ where: { authorId: parent.id || undefined },
+ })
+ //delete-end
+ //add-start
+ return context.prisma.user
+ .findUnique({
+ where: { id: parent.id || undefined },
+ })
+ .posts()
+ },
+ //add-end
+ })
+ },
+})
+```
+
+
+
+
+```js no-copy
+{
+ timestamp: 2021-02-19T09:59:46.340Z,
+ query: 'SELECT `dev`.`User`.`id`, `dev`.`User`.`email`, `dev`.`User`.`name` FROM `dev`.`User` WHERE 1=1 LIMIT ? OFFSET ?',
+ params: '[-1,0]',
+ duration: 0,
+ target: 'quaint::connector::metrics'
+}
+{
+ timestamp: 2021-02-19T09:59:46.350Z,
+ query: 'SELECT `dev`.`User`.`id` FROM `dev`.`User` WHERE `dev`.`User`.`id` IN (?,?,?) LIMIT ? OFFSET ?',
+ params: '[1,2,3,-1,0]',
+ duration: 0,
+ target: 'quaint::connector::metrics'
+}
+{
+ timestamp: 2021-02-19T09:59:46.350Z,
+ query: 'SELECT `dev`.`Post`.`id`, `dev`.`Post`.`createdAt`, `dev`.`Post`.`updatedAt`, `dev`.`Post`.`title`, `dev`.`Post`.`content`, `dev`.`Post`.`published`, `dev`.`Post`.`viewCount`, `dev`.`Post`.`authorId` FROM `dev`.`Post` WHERE `dev`.`Post`.`authorId` IN (?,?,?) LIMIT ? OFFSET ?',
+ params: '[1,2,3,-1,0]',
+ duration: 0,
+ target: 'quaint::connector::metrics'
+}
+```
+
+
+
+
+If the `posts` resolver is invoked once per user, the dataloader in Prisma Client groups `findUnique()` queries with the same parameters and selection set. Each group is optimized into a single `findMany()`.
+
+#### Solution 2: Using JOINs to perform queries
+
+You can perform the query with a [database join](/orm/prisma-client/queries/relation-queries#relation-load-strategies-preview) by setting `relationLoadStrategy` to `"join"`, ensuring that only **one** query is executed against the database.
+
+```ts
+const User = objectType({
+ name: 'User',
+ definition(t) {
+ t.nonNull.int('id')
+ t.string('name')
+ t.nonNull.string('email')
+ t.nonNull.list.nonNull.field('posts', {
+ type: 'Post',
+ resolve: (parent, _, context) => {
+ return context.prisma.post.findMany({
+ relationLoadStrategy: "join",
+ where: { authorId: parent.id || undefined },
+ })
+ },
+ })
+ },
+})
+```
+
+### n+1 in other contexts
+
+The n+1 problem is most commonly seen in a GraphQL context because you have to find a way to optimize a single query across multiple resolvers. However, you can just as easily introduce the n+1 problem by looping through results with `forEach` in your own code.
+
+The following code results in n+1 queries - one `findMany()` to get all users, and one `findMany()` **per user** to get each user's posts:
+
+
+
+
+```ts
+// One query to get all users
+const users = await prisma.user.findMany({})
+
+// One query PER USER to get all posts
+users.forEach(async (usr) => {
+ const posts = await prisma.post.findMany({
+ where: {
+ authorId: usr.id,
+ },
+ })
+
+ // Do something with each users' posts
+})
+```
+
+
+
+
+```sql no-copy
+SELECT "public"."User"."id", "public"."User"."email", "public"."User"."name" FROM "public"."User" WHERE 1=1 OFFSET $1
+SELECT "public"."Post"."id", "public"."Post"."title" FROM "public"."Post" WHERE "public"."Post"."authorId" = $1 OFFSET $2
+SELECT "public"."Post"."id", "public"."Post"."title" FROM "public"."Post" WHERE "public"."Post"."authorId" = $1 OFFSET $2
+SELECT "public"."Post"."id", "public"."Post"."title" FROM "public"."Post" WHERE "public"."Post"."authorId" = $1 OFFSET $2
+SELECT "public"."Post"."id", "public"."Post"."title" FROM "public"."Post" WHERE "public"."Post"."authorId" = $1 OFFSET $2
+/* ..and so on .. */
+```
+
+
+
+
+This is not an efficient way to query. Instead, you can:
+
+- Use nested reads ([`include`](/6.0/orm/reference/prisma-client-reference#include) ) to return users and related posts
+- Use the [`in`](/6.0/orm/reference/prisma-client-reference#in) filter
+- Set the [`relationLoadStrategy`](/orm/prisma-client/queries/relation-queries#relation-load-strategies-preview) to `"join"`
+
+#### Solving n+1 with `include`
+
+You can use `include` to return each user's posts. This only results in **two** SQL queries - one to get users, and one to get posts. This is known as a [nested read](/orm/prisma-client/queries/relation-queries#nested-reads).
+
+
+
+
+```ts
+const usersWithPosts = await prisma.user.findMany({
+ include: {
+ posts: true,
+ },
+})
+```
+
+
+
+
+```sql no-copy
+SELECT "public"."User"."id", "public"."User"."email", "public"."User"."name" FROM "public"."User" WHERE 1=1 OFFSET $1
+SELECT "public"."Post"."id", "public"."Post"."title", "public"."Post"."authorId" FROM "public"."Post" WHERE "public"."Post"."authorId" IN ($1,$2,$3,$4) OFFSET $5
+```
+
+
+
+
+#### Solving n+1 with `in`
+
+If you have a list of user IDs, you can use the `in` filter to return all posts where the `authorId` is `in` that list of IDs:
+
+
+
+
+```ts
+const users = await prisma.user.findMany({})
+
+const userIds = users.map((x) => x.id)
+
+const posts = await prisma.post.findMany({
+ where: {
+ authorId: {
+ in: userIds,
+ },
+ },
+})
+```
+
+
+
+
+```sql no-copy
+SELECT "public"."User"."id", "public"."User"."email", "public"."User"."name" FROM "public"."User" WHERE 1=1 OFFSET $1
+SELECT "public"."Post"."id", "public"."Post"."createdAt", "public"."Post"."updatedAt", "public"."Post"."title", "public"."Post"."content", "public"."Post"."published", "public"."Post"."authorId" FROM "public"."Post" WHERE "public"."Post"."authorId" IN ($1,$2,$3,$4) OFFSET $5
+```
+
+
+
+
+#### Solving n+1 with `relationLoadStrategy: "join"`
+
+You can perform the query with a [database join](/orm/prisma-client/queries/relation-queries#relation-load-strategies-preview) by setting `relationLoadStrategy` to `"join"`, ensuring that only **one** query is executed against the database.
+
+```ts
+const users = await prisma.user.findMany({})
+
+const userIds = users.map((x) => x.id)
+
+const posts = await prisma.post.findMany({
+ relationLoadStrategy: "join",
+ where: {
+ authorId: {
+ in: userIds,
+ },
+ },
+})
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/index.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/index.mdx
new file mode 100644
index 0000000000..befc525670
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/100-queries/index.mdx
@@ -0,0 +1,10 @@
+---
+title: 'Queries'
+metaTitle: 'Prisma Client Queries'
+metaDescription: 'Learn about the database queries you can send with Prisma Client.'
+hide_table_of_contents: true
+---
+
+## In this section
+
+
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/150-using-raw-sql/100-typedsql.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/150-using-raw-sql/100-typedsql.mdx
new file mode 100644
index 0000000000..5f3b7cb471
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/150-using-raw-sql/100-typedsql.mdx
@@ -0,0 +1,265 @@
+---
+title: 'TypedSQL'
+metaTitle: 'Writing Type-safe SQL with TypedSQL and Prisma Client'
+metaDescription: 'Learn how to use TypedSQL to write fully type-safe SQL queries that are compatible with any SQL console and Prisma Client.'
+sidebar_class_name: preview-badge
+---
+
+## Getting started with TypedSQL
+
+To start using TypedSQL in your Prisma project, follow these steps:
+
+1. Ensure you have `@prisma/client` and `prisma` installed and updated to at least version `5.19.0`.
+
+ ```terminal
+ npm install @prisma/client@latest
+ npm install -D prisma@latest
+ ```
+
+1. Add the `typedSql` preview feature flag to your `schema.prisma` file:
+
+ ```prisma
+ generator client {
+ provider = "prisma-client" // or "prisma-client-js"
+ previewFeatures = ["typedSql"]
+ output = "../src/generated/prisma"
+ }
+ ```
+ :::tip[Using driver adapters with TypedSQL]
+
+ If you are deploying Prisma in serverless or edge environments, you can use [driver adapters](/orm/overview/databases/database-drivers#driver-adapters) to connect through JavaScript database drivers. Driver adapters are compatible with TypedSQL, with the exception of `@prisma/adapter-better-sqlite3`. For SQLite support, use [`@prisma/adapter-libsql`](https://www.npmjs.com/package/@prisma/adapter-libsql) instead. All other driver adapters are supported.
+
+ :::
+
+1. Create a `sql` directory inside your `prisma` directory. This is where you'll write your SQL queries.
+
+ ```terminal
+ mkdir -p prisma/sql
+ ```
+
+ :::note[Custom SQL folder location]
+
+ Starting with Prisma 6.12.0, you can configure a custom location for your SQL files using the Prisma config file. Create a `prisma.config.ts` file in your project root and specify the `typedSql.path` option:
+
+ ```typescript title="prisma.config.ts"
+ import { defineConfig } from 'prisma/config'
+
+ export default defineConfig({
+ schema: './prisma/schema.prisma',
+ typedSql: {
+ path: './prisma/sql',
+ },
+ })
+ ```
+
+ :::
+
+1. Create a new `.sql` file in your `prisma/sql` directory. For example, `getUsersWithPosts.sql`. Note that the file name must be a valid JS identifier and cannot start with a `$`.
+
+1. Write your SQL queries in your new `.sql` file. For example:
+
+ ```sql title="prisma/sql/getUsersWithPosts.sql"
+ SELECT u.id, u.name, COUNT(p.id) as "postCount"
+ FROM "User" u
+ LEFT JOIN "Post" p ON u.id = p."authorId"
+ GROUP BY u.id, u.name
+ ```
+
+1. Generate Prisma Client with the `sql` flag to ensure TypeScript functions and types for your SQL queries are created:
+
+ :::warning
+
+ Make sure that any pending migrations are applied before generating the client with the `sql` flag.
+
+ :::
+
+ ```terminal
+ prisma generate --sql
+ ```
+
+ If you don't want to regenerate the client after every change, this command also works with the existing `--watch` flag:
+
+ ```terminal
+ prisma generate --sql --watch
+ ```
+
+1. Now you can import and use your SQL queries in your TypeScript code:
+
+ ```typescript title="/src/index.ts"
+ import { PrismaClient } from './generated/prisma/client'
+ import { getUsersWithPosts } from './generated/prisma/sql'
+
+ const prisma = new PrismaClient()
+
+ const usersWithPostCounts = await prisma.$queryRawTyped(getUsersWithPosts())
+ console.log(usersWithPostCounts)
+ ```
+
+ :::note
+
+ If you do not customize the generator `output`, you can import from `@prisma/client` and `@prisma/client/sql` instead.
+
+ :::
+
+## Passing Arguments to TypedSQL Queries
+
+To pass arguments to your TypedSQL queries, you can use parameterized queries. This allows you to write flexible and reusable SQL statements while maintaining type safety. Here's how to do it:
+
+1. In your SQL file, use placeholders for the parameters you want to pass. The syntax for placeholders depends on your database engine:
+
+
+
+ For PostgreSQL, use the positional placeholders `$1`, `$2`, etc.:
+
+ ```sql title="prisma/sql/getUsersByAge.sql"
+ SELECT id, name, age
+ FROM users
+ WHERE age > $1 AND age < $2
+ ```
+
+
+ For MySQL, use the positional placeholders `?`:
+
+ ```sql title="prisma/sql/getUsersByAge.sql"
+ SELECT id, name, age
+ FROM users
+ WHERE age > ? AND age < ?
+ ```
+
+
+ In SQLite, there are a number of different placeholders you can use. Positional placeholders (`$1`, `$2`, etc.), general placeholders (`?`), and named placeholders (`:minAge`, `:maxAge`, etc.) are all available. For this example, we'll use named placeholders `:minAge` and `:maxAge`:
+
+ ```sql title="prisma/sql/getUsersByAge.sql"
+ SELECT id, name, age
+ FROM users
+ WHERE age > :minAge AND age < :maxAge
+ ```
+
+
+
+ :::note
+
+ See below for information on how to [define argument types in your SQL files](#defining-argument-types-in-your-sql-files).
+
+ :::
+
+1. When using the generated function in your TypeScript code, pass the arguments as additional parameters to `$queryRawTyped`:
+
+ ```typescript title="/src/index.ts"
+ import { PrismaClient } from './generated/prisma/client'
+ import { getUsersByAge } from './generated/prisma/sql'
+
+ const prisma = new PrismaClient()
+
+ const minAge = 18
+ const maxAge = 30
+ const users = await prisma.$queryRawTyped(getUsersByAge(minAge, maxAge))
+ console.log(users)
+ ```
+
+By using parameterized queries, you ensure type safety and protect against SQL injection vulnerabilities. The TypedSQL generator will create the appropriate TypeScript types for the parameters based on your SQL query, providing full type checking for both the query results and the input parameters.
+
+### Passing array arguments to TypedSQL
+
+TypedSQL supports passing arrays as arguments for PostgreSQL. Use PostgreSQL's `ANY` operator with an array parameter.
+
+```sql title="prisma/sql/getUsersByIds.sql"
+SELECT id, name, email
+FROM users
+WHERE id = ANY($1)
+```
+
+```typescript title="/src/index.ts"
+import { PrismaClient } from './generated/prisma/client'
+import { getUsersByIds } from './generated/prisma/sql'
+
+const prisma = new PrismaClient()
+
+const userIds = [1, 2, 3]
+const users = await prisma.$queryRawTyped(getUsersByIds(userIds))
+console.log(users)
+```
+
+TypedSQL will generate the appropriate TypeScript types for the array parameter, ensuring type safety for both the input and the query results.
+
+:::note
+
+When passing array arguments, be mindful of the maximum number of placeholders your database supports in a single query. For very large arrays, you may need to split the query into multiple smaller queries.
+
+:::
+
+### Defining argument types in your SQL files
+
+Argument typing in TypedSQL is accomplished via specific comments in your SQL files. These comments are of the form:
+
+```sql
+-- @param {Type} $N:alias optional description
+```
+
+Where `Type` is a valid database type, `N` is the position of the argument in the query, and `alias` is an optional alias for the argument that is used in the TypeScript type.
+
+As an example, if you needed to type a single string argument with the alias `name` and the description "The name of the user", you would add the following comment to your SQL file:
+```sql
+-- @param {String} $1:name The name of the user
+```
+
+To indicate that a parameter is nullable, add a question mark after the alias:
+
+```sql
+-- @param {String} $1:name? The name of the user (optional)
+```
+
+Currently accepted types are `Int`, `BigInt`, `Float`, `Boolean`, `String`, `DateTime`, `Json`, `Bytes`, `null`, and `Decimal`.
+
+Taking the [example from above](#passing-arguments-to-typedsql-queries), the SQL file would look like this:
+
+```sql
+-- @param {Int} $1:minAge
+-- @param {Int} $2:maxAge
+SELECT id, name, age
+FROM users
+WHERE age > $1 AND age < $2
+```
+
+The format of argument type definitions is the same regardless of the database engine.
+
+:::note
+
+Manual argument type definitions are not supported for array arguments. For these arguments, you will need to rely on the type inference provided by TypedSQL.
+
+:::
+
+## Examples
+
+For practical examples of how to use TypedSQL, please refer to the [TypedSQL example in the Prisma Examples repo](https://github.com/prisma/prisma-examples/tree/latest/generator-prisma-client/basic-typedsql).
+
+## Limitations of TypedSQL
+
+### Supported Databases
+
+TypedSQL supports modern versions of MySQL and PostgreSQL without any further configuration. For MySQL versions older than 8.0 and all SQLite versions, you will need to manually [describe argument types](#defining-argument-types-in-your-sql-files) in your SQL files. The types of inputs are inferred in all supported versions of PostgreSQL and MySQL 8.0 and later.
+
+TypedSQL does not work with MongoDB, as it is specifically designed for SQL databases.
+
+### Active Database Connection Required
+
+TypedSQL requires an active database connection to function properly. This means you need to have a running database instance that Prisma can connect to when generating the client with the `--sql` flag. If a `directUrl` is provided in your Prisma configuration, TypedSQL will use that for the connection.
+
+### Dynamic SQL Queries with Dynamic Columns
+
+TypedSQL does not natively support constructing SQL queries with dynamically added columns. When you need to create a query where the columns are determined at runtime, you must use the `$queryRaw` and `$executeRaw` methods. These methods allow for the execution of raw SQL, which can include dynamic column selections.
+
+**Example of a query using dynamic column selection:**
+
+```typescript
+const columns = 'name, email, age'; // Columns determined at runtime
+const result = await prisma.$queryRawUnsafe(
+ `SELECT ${columns} FROM Users WHERE active = true`
+);
+```
+
+In this example, the columns to be selected are defined dynamically and included in the SQL query. While this approach provides flexibility, it requires careful attention to security, particularly to [avoid SQL injection vulnerabilities](/orm/prisma-client/using-raw-sql/raw-queries#sql-injection-prevention). Additionally, using raw SQL queries means foregoing the type-safety and DX of TypedSQL.
+
+## Acknowledgements
+
+This feature was heavily inspired by [PgTyped](https://github.com/adelsz/pgtyped) and [SQLx](https://github.com/launchbadge/sqlx). Additionally, SQLite parsing is handled by SQLx.
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/150-using-raw-sql/200-raw-queries.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/150-using-raw-sql/200-raw-queries.mdx
new file mode 100644
index 0000000000..e0ff6126d1
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/150-using-raw-sql/200-raw-queries.mdx
@@ -0,0 +1,867 @@
+---
+title: "Raw queries"
+metaTitle: "Raw queries"
+metaDescription: "Learn how you can send raw SQL and MongoDB queries to your database using the raw() methods from the Prisma Client API."
+---
+
+:::warning
+
+With Prisma ORM `5.19.0`, we have released [TypedSQL](/orm/prisma-client/using-raw-sql). TypedSQL is a new way to write SQL queries that are type-safe and even easier to add to your workflow.
+
+We strongly recommend using TypedSQL queries over the legacy raw queries described below whenever possible.
+
+:::
+
+Prisma Client supports the option of sending raw queries to your database. You may wish to use raw queries if:
+
+- you want to run a heavily optimized query
+- you require a feature that Prisma Client does not yet support (please [consider raising an issue](https://github.com/prisma/prisma/issues/new/choose))
+
+Raw queries are available for all relational databases Prisma ORM supports. In addition, from version `3.9.0` raw queries are supported in MongoDB. For more details, see the relevant sections:
+
+- [Raw queries with relational databases](#raw-queries-with-relational-databases)
+- [Raw queries with MongoDB](#raw-queries-with-mongodb)
+
+## Raw queries with relational databases
+
+For relational databases, Prisma Client exposes four methods that allow you to send raw queries. You can use:
+
+- `$queryRaw` to return actual records (for example, using `SELECT`).
+- `$executeRaw` to return a count of affected rows (for example, after an `UPDATE` or `DELETE`).
+- `$queryRawUnsafe` to return actual records (for example, using `SELECT`) using a raw string.
+- `$executeRawUnsafe` to return a count of affected rows (for example, after an `UPDATE` or `DELETE`) using a raw string.
+
+The methods with "Unsafe" in the name are a lot more flexible but are at **significant risk of making your code vulnerable to SQL injection**.
+
+The other two methods are safe to use with a simple template tag, no string building, and no concatenation. **However**, caution is required for more complex use cases as it is still possible to introduce SQL injection if these methods are used in certain ways. For more details, see the [SQL injection prevention](#sql-injection-prevention) section below.
+
+> **Note**: All methods in the above list can only run **one** query at a time. You cannot append a second query - for example, calling any of them with `select 1; select 2;` will not work.
+
+### `$queryRaw`
+
+`$queryRaw` returns actual database records. For example, the following `SELECT` query returns all fields for each record in the `User` table:
+
+```ts no-lines
+const result = await prisma.$queryRaw`SELECT * FROM User`;
+```
+
+The method is implemented as a [tagged template](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#tagged_templates), which allows you to pass a template literal where you can easily insert your [variables](#using-variables). In turn, Prisma Client creates prepared statements that are safe from SQL injections:
+
+```ts no-lines
+const email = "emelie@prisma.io";
+const result = await prisma.$queryRaw`SELECT * FROM User WHERE email = ${email}`;
+```
+
+You can also use the [`Prisma.sql`](#tagged-template-helpers) helper, in fact, the `$queryRaw` method will **only accept** a template string or the `Prisma.sql` helper:
+
+```ts no-lines
+const email = "emelie@prisma.io";
+const result = await prisma.$queryRaw(Prisma.sql`SELECT * FROM User WHERE email = ${email}`);
+```
+
+
+
+If you use string building to incorporate untrusted input into queries passed to this method, then you open up the possibility for SQL injection attacks. SQL injection attacks can expose your data to modification or deletion. The preferred mechanism would be to include the text of the query at the point that you run this method. For more information on this risk and also examples of how to prevent it, see the [SQL injection prevention](#sql-injection-prevention) section below.
+
+
+
+#### Considerations
+
+Be aware that:
+
+- Template variables cannot be used inside SQL string literals. For example, the following query would **not** work:
+
+ ```ts no-lines
+ const name = "Bob";
+ await prisma.$queryRaw`SELECT 'My name is ${name}';`;
+ ```
+
+ Instead, you can either pass the whole string as a variable, or use string concatenation:
+
+ ```ts no-lines
+ const name = "My name is Bob";
+ await prisma.$queryRaw`SELECT ${name};`;
+ ```
+
+ ```ts no-lines
+ const name = "Bob";
+ await prisma.$queryRaw`SELECT 'My name is ' || ${name};`;
+ ```
+
+- Template variables can only be used for data values (such as `email` in the example above). Variables cannot be used for identifiers such as column names, table names or database names, or for SQL keywords. For example, the following two queries would **not** work:
+
+ ```ts no-lines
+ const myTable = "user";
+ await prisma.$queryRaw`SELECT * FROM ${myTable};`;
+ ```
+
+ ```ts no-lines
+ const ordering = "desc";
+ await prisma.$queryRaw`SELECT * FROM Table ORDER BY ${ordering};`;
+ ```
+
+- Prisma maps any database values returned by `$queryRaw` and `$queryRawUnsafe` to their corresponding JavaScript types. [Learn more](#raw-query-type-mapping).
+
+- `$queryRaw` does not support dynamic table names in PostgreSQL databases. [Learn more](#dynamic-table-names-in-postgresql)
+
+#### Return type
+
+`$queryRaw` returns an array. Each object corresponds to a database record:
+
+```json5
+[
+ { id: 1, email: "emelie@prisma.io", name: "Emelie" },
+ { id: 2, email: "yin@prisma.io", name: "Yin" },
+]
+```
+
+You can also [type the results of `$queryRaw`](#typing-queryraw-results).
+
+#### Signature
+
+```ts no-lines
+$queryRaw(query: TemplateStringsArray | Prisma.Sql, ...values: any[]): PrismaPromise;
+```
+
+#### Typing `$queryRaw` results
+
+`PrismaPromise` uses a [generic type parameter `T`](https://www.typescriptlang.org/docs/handbook/generics.html). You can determine the type of `T` when you invoke the `$queryRaw` method. In the following example, `$queryRaw` returns `User[]`:
+
+```ts
+// import the generated `User` type from the `@prisma/client` module
+import { User } from "@prisma/client";
+
+const result = await prisma.$queryRaw`SELECT * FROM User`;
+// result is of type: `User[]`
+```
+
+> **Note**: If you do not provide a type, `$queryRaw` defaults to `unknown`.
+
+If you are selecting **specific fields** of the model or want to include relations, refer to the documentation about [leveraging Prisma Client's generated types](/orm/prisma-client/type-safety/operating-against-partial-structures-of-model-types#problem-using-variations-of-the-generated-model-type) if you want to make sure that the results are properly typed.
+
+#### Type caveats when using raw SQL
+
+When you type the results of `$queryRaw`, the raw data might not always match the suggested TypeScript type. For example, the following Prisma model includes a `Boolean` field named `published`:
+
+```prisma highlight=3;normal
+model Post {
+ id Int @id @default(autoincrement())
+ //highlight-next-line
+ published Boolean @default(false)
+ title String
+ content String?
+}
+```
+
+The following query returns all posts. It then prints out the value of the `published` field for each `Post`:
+
+```ts
+const result = await prisma.$queryRaw`SELECT * FROM Post`;
+
+result.forEach((x) => {
+ console.log(x.published);
+});
+```
+
+For regular CRUD queries, the Prisma Client query engine standardizes the return type for all databases. **Using the raw queries does not**. If the database provider is MySQL, the returned values are `1` or `0`. However, if the database provider is PostgreSQL, the values are `true` or `false`.
+
+> **Note**: Prisma sends JavaScript integers to PostgreSQL as `INT8`. This might conflict with your user-defined functions that accept only `INT4` as input. If you use `$queryRaw` in conjunction with a PostgreSQL database, update the input types to `INT8`, or cast your query parameters to `INT4`.
+
+#### Dynamic table names in PostgreSQL
+
+[It is not possible to interpolate table names](#considerations). This means that you cannot use dynamic table names with `$queryRaw`. Instead, you must use [`$queryRawUnsafe`](#queryrawunsafe), as follows:
+
+```ts
+let userTable = "User";
+let result = await prisma.$queryRawUnsafe(`SELECT * FROM ${userTable}`);
+```
+
+Note that if you use `$queryRawUnsafe` in conjunction with user inputs, you risk SQL injection attacks. [Learn more](#queryrawunsafe).
+
+### `$queryRawUnsafe()`
+
+The `$queryRawUnsafe()` method allows you to pass a raw string (or template string) to the database.
+
+
+
+If you use this method with user inputs (in other words, `SELECT * FROM table WHERE columnx = ${userInput}`), then you open up the possibility for SQL injection attacks. SQL injection attacks can expose your data to modification or deletion.
+
+Wherever possible you should use the `$queryRaw` method instead. When used correctly `$queryRaw` method is significantly safer but note that the `$queryRaw` method can also be made vulnerable in certain circumstances. For more information, see the [SQL injection prevention](#sql-injection-prevention) section below.
+
+
+
+The following query returns all fields for each record in the `User` table:
+
+```ts
+// import the generated `User` type from the `@prisma/client` module
+import { User } from "@prisma/client";
+
+const result = await prisma.$queryRawUnsafe("SELECT * FROM User");
+```
+
+You can also run a parameterized query. The following example returns all users whose email contains the string `emelie@prisma.io`:
+
+```ts
+prisma.$queryRawUnsafe("SELECT * FROM users WHERE email = $1", "emelie@prisma.io");
+```
+
+> **Note**: Prisma sends JavaScript integers to PostgreSQL as `INT8`. This might conflict with your user-defined functions that accept only `INT4` as input. If you use a parameterized `$queryRawUnsafe` query in conjunction with a PostgreSQL database, update the input types to `INT8`, or cast your query parameters to `INT4`.
+
+For more details on using parameterized queries, see the [parameterized queries](#parameterized-queries) section below.
+
+#### Signature
+
+```ts no-lines
+$queryRawUnsafe(query: string, ...values: any[]): PrismaPromise;
+```
+
+### `$executeRaw`
+
+`$executeRaw` returns the _number of rows affected by a database operation_, such as `UPDATE` or `DELETE`. This function does **not** return database records. The following query updates records in the database and returns a count of the number of records that were updated:
+
+```ts
+const result: number =
+ await prisma.$executeRaw`UPDATE User SET active = true WHERE emailValidated = true`;
+```
+
+The method is implemented as a [tagged template](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#tagged_templates), which allows you to pass a template literal where you can easily insert your [variables](#using-variables). In turn, Prisma Client creates prepared statements that are safe from SQL injections:
+
+```ts
+const emailValidated = true;
+const active = true;
+
+const result: number =
+ await prisma.$executeRaw`UPDATE User SET active = ${active} WHERE emailValidated = ${emailValidated};`;
+```
+
+
+
+If you use string building to incorporate untrusted input into queries passed to this method, then you open up the possibility for SQL injection attacks. SQL injection attacks can expose your data to modification or deletion. The preferred mechanism would be to include the text of the query at the point that you run this method. For more information on this risk and also examples of how to prevent it, see the [SQL injection prevention](#sql-injection-prevention) section below.
+
+
+
+#### Considerations
+
+Be aware that:
+
+- `$executeRaw` does not support multiple queries in a single string (for example, `ALTER TABLE` and `CREATE TABLE` together).
+- Prisma Client submits prepared statements, and prepared statements only allow a subset of SQL statements. For example, `START TRANSACTION` is not permitted. You can learn more about [the syntax that MySQL allows in Prepared Statements here](https://dev.mysql.com/doc/refman/8.0/en/sql-prepared-statements.html).
+- [`PREPARE` does not support `ALTER`](https://www.postgresql.org/docs/current/sql-prepare.html) - see the [workaround](#alter-limitation-postgresql).
+- Template variables cannot be used inside SQL string literals. For example, the following query would **not** work:
+
+ ```ts no-lines
+ const name = "Bob";
+ await prisma.$executeRaw`UPDATE user SET greeting = 'My name is ${name}';`;
+ ```
+
+ Instead, you can either pass the whole string as a variable, or use string concatenation:
+
+ ```ts no-lines
+ const name = "My name is Bob";
+ await prisma.$executeRaw`UPDATE user SET greeting = ${name};`;
+ ```
+
+ ```ts no-lines
+ const name = "Bob";
+ await prisma.$executeRaw`UPDATE user SET greeting = 'My name is ' || ${name};`;
+ ```
+
+- Template variables can only be used for data values (such as `email` in the example above). Variables cannot be used for identifiers such as column names, table names or database names, or for SQL keywords. For example, the following two queries would **not** work:
+
+ ```ts no-lines
+ const myTable = "user";
+ await prisma.$executeRaw`UPDATE ${myTable} SET active = true;`;
+ ```
+
+ ```ts no-lines
+ const ordering = "desc";
+ await prisma.$executeRaw`UPDATE User SET active = true ORDER BY ${desc};`;
+ ```
+
+#### Return type
+
+`$executeRaw` returns a `number`.
+
+#### Signature
+
+```ts
+$executeRaw(query: TemplateStringsArray | Prisma.Sql, ...values: any[]): PrismaPromise;
+```
+
+### `$executeRawUnsafe()`
+
+The `$executeRawUnsafe()` method allows you to pass a raw string (or template string) to the database. Like `$executeRaw`, it does **not** return database records, but returns the number of rows affected.
+
+
+
+If you use this method with user inputs (in other words, `SELECT * FROM table WHERE columnx = ${userInput}`), then you open up the possibility for SQL injection attacks. SQL injection attacks can expose your data to modification or deletion.
+
+Wherever possible you should use the `$executeRaw` method instead. When used correctly `$executeRaw` method is significantly safer but note that the `$executeRaw` method can also be made vulnerable in certain circumstances. For more information, see the [SQL injection prevention](#sql-injection-prevention) section below.
+
+
+
+The following example uses a template string to update records in the database. It then returns a count of the number of records that were updated:
+
+```ts
+const emailValidated = true;
+const active = true;
+
+const result = await prisma.$executeRawUnsafe(
+ `UPDATE User SET active = ${active} WHERE emailValidated = ${emailValidated}`
+);
+```
+
+The same can be written as a parameterized query:
+
+```ts
+const result = prisma.$executeRawUnsafe(
+ "UPDATE User SET active = $1 WHERE emailValidated = $2",
+ "yin@prisma.io",
+ true
+);
+```
+
+For more details on using parameterized queries, see the [parameterized queries](#parameterized-queries) section below.
+
+#### Signature
+
+```ts no-lines
+$executeRawUnsafe(query: string, ...values: any[]): PrismaPromise;
+```
+
+### Raw query type mapping
+
+Prisma maps any database values returned by `$queryRaw` and `$queryRawUnsafe`to their corresponding [JavaScript types](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Data_structures). This behavior is the same as for regular Prisma query methods like `findMany()`.
+
+
+
+**Feature availability:**
+
+- In v3.14.x and v3.15.x, raw query type mapping was available with the preview feature `improvedQueryRaw`. We made raw query type mapping [Generally Available](/orm/more/releases#generally-available-ga) in version 4.0.0, so you do not need to use `improvedQueryRaw` in version 4.0.0 or later.
+- Before version 4.0.0, raw query type mapping was not available for SQLite.
+
+
+
+As an example, take a raw query that selects columns with `BigInt`, `Bytes`, `Decimal` and `Date` types from a table:
+
+
+
+
+
+```ts
+const result = await prisma.$queryRaw`SELECT bigint, bytes, decimal, date FROM "Table";`;
+
+console.log(result);
+```
+
+
+
+
+
+```terminal no-copy wrap
+{ bigint: BigInt("123"), bytes: ), decimal: Decimal("12.34"), date: Date("") }
+```
+
+
+
+
+
+In the `result` object, the database values have been mapped to the corresponding JavaScript types.
+
+The following table shows the conversion between types used in the database and the JavaScript type returned by the raw query:
+
+| Database type | JavaScript type |
+| ----------------------- | ----------------------------------------------------------------------------------------------------------------------- |
+| Text | `String` |
+| 32-bit integer | `Number` |
+| 32-bit unsigned integer | `BigInt` |
+| Floating point number | `Number` |
+| Double precision number | `Number` |
+| 64-bit integer | `BigInt` |
+| Decimal / numeric | `Decimal` |
+| Bytes | `Uint8Array` ([before v6](/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-6#usage-of-buffer): `Buffer`) |
+| Json | `Object` |
+| DateTime | `Date` |
+| Date | `Date` |
+| Time | `Date` |
+| Uuid | `String` |
+| Xml | `String` |
+
+Note that the exact name for each database type will vary between databases – for example, the boolean type is known as `boolean` in PostgreSQL and `STRING` in CockroachDB. See the [Scalar types reference](/orm/reference/prisma-schema-reference#model-field-scalar-types) for full details of type names for each database.
+
+### Raw query typecasting behavior
+
+Raw queries with Prisma Client might require parameters to be in the expected types of the SQL function or query. Prisma Client does not do subtle, implicit casts.
+
+As an example, take the following query using PostgreSQL's `LENGTH` function, which only accepts the `text` type as an input:
+
+```ts
+await prisma.$queryRaw`SELECT LENGTH(${42});`;
+```
+
+This query returns an error:
+
+```terminal wrap
+// ERROR: function length(integer) does not exist
+// HINT: No function matches the given name and argument types. You might need to add explicit type casts.
+```
+
+The solution in this case is to explicitly cast `42` to the `text` type:
+
+```ts
+await prisma.$queryRaw`SELECT LENGTH(${42}::text);`;
+```
+
+:::info
+
+**Feature availability:** This funtionality is [Generally Available](/orm/more/releases#generally-available-ga) since version 4.0.0. In v3.14.x and v3.15.x, it was available with the preview feature `improvedQueryRaw`.
+
+For the example above before version 4.0.0, Prisma ORM silently coerces `42` to `text` and does not require the explicit cast.
+
+On the other hand the following raw query now works correctly, returning an integer result, and failed before:
+
+```ts
+await prisma.$queryRaw`SELECT ${1.5}::int as int`;
+
+// Now: [{ int: 2 }]
+// Before: db error: ERROR: incorrect binary data format in bind parameter 1
+```
+
+:::
+
+### Transactions
+
+In 2.10.0 and later, you can use `.$executeRaw()` and `.$queryRaw()` inside a [transaction](/orm/prisma-client/queries/transactions).
+
+### Using variables
+
+`$executeRaw` and `$queryRaw` are implemented as [**tagged templates**](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#tagged_templates). Tagged templates are the recommended way to use variables with raw SQL in the Prisma Client.
+
+The following example includes a placeholder named `${userId}`:
+
+```ts
+const userId = 42;
+const result = await prisma.$queryRaw`SELECT * FROM User WHERE id = ${userId};`;
+```
+
+✔ Benefits of using the tagged template versions of `$queryRaw` and `$executeRaw` include:
+
+- Prisma Client escapes all variables.
+- Tagged templates are database-agnostic - you do not need to remember if variables should be written as `$1` (PostgreSQL) or `?` (MySQL).
+- [SQL Template Tag](https://github.com/blakeembrey/sql-template-tag) give you access to [useful helpers](#tagged-template-helpers).
+- Embedded, named variables are easier to read.
+
+> **Note**: You cannot pass a table or column name into a tagged template placeholder. For example, you cannot `SELECT ?` and pass in `*` or `id, name` based on some condition.
+
+#### Tagged template helpers
+
+Prisma Client specifically uses [SQL Template Tag](https://github.com/blakeembrey/sql-template-tag), which exposes a number of helpers. For example, the following query uses `join()` to pass in a list of IDs:
+
+```ts
+import { Prisma } from "@prisma/client";
+
+const ids = [1, 3, 5, 10, 20];
+const result = await prisma.$queryRaw`SELECT * FROM User WHERE id IN (${Prisma.join(ids)})`;
+```
+
+The following example uses the `empty` and `sql` helpers to change the query depending on whether `userName` is empty:
+
+```ts
+import { Prisma } from "@prisma/client";
+
+const userName = "";
+const result = await prisma.$queryRaw`SELECT * FROM User ${
+ userName ? Prisma.sql`WHERE name = ${userName}` : Prisma.empty // Cannot use "" or NULL here!
+}`;
+```
+
+#### `ALTER` limitation (PostgreSQL)
+
+PostgreSQL [does not support using `ALTER` in a prepared statement](https://www.postgresql.org/docs/current/sql-prepare.html), which means that the following queries **will not work**:
+
+```ts
+await prisma.$executeRaw`ALTER USER prisma WITH PASSWORD "${password}"`;
+await prisma.$executeRaw(Prisma.sql`ALTER USER prisma WITH PASSWORD "${password}"`);
+```
+
+You can use the following query, but be aware that this is potentially **unsafe** as `${password}` is not escaped:
+
+```ts
+await prisma.$executeRawUnsafe('ALTER USER prisma WITH PASSWORD "$1"', password})
+```
+
+### Unsupported types
+
+[`Unsupported` types](/orm/reference/prisma-schema-reference#unsupported) need to be cast to Prisma Client supported types before using them in `$queryRaw` or `$queryRawUnsafe`. For example, take the following model, which has a `location` field with an `Unsupported` type:
+
+```tsx
+model Country {
+ location Unsupported("point")?
+}
+```
+
+The following query on the unsupported field will **not** work:
+
+```tsx
+await prisma.$queryRaw`SELECT location FROM Country;`;
+```
+
+Instead, cast `Unsupported` fields to any supported Prisma Client type, **if your `Unsupported` column supports the cast**.
+
+The most common type you may want to cast your `Unsupported` column to is `String`. For example, on PostgreSQL, this would map to the `text` type:
+
+```tsx
+await prisma.$queryRaw`SELECT location::text FROM Country;`;
+```
+
+The database will thus provide a `String` representation of your data which Prisma Client supports.
+
+For details of supported Prisma types, see the [Prisma connector overview](/orm/overview/databases) for the relevant database.
+
+## SQL injection prevention
+
+The ideal way to avoid SQL injection in Prisma Client is to use the ORM models to perform queries wherever possible.
+
+Where this is not possible and raw queries are required, Prisma Client provides various raw methods, but it is important to use these methods safely.
+
+This section will provide various examples of using these methods safely and unsafely. You can test these examples in the [Prisma Playground](https://playground.prisma.io/examples).
+
+### In `$queryRaw` and `$executeRaw`
+
+#### Simple, safe use of `$queryRaw` and `$executeRaw`
+
+These methods can mitigate the risk of SQL injection by escaping all variables when you use tagged templates and sends all queries as prepared statements.
+
+```ts
+$queryRaw`...`; // Tagged template
+$executeRaw`...`; // Tagged template
+```
+
+The following example is safe ✅ from SQL Injection:
+
+```ts
+const inputString = `'Sarah' UNION SELECT id, title FROM "Post"`;
+const result = await prisma.$queryRaw`SELECT id, name FROM "User" WHERE name = ${inputString}`;
+
+console.log(result);
+```
+
+#### Unsafe use of `$queryRaw` and `$executeRaw`
+
+However, it is also possible to use these methods in unsafe ways.
+
+One way is by artificially generating a tagged template that unsafely concatenates user input.
+
+The following example is vulnerable ❌ to SQL Injection:
+
+```ts
+// Unsafely generate query text
+const inputString = `'Sarah' UNION SELECT id, title FROM "Post"`; // SQL Injection
+const query = `SELECT id, name FROM "User" WHERE name = ${inputString}`;
+
+// Version for Typescript
+const stringsArray: any = [...[query]];
+
+// Version for Javascript
+const stringsArray = [...[query]];
+
+// Use the `raw` property to impersonate a tagged template
+stringsArray.raw = [query];
+
+// Use queryRaw
+const result = await prisma.$queryRaw(stringsArray);
+console.log(result);
+```
+
+Another way to make these methods vulnerable is misuse of the `Prisma.raw` function.
+
+The following examples are all vulnerable ❌ to SQL Injection:
+
+```ts
+const inputString = `'Sarah' UNION SELECT id, title FROM "Post"`;
+const result = await prisma.$queryRaw`SELECT id, name FROM "User" WHERE name = ${Prisma.raw(
+ inputString
+)}`;
+console.log(result);
+```
+
+```ts
+const inputString = `'Sarah' UNION SELECT id, title FROM "Post"`;
+const result = await prisma.$queryRaw(
+ Prisma.raw(`SELECT id, name FROM "User" WHERE name = ${inputString}`)
+);
+console.log(result);
+```
+
+```ts
+const inputString = `'Sarah' UNION SELECT id, title FROM "Post"`;
+const query = Prisma.raw(`SELECT id, name FROM "User" WHERE name = ${inputString}`);
+const result = await prisma.$queryRaw(query);
+console.log(result);
+```
+
+#### Safely using `$queryRaw` and `$executeRaw` in more complex scenarios
+
+##### Building raw queries separate to query execution
+
+If you want to build your raw queries elsewhere or separate to your parameters you will need to use one of the following methods.
+
+In this example, the `sql` helper method is used to build the query text by safely including the variable. It is safe ✅ from SQL Injection:
+
+```ts
+// inputString can be untrusted input
+const inputString = `'Sarah' UNION SELECT id, title FROM "Post"`;
+
+// Safe if the text query below is completely trusted content
+const query = Prisma.sql`SELECT id, name FROM "User" WHERE name = ${inputString}`;
+
+const result = await prisma.$queryRaw(query);
+console.log(result);
+```
+
+In this example which is safe ✅ from SQL Injection, the `sql` helper method is used to build the query text including a parameter marker for the input value. Each variable is represented by a marker symbol (`?` for MySQL, `$1`, `$2`, and so on for PostgreSQL). Note that the examples just show PostgreSQL queries.
+
+```ts
+// Version for Typescript
+const query: any;
+
+// Version for Javascript
+const query;
+
+// Safe if the text query below is completely trusted content
+query = Prisma.sql`SELECT id, name FROM "User" WHERE name = $1`;
+
+// inputString can be untrusted input
+const inputString = `'Sarah' UNION SELECT id, title FROM "Post"`;
+query.values = [inputString];
+
+const result = await prisma.$queryRaw(query);
+console.log(result);
+```
+
+> **Note**: PostgreSQL variables are represented by `$1`, etc
+
+##### Building raw queries elsewhere or in stages
+
+If you want to build your raw queries somewhere other than where the query is executed, the ideal way to do this is to create an `Sql` object from the segments of your query and pass it the parameter value.
+
+In the following example we have two variables to parameterize. The example is safe ✅ from SQL Injection as long as the query strings being passed to `Prisma.sql` only contain trusted content:
+
+```ts
+// Example is safe if the text query below is completely trusted content
+const query1 = `SELECT id, name FROM "User" WHERE name = `; // The first parameter would be inserted after this string
+const query2 = ` OR name = `; // The second parameter would be inserted after this string
+
+const inputString1 = "Fred";
+const inputString2 = `'Sarah' UNION SELECT id, title FROM "Post"`;
+
+const query = Prisma.sql([query1, query2, ""], inputString1, inputString2);
+const result = await prisma.$queryRaw(query);
+console.log(result);
+```
+
+> Note: Notice that the string array being passed as the first parameter `Prisma.sql` needs to have an empty string at the end as the `sql` function expects one more query segment than the number of parameters.
+
+If you want to build your raw queries into one large string, this is still possible but requires some care as it is uses the potentially dangerous `Prisma.raw` method. You also need to build your query using the correct parameter markers for your database as Prisma won't be able to provide markers for the relevant database as it usually is.
+
+The following example is safe ✅ from SQL Injection as long as the query strings being passed to `Prisma.raw` only contain trusted content:
+
+```ts
+// Version for Typescript
+const query: any;
+
+// Version for Javascript
+const query;
+
+// Example is safe if the text query below is completely trusted content
+const query1 = `SELECT id, name FROM "User" `;
+const query2 = `WHERE name = $1 `;
+
+query = Prisma.raw(`${query1}${query2}`);
+
+// inputString can be untrusted input
+const inputString = `'Sarah' UNION SELECT id, title FROM "Post"`;
+query.values = [inputString];
+
+const result = await prisma.$queryRaw(query);
+console.log(result);
+```
+
+### In `$queryRawUnsafe` and `$executeRawUnsafe`
+
+#### Using `$queryRawUnsafe` and `$executeRawUnsafe` unsafely
+
+If you cannot use tagged templates, you can instead use [`$queryRawUnsafe`](/orm/prisma-client/using-raw-sql/raw-queries#queryrawunsafe) or [`$executeRawUnsafe`](/orm/prisma-client/using-raw-sql/raw-queries#executerawunsafe). However, **be aware that these functions significantly increase the risk of SQL injection vulnerabilities in your code**.
+
+The following example concatenates `query` and `inputString`. Prisma Client ❌ **cannot** escape `inputString` in this example, which makes it vulnerable to SQL injection:
+
+```ts
+const inputString = '"Sarah" UNION SELECT id, title, content FROM Post'; // SQL Injection
+const query = "SELECT id, name, email FROM User WHERE name = " + inputString;
+const result = await prisma.$queryRawUnsafe(query);
+
+console.log(result);
+```
+
+#### Parameterized queries
+
+As an alternative to tagged templates, `$queryRawUnsafe` supports standard parameterized queries where each variable is represented by a symbol (`?` for MySQL, `$1`, `$2`, and so on for PostgreSQL). Note that the examples just show PostgreSQL queries.
+
+The following example is safe ✅ from SQL Injection:
+
+```ts
+const userName = "Sarah";
+const email = "sarah@prisma.io";
+const result = await prisma.$queryRawUnsafe(
+ "SELECT * FROM User WHERE (name = $1 OR email = $2)",
+ userName,
+ email
+);
+```
+
+> **Note**: PostgreSQL variables are represented by `$1` and `$2`
+
+As with tagged templates, Prisma Client escapes all variables when they are provided in this way.
+
+> **Note**: You cannot pass a table or column name as a variable into a parameterized query. For example, you cannot `SELECT ?` and pass in `*` or `id, name` based on some condition.
+
+##### Parameterized PostgreSQL `ILIKE` query
+
+When you use `ILIKE`, the `%` wildcard character(s) should be included in the variable itself, not the query (`string`). This example is safe ✅ from SQL Injection.
+
+```ts
+const userName = "Sarah";
+const emailFragment = "prisma.io";
+const result = await prisma.$queryRawUnsafe(
+ 'SELECT * FROM "User" WHERE (name = $1 OR email ILIKE $2)',
+ userName,
+ `%${emailFragment}`
+);
+```
+
+> **Note**: Using `%$2` as an argument would not work
+
+## Raw queries with MongoDB
+
+For MongoDB in versions `3.9.0` and later, Prisma Client exposes three methods that allow you to send raw queries. You can use:
+
+- `$runCommandRaw` to run a command against the database
+- `.findRaw` to find zero or more documents that match the filter.
+- `.aggregateRaw` to perform aggregation operations on a collection.
+
+### `$runCommandRaw()`
+
+`$runCommandRaw()` runs a raw MongoDB command against the database. As input, it accepts all [MongoDB database commands](https://www.mongodb.com/docs/manual/reference/command/), with the following exceptions:
+
+- `find` (use [`findRaw()`](#findraw) instead)
+- `aggregate` (use [`aggregateRaw()`](#aggregateraw) instead)
+
+When you use `$runCommandRaw()` to run a MongoDB database command, note the following:
+
+- The object that you pass when you invoke `$runCommandRaw()` must follow the syntax of the MongoDB database command.
+- You must connect to the database with an appropriate role for the MongoDB database command.
+
+In the following example, a query inserts two records with the same `_id`. This bypasses normal document validation.
+
+```ts no-lines
+prisma.$runCommandRaw({
+ insert: "Pets",
+ bypassDocumentValidation: true,
+ documents: [
+ {
+ _id: 1,
+ name: "Felinecitas",
+ type: "Cat",
+ breed: "Russian Blue",
+ age: 12,
+ },
+ {
+ _id: 1,
+ name: "Nao Nao",
+ type: "Dog",
+ breed: "Chow Chow",
+ age: 2,
+ },
+ ],
+});
+```
+
+:::warning
+
+Do not use `$runCommandRaw()` for queries which contain the `"find"` or `"aggregate"` commands, because you might be unable to fetch all data. This is because MongoDB returns a [cursor](https://www.mongodb.com/docs/manual/tutorial/iterate-a-cursor/) that is attached to your MongoDB session, and you might not hit the same MongoDB session every time. For these queries, you should use the specialised [`findRaw()`](#findraw) and [`aggregateRaw()`](#aggregateraw) methods instead.
+
+:::
+
+#### Return type
+
+`$runCommandRaw()` returns a `JSON` object whose shape depends on the inputs.
+
+#### Signature
+
+```ts no-lines
+$runCommandRaw(command: InputJsonObject): PrismaPromise;
+```
+
+### `findRaw()`
+
+`.findRaw()` returns actual database records. It will find zero or more documents that match the filter on the `User` collection:
+
+```ts no-lines
+const result = await prisma.user.findRaw({
+ filter: { age: { $gt: 25 } },
+ options: { projection: { _id: false } },
+});
+```
+
+#### Return type
+
+`.findRaw()` returns a `JSON` object whose shape depends on the inputs.
+
+#### Signature
+
+```ts no-lines
+.findRaw(args?: {filter?: InputJsonObject, options?: InputJsonObject}): PrismaPromise;
+```
+
+- `filter`: The query predicate filter. If unspecified, then all documents in the collection will match the [predicate](https://www.mongodb.com/docs/manual/reference/operator/query).
+- `options`: Additional options to pass to the [`find` command](https://www.mongodb.com/docs/manual/reference/command/find/#command-fields).
+
+### `aggregateRaw()`
+
+`.aggregateRaw()` returns aggregated database records. It will perform aggregation operations on the `User` collection:
+
+```ts no-lines
+const result = await prisma.user.aggregateRaw({
+ pipeline: [
+ { $match: { status: "registered" } },
+ { $group: { _id: "$country", total: { $sum: 1 } } },
+ ],
+});
+```
+
+#### Return type
+
+`.aggregateRaw()` returns a `JSON` object whose shape depends on the inputs.
+
+#### Signature
+
+```ts no-lines
+.aggregateRaw(args?: {pipeline?: InputJsonObject[], options?: InputJsonObject}): PrismaPromise;
+```
+
+- `pipeline`: An array of aggregation stages to process and transform the document stream via the [aggregation pipeline](https://www.mongodb.com/docs/manual/reference/operator/aggregation-pipeline).
+- `options`: Additional options to pass to the [`aggregate` command](https://www.mongodb.com/docs/manual/reference/command/aggregate/#command-fields).
+
+#### Caveats
+
+When working with custom objects like `ObjectId` or `Date,` you will have to pass them according to the [MongoDB extended JSON Spec](https://www.mongodb.com/docs/manual/reference/mongodb-extended-json/#type-representations).
+Example:
+```ts no-lines
+const result = await prisma.user.aggregateRaw({
+ pipeline: [
+ { $match: { _id: { $oid: id } } }
+// ^ notice the $oid convention here
+ ],
+});
+
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/150-using-raw-sql/300-safeql.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/150-using-raw-sql/300-safeql.mdx
new file mode 100644
index 0000000000..a899de290a
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/150-using-raw-sql/300-safeql.mdx
@@ -0,0 +1,383 @@
+---
+title: 'SafeQL & Prisma Client'
+metaTitle: 'Integrate SafeQL with Prisma Client'
+metaDescription: 'Learn how to use SafeQL and Prisma Client extensions to work around features not natively supported by Prisma, such as PostGIS.'
+---
+
+## Overview
+
+This page explains how to improve the experience of writing raw SQL in Prisma ORM. It uses [Prisma Client extensions](/orm/prisma-client/client-extensions) and [SafeQL](https://safeql.dev) to create custom, type-safe Prisma Client queries which abstract custom SQL that your app might need (using `$queryRaw`).
+
+The example will be using [PostGIS](https://postgis.net/) and PostgreSQL, but is applicable to any raw SQL queries that you might need in your application.
+
+:::note
+
+This page builds on the [legacy raw query methods](/orm/prisma-client/using-raw-sql/raw-queries) available in Prisma Client. While many use cases for raw SQL in Prisma Client are covered by [TypedSQL](/orm/prisma-client/using-raw-sql/typedsql), using these legacy methods is still the recommended approach for working with `Unsupported` fields.
+
+:::
+
+## What is SafeQL?
+
+[SafeQL](https://safeql.dev/) allows for advanced linting and type safety within raw SQL queries. After setup, SafeQL works with Prisma Client `$queryRaw` and `$executeRaw` to provide type safety when raw queries are required.
+
+SafeQL runs as an [ESLint](https://eslint.org/) plugin and is configured using ESLint rules. This guide doesn't cover setting up ESLint and we will assume that you already having it running in your project.
+
+## Prerequisites
+
+To follow along, you will be expected to have:
+
+- A [PostgreSQL](https://www.postgresql.org/) database with PostGIS installed
+- Prisma ORM set up in your project
+- ESLint set up in your project
+
+## Geographic data support in Prisma ORM
+
+At the time of writing, Prisma ORM does not support working with geographic data, specifically using [PostGIS](https://github.com/prisma/prisma/issues/2789).
+
+A model that has geographic data columns will be stored using the [`Unsupported`](/orm/reference/prisma-schema-reference#unsupported) data type. Fields with `Unsupported` types are present in the generated Prisma Client and will be typed as `any`. A model with a required `Unsupported` type does not expose write operations such as `create`, and `update`.
+
+Prisma Client supports write operations on models with a required `Unsupported` field using `$queryRaw` and `$executeRaw`. You can use Prisma Client extensions and SafeQL to improve the type-safety when working with geographical data in raw queries.
+
+## 1. Set up Prisma ORM for use with PostGIS
+
+If you haven't already, enable the `postgresqlExtensions` Preview feature and add the `postgis` PostgreSQL extension in your Prisma schema:
+
+```prisma
+generator client {
+ provider = "prisma-client-js"
+ //add-next-line
+ previewFeatures = ["postgresqlExtensions"]
+}
+
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+ //add-next-line
+ extensions = [postgis]
+}
+```
+
+
+
+If you are not using a hosted database provider, you will likely need to install the `postgis` extension. Refer to [PostGIS's docs](http://postgis.net/documentation/getting_started/#installing-postgis) to learn more about how to get started with PostGIS. If you're using Docker Compose, you can use the following snippet to set up a PostgreSQL database that has PostGIS installed:
+
+```yaml
+version: '3.6'
+services:
+ pgDB:
+ image: postgis/postgis:13-3.1-alpine
+ restart: always
+ ports:
+ - '5432:5432'
+ volumes:
+ - db_data:/var/lib/postgresql/data
+ environment:
+ POSTGRES_PASSWORD: password
+ POSTGRES_DB: geoexample
+volumes:
+ db_data:
+```
+
+
+
+Next, create a migration and execute a migration to enable the extension:
+
+```terminal
+npx prisma migrate dev --name add-postgis
+```
+
+For reference, the output of the migration file should look like the following:
+
+```sql file=migrations/TIMESTAMP_add_postgis/migration.sql
+-- CreateExtension
+CREATE EXTENSION IF NOT EXISTS "postgis";
+```
+
+You can double-check that the migration has been applied by running `prisma migrate status`.
+
+## 2. Create a new model that uses a geographic data column
+
+Add a new model with a column with a `geography` data type once the migration is applied. For this guide, we'll use a model called `PointOfInterest`.
+
+```prisma
+model PointOfInterest {
+ id Int @id @default(autoincrement())
+ name String
+ location Unsupported("geography(Point, 4326)")
+}
+```
+
+You'll notice that the `location` field uses an [`Unsupported`](/orm/reference/prisma-schema-reference#unsupported) type. This means that we lose a lot of the benefits of Prisma ORM when working with `PointOfInterest`. We'll be using [SafeQL](https://safeql.dev/) to fix this.
+
+Like before, create and execute a migration using the `prisma migrate dev` command to create the `PointOfInterest` table in your database:
+
+```terminal
+npx prisma migrate dev --name add-poi
+```
+
+For reference, here is the output of the SQL migration file generated by Prisma Migrate:
+
+```sql file=migrations/TIMESTAMP_add_poi/migration.sql
+-- CreateTable
+CREATE TABLE "PointOfInterest" (
+ "id" SERIAL NOT NULL,
+ "name" TEXT NOT NULL,
+ "location" geography(Point, 4326) NOT NULL,
+
+ CONSTRAINT "PointOfInterest_pkey" PRIMARY KEY ("id")
+);
+```
+
+## 3. Integrate SafeQL
+
+SafeQL is easily integrated with Prisma ORM in order to lint `$queryRaw` and `$executeRaw` Prisma operations. You can reference [SafeQL's integration guide](https://safeql.dev/compatibility/prisma.html) or follow the steps below.
+
+### 3.1. Install the `@ts-safeql/eslint-plugin` npm package
+
+```terminal
+npm install -D @ts-safeql/eslint-plugin libpg-query
+```
+
+This ESLint plugin is what will allow for queries to be linted.
+
+### 3.2. Add `@ts-safeql/eslint-plugin` to your ESLint plugins
+
+Next, add `@ts-safeql/eslint-plugin` to your list of ESLint plugins. In our example we are using an `.eslintrc.js` file, but this can be applied to any way that you [configure ESLint](https://eslint.org/docs/latest/use/configure/).
+
+```js file=.eslintrc.js highlight=3
+/** @type {import('eslint').Linter.Config} */
+module.exports = {
+ "plugins": [..., "@ts-safeql/eslint-plugin"],
+ ...
+}
+```
+
+### 3.3 Add `@ts-safeql/check-sql` rules
+
+Now, setup the rules that will enable SafeQL to mark invalid SQL queries as ESLint errors.
+
+```js file=.eslintrc.js highlight=4-22;add
+/** @type {import('eslint').Linter.Config} */
+module.exports = {
+ plugins: [..., '@ts-safeql/eslint-plugin'],
+ //add-start
+ rules: {
+ '@ts-safeql/check-sql': [
+ 'error',
+ {
+ connections: [
+ {
+ // The migrations path:
+ migrationsDir: './prisma/migrations',
+ targets: [
+ // This makes `prisma.$queryRaw` and `prisma.$executeRaw` commands linted
+ { tag: 'prisma.+($queryRaw|$executeRaw)', transform: '{type}[]' },
+ ],
+ },
+ ],
+ },
+ ],
+ },
+}
+//add-end
+```
+
+> **Note**: If your `PrismaClient` instance is called something different than `prisma`, you need to adjust the value for `tag` accordingly. For example, if it is called `db`, the value for `tag` should be `'db.+($queryRaw|$executeRaw)'`.
+
+### 3.4. Connect to your database
+
+Finally, set up a `connectionUrl` for SafeQL so that it can introspect your database and retrieve the table and column names you use in your schema. SafeQL then uses this information for linting and highlighting problems in your raw SQL statements.
+
+Our example relies on the [`dotenv`](https://github.com/motdotla/dotenv) package to get the same connection string that is used by Prisma ORM. We recommend this in order to keep your database URL out of version control.
+
+If you haven't installed `dotenv` yet, you can install it as follows:
+
+```terminal
+npm install dotenv
+```
+
+Then update your ESLint config as follows:
+
+```js file=.eslintrc.js highlight=1,6-9,16;add
+//add-next-line
+require('dotenv').config()
+
+/** @type {import('eslint').Linter.Config} */
+module.exports = {
+ plugins: ['@ts-safeql/eslint-plugin'],
+ //add-start
+ // exclude `parserOptions` if you are not using TypeScript
+ parserOptions: {
+ project: './tsconfig.json',
+ },
+ //add-end
+ rules: {
+ '@ts-safeql/check-sql': [
+ 'error',
+ {
+ connections: [
+ {
+ //add-next-line
+ connectionUrl: process.env.DATABASE_URL,
+ // The migrations path:
+ migrationsDir: './prisma/migrations',
+ targets: [
+ // what you would like SafeQL to lint. This makes `prisma.$queryRaw` and `prisma.$executeRaw`
+ // commands linted
+ { tag: 'prisma.+($queryRaw|$executeRaw)', transform: '{type}[]' },
+ ],
+ },
+ ],
+ },
+ ],
+ },
+}
+```
+
+SafeQL is now fully configured to help you write better raw SQL using Prisma Client.
+
+## 4. Creating extensions to make raw SQL queries type-safe
+
+In this section, we'll create two [`model`](/orm/prisma-client/client-extensions/model) extensions with custom queries to be able to work conveniently with the `PointOfInterest` model:
+
+1. A `create` query that allows us to create new `PointOfInterest` records in the database
+1. A `findClosestPoints` query that returns the `PointOfInterest` records that are closest to a given coordinate
+
+### 4.1. Adding an extension to create `PointOfInterest` records
+
+The `PointOfInterest` model in the Prisma schema uses an `Unsupported` type. As a consequence, the generated `PointOfInterest` type in Prisma Client can't be used to carry values for latitude and longitude.
+
+We will resolve this by defining two custom types that better represent our model in TypeScript:
+
+```ts
+type MyPoint = {
+ latitude: number
+ longitude: number
+}
+
+type MyPointOfInterest = {
+ name: string
+ location: MyPoint
+}
+```
+
+Next, you can add a `create` query to the `pointOfInterest` property of your Prisma Client:
+
+```ts highlight=19;normal
+const prisma = new PrismaClient().$extends({
+ model: {
+ pointOfInterest: {
+ async create(data: {
+ name: string
+ latitude: number
+ longitude: number
+ }) {
+ // Create an object using the custom types from above
+ const poi: MyPointOfInterest = {
+ name: data.name,
+ location: {
+ latitude: data.latitude,
+ longitude: data.longitude,
+ },
+ }
+
+ // Insert the object into the database
+ const point = `POINT(${poi.location.longitude} ${poi.location.latitude})`
+ await prisma.$queryRaw`
+ INSERT INTO "PointOfInterest" (name, location) VALUES (${poi.name}, ST_GeomFromText(${point}, 4326));
+ `
+
+ // Return the object
+ return poi
+ },
+ },
+ },
+})
+```
+
+Notice that the SQL in the line that's highlighted in the code snippet gets checked by SafeQL! For example, if you change the name of the table from `"PointOfInterest"` to `"PointOfInterest2"`, the following error appears:
+
+```
+error Invalid Query: relation "PointOfInterest2" does not exist @ts-safeql/check-sql
+```
+
+This also works with the column names `name` and `location`.
+
+You can now create new `PointOfInterest` records in your code as follows:
+
+```ts
+const poi = await prisma.pointOfInterest.create({
+ name: 'Berlin',
+ latitude: 52.52,
+ longitude: 13.405,
+})
+```
+
+### 4.2. Adding an extension to query for closest to `PointOfInterest` records
+
+Now let's make a Prisma Client extension in order to query this model. We will be making an extension that finds the closest points of interest to a given longitude and latitude.
+
+```ts
+const prisma = new PrismaClient().$extends({
+ model: {
+ pointOfInterest: {
+ async create(data: {
+ name: string
+ latitude: number
+ longitude: number
+ }) {
+ // ... same code as before
+ },
+
+ async findClosestPoints(latitude: number, longitude: number) {
+ // Query for clostest points of interests
+ const result = await prisma.$queryRaw<
+ {
+ id: number | null
+ name: string | null
+ st_x: number | null
+ st_y: number | null
+ }[]
+ >`SELECT id, name, ST_X(location::geometry), ST_Y(location::geometry)
+ FROM "PointOfInterest"
+ ORDER BY ST_DistanceSphere(location::geometry, ST_MakePoint(${longitude}, ${latitude})) DESC`
+
+ // Transform to our custom type
+ const pois: MyPointOfInterest[] = result.map((data) => {
+ return {
+ name: data.name,
+ location: {
+ latitude: data.st_x || 0,
+ longitude: data.st_y || 0,
+ },
+ }
+ })
+
+ // Return data
+ return pois
+ },
+ },
+ },
+})
+```
+
+Now, you can use our Prisma Client as normal to find close points of interest to a given longitude and latitude using the custom method created on the `PointOfInterest` model.
+
+```ts
+const closestPointOfInterest = await prisma.pointOfInterest.findClosestPoints(
+ 53.5488,
+ 9.9872
+)
+```
+
+Similar to before, we again have the benefit of SafeQL to add extra type safety to our raw queries. For example, if we removed the cast to `geometry` for `location` by changing `location::geometry` to just `location`, we would get linting errors in the `ST_X`, `ST_Y` or `ST_DistanceSphere` functions respectively.
+
+```terminal
+error Invalid Query: function st_distancesphere(geography, geometry) does not exist @ts-safeql/check-sql
+```
+
+## Conclusion
+
+While you may sometimes need to drop down to raw SQL when using Prisma ORM, you can use various techniques to make the experience of writing raw SQL queries with Prisma ORM better.
+
+In this article, you have used SafeQL and Prisma Client extensions to create custom, type-safe Prisma Client queries to abstract PostGIS operations which are currently not natively supported in Prisma ORM.
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/150-using-raw-sql/index.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/150-using-raw-sql/index.mdx
new file mode 100644
index 0000000000..b598c28e4c
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/150-using-raw-sql/index.mdx
@@ -0,0 +1,71 @@
+---
+title: 'Write your own SQL'
+metaTitle: 'Write Your Own SQL in Prisma Client'
+metaDescription: 'Learn how to use raw SQL queries in Prisma Client.'
+---
+
+While the Prisma Client API aims to make all your database queries intuitive, type-safe, and convenient, there may still be situations where raw SQL is the best tool for the job.
+
+This can happen for various reasons, such as the need to optimize the performance of a specific query or because your data requirements can't be fully expressed by Prisma Client's query API.
+
+In most cases, [TypedSQL](#writing-type-safe-queries-with-prisma-client-and-typedsql) allows you to express your query in SQL while still benefiting from Prisma Client's excellent user experience. However, since TypedSQL is statically typed, it may not handle certain scenarios, such as dynamically generated `WHERE` clauses. In these cases, you will need to use [`$queryRaw`](/orm/prisma-client/using-raw-sql/raw-queries#queryraw) or [`$executeRaw`](/orm/prisma-client/using-raw-sql/raw-queries#executeraw), or their unsafe counterparts.
+
+## Writing type-safe queries with Prisma Client and TypedSQL
+
+:::info
+
+TypedSQL is available in Prisma ORM 5.19.0 and later. For raw database access in previous versions, see [our raw queries documentation](/orm/prisma-client/using-raw-sql/raw-queries).
+
+:::
+
+### What is TypedSQL?
+
+TypedSQL is a new feature of Prisma ORM that allows you to write your queries in `.sql` files while still enjoying the great developer experience of Prisma Client. You can write the code you're comfortable with and benefit from fully-typed inputs and outputs.
+
+With TypedSQL, you can:
+
+1. Write complex SQL queries using familiar syntax
+2. Benefit from full IDE support and syntax highlighting for SQL
+3. Import your SQL queries as fully typed functions in your TypeScript code
+4. Maintain the flexibility of raw SQL with the safety of Prisma's type system
+
+TypedSQL is particularly useful for:
+
+- Complex reporting queries that are difficult to express using Prisma's query API
+- Performance-critical operations that require fine-tuned SQL
+- Leveraging database-specific features not yet supported in Prisma's API
+
+By using TypedSQL, you can write efficient, type-safe database queries without sacrificing the power and flexibility of raw SQL. This feature allows you to seamlessly integrate custom SQL queries into your Prisma-powered applications, ensuring type safety and improving developer productivity.
+
+For a detailed guide on how to get started with TypedSQL, including setup instructions and usage examples, please refer to our [TypedSQL documentation](/orm/prisma-client/using-raw-sql/typedsql).
+
+## Raw queries
+
+Prior to version 5.19.0, Prisma Client only supported raw SQL queries that were not type-safe and required manual mapping of the query result to the desired type.
+
+While not as ergonomic as [TypedSQL](#writing-type-safe-queries-with-prisma-client-and-typedsql), these queries are still supported and are useful when TypedSQL queries are not possible either due to features not yet supported in TypedSQL or when the query is dynamically generated.
+
+### Alternative approaches to raw SQL queries in relational databases
+
+Prisma ORM supports four methods to execute raw SQL queries in relational databases:
+
+- [`$queryRaw`](/orm/prisma-client/using-raw-sql/raw-queries#queryraw)
+- [`$executeRaw`](/orm/prisma-client/using-raw-sql/raw-queries#executeraw)
+- [`$queryRawUnsafe`](/orm/prisma-client/using-raw-sql/raw-queries#queryrawunsafe)
+- [`$executeRawUnsafe`](/orm/prisma-client/using-raw-sql/raw-queries#executerawunsafe)
+
+These commands are similar to using TypedSQL, but they are not type-safe and are written as strings in your code rather than in dedicated `.sql` files.
+
+### Alternative approaches to raw queries in document databases
+
+For MongoDB, Prisma ORM supports three methods to execute raw queries:
+
+- [`$runCommandRaw`](/orm/prisma-client/using-raw-sql/raw-queries#runcommandraw)
+- [`.findRaw`](/orm/prisma-client/using-raw-sql/raw-queries#findraw)
+- [`.aggregateRaw`](/orm/prisma-client/using-raw-sql/raw-queries#aggregateraw)
+
+These methods allow you to execute raw MongoDB commands and queries, providing flexibility when you need to use MongoDB-specific features or optimizations.
+
+`$runCommandRaw` is used to execute database commands, `.findRaw` is used to find documents that match a filter, and `.aggregateRaw` is used for aggregation operations. All three methods are available from Prisma version 3.9.0 and later.
+
+Similar to raw queries in relational databases, these methods are not type-safe and require manual handling of the query results.
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/200-special-fields-and-types/057-composite-types.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/200-special-fields-and-types/057-composite-types.mdx
new file mode 100644
index 0000000000..d41ba8a6e0
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/200-special-fields-and-types/057-composite-types.mdx
@@ -0,0 +1,799 @@
+---
+title: 'Composite types'
+metaTitle: 'Composite types'
+metaDescription: 'Composite types'
+tocDepth: 3
+---
+
+
+
+
+
+Composite types are only available with MongoDB.
+
+
+
+[Composite types](/orm/prisma-schema/data-model/models#defining-composite-types), known as [embedded documents](https://www.mongodb.com/docs/manual/data-modeling/#embedded-data) in MongoDB, allow you to embed records within other records.
+
+We made composite types [Generally Available](/orm/more/releases#generally-available-ga) in v3.12.0. They were previously available in [Preview](/orm/reference/preview-features) from v3.10.0.
+
+This page explains how to:
+
+- [find](#finding-records-that-contain-composite-types-with-find-and-findmany) records that contain composite types using `findFirst` and `findMany`
+- [create](#creating-records-with-composite-types-using-create-and-createmany) new records with composite types using `create` and `createMany`
+- [update](#changing-composite-types-within-update-and-updatemany) composite types within existing records using `update` and `updateMany`
+- [delete](#deleting-records-that-contain-composite-types-with-delete-and-deletemany) records with composite types using `delete` and `deleteMany`
+
+
+
+## Example schema
+
+We’ll use this schema for the examples that follow:
+
+```prisma file=schema.prisma showLineNumbers
+generator client {
+ provider = "prisma-client-js"
+}
+
+datasource db {
+ provider = "mongodb"
+ url = env("DATABASE_URL")
+}
+
+model Product {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ name String @unique
+ price Float
+ colors Color[]
+ sizes Size[]
+ photos Photo[]
+ orders Order[]
+}
+
+model Order {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ product Product @relation(fields: [productId], references: [id])
+ color Color
+ size Size
+ shippingAddress Address
+ billingAddress Address?
+ productId String @db.ObjectId
+}
+
+enum Color {
+ Red
+ Green
+ Blue
+}
+
+enum Size {
+ Small
+ Medium
+ Large
+ XLarge
+}
+
+type Photo {
+ height Int @default(200)
+ width Int @default(100)
+ url String
+}
+
+type Address {
+ street String
+ city String
+ zip String
+}
+```
+
+In this schema, the `Product` model has a `Photo[]` composite type, and the `Order` model has two composite `Address` types. The `shippingAddress` is required, but the `billingAddress` is optional.
+
+## Considerations when using composite types
+
+There are currently some limitations when using composite types in Prisma Client:
+
+- [`findUnique()`](/6.0/orm/reference/prisma-client-reference#findunique) can't filter on composite types
+- [`aggregate`](/orm/prisma-client/queries/aggregation-grouping-summarizing#aggregate), [`groupBy()`](/orm/prisma-client/queries/aggregation-grouping-summarizing#group-by), [`count`](/orm/prisma-client/queries/aggregation-grouping-summarizing#count) don’t support composite operations
+
+## Default values for required fields on composite types
+
+From version 4.0.0, if you carry out a database read on a composite type when all of the following conditions are true, then Prisma Client inserts the default value into the result.
+
+Conditions:
+
+- A field on the composite type is [required](/orm/prisma-schema/data-model/models#optional-and-mandatory-fields), and
+- this field has a [default value](/orm/prisma-schema/data-model/models#defining-a-default-value), and
+- this field is not present in the returned document or documents.
+
+Note:
+
+- This is the same behavior as with [model fields](/orm/reference/prisma-schema-reference#model-field-scalar-types).
+- On read operations, Prisma Client inserts the default value into the result, but does not insert the default value into the database.
+
+In our example schema, suppose that you add a required field to `photo`. This field, `bitDepth`, has a default value:
+
+```prisma file=schema.prisma highlight=4;add
+...
+type Photo {
+ ...
+ //add-next-line
+ bitDepth Int @default(8)
+}
+
+...
+```
+
+Suppose that you then run `npx prisma db push` to [update your database](/orm/reference/prisma-cli-reference#db-push) and regenerate your Prisma Client with `npx prisma generate`. Then, you run the following application code:
+
+```ts
+console.dir(await prisma.product.findMany({}), { depth: Infinity })
+```
+
+The `bitDepth` field has no content because you have only just added this field, so the query returns the default value of `8`.
+
+** Earlier versions **
+
+Before version 4.0.0, Prisma ORM threw a P2032 error as follows:
+
+```
+Error converting field "bitDepth" of expected non-nullable
+type "int", found incompatible value of "null".
+```
+
+## Finding records that contain composite types with `find` and `findMany`
+
+Records can be filtered by a composite type within the `where` operation.
+
+The following section describes the operations available for filtering by a single type or multiple types, and gives examples of each.
+
+### Filtering for one composite type
+
+Use the `is`, `equals`, `isNot` and `isSet` operations to change a single composite type:
+
+- `is`: Filter results by matching composite types. Requires one or more fields to be present _(e.g. Filter orders by the street name on the shipping address)_
+- `equals`: Filter results by matching composite types. Requires all fields to be present. _(e.g. Filter orders by the full shipping address)_
+- `isNot`: Filter results by non-matching composite types
+- `isSet` : Filter optional fields to include only results that have been set (either set to a value, or explicitly set to `null`). Setting this filter to `true` will exclude `undefined` results that are not set at all.
+
+For example, use `is` to filter for orders with a street name of `'555 Candy Cane Lane'`:
+
+```ts
+const orders = await prisma.order.findMany({
+ where: {
+ shippingAddress: {
+ is: {
+ street: '555 Candy Cane Lane',
+ },
+ },
+ },
+})
+```
+
+Use `equals` to filter for orders which match on all fields in the shipping address:
+
+```ts
+const orders = await prisma.order.findMany({
+ where: {
+ shippingAddress: {
+ equals: {
+ street: '555 Candy Cane Lane',
+ city: 'Wonderland',
+ zip: '52337',
+ },
+ },
+ },
+})
+```
+
+You can also use a shorthand notation for this query, where you leave out the `equals`:
+
+```ts
+const orders = await prisma.order.findMany({
+ where: {
+ shippingAddress: {
+ street: '555 Candy Cane Lane',
+ city: 'Wonderland',
+ zip: '52337',
+ },
+ },
+})
+```
+
+Use `isNot` to filter for orders that do not have a `zip` code of `'52337'`:
+
+```ts
+const orders = await prisma.order.findMany({
+ where: {
+ shippingAddress: {
+ isNot: {
+ zip: '52337',
+ },
+ },
+ },
+})
+```
+
+Use `isSet` to filter for orders where the optional `billingAddress` has been set (either to a value or to `null`):
+
+```ts
+const orders = await prisma.order.findMany({
+ where: {
+ billingAddress: {
+ isSet: true,
+ },
+ },
+})
+```
+
+### Filtering for many composite types
+
+Use the `equals`, `isEmpty`, `every`, `some` and `none` operations to filter for multiple composite types:
+
+- `equals`: Checks exact equality of the list
+- `isEmpty`: Checks if the list is empty
+- `every`: Every item in the list must match the condition
+- `some`: One or more of the items in the list must match the condition
+- `none`: None of the items in the list can match the condition
+- `isSet` : Filter optional fields to include only results that have been set (either set to a value, or explicitly set to `null`). Setting this filter to `true` will exclude `undefined` results that are not set at all.
+
+For example, you can use `equals` to find products with a specific list of photos (all `url`, `height` and `width` fields must match):
+
+```ts
+const product = prisma.product.findMany({
+ where: {
+ photos: {
+ equals: [
+ {
+ url: '1.jpg',
+ height: 200,
+ width: 100,
+ },
+ {
+ url: '2.jpg',
+ height: 200,
+ width: 100,
+ },
+ ],
+ },
+ },
+})
+```
+
+You can also use a shorthand notation for this query, where you leave out the `equals` and specify just the fields that you want to filter for:
+
+```ts
+const product = prisma.product.findMany({
+ where: {
+ photos: [
+ {
+ url: '1.jpg',
+ height: 200,
+ width: 100,
+ },
+ {
+ url: '2.jpg',
+ height: 200,
+ width: 100,
+ },
+ ],
+ },
+})
+```
+
+Use `isEmpty` to filter for products with no photos:
+
+```ts
+const product = prisma.product.findMany({
+ where: {
+ photos: {
+ isEmpty: true,
+ },
+ },
+})
+```
+
+Use `some` to filter for products where one or more photos has a `url` of `"2.jpg"`:
+
+```ts
+const product = prisma.product.findFirst({
+ where: {
+ photos: {
+ some: {
+ url: '2.jpg',
+ },
+ },
+ },
+})
+```
+
+Use `none` to filter for products where no photos have a `url` of `"2.jpg"`:
+
+```ts
+const product = prisma.product.findFirst({
+ where: {
+ photos: {
+ none: {
+ url: '2.jpg',
+ },
+ },
+ },
+})
+```
+
+## Creating records with composite types using `create` and `createMany`
+
+
+
+When you create a record with a composite type that has a unique restraint, note that MongoDB does not enforce unique values inside a record. [Learn more](#duplicate-values-in-unique-fields-of-composite-types).
+
+
+
+Composite types can be created within a `create` or `createMany` method using the `set` operation. For example, you can use `set` within `create` to create an `Address` composite type inside an `Order`:
+
+```ts
+const order = await prisma.order.create({
+ data: {
+ // Normal relation
+ product: { connect: { id: 'some-object-id' } },
+ color: 'Red',
+ size: 'Large',
+ // Composite type
+ shippingAddress: {
+ set: {
+ street: '1084 Candycane Lane',
+ city: 'Silverlake',
+ zip: '84323',
+ },
+ },
+ },
+})
+```
+
+You can also use a shorthand notation where you leave out the `set` and specify just the fields that you want to create:
+
+```ts
+const order = await prisma.order.create({
+ data: {
+ // Normal relation
+ product: { connect: { id: 'some-object-id' } },
+ color: 'Red',
+ size: 'Large',
+ // Composite type
+ shippingAddress: {
+ street: '1084 Candycane Lane',
+ city: 'Silverlake',
+ zip: '84323',
+ },
+ },
+})
+```
+
+For an optional type, like the `billingAddress`, you can also set the value to `null`:
+
+```ts
+const order = await prisma.order.create({
+ data: {
+ // Normal relation
+ product: { connect: { id: 'some-object-id' } },
+ color: 'Red',
+ size: 'Large',
+ // Composite type
+ shippingAddress: {
+ street: '1084 Candycane Lane',
+ city: 'Silverlake',
+ zip: '84323',
+ },
+ // Embedded optional type, set to null
+ billingAddress: {
+ set: null,
+ },
+ },
+})
+```
+
+To model the case where an `product` contains a list of multiple `photos`, you can `set` multiple composite types at once:
+
+```ts
+const product = await prisma.product.create({
+ data: {
+ name: 'Forest Runners',
+ price: 59.99,
+ colors: ['Red', 'Green'],
+ sizes: ['Small', 'Medium', 'Large'],
+ // New composite type
+ photos: {
+ set: [
+ { height: 100, width: 200, url: '1.jpg' },
+ { height: 100, width: 200, url: '2.jpg' },
+ ],
+ },
+ },
+})
+```
+
+You can also use a shorthand notation where you leave out the `set` and specify just the fields that you want to create:
+
+```ts
+const product = await prisma.product.create({
+ data: {
+ name: 'Forest Runners',
+ price: 59.99,
+ // Scalar lists that we already support
+ colors: ['Red', 'Green'],
+ sizes: ['Small', 'Medium', 'Large'],
+ // New composite type
+ photos: [
+ { height: 100, width: 200, url: '1.jpg' },
+ { height: 100, width: 200, url: '2.jpg' },
+ ],
+ },
+})
+```
+
+These operations also work within the `createMany` method. For example, you can create multiple `product`s which each contain a list of `photos`:
+
+```ts
+const product = await prisma.product.createMany({
+ data: [
+ {
+ name: 'Forest Runners',
+ price: 59.99,
+ colors: ['Red', 'Green'],
+ sizes: ['Small', 'Medium', 'Large'],
+ photos: [
+ { height: 100, width: 200, url: '1.jpg' },
+ { height: 100, width: 200, url: '2.jpg' },
+ ],
+ },
+ {
+ name: 'Alpine Blazers',
+ price: 85.99,
+ colors: ['Blue', 'Red'],
+ sizes: ['Large', 'XLarge'],
+ photos: [
+ { height: 100, width: 200, url: '1.jpg' },
+ { height: 150, width: 200, url: '4.jpg' },
+ { height: 200, width: 200, url: '5.jpg' },
+ ],
+ },
+ ],
+})
+```
+
+## Changing composite types within `update` and `updateMany`
+
+
+
+When you update a record with a composite type that has a unique restraint, note that MongoDB does not enforce unique values inside a record. [Learn more](#duplicate-values-in-unique-fields-of-composite-types).
+
+
+
+Composite types can be set, updated or removed within an `update` or `updateMany` method. The following section describes the operations available for updating a single type or multiple types at once, and gives examples of each.
+
+### Changing a single composite type
+
+Use the `set`, `unset` `update` and `upsert` operations to change a single composite type:
+
+- Use `set` to set a composite type, overriding any existing value
+- Use `unset` to unset a composite type. Unlike `set: null`, `unset` removes the field entirely
+- Use `update` to update a composite type
+- Use `upsert` to `update` an existing composite type if it exists, and otherwise `set` the composite type
+
+For example, use `update` to update a required `shippingAddress` with an `Address` composite type inside an `Order`:
+
+```ts
+const order = await prisma.order.update({
+ where: {
+ id: 'some-object-id',
+ },
+ data: {
+ shippingAddress: {
+ // Update just the zip field
+ update: {
+ zip: '41232',
+ },
+ },
+ },
+})
+```
+
+For an optional embedded type, like the `billingAddress`, use `upsert` to create a new record if it does not exist, and update the record if it does:
+
+```ts
+const order = await prisma.order.update({
+ where: {
+ id: 'some-object-id',
+ },
+ data: {
+ billingAddress: {
+ // Create the address if it doesn't exist,
+ // otherwise update it
+ upsert: {
+ set: {
+ street: '1084 Candycane Lane',
+ city: 'Silverlake',
+ zip: '84323',
+ },
+ update: {
+ zip: '84323',
+ },
+ },
+ },
+ },
+})
+```
+
+You can also use the `unset` operation to remove an optional embedded type. The following example uses `unset` to remove the `billingAddress` from an `Order`:
+
+```ts
+const order = await prisma.order.update({
+ where: {
+ id: 'some-object-id',
+ },
+ data: {
+ billingAddress: {
+ // Unset the billing address
+ // Removes "billingAddress" field from order
+ unset: true,
+ },
+ },
+})
+```
+
+You can use [filters](/orm/prisma-client/special-fields-and-types/composite-types#finding-records-that-contain-composite-types-with-find-and-findmany) within `updateMany` to update all records that match a composite type. The following example uses the `is` filter to match the street name from a shipping address on a list of orders:
+
+```ts
+const orders = await prisma.order.updateMany({
+ where: {
+ shippingAddress: {
+ is: {
+ street: '555 Candy Cane Lane',
+ },
+ },
+ },
+ data: {
+ shippingAddress: {
+ update: {
+ street: '111 Candy Cane Drive',
+ },
+ },
+ },
+})
+```
+
+### Changing multiple composite types
+
+Use the `set`, `push`, `updateMany` and `deleteMany` operations to change a list of composite types:
+
+- `set`: Set an embedded list of composite types, overriding any existing list
+- `push`: Push values to the end of an embedded list of composite types
+- `updateMany`: Update many composite types at once
+- `deleteMany`: Delete many composite types at once
+
+For example, use `push` to add a new photo to the `photos` list:
+
+```ts
+const product = prisma.product.update({
+ where: {
+ id: '62de6d328a65d8fffdae2c18',
+ },
+ data: {
+ photos: {
+ // Push a photo to the end of the photos list
+ push: [{ height: 100, width: 200, url: '1.jpg' }],
+ },
+ },
+})
+```
+
+Use `updateMany` to update photos with a `url` of `1.jpg` or `2.png`:
+
+```ts
+const product = prisma.product.update({
+ where: {
+ id: '62de6d328a65d8fffdae2c18',
+ },
+ data: {
+ photos: {
+ updateMany: {
+ where: {
+ url: '1.jpg',
+ },
+ data: {
+ url: '2.png',
+ },
+ },
+ },
+ },
+})
+```
+
+The following example uses `deleteMany` to delete all photos with a `height` of 100:
+
+```ts
+const product = prisma.product.update({
+ where: {
+ id: '62de6d328a65d8fffdae2c18',
+ },
+ data: {
+ photos: {
+ deleteMany: {
+ where: {
+ height: 100,
+ },
+ },
+ },
+ },
+})
+```
+
+## Upserting composite types with `upsert`
+
+
+
+When you create or update the values in a composite type that has a unique restraint, note that MongoDB does not enforce unique values inside a record. [Learn more](#duplicate-values-in-unique-fields-of-composite-types).
+
+
+
+To create or update a composite type, use the `upsert` method. You can use the same composite operations as the `create` and `update` methods above.
+
+For example, use `upsert` to either create a new product or add a photo to an existing product:
+
+```ts
+const product = await prisma.product.upsert({
+ where: {
+ name: 'Forest Runners',
+ },
+ create: {
+ name: 'Forest Runners',
+ price: 59.99,
+ colors: ['Red', 'Green'],
+ sizes: ['Small', 'Medium', 'Large'],
+ photos: [
+ { height: 100, width: 200, url: '1.jpg' },
+ { height: 100, width: 200, url: '2.jpg' },
+ ],
+ },
+ update: {
+ photos: {
+ push: { height: 300, width: 400, url: '3.jpg' },
+ },
+ },
+})
+```
+
+## Deleting records that contain composite types with `delete` and `deleteMany`
+
+To remove records which embed a composite type, use the `delete` or `deleteMany` methods. This will also remove the embedded composite type.
+
+For example, use `deleteMany` to delete all products with a `size` of `"Small"`. This will also delete any embedded `photos`.
+
+```ts
+const deleteProduct = await prisma.product.deleteMany({
+ where: {
+ sizes: {
+ equals: 'Small',
+ },
+ },
+})
+```
+
+You can also use [filters](/orm/prisma-client/special-fields-and-types/composite-types#finding-records-that-contain-composite-types-with-find-and-findmany) to delete records that match a composite type. The example below uses the `some` filter to delete products that contain a certain photo:
+
+```ts
+const product = await prisma.product.deleteMany({
+ where: {
+ photos: {
+ some: {
+ url: '2.jpg',
+ },
+ },
+ },
+})
+```
+
+## Ordering composite types
+
+You can use the `orderBy` operation to sort results in ascending or descending order.
+
+For example, the following command finds all orders and orders them by the city name in the shipping address, in ascending order:
+
+```ts
+const orders = await prisma.order.findMany({
+ orderBy: {
+ shippingAddress: {
+ city: 'asc',
+ },
+ },
+})
+```
+
+## Duplicate values in unique fields of composite types
+
+Be careful when you carry out any of the following operations on a record with a composite type that has a unique constraint. In this situation, MongoDB does not enforce unique values inside a record.
+
+- When you create the record
+- When you add data to the record
+- When you update data in the record
+
+If your schema has a composite type with a `@@unique` constraint, MongoDB prevents you from storing the same value for the constrained value in two or more of the records that contain this composite type. However, MongoDB does does not prevent you from storing multiple copies of the same field value in a single record.
+
+Note that you can [use Prisma ORM relations to work around this issue](#use-prisma-orm-relations-to-enforce-unique-values-in-a-record).
+
+For example, in the following schema, `MailBox` has a composite type, `addresses`, which has a `@@unique` constraint on the `email` field.
+
+```prisma
+type Address {
+ email String
+}
+
+model MailBox {
+ name String
+ addresses Address[]
+
+ @@unique([addresses.email])
+}
+```
+
+The following code creates a record with two identical values in `address`. MongoDB does not throw an error in this situation, and it stores `alice@prisma.io` in `addresses` twice.
+
+```ts
+await prisma.MailBox.createMany({
+ data: [
+ {
+ name: 'Alice',
+ addresses: {
+ set: [
+ {
+ address: 'alice@prisma.io', // Not unique
+ },
+ {
+ address: 'alice@prisma.io', // Not unique
+ },
+ ],
+ },
+ },
+ ],
+})
+```
+
+Note: MongoDB throws an error if you try to store the same value in two separate records. In our example above, if you try to store the email address `alice@prisma.io` for the user Alice and for the user Bob, MongoDB does not store the data and throws an error.
+
+### Use Prisma ORM relations to enforce unique values in a record
+
+In the example above, MongoDB did not enforce the unique constraint on a nested address name. However, you can model your data differently to enforce unique values in a record. To do so, use Prisma ORM [relations](/orm/prisma-schema/data-model/relations) to turn the composite type into a collection. Set a relationship to this collection and place a unique constraint on the field that you want to be unique.
+
+In the following example, MongoDB enforces unique values in a record. There is a relation between `Mailbox` and the `Address` model. Also, the `name` field in the `Address` model has a unique constraint.
+
+```prisma
+model Address {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ name String
+ mailbox Mailbox? @relation(fields: [mailboxId], references: [id])
+ mailboxId String? @db.ObjectId
+
+ @@unique([name])
+}
+
+model Mailbox {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ name String
+ addresses Address[] @relation
+}
+```
+
+```ts
+await prisma.MailBox.create({
+ data: {
+ name: 'Alice',
+ addresses: {
+ create: [
+ { name: 'alice@prisma.io' }, // Not unique
+ { name: 'alice@prisma.io' }, // Not unique
+ ],
+ },
+ },
+})
+```
+
+If you run the above code, MongoDB enforces the unique constraint. It does not allow your application to add two addresses with the name `alice@prisma.io`.
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/200-special-fields-and-types/080-null-and-undefined.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/200-special-fields-and-types/080-null-and-undefined.mdx
new file mode 100644
index 0000000000..79f29253a9
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/200-special-fields-and-types/080-null-and-undefined.mdx
@@ -0,0 +1,477 @@
+---
+title: 'Null and undefined'
+metaTitle: 'Null and undefined in Prisma Client (Reference)'
+metaDescription: 'How Prisma Client handles null and undefined'
+preview: false
+---
+
+:::warning
+
+In Prisma ORM, if `undefined` is passed as a value, it is not included in the generated query. This behavior can lead to unexpected results and data loss. In order to prevent this, we strongly recommend updating to version 5.20.0 or later to take advantage of the new `strictUndefinedChecks` Preview feature, described below.
+
+For documentation on the current behavior (without the `strictUndefinedChecks` Preview feature) see [current behavior](#current-behavior).
+
+:::
+
+## Strict undefined checks (Preview feature)
+
+Prisma ORM 5.20.0 introduces a new Preview feature called `strictUndefinedChecks`. This feature changes how Prisma Client handles `undefined` values, offering better protection against accidental data loss or unintended query behavior.
+
+### Enabling strict undefined checks
+
+To enable this feature, add the following to your Prisma schema:
+
+```prisma
+generator client {
+ provider = "prisma-client-js"
+ previewFeatures = ["strictUndefinedChecks"]
+}
+```
+
+### Using strict undefined checks
+
+When this feature is enabled:
+
+1. Explicitly setting a field to `undefined` in a query will cause a runtime error.
+2. To skip a field in a query, use the new `Prisma.skip` symbol instead of `undefined`.
+
+Example usage:
+
+```typescript
+// This will throw an error
+prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: undefined // Error: Cannot explicitly use undefined here
+ }
+})
+
+// Use `Prisma.skip` (a symbol provided by Prisma) to omit a field
+prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: Prisma.skip // This field will be omitted from the query
+ }
+})
+```
+
+This change helps prevent accidental deletions or updates, such as:
+
+```typescript
+// Before: This would delete all users
+prisma.user.deleteMany({
+ where: {
+ id: undefined
+ }
+})
+
+// After: This will throw an error
+Invalid \`prisma.user.deleteMany()\` invocation in
+/client/tests/functional/strictUndefinedChecks/test.ts:0:0
+ XX })
+ XX
+ XX test('throws on undefined input field', async () => {
+→ XX const result = prisma.user.deleteMany({
+ where: {
+ id: undefined
+ ~~~~~~~~~
+ }
+ })
+Invalid value for argument \`where\`: explicitly \`undefined\` values are not allowed."
+```
+
+### Migration path
+
+To migrate existing code:
+
+```typescript
+// Before
+let optionalEmail: string | undefined
+
+prisma.user.create({
+ data: {
+ name: 'Alice',
+ email: optionalEmail
+ }
+})
+
+// After
+prisma.user.create({
+ data: {
+ name: 'Alice',
+ // highlight-next-line
+ email: optionalEmail ?? Prisma.skip
+ }
+})
+```
+
+### `exactOptionalPropertyTypes`
+
+In addition to `strictUndefinedChecks`, we also recommend enabling the TypeScript compiler option `exactOptionalPropertyTypes`. This option enforces that optional properties must match exactly, which can help catch potential issues with `undefined` values in your code. While `strictUndefinedChecks` will raise runtime errors for invalid `undefined` usage, `exactOptionalPropertyTypes` will catch these issues during the build process.
+
+Learn more about `exactOptionalPropertyTypes` in the [TypeScript documentation](https://www.typescriptlang.org/tsconfig/#exactOptionalPropertyTypes).
+
+### Feedback
+
+As always, we welcome your feedback on this feature. Please share your thoughts and suggestions in the [GitHub discussion for this Preview feature](https://github.com/prisma/prisma/discussions/25271).
+
+## current behavior
+
+Prisma Client differentiates between `null` and `undefined`:
+
+- `null` is a **value**
+- `undefined` means **do nothing**
+
+:::info
+
+This is particularly important to account for in [a **Prisma ORM with GraphQL context**, where `null` and `undefined` are interchangeable](#null-and-undefined-in-a-graphql-resolver).
+
+:::
+
+The data below represents a `User` table. This set of data will be used in all of the examples below:
+
+| id | name | email |
+| --- | ------- | ----------------- |
+| 1 | Nikolas | nikolas@gmail.com |
+| 2 | Martin | martin@gmail.com |
+| 3 | _empty_ | sabin@gmail.com |
+| 4 | Tyler | tyler@gmail.com |
+
+### `null` and `undefined` in queries that affect _many_ records
+
+This section will cover how `undefined` and `null` values affect the behavior of queries that interact with or create multiple records in a database.
+
+#### Null
+
+Consider the following Prisma Client query which searches for all users whose `name` value matches the provided `null` value:
+
+
+
+
+
+```ts
+const users = await prisma.user.findMany({
+ where: {
+ name: null,
+ },
+})
+```
+
+
+
+
+
+```json
+[
+ {
+ "id": 3,
+ "name": null,
+ "email": "sabin@gmail.com"
+ }
+]
+```
+
+
+
+
+
+Because `null` was provided as the filter for the `name` column, Prisma Client will generate a query that searches for all records in the `User` table whose `name` column is _empty_.
+
+#### Undefined
+
+Now consider the scenario where you run the same query with `undefined` as the filter value on the `name` column:
+
+
+
+
+
+```ts
+const users = await prisma.user.findMany({
+ where: {
+ name: undefined,
+ },
+})
+```
+
+
+
+
+```json
+[
+ {
+ "id": 1,
+ "name": "Nikolas",
+ "email": "nikolas@gmail.com"
+ },
+ {
+ "id": 2,
+ "name": "Martin",
+ "email": "martin@gmail.com"
+ },
+ {
+ "id": 3,
+ "name": null,
+ "email": "sabin@gmail.com"
+ },
+ {
+ "id": 4,
+ "name": "Tyler",
+ "email": "tyler@gmail.com"
+ }
+]
+```
+
+
+
+
+Using `undefined` as a value in a filter essentially tells Prisma Client you have decided _not to define a filter_ for that column.
+
+An equivalent way to write the above query would be:
+
+```ts
+const users = await prisma.user.findMany()
+```
+
+This query will select every row from the `User` table.
+
+
+
+**Note**: Using `undefined` as the value of any key in a Prisma Client query's parameter object will cause Prisma ORM to act as if that key was not provided at all.
+
+
+
+Although this section's examples focused on the `findMany` function, the same concepts apply to any function that can affect multiple records, such as `updateMany` and `deleteMany`.
+
+### `null` and `undefined` in queries that affect _one_ record
+
+This section will cover how `undefined` and `null` values affect the behavior of queries that interact with or create a single record in a database.
+
+
+
+**Note**: `null` is not a valid filter value in a `findUnique()` query.
+
+
+
+The query behavior when using `null` and `undefined` in the filter criteria of a query that affects a single record is very similar to the behaviors described in the previous section.
+
+#### Null
+
+Consider the following query where `null` is used to filter the `name` column:
+
+
+
+
+
+```ts
+const user = await prisma.user.findFirst({
+ where: {
+ name: null,
+ },
+})
+```
+
+
+
+
+
+```json
+[
+ {
+ "id": 3,
+ "name": null,
+ "email": "sabin@gmail.com"
+ }
+]
+```
+
+
+
+
+Because `null` was used as the filter on the `name` column, Prisma Client will generate a query that searches for the first record in the `User` table whose `name` value is _empty_.
+
+#### Undefined
+
+If `undefined` is used as the filter value on the `name` column instead, _the query will act as if no filter criteria was passed to that column at all_.
+
+Consider the query below:
+
+
+
+
+
+```ts
+const user = await prisma.user.findFirst({
+ where: {
+ name: undefined,
+ },
+})
+```
+
+
+
+
+
+```json
+[
+ {
+ "id": 1,
+ "name": "Nikolas",
+ "email": "nikolas@gmail.com"
+ }
+]
+```
+
+
+
+
+In this scenario, the query will return the very first record in the database.
+
+Another way to represent the above query is:
+
+```ts
+const user = await prisma.user.findFirst()
+```
+
+Although this section's examples focused on the `findFirst` function, the same concepts apply to any function that affects a single record.
+
+### `null` and `undefined` in a GraphQL resolver
+
+For this example, consider a database based on the following Prisma schema:
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+}
+```
+
+In the following GraphQL mutation that updates a user, both `authorEmail` and `name` accept `null`. From a GraphQL perspective, this means that fields are **optional**:
+
+```ts
+type Mutation {
+ // Update author's email or name, or both - or neither!
+ updateUser(id: Int!, authorEmail: String, authorName: String): User!
+}
+```
+
+However, if you pass `null` values for `authorEmail` or `authorName` on to Prisma Client, the following will happen:
+
+- If `args.authorEmail` is `null`, the query will **fail**. `email` does not accept `null`.
+- If `args.authorName` is `null`, Prisma Client changes the value of `name` to `null`. This is probably not how you want an update to work.
+
+```ts
+updateUser: (parent, args, ctx: Context) => {
+ return ctx.prisma.user.update({
+ where: { id: Number(args.id) },
+ data: {
+ //highlight-start
+ email: args.authorEmail, // email cannot be null
+ name: args.authorName // name set to null - potentially unwanted behavior
+ //highlight-end
+ },
+ })
+},
+```
+
+Instead, set the value of `email` and `name` to `undefined` if the input value is `null`. Doing this is the same as not updating the field at all:
+
+```ts
+updateUser: (parent, args, ctx: Context) => {
+ return ctx.prisma.user.update({
+ where: { id: Number(args.id) },
+ data: {
+ //highlight-start
+ email: args.authorEmail != null ? args.authorEmail : undefined, // If null, do nothing
+ name: args.authorName != null ? args.authorName : undefined // If null, do nothing
+ //highlight-end
+ },
+ })
+},
+```
+
+### The effect of `null` and `undefined` on conditionals
+
+There are some caveats to filtering with conditionals which might produce unexpected results. When filtering with conditionals you might expect one result but receive another given how Prisma Client treats nullable values.
+
+The following table provides a high-level overview of how the different operators handle 0, 1 and `n` filters.
+
+| Operator | 0 filters | 1 filter | n filters |
+| -------- | ----------------- | ---------------------- | -------------------- |
+| `OR` | return empty list | validate single filter | validate all filters |
+| `AND` | return all items | validate single filter | validate all filters |
+| `NOT` | return all items | validate single filter | validate all filters |
+
+This example shows how an `undefined` parameter impacts the results returned by a query that uses the [`OR`](/6.0/orm/reference/prisma-client-reference#or) operator.
+
+```ts
+interface FormData {
+ name: string
+ email?: string
+}
+
+const formData: FormData = {
+ name: 'Emelie',
+}
+
+const users = await prisma.user.findMany({
+ where: {
+ OR: [
+ {
+ email: {
+ contains: formData.email,
+ },
+ },
+ ],
+ },
+})
+
+// returns: []
+```
+
+The query receives filters from a formData object, which includes an optional email property. In this instance, the value of the email property is `undefined`. When this query is run no data is returned.
+
+This is in contrast to the [`AND`](/6.0/orm/reference/prisma-client-reference#and) and [`NOT`](/6.0/orm/reference/prisma-client-reference#not-1) operators, which will both return all the users
+if you pass in an `undefined` value.
+
+> This is because passing an `undefined` value to an `AND` or `NOT` operator is the same
+> as passing nothing at all, meaning the `findMany` query in the example will run without any filters and return all the users.
+
+```ts
+interface FormData {
+ name: string
+ email?: string
+}
+
+const formData: FormData = {
+ name: 'Emelie',
+}
+
+const users = await prisma.user.findMany({
+ where: {
+ AND: [
+ {
+ email: {
+ contains: formData.email,
+ },
+ },
+ ],
+ },
+})
+
+// returns: { id: 1, email: 'ems@boop.com', name: 'Emelie' }
+
+const users = await prisma.user.findMany({
+ where: {
+ NOT: [
+ {
+ email: {
+ contains: formData.email,
+ },
+ },
+ ],
+ },
+})
+
+// returns: { id: 1, email: 'ems@boop.com', name: 'Emelie' }
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/200-special-fields-and-types/100-working-with-json-fields.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/200-special-fields-and-types/100-working-with-json-fields.mdx
new file mode 100644
index 0000000000..4e2817a667
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/200-special-fields-and-types/100-working-with-json-fields.mdx
@@ -0,0 +1,1072 @@
+---
+title: 'Working with Json fields'
+metaTitle: 'Working with Json fields (Concepts)'
+metaDescription: 'How to read, write, and filter by Json fields.'
+tocDepth: 3
+---
+
+Use the [`Json`](/orm/reference/prisma-schema-reference#json) Prisma ORM field type to read, write, and perform basic filtering on JSON types in the underlying database. In the following example, the `User` model has an optional `Json` field named `extendedPetsData`:
+
+```prisma highlight=6;normal
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ posts Post[]
+ //highlight-next-line
+ extendedPetsData Json?
+}
+```
+
+Example field value:
+
+```json
+{
+ "pet1": {
+ "petName": "Claudine",
+ "petType": "House cat"
+ },
+ "pet2": {
+ "petName": "Sunny",
+ "petType": "Gerbil"
+ }
+}
+```
+
+
+The `Json` field supports a few additional types, such as `string` and `boolean`. These additional types exist to match the types supported by [`JSON.parse()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse):
+
+```ts
+export type JsonValue =
+ | string
+ | number
+ | boolean
+ | null
+ | JsonObject
+ | JsonArray
+```
+
+## Use cases for JSON fields
+
+Reasons to store data as JSON rather than representing data as related models include:
+
+- You need to store data that does not have a consistent structure
+- You are importing data from another system and do not want to map that data to Prisma models
+
+## Reading a `Json` field
+
+You can use the `Prisma.JsonArray` and `Prisma.JsonObject` utility classes to work with the contents of a `Json` field:
+
+```ts
+const { PrismaClient, Prisma } = require('@prisma/client')
+
+const user = await prisma.user.findFirst({
+ where: {
+ id: 9,
+ },
+})
+
+// Example extendedPetsData data:
+// [{ name: 'Bob the dog' }, { name: 'Claudine the cat' }]
+
+if (
+ user?.extendedPetsData &&
+ typeof user?.extendedPetsData === 'object' &&
+ Array.isArray(user?.extendedPetsData)
+) {
+ const petsObject = user?.extendedPetsData as Prisma.JsonArray
+
+ const firstPet = petsObject[0]
+}
+```
+
+See also: [Advanced example: Update a nested JSON key value](#advanced-example-update-a-nested-json-key-value)
+
+## Writing to a `Json` field
+
+The following example writes a JSON object to the `extendedPetsData` field:
+
+```ts
+var json = [
+ { name: 'Bob the dog' },
+ { name: 'Claudine the cat' },
+] as Prisma.JsonArray
+
+const createUser = await prisma.user.create({
+ data: {
+ email: 'birgitte@prisma.io',
+ extendedPetsData: json,
+ },
+})
+```
+
+> **Note**: JavaScript objects (for example, `{ extendedPetsData: "none"}`) are automatically converted to JSON.
+
+See also: [Advanced example: Update a nested JSON key value](#advanced-example-update-a-nested-json-key-value)
+
+## Filter on a `Json` field (simple)
+
+You can filter rows of `Json` type.
+
+### Filter on exact field value
+
+The following query returns all users where the value of `extendedPetsData` matches the `json` variable exactly:
+
+```ts
+var json = [{ name: 'Bob the dog' }, { name: 'Claudine the cat' }]
+
+const getUsers = await prisma.user.findMany({
+ where: {
+ extendedPetsData: {
+ equals: json,
+ },
+ },
+})
+```
+
+The following query returns all users where the value of `extendedPetsData` does **not** match the `json` variable exactly:
+
+```ts
+var json = [{ name: 'Bob the dog' }, { name: 'Claudine the cat' }]
+
+const getUsers = await prisma.user.findMany({
+ where: {
+ extendedPetsData: {
+ not: json,
+ },
+ },
+})
+```
+
+## Filter on a `Json` field (advanced)
+
+You can also filter rows by the data inside a `Json` field. We call this **advanced `Json` filtering**. This functionality is supported by [PostgreSQL](/orm/overview/databases/postgresql) and [MySQL](/orm/overview/databases/mysql) only with [different syntaxes for the `path` option](#path-syntax-depending-on-database).
+
+
+
+PostgreSQL does not support [filtering on object key values in arrays](#filtering-on-object-key-value-inside-array).
+
+
+
+
+
+The availability of advanced `Json` filtering depends on your Prisma version:
+
+- v4.0.0 or later: advanced `Json` filtering is [generally available](/orm/more/releases#generally-available-ga).
+- From v2.23.0, but before v4.0.0: advanced `Json` filtering is a [preview feature](/orm/reference/preview-features/client-preview-features). Add `previewFeatures = ["filterJson"]` to your schema. [Learn more](/orm/reference/preview-features/client-preview-features#enabling-a-prisma-client-preview-feature).
+- Before v2.23.0: you can [filter on the exact `Json` field value](#filter-on-exact-field-value), but you cannot use the other features described in this section.
+
+
+
+### `path` syntax depending on database
+
+The filters below use a `path` option to select specific parts of the `Json` value to filter on. The implementation of that filtering differs between connectors:
+
+- The [MySQL connector](/orm/overview/databases/mysql) uses [MySQL's implementation of JSON path](https://dev.mysql.com/doc/refman/8.0/en/json.html#json-path-syntax)
+- The [PostgreSQL connector](/orm/overview/databases/postgresql) uses the custom JSON functions and operators [supported in version 12 _and earlier_](https://www.postgresql.org/docs/11/functions-json.html)
+
+For example, the following is a valid MySQL `path` value:
+
+```
+$petFeatures.petName
+```
+
+The following is a valid PostgreSQL `path` value:
+
+```
+["petFeatures", "petName"]
+```
+
+### Filter on object property
+
+You can filter on a specific property inside a block of JSON. In the following examples, the value of `extendedPetsData` is a one-dimensional, unnested JSON object:
+
+```json highlight=11;normal
+{
+ "petName": "Claudine",
+ "petType": "House cat"
+}
+```
+
+The following query returns all users where the value of `petName` is `"Claudine"`:
+
+
+
+
+```ts
+const getUsers = await prisma.user.findMany({
+ where: {
+ extendedPetsData: {
+ path: ['petName'],
+ equals: 'Claudine',
+ },
+ },
+})
+```
+
+
+
+
+```ts
+const getUsers = await prisma.user.findMany({
+ where: {
+ extendedPetsData: {
+ path: '$.petName',
+ equals: 'Claudine',
+ },
+ },
+})
+```
+
+
+
+
+
+The following query returns all users where the value of `petType` _contains_ `"cat"`:
+
+
+
+
+```ts
+const getUsers = await prisma.user.findMany({
+ where: {
+ extendedPetsData: {
+ path: ['petType'],
+ string_contains: 'cat',
+ },
+ },
+})
+```
+
+
+
+
+```ts
+const getUsers = await prisma.user.findMany({
+ where: {
+ extendedPetsData: {
+ path: '$.petType',
+ string_contains: 'cat',
+ },
+ },
+})
+```
+
+
+
+
+The following string filters are available:
+
+- [`string_contains`](/6.0/orm/reference/prisma-client-reference#string_contains)
+- [`string_starts_with`](/6.0/orm/reference/prisma-client-reference#string_starts_with)
+- [`string_ends_with`](/6.0/orm/reference/prisma-client-reference#string_ends_with) .
+
+To use case insensitive filter with these, you can use the [`mode`](/6.0/orm/reference/prisma-client-reference#mode) option:
+
+
+
+
+```ts
+const getUsers = await prisma.user.findMany({
+ where: {
+ extendedPetsData: {
+ path: ['petType'],
+ string_contains: 'cat',
+ mode: 'insensitive'
+ },
+ },
+})
+```
+
+
+
+
+```ts
+const getUsers = await prisma.user.findMany({
+ where: {
+ extendedPetsData: {
+ path: '$.petType',
+ string_contains: 'cat',
+ mode: 'insensitive'
+ },
+ },
+})
+```
+
+
+
+
+### Filter on nested object property
+
+You can filter on nested JSON properties. In the following examples, the value of `extendedPetsData` is a JSON object with several levels of nesting.
+
+```json
+{
+ "pet1": {
+ "petName": "Claudine",
+ "petType": "House cat"
+ },
+ "pet2": {
+ "petName": "Sunny",
+ "petType": "Gerbil",
+ "features": {
+ "eyeColor": "Brown",
+ "furColor": "White and black"
+ }
+ }
+}
+```
+
+The following query returns all users where `"pet2"` → `"petName"` is `"Sunny"`:
+
+
+
+
+```ts
+const getUsers = await prisma.user.findMany({
+ where: {
+ extendedPetsData: {
+ path: ['pet2', 'petName'],
+ equals: 'Sunny',
+ },
+ },
+})
+```
+
+
+
+
+```ts
+const getUsers = await prisma.user.findMany({
+ where: {
+ extendedPetsData: {
+ path: '$.pet2.petName',
+ equals: 'Sunny',
+ },
+ },
+})
+```
+
+
+
+
+The following query returns all users where:
+
+- `"pet2"` → `"petName"` is `"Sunny"`
+- `"pet2"` → `"features"` → `"furColor"` contains `"black"`
+
+
+
+
+```ts
+const getUsers = await prisma.user.findMany({
+ where: {
+ AND: [
+ {
+ extendedPetsData: {
+ path: ['pet2', 'petName'],
+ equals: 'Sunny',
+ },
+ },
+ {
+ extendedPetsData: {
+ path: ['pet2', 'features', 'furColor'],
+ string_contains: 'black',
+ },
+ },
+ ],
+ },
+})
+```
+
+
+
+
+```ts
+const getUsers = await prisma.user.findMany({
+ where: {
+ AND: [
+ {
+ extendedPetsData: {
+ path: '$.pet2.petName',
+ equals: 'Sunny',
+ },
+ },
+ {
+ extendedPetsData: {
+ path: '$.pet2.features.furColor',
+ string_contains: 'black',
+ },
+ },
+ ],
+ },
+})
+```
+
+
+
+
+
+### Filtering on an array value
+
+You can filter on the presence of a specific value in a scalar array (strings, integers). In the following example, the value of `extendedPetsData` is an array of strings:
+
+```json
+["Claudine", "Sunny"]
+```
+
+The following query returns all users with a pet named `"Claudine"`:
+
+
+
+
+```ts
+const getUsers = await prisma.user.findMany({
+ where: {
+ extendedPetsData: {
+ array_contains: ['Claudine'],
+ },
+ },
+})
+```
+
+
+
+**Note**: In PostgreSQL, the value of `array_contains` must be an array and not a string, even if the array only contains a single value.
+
+
+
+
+
+
+```ts
+const getUsers = await prisma.user.findMany({
+ where: {
+ extendedPetsData: {
+ array_contains: 'Claudine',
+ },
+ },
+})
+```
+
+
+
+
+
+The following array filters are available:
+
+- [`array_contains`](/6.0/orm/reference/prisma-client-reference#array_contains)
+- [`array_starts_with`](/6.0/orm/reference/prisma-client-reference#array_starts_with)
+- [`array_ends_with`](/6.0/orm/reference/prisma-client-reference#array_ends_with)
+
+### Filtering on nested array value
+
+You can filter on the presence of a specific value in a scalar array (strings, integers). In the following examples, the value of `extendedPetsData` includes nested scalar arrays of names:
+
+```json
+{
+ "cats": { "owned": ["Bob", "Sunny"], "fostering": ["Fido"] },
+ "dogs": { "owned": ["Ella"], "fostering": ["Prince", "Empress"] }
+}
+```
+
+#### Scalar value arrays
+
+The following query returns all users that foster a cat named `"Fido"`:
+
+
+
+
+```ts
+const getUsers = await prisma.user.findMany({
+ where: {
+ extendedPetsData: {
+ path: ['cats', 'fostering'],
+ array_contains: ['Fido'],
+ },
+ },
+})
+```
+
+
+
+**Note**: In PostgreSQL, the value of `array_contains` must be an array and not a string, even if the array only contains a single value.
+
+
+
+
+
+
+```ts
+const getUsers = await prisma.user.findMany({
+ where: {
+ extendedPetsData: {
+ path: '$.cats.fostering',
+ array_contains: 'Fido',
+ },
+ },
+})
+```
+
+
+
+
+The following query returns all users that foster cats named `"Fido"` _and_ `"Bob"`:
+
+
+
+
+```ts
+const getUsers = await prisma.user.findMany({
+ where: {
+ extendedPetsData: {
+ path: ['cats', 'fostering'],
+ array_contains: ['Fido', 'Bob'],
+ },
+ },
+})
+```
+
+
+
+
+```ts
+const getUsers = await prisma.user.findMany({
+ where: {
+ extendedPetsData: {
+ path: '$.cats.fostering',
+ array_contains: ['Fido', 'Bob'],
+ },
+ },
+})
+```
+
+
+
+
+#### JSON object arrays
+
+
+
+
+```ts
+const json = [{ status: 'expired', insuranceID: 92 }]
+
+const checkJson = await prisma.user.findMany({
+ where: {
+ extendedPetsData: {
+ path: ['insurances'],
+ array_contains: json,
+ },
+ },
+})
+```
+
+
+
+
+```ts
+const json = { status: 'expired', insuranceID: 92 }
+
+const checkJson = await prisma.user.findMany({
+ where: {
+ extendedPetsData: {
+ path: '$.insurances',
+ array_contains: json,
+ },
+ },
+})
+```
+
+
+
+
+- If you are using PostgreSQL, you must pass in an array of objects to match, even if that array only contains one object:
+
+ ```json5
+ [{ status: 'expired', insuranceID: 92 }]
+ // PostgreSQL
+ ```
+
+ If you are using MySQL, you must pass in a single object to match:
+
+ ```json5
+ { status: 'expired', insuranceID: 92 }
+ // MySQL
+ ```
+
+- If your filter array contains multiple objects, PostgreSQL will only return results if _all_ objects are present - not if at least one object is present.
+
+- You must set `array_contains` to a JSON object, not a string. If you use a string, Prisma Client escapes the quotation marks and the query will not return results. For example:
+
+ ```ts
+ array_contains: '[{"status": "expired", "insuranceID": 92}]'
+ ```
+
+ is sent to the database as:
+
+ ```
+ [{\"status\": \"expired\", \"insuranceID\": 92}]
+ ```
+
+### Targeting an array element by index
+
+You can filter on the value of an element in a specific position.
+
+```json
+{ "owned": ["Bob", "Sunny"], "fostering": ["Fido"] }
+```
+
+
+
+
+```ts
+const getUsers = await prisma.user.findMany({
+ where: {
+ comments: {
+ path: ['owned', '1'],
+ string_contains: 'Bob',
+ },
+ },
+})
+```
+
+
+
+
+
+```ts
+const getUsers = await prisma.user.findMany({
+ where: {
+ comments: {
+ path: '$.owned[1]',
+ string_contains: 'Bob',
+ },
+ },
+})
+```
+
+
+
+
+
+### Filtering on object key value inside array
+
+Depending on your provider, you can filter on the key value of an object inside an array.
+
+
+
+Filtering on object key values within an array is **only** supported by the [MySQL database connector](/orm/overview/databases/mysql). However, you can still [filter on the presence of entire JSON objects](#json-object-arrays).
+
+
+
+In the following example, the value of `extendedPetsData` is an array of objects with a nested `insurances` array, which contains two objects:
+
+```json
+[
+ {
+ "petName": "Claudine",
+ "petType": "House cat",
+ "insurances": [
+ { "insuranceID": 92, "status": "expired" },
+ { "insuranceID": 12, "status": "active" }
+ ]
+ },
+ {
+ "petName": "Sunny",
+ "petType": "Gerbil"
+ },
+ {
+ "petName": "Gerald",
+ "petType": "Corn snake"
+ },
+ {
+ "petName": "Nanna",
+ "petType": "Moose"
+ }
+]
+```
+
+The following query returns all users where at least one pet is a moose:
+
+```ts
+const getUsers = await prisma.user.findMany({
+ where: {
+ extendedPetsData: {
+ path: '$[*].petType',
+ array_contains: 'Moose',
+ },
+ },
+})
+```
+
+- `$[*]` is the root array of pet objects
+- `petType` matches the `petType` key in any pet object
+
+The following query returns all users where at least one pet has an expired insurance:
+
+```ts
+const getUsers = await prisma.user.findMany({
+ where: {
+ extendedPetsData: {
+ path: '$[*].insurances[*].status',
+ array_contains: 'expired',
+ },
+ },
+})
+```
+
+- `$[*]` is the root array of pet objects
+- `insurances[*]` matches any `insurances` array inside any pet object
+- `status` matches any `status` key in any insurance object
+
+## Advanced example: Update a nested JSON key value
+
+The following example assumes that the value of `extendedPetsData` is some variation of the following:
+
+```json
+{
+ "petName": "Claudine",
+ "petType": "House cat",
+ "insurances": [
+ { "insuranceID": 92, "status": "expired" },
+ { "insuranceID": 12, "status": "active" }
+ ]
+}
+```
+
+The following example:
+
+1. Gets all users
+1. Change the `"status"` of each insurance object to `"expired"`
+1. Get all users that have an expired insurance where the ID is `92`
+
+
+
+
+```ts
+const userQueries: string | any[] = []
+
+getUsers.forEach((user) => {
+ if (
+ user.extendedPetsData &&
+ typeof user.extendedPetsData === 'object' &&
+ !Array.isArray(user.extendedPetsData)
+ ) {
+ const petsObject = user.extendedPetsData as Prisma.JsonObject
+
+ const i = petsObject['insurances']
+
+ if (i && typeof i === 'object' && Array.isArray(i)) {
+ const insurancesArray = i as Prisma.JsonArray
+
+ insurancesArray.forEach((i) => {
+ if (i && typeof i === 'object' && !Array.isArray(i)) {
+ const insuranceObject = i as Prisma.JsonObject
+
+ insuranceObject['status'] = 'expired'
+ }
+ })
+
+ const whereClause = Prisma.validator()({
+ id: user.id,
+ })
+
+ const dataClause = Prisma.validator()({
+ extendedPetsData: petsObject,
+ })
+
+ userQueries.push(
+ prisma.user.update({
+ where: whereClause,
+ data: dataClause,
+ })
+ )
+ }
+ }
+})
+
+if (userQueries.length > 0) {
+ console.log(userQueries.length + ' queries to run!')
+ await prisma.$transaction(userQueries)
+}
+
+const json = [{ status: 'expired', insuranceID: 92 }]
+
+const checkJson = await prisma.user.findMany({
+ where: {
+ extendedPetsData: {
+ path: ['insurances'],
+ array_contains: json,
+ },
+ },
+})
+
+console.log(checkJson.length)
+```
+
+
+
+
+
+```ts
+const userQueries: string | any[] = []
+
+getUsers.forEach((user) => {
+ if (
+ user.extendedPetsData &&
+ typeof user.extendedPetsData === 'object' &&
+ !Array.isArray(user.extendedPetsData)
+ ) {
+ const petsObject = user.extendedPetsData as Prisma.JsonObject
+
+ const insuranceList = petsObject['insurances'] // is a Prisma.JsonArray
+
+ if (Array.isArray(insuranceList)) {
+ insuranceList.forEach((insuranceItem) => {
+ if (
+ insuranceItem &&
+ typeof insuranceItem === 'object' &&
+ !Array.isArray(insuranceItem)
+ ) {
+ insuranceItem['status'] = 'expired' // is a Prisma.JsonObject
+ }
+ })
+
+ const whereClause = Prisma.validator()({
+ id: user.id,
+ })
+
+ const dataClause = Prisma.validator()({
+ extendedPetsData: petsObject,
+ })
+
+ userQueries.push(
+ prisma.user.update({
+ where: whereClause,
+ data: dataClause,
+ })
+ )
+ }
+ }
+})
+
+if (userQueries.length > 0) {
+ console.log(userQueries.length + ' queries to run!')
+ await prisma.$transaction(userQueries)
+}
+
+const json = { status: 'expired', insuranceID: 92 }
+
+const checkJson = await prisma.user.findMany({
+ where: {
+ extendedPetsData: {
+ path: '$.insurances',
+ array_contains: json,
+ },
+ },
+})
+
+console.log(checkJson.length)
+```
+
+
+
+
+## Using `null` Values
+
+There are two types of `null` values possible for a `JSON` field in an SQL database.
+
+- Database `NULL`: The value in the database is a `NULL`.
+- JSON `null`: The value in the database contains a JSON value that is `null`.
+
+To differentiate between these possibilities, we've introduced three _null enums_ you can use:
+
+- `JsonNull`: Represents the `null` value in JSON.
+- `DbNull`: Represents the `NULL` value in the database.
+- `AnyNull`: Represents both `null` JSON values and `NULL` database values. (Only when filtering)
+
+
+
+From v4.0.0, `JsonNull`, `DbNull`, and `AnyNull` are objects. Before v4.0.0, they were strings.
+
+
+
+
+
+- When filtering using any of the _null enums_ you can not use a shorthand and leave the `equals` operator off.
+- These _null enums_ do not apply to MongoDB because there the difference between a JSON `null` and a database `NULL` does not exist.
+- The _null enums_ do not apply to the `array_contains` operator in all databases because there can only be a JSON `null` within a JSON array. Since there cannot be a database `NULL` within a JSON array, `{ array_contains: null }` is not ambiguous.
+
+
+
+For example:
+
+```prisma
+model Log {
+ id Int @id
+ meta Json
+}
+```
+
+Here is an example of using `AnyNull`:
+
+```ts highlight=7;normal
+import { Prisma } from '@prisma/client'
+
+prisma.log.findMany({
+ where: {
+ data: {
+ meta: {
+ equals: Prisma.AnyNull,
+ },
+ },
+ },
+})
+```
+
+### Inserting `null` Values
+
+This also applies to `create`, `update` and `upsert`. To insert a `null` value
+into a `Json` field, you would write:
+
+```ts highlight=5;normal
+import { Prisma } from '@prisma/client'
+
+prisma.log.create({
+ data: {
+ meta: Prisma.JsonNull,
+ },
+})
+```
+
+And to insert a database `NULL` into a `Json` field, you would write:
+
+```ts highlight=5;normal
+import { Prisma } from '@prisma/client'
+
+prisma.log.create({
+ data: {
+ meta: Prisma.DbNull,
+ },
+})
+```
+
+### Filtering by `null` Values
+
+To filter by `JsonNull` or `DbNull`, you would write:
+
+```ts highlight=6;normal
+import { Prisma } from '@prisma/client'
+
+prisma.log.findMany({
+ where: {
+ meta: {
+ equals: Prisma.AnyNull,
+ },
+ },
+})
+```
+
+
+
+These _null enums_ do not apply to MongoDB because MongoDB does not differentiate between a JSON `null` and a database `NULL`. They also do not apply to the `array_contains` operator in all databases because there can only be a JSON `null` within a JSON array. Since there cannot be a database `NULL` within a JSON array, `{ array_contains: null }` is not ambiguous.
+
+
+
+## Typed `Json` Fields
+
+Prisma's `Json` fields are untyped by default. To add strong typing, you can use the external package [prisma-json-types-generator](https://www.npmjs.com/package/prisma-json-types-generator).
+
+1. First, install the package and add the generator to your `schema.prisma`:
+
+ ```bash
+ npm install -D prisma-json-types-generator
+ ```
+
+ ```prisma file=schema.prisma
+ generator client {
+ provider = "prisma-client-js"
+ }
+
+ generator json {
+ provider = "prisma-json-types-generator"
+ }
+ ```
+
+2. Next, link a field to a TypeScript type using an [AST comment](/orm/prisma-schema/overview#comments).
+
+ ```prisma highlight=4;normal file=schema.prisma showLineNumbers
+ model Log {
+ id Int @id
+
+ //highlight-next-line
+ /// [LogMetaType]
+ meta Json
+ }
+ ```
+
+3. Then, define `LogMetaType` in a type declaration file (e.g., `types.ts`) that is included in your `tsconfig.json`.
+
+ ```ts file=types.ts showLineNumbers
+ declare global {
+ namespace PrismaJson {
+ type LogMetaType = { timestamp: number; host: string };
+ }
+ }
+
+ // This file must be a module.
+ export {};
+ ```
+
+Now, `Log.meta` will be strongly typed as `{ timestamp: number; host: string }`.
+
+### Typing `String` Fields and Advanced Features
+
+You can also apply these techniques to `String` fields. This is especially useful for creating string-based enums directly in your schema when your database does not support enum types.
+
+```prisma
+model Post {
+ id Int @id
+
+ /// !['draft' | 'published']
+ status String
+
+ /// [LogMetaType]
+ meta Json[]
+}
+```
+
+This results in `post.status` being strongly typed as `'draft' | 'published'` and `post.meta` as `LogMetaType[]`.
+
+For a complete guide on configuration, monorepo setup, and other advanced features, please refer to the [official `prisma-json-types-generator` documentation](https://github.com/arthurfiorette/prisma-json-types-generator#readme).
+
+## `Json` FAQs
+
+### Can you select a subset of JSON key/values to return?
+
+No - it is not yet possible to [select which JSON elements to return](https://github.com/prisma/prisma/issues/2431). Prisma Client returns the entire JSON object.
+
+### Can you filter on the presence of a specific key?
+
+No - it is not yet possible to filter on the presence of a specific key.
+
+### Is case insensitive filtering supported?
+
+No - [case insensitive filtering](https://github.com/prisma/prisma/issues/7390) is not yet supported.
+
+### Can you sort an object property within a JSON value?
+
+No, [sorting object properties within a JSON value](https://github.com/prisma/prisma/issues/10346) (order-by-prop) is not currently supported.
+
+### How to set a default value for JSON fields?
+
+When you want to set a `@default` value the `Json` type, you need to enclose it with double-quotes inside the `@default` attribute (and potentially escape any "inner" double-quotes using a backslash), for example:
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ json1 Json @default("[]")
+ json2 Json @default("{ \"hello\": \"world\" }")
+}
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/200-special-fields-and-types/200-working-with-scalar-lists-arrays.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/200-special-fields-and-types/200-working-with-scalar-lists-arrays.mdx
new file mode 100644
index 0000000000..8cb3f28495
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/200-special-fields-and-types/200-working-with-scalar-lists-arrays.mdx
@@ -0,0 +1,221 @@
+---
+title: 'Working with scalar lists'
+metaTitle: 'Working with scalar lists/arrays (Concepts)'
+metaDescription: 'How to read, write, and filter by scalar lists / arrays.'
+tocDepth: 3
+---
+
+
+
+[Scalar lists](/orm/reference/prisma-schema-reference#-modifier) are represented by the `[]` modifier and are only available if the underlying database supports scalar lists. The following example has one scalar `String` list named `pets`:
+
+
+
+
+```prisma highlight=4;normal
+model User {
+ id Int @id @default(autoincrement())
+ name String
+ //highlight-next-line
+ pets String[]
+}
+```
+
+
+
+
+```prisma highlight=4;normal
+model User {
+ id String @id @default(auto()) @map("_id") @db.ObjectId
+ name String
+ //highlight-next-line
+ pets String[]
+}
+```
+
+
+
+
+Example field value:
+
+```json5
+['Fido', 'Snoopy', 'Brian']
+```
+
+
+
+## Setting the value of a scalar list
+
+The following example demonstrates how to [`set`](/6.0/orm/reference/prisma-client-reference#set-1) the value of a scalar list (`coinflips`) when you create a model:
+
+```ts
+const createdUser = await prisma.user.create({
+ data: {
+ email: 'eloise@prisma.io',
+ coinflips: [true, true, true, false, true],
+ },
+})
+```
+
+## Unsetting the value of a scalar list
+
+
+
+This method is available on MongoDB only in versions
+[3.11.1](https://github.com/prisma/prisma/releases/tag/3.11.1) and later.
+
+
+
+The following example demonstrates how to [`unset`](/6.0/orm/reference/prisma-client-reference#unset) the value of a scalar list (`coinflips`):
+
+```ts
+const createdUser = await prisma.user.create({
+ data: {
+ email: 'eloise@prisma.io',
+ coinflips: {
+ unset: true,
+ },
+ },
+})
+```
+
+Unlike `set: null`, `unset` removes the list entirely.
+
+## Adding items to a scalar list
+
+
+
+Available for:
+
+- PostgreSQL in versions [2.15.0](https://github.com/prisma/prisma/releases/tag/2.15.0) and later
+- CockroachDB in versions [3.9.0](https://github.com/prisma/prisma/releases/tag/3.9.0) and later
+- MongoDB in versions [3.11.0](https://github.com/prisma/prisma/releases/tag/3.11.0) and later
+
+
+
+Use the [`push`](/6.0/orm/reference/prisma-client-reference#push) method to add a single value to a scalar list:
+
+```ts
+const userUpdate = await prisma.user.update({
+ where: {
+ id: 9,
+ },
+ data: {
+ coinflips: {
+ push: true,
+ },
+ },
+})
+```
+
+In earlier versions, you have to overwrite the entire value. The following example retrieves user, uses `push()` to add three new coin flips, and overwrites the `coinflips` field in an `update`:
+
+```ts
+const user = await prisma.user.findUnique({
+ where: {
+ email: 'eloise@prisma.io',
+ },
+})
+
+if (user) {
+ console.log(user.coinflips)
+
+ user.coinflips.push(true, true, false)
+
+ const updatedUser = await prisma.user.update({
+ where: {
+ email: 'eloise@prisma.io',
+ },
+ data: {
+ coinflips: user.coinflips,
+ },
+ })
+
+ console.log(updatedUser.coinflips)
+}
+```
+
+## Filtering scalar lists
+
+
+
+Available for:
+
+- PostgreSQL in versions [2.15.0](https://github.com/prisma/prisma/releases/tag/2.15.0) and later
+- CockroachDB in versions [3.9.0](https://github.com/prisma/prisma/releases/tag/3.9.0) and later
+- MongoDB in versions [3.11.0](https://github.com/prisma/prisma/releases/tag/3.11.0) and later
+
+
+
+Use [scalar list filters](/6.0/orm/reference/prisma-client-reference#scalar-list-filters) to filter for records with scalar lists that match a specific condition. The following example returns all posts where the tags list includes `databases` _and_ `typescript`:
+
+```ts
+const posts = await prisma.post.findMany({
+ where: {
+ tags: {
+ hasEvery: ['databases', 'typescript'],
+ },
+ },
+})
+```
+
+### `NULL` values in arrays
+
+
+
+This section applies to:
+
+- PostgreSQL in versions [2.15.0](https://github.com/prisma/prisma/releases/tag/2.15.0) and later
+- CockroachDB in versions [3.9.0](https://github.com/prisma/prisma/releases/tag/3.9.0) and later
+
+
+
+When using scalar list filters with a relational database connector, array fields with a `NULL` value are not considered by the following conditions:
+
+- `NOT` (array does not contain X)
+- `isEmpty` (array is empty)
+
+This means that records you might expect to see are not returned. Consider the following examples:
+
+- The following query returns all posts where the `tags` **do not** include `databases`:
+
+ ```ts
+ const posts = await prisma.post.findMany({
+ where: {
+ NOT: {
+ tags: {
+ has: 'databases',
+ },
+ },
+ },
+ })
+ ```
+
+ - ✔ Arrays that do not contain `"databases"`, such as `{"typescript", "graphql"}`
+ - ✔ Empty arrays, such as `[]`
+
+ The query does not return:
+
+ - ✘ `NULL` arrays, even though they do not contain `"databases"`
+
+The following query returns all posts where `tags` is empty:
+
+```ts
+const posts = await prisma.post.findMany({
+ where: {
+ tags: {
+ isEmpty: true,
+ },
+ },
+})
+```
+
+The query returns:
+
+- ✔ Empty arrays, such as `[]`
+
+The query does not return:
+
+- ✘ `NULL` arrays, even though they could be considered empty
+
+To work around this issue, you can set the default value of array fields to `[]`.
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/200-special-fields-and-types/300-working-with-composite-ids-and-constraints.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/200-special-fields-and-types/300-working-with-composite-ids-and-constraints.mdx
new file mode 100644
index 0000000000..d687f60a12
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/200-special-fields-and-types/300-working-with-composite-ids-and-constraints.mdx
@@ -0,0 +1,208 @@
+---
+title: 'Working with compound IDs and unique constraints'
+metaTitle: 'Working with compound IDs and unique constraints (Concepts)'
+metaDescription: 'How to read, write, and filter by compound IDs and unique constraints.'
+tocDepth: 2
+---
+
+
+
+Composite IDs and compound unique constraints can be defined in your Prisma schema using the [`@@id`](/orm/reference/prisma-schema-reference#id-1) and [`@@unique`](/orm/reference/prisma-schema-reference#unique-1) attributes.
+
+
+
+**MongoDB does not support `@@id`**
+MongoDB does not support composite IDs, which means you cannot identify a model with a `@@id` attribute.
+
+
+
+A composite ID or compound unique constraint uses the combined values of two fields as a primary key or identifier in your database table. In the following example, the `postId` field and `userId` field are used as a composite ID for a `Like` table:
+
+```prisma highlight=22;normal
+model User {
+ id Int @id @default(autoincrement())
+ name String
+ post Post[]
+ likes Like[]
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ content String
+ User User? @relation(fields: [userId], references: [id])
+ userId Int?
+ likes Like[]
+}
+
+model Like {
+ postId Int
+ userId Int
+ User User @relation(fields: [userId], references: [id])
+ Post Post @relation(fields: [postId], references: [id])
+
+ //highlight-next-line
+ @@id([postId, userId])
+}
+```
+
+Querying for records from the `Like` table (e.g. using `prisma.like.findMany()`) would return objects that look as follows:
+
+```json
+{
+ "postId": 1,
+ "userId": 1
+}
+```
+
+Although there are only two fields in the response, those two fields make up a compound ID named `postId_userId`.
+
+You can also create a named compound ID or compound unique constraint by using the `@@id` or `@@unique` attributes' `name` field. For example:
+
+```prisma highlight=7;normal
+model Like {
+ postId Int
+ userId Int
+ User User @relation(fields: [userId], references: [id])
+ Post Post @relation(fields: [postId], references: [id])
+
+ //highlight-next-line
+ @@id(name: "likeId", [postId, userId])
+}
+```
+
+
+
+## Where you can use compound IDs and unique constraints
+
+Compound IDs and compound unique constraints can be used when working with _unique_ data.
+
+Below is a list of Prisma Client functions that accept a compound ID or compound unique constraint in the `where` filter of the query:
+
+- `findUnique()`
+- `findUniqueOrThrow`
+- `delete`
+- `update`
+- `upsert`
+
+A composite ID and a composite unique constraint is also usable when creating relational data with `connect` and `connectOrCreate`.
+
+## Filtering records by a compound ID or unique constraint
+
+Although your query results will not display a compound ID or unique constraint as a field, you can use these compound values to filter your queries for unique records:
+
+```ts highlight=3-6;normal
+const like = await prisma.like.findUnique({
+ where: {
+ likeId: {
+ userId: 1,
+ postId: 1,
+ },
+ },
+})
+```
+
+
+
+Note composite ID and compound unique constraint keys are only available as filter options for _unique_ queries such as `findUnique()` and `findUniqueOrThrow`. See the [section](/orm/prisma-client/special-fields-and-types/working-with-composite-ids-and-constraints#where-you-can-use-compound-ids-and-unique-constraints) above for a list of places these fields may be used.
+
+
+
+## Deleting records by a compound ID or unique constraint
+
+A compound ID or compound unique constraint may be used in the `where` filter of a `delete` query:
+
+```ts highlight=3-6;normal
+const like = await prisma.like.delete({
+ where: {
+ likeId: {
+ userId: 1,
+ postId: 1,
+ },
+ },
+})
+```
+
+## Updating and upserting records by a compound ID or unique constraint
+
+A compound ID or compound unique constraint may be used in the `where` filter of an `update` query:
+
+```ts highlight=3-6;normal
+const like = await prisma.like.update({
+ where: {
+ likeId: {
+ userId: 1,
+ postId: 1,
+ },
+ },
+ data: {
+ postId: 2,
+ },
+})
+```
+
+They may also be used in the `where` filter of an `upsert` query:
+
+```ts highlight=3-6;normal
+await prisma.like.upsert({
+ where: {
+ likeId: {
+ userId: 1,
+ postId: 1,
+ },
+ },
+ update: {
+ userId: 2,
+ },
+ create: {
+ userId: 2,
+ postId: 1,
+ },
+})
+```
+
+## Filtering relation queries by a compound ID or unique constraint
+
+Compound IDs and compound unique constraint can also be used in the `connect` and `connectOrCreate` keys used when connecting records to create a relationship.
+
+For example, consider this query:
+
+```ts highlight=6-9;normal
+await prisma.user.create({
+ data: {
+ name: 'Alice',
+ likes: {
+ connect: {
+ likeId: {
+ postId: 1,
+ userId: 2,
+ },
+ },
+ },
+ },
+})
+```
+
+The `likeId` compound ID is used as the identifier in the `connect` object that is used to locate the `Like` table's record that will be linked to the new user: `"Alice"`.
+
+Similarly, the `likeId` can be used in `connectOrCreate`'s `where` filter to attempt to locate an existing record in the `Like` table:
+
+```ts highlight=10-13;normal
+await prisma.user.create({
+ data: {
+ name: 'Alice',
+ likes: {
+ connectOrCreate: {
+ create: {
+ postId: 1,
+ },
+ where: {
+ likeId: {
+ postId: 1,
+ userId: 1,
+ },
+ },
+ },
+ },
+ },
+})
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/200-special-fields-and-types/index.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/200-special-fields-and-types/index.mdx
new file mode 100644
index 0000000000..bb9f73c3c2
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/200-special-fields-and-types/index.mdx
@@ -0,0 +1,180 @@
+---
+title: 'Fields & types'
+metaTitle: 'Fields & types'
+metaDescription: 'Learn how to use about special fields and types with Prisma Client.'
+tocDepth: 3
+---
+
+This section covers various special fields and types you can use with Prisma Client.
+
+## Working with `Decimal`
+
+`Decimal` fields are represented by the [`Decimal.js` library](https://mikemcl.github.io/decimal.js/). The following example demonstrates how to import and use `Prisma.Decimal`:
+
+```ts
+import { PrismaClient, Prisma } from '@prisma/client'
+
+const newTypes = await prisma.sample.create({
+ data: {
+ cost: new Prisma.Decimal(24.454545),
+ },
+})
+```
+
+
+
+You can also perform arithmetic operations:
+
+```ts
+import { PrismaClient, Prisma } from '@prisma/client'
+
+const newTypes = await prisma.sample.create({
+ data: {
+ cost: new Prisma.Decimal(24.454545).plus(1),
+ },
+})
+```
+
+`Prisma.Decimal` uses Decimal.js, see [Decimal.js docs](https://mikemcl.github.io/decimal.js) to learn more.
+
+
+:::warning
+
+The use of the `Decimal` field [is not currently supported in MongoDB](https://github.com/prisma/prisma/issues/12637).
+
+:::
+
+## Working with `BigInt`
+
+### Overview
+
+`BigInt` fields are represented by the [`BigInt` type](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt) (Node.js 10.4.0+ required). The following example demonstrates how to use the `BigInt` type:
+
+```ts
+import { PrismaClient, Prisma } from '@prisma/client'
+
+const newTypes = await prisma.sample.create({
+ data: {
+ revenue: BigInt(534543543534),
+ },
+})
+```
+
+### Serializing `BigInt`
+
+Prisma Client returns records as plain JavaScript objects. If you attempt to use `JSON.stringify` on an object that includes a `BigInt` field, you will see the following error:
+
+```
+Do not know how to serialize a BigInt
+```
+
+To work around this issue, use a customized implementation of `JSON.stringify`:
+
+```js
+JSON.stringify(
+ this,
+ (key, value) => (typeof value === 'bigint' ? value.toString() : value) // return everything else unchanged
+)
+```
+
+## Working with `Bytes`
+
+`Bytes` fields are represented by the [`Uint8Array`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Uint8Array) type. The following example demonstrates how to use the `Uint8Array` type:
+
+```ts
+import { PrismaClient, Prisma } from '@prisma/client'
+
+const newTypes = await prisma.sample.create({
+ data: {
+ myField: new Uint8Array([1, 2, 3, 4]),
+ },
+})
+```
+
+Note that **before Prisma v6**, `Bytes` were represented by the [`Buffer`](https://nodejs.org/api/buffer.html) type:
+
+```ts
+import { PrismaClient, Prisma } from '@prisma/client'
+
+const newTypes = await prisma.sample.create({
+ data: {
+ myField: Buffer.from([1, 2, 3, 4]),
+ },
+})
+```
+
+Learn more in the [upgrade guide to v6](/orm/more/upgrade-guides/upgrading-versions/upgrading-to-prisma-6).
+
+## Working with `DateTime`
+
+:::note
+
+There currently is a [bug](https://github.com/prisma/prisma/issues/9516) that doesn't allow you to pass in `DateTime` values as strings and produces a runtime error when you do. `DateTime` values need to be passed as [`Date`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date) objects (i.e. `new Date('2024-12-04')` instead of `'2024-12-04'`).
+
+:::
+
+When creating records that have fields of type [`DateTime`](/orm/reference/prisma-schema-reference#datetime), Prisma Client accepts values as [`Date`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date) objects adhering to the [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601) standard.
+
+Consider the following schema:
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ birthDate DateTime?
+}
+```
+
+Here are some examples for creating new records:
+
+##### Jan 01, 1998; 00 h 00 min and 000 ms
+
+```ts
+await prisma.user.create({
+ data: {
+ birthDate: new Date('1998')
+ }
+})
+```
+
+##### Dec 01, 1998; 00 h 00 min and 000 ms
+
+```ts
+await prisma.user.create({
+ data: {
+ birthDate: new Date('1998-12')
+ }
+})
+```
+
+##### Dec 24, 1998; 00 h 00 min and 000 ms
+
+```ts
+await prisma.user.create({
+ data: {
+ birthDate: new Date('1998-12-24')
+ }
+})
+```
+
+##### Dec 24, 1998; 06 h 22 min 33s and 444 ms
+
+```ts
+await prisma.user.create({
+ data: {
+ birthDate: new Date('1998-12-24T06:22:33.444Z')
+ }
+})
+```
+
+
+## Working with `Json`
+
+See: [Working with `Json` fields](/orm/prisma-client/special-fields-and-types/working-with-json-fields)
+
+## Working with scalar lists / scalar arrays
+
+See: [Working with scalar lists / arrays](/orm/prisma-client/special-fields-and-types/working-with-scalar-lists-arrays)
+
+## Working with composite IDs and compound unique constraints
+
+See: [Working with composite IDs and compound unique constraints](/orm/prisma-client/special-fields-and-types/working-with-composite-ids-and-constraints)
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/100-model.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/100-model.mdx
new file mode 100644
index 0000000000..2e3c2d97f1
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/100-model.mdx
@@ -0,0 +1,162 @@
+---
+title: '`model`: Add custom methods to your models'
+metaTitle: 'Prisma Client extensions: model component'
+metaDescription: 'Extend the functionality of Prisma Client, model component'
+toc_max_heading_level: 4
+---
+
+
+
+
+
+Prisma Client extensions are Generally Available from versions 4.16.0 and later. They were introduced in Preview in version 4.7.0. Make sure you enable the `clientExtensions` Preview feature flag if you are running on a version earlier than 4.16.0.
+
+
+
+You can use the `model` [Prisma Client extensions](/orm/prisma-client/client-extensions) component type to add custom methods to your models.
+
+Possible uses for the `model` component include the following:
+
+- New operations to operate alongside existing Prisma Client operations, such as `findMany`
+- Encapsulated business logic
+- Repetitive operations
+- Model-specific utilities
+
+
+
+## Add a custom method
+
+Use the `$extends` [client-level method](/6.0/orm/reference/prisma-client-reference#client-methods) to create an _extended client_. An extended client is a variant of the standard Prisma Client that is wrapped by one or more extensions. Use the `model` extension component to add methods to models in your schema.
+
+### Add a custom method to a specific model
+
+To extend a specific model in your schema, use the following structure. This example adds a method to the `user` model.
+
+```ts
+const prisma = new PrismaClient().$extends({
+ name?: '', // (optional) names the extension for error logs
+ model?: {
+ user: { ... } // in this case, we extend the `user` model
+ },
+});
+```
+
+#### Example
+
+The following example adds a method called `signUp` to the `user` model. This method creates a new user with the specified email address:
+
+```ts
+const prisma = new PrismaClient().$extends({
+ model: {
+ user: {
+ async signUp(email: string) {
+ await prisma.user.create({ data: { email } })
+ },
+ },
+ },
+})
+```
+
+You would call `signUp` in your application as follows:
+
+```ts
+const user = await prisma.user.signUp('john@prisma.io')
+```
+
+### Add a custom method to all models in your schema
+
+To extend _all_ models in your schema, use the following structure:
+
+```ts
+const prisma = new PrismaClient().$extends({
+ name?: '', // `name` is an optional field that you can use to name the extension for error logs
+ model?: {
+ $allModels: { ... }
+ },
+})
+```
+
+#### Example
+
+The following example adds an `exists` method to all models.
+
+```ts
+const prisma = new PrismaClient().$extends({
+ model: {
+ $allModels: {
+ async exists(
+ this: T,
+ where: Prisma.Args['where']
+ ): Promise {
+ // Get the current model at runtime
+ const context = Prisma.getExtensionContext(this)
+
+ const result = await (context as any).findFirst({ where })
+ return result !== null
+ },
+ },
+ },
+})
+```
+
+You would call `exists` in your application as follows:
+
+```ts
+// `exists` method available on all models
+await prisma.user.exists({ name: 'Alice' })
+await prisma.post.exists({
+ OR: [{ title: { contains: 'Prisma' } }, { content: { contains: 'Prisma' } }],
+})
+```
+
+## Call a custom method from another custom method
+
+You can call a custom method from another custom method, if the two methods are declared on the same model. For example, you can call a custom method on the `user` model from another custom method on the `user` model. It does not matter if the two methods are declared in the same extension or in different extensions.
+
+To do so, use `Prisma.getExtensionContext(this).methodName`. Note that you cannot use `prisma.user.methodName`. This is because `prisma` is not extended yet, and therefore does not contain the new method.
+
+For example:
+
+```ts
+const prisma = new PrismaClient().$extends({
+ model: {
+ user: {
+ firstMethod() {
+ ...
+ },
+ secondMethod() {
+ Prisma.getExtensionContext(this).firstMethod()
+ }
+ }
+ }
+})
+```
+
+## Get the current model name at runtime
+
+
+
+This feature is available from version 4.9.0.
+
+
+
+You can get the name of the current model at runtime with `Prisma.getExtensionContext(this).$name`. You might use this to write out the model name to a log, to send the name to another service, or to branch your code based on the model.
+
+For example:
+
+```ts
+// `context` refers to the current model
+const context = Prisma.getExtensionContext(this)
+
+// `context.$name` returns the name of the current model
+console.log(context.$name)
+
+// Usage
+await(context as any).findFirst({ args })
+```
+
+Refer to [Add a custom method to all models in your schema](#example-1) for a concrete example for retrieving the current model name at runtime.
+
+## Advanced type safety: type utilities for defining generic extensions
+
+You can improve the type-safety of `model` components in your shared extensions with [type utilities](/orm/prisma-client/client-extensions/type-utilities).
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/110-client.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/110-client.mdx
new file mode 100644
index 0000000000..b37af91d0b
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/110-client.mdx
@@ -0,0 +1,67 @@
+---
+title: '`client`: Add methods to Prisma Client'
+metaTitle: 'Prisma Client extensions: client component'
+metaDescription: 'Extend the functionality of Prisma Client, client component'
+toc_max_heading_level: 4
+---
+
+
+
+
+
+Prisma Client extensions are Generally Available from versions 4.16.0 and later. They were introduced in Preview in version 4.7.0. Make sure you enable the `clientExtensions` Preview feature flag if you are running on a version earlier than 4.16.0.
+
+
+
+You can use the `client` [Prisma Client extensions](/orm/prisma-client/client-extensions) component to add top-level methods to Prisma Client.
+
+
+
+## Extend Prisma Client
+
+Use the `$extends` [client-level method](/6.0/orm/reference/prisma-client-reference#client-methods) to create an _extended client_. An extended client is a variant of the standard Prisma Client that is wrapped by one or more extensions. Use the `client` extension component to add top-level methods to Prisma Client.
+
+To add a top-level method to Prisma Client, use the following structure:
+
+```ts
+const prisma = new PrismaClient().$extends({
+ client?: { ... }
+})
+```
+
+### Example
+
+The following example uses the `client` component to add two methods to Prisma Client:
+
+- `$log` outputs a message.
+- `$totalQueries` returns the number of queries executed by the current client instance. It uses the [metrics](/orm/prisma-client/observability-and-logging/metrics) feature to collect this information.
+
+
+
+To use metrics in your project, you must enable the `metrics` feature flag in the `generator` block of your `schema.prisma` file. [Learn more](/orm/prisma-client/observability-and-logging/metrics#2-enable-the-feature-flag-in-the-prisma-schema-file).
+
+
+
+```ts
+const prisma = new PrismaClient().$extends({
+ client: {
+ $log: (s: string) => console.log(s),
+ async $totalQueries() {
+ const index_prisma_client_queries_total = 0
+ // Prisma.getExtensionContext(this) in the following block
+ // returns the current client instance
+ const metricsCounters = await (
+ await Prisma.getExtensionContext(this).$metrics.json()
+ ).counters
+
+ return metricsCounters[index_prisma_client_queries_total].value
+ },
+ },
+})
+
+async function main() {
+ prisma.$log('Hello world')
+ const totalQueries = await prisma.$totalQueries()
+ console.log(totalQueries)
+}
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/120-query.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/120-query.mdx
new file mode 100644
index 0000000000..2191119d94
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/120-query.mdx
@@ -0,0 +1,302 @@
+---
+title: '`query`: Create custom Prisma Client queries'
+metaTitle: 'Prisma Client extensions: query component'
+metaDescription: 'Extend the functionality of Prisma Client, query component'
+toc_max_heading_level: 4
+---
+
+
+
+
+
+Prisma Client extensions are Generally Available from versions 4.16.0 and later. They were introduced in Preview in version 4.7.0. Make sure you enable the `clientExtensions` Preview feature flag if you are running on a version earlier than 4.16.0.
+
+
+
+You can use the `query` [Prisma Client extensions](/orm/prisma-client/client-extensions) component type to hook into the query life-cycle and modify an incoming query or its result.
+
+You can use Prisma Client extensions `query` component to create independent clients. This provides an alternative to [middlewares](/6.0/orm/prisma-client/client-extensions/middleware). You can bind one client to a specific filter or user, and another client to another filter or user. For example, you might do this to get [user isolation](/orm/prisma-client/client-extensions#extended-clients) in a row-level security (RLS) extension. In addition, unlike middlewares the `query` extension component gives you end-to-end type safety. [Learn more about `query` extensions versus middlewares](#query-extensions-versus-middlewares).
+
+
+
+## Extend Prisma Client query operations
+
+Use the `$extends` [client-level method](/6.0/orm/reference/prisma-client-reference#client-methods) to create an [extended client](/orm/prisma-client/client-extensions#about-prisma-client-extensions). An extended client is a variant of the standard Prisma Client that is wrapped by one or more extensions.
+
+Use the `query` extension component to modify queries. You can modify a custom query in the following:
+
+- [A specific operation in a specific model](#modify-a-specific-operation-in-a-specific-model)
+- [A specific operation in all models of your schema](#modify-a-specific-operation-in-all-models-of-your-schema)
+- [All Prisma Client operations](#modify-all-prisma-client-operations)
+- [All operations in a specific model](#modify-all-operations-in-a-specific-model)
+- [All operations in all models of your schema](#modify-all-operations-in-all-models-of-your-schema)
+- [A specific top-level raw query operation](#modify-a-top-level-raw-query-operation)
+
+To create a custom query, use the following structure:
+
+```ts
+const prisma = new PrismaClient().$extends({
+ name?: 'name',
+ query?: {
+ user: { ... } // in this case, we add a query to the `user` model
+ },
+});
+```
+
+The properties are as follows:
+
+- `name`: (optional) specifies a name for the extension that appears in error logs.
+- `query`: defines a custom query.
+
+### Modify a specific operation in a specific model
+
+The `query` object can contain functions that map to the names of the [Prisma Client operations](/6.0/orm/reference/prisma-client-reference#model-queries), such as `findUnique()`, `findFirst`, `findMany`, `count`, and `create`. The following example modifies `user.findMany` to a use a customized query that finds only users who are older than 18 years:
+
+```ts
+const prisma = new PrismaClient().$extends({
+ query: {
+ user: {
+ async findMany({ model, operation, args, query }) {
+ // take incoming `where` and set `age`
+ args.where = { ...args.where, age: { gt: 18 } }
+
+ return query(args)
+ },
+ },
+ },
+})
+
+await prisma.user.findMany() // returns users whose age is greater than 18
+```
+
+In the above example, a call to `prisma.user.findMany` triggers `query.user.findMany`. Each callback receives a type-safe `{ model, operation, args, query }` object that describes the query. This object has the following properties:
+
+- `model`: the name of the containing model for the query that we want to extend.
+
+ In the above example, the `model` is a string of type `"User"`.
+
+- `operation`: the name of the operation being extended and executed.
+
+ In the above example, the `operation` is a string of type `"findMany"`.
+
+- `args`: the specific query input information to be extended.
+
+ This is a type-safe object that you can mutate before the query happens. You can mutate any of the properties in `args`. Exception: you cannot mutate `include` or `select` because that would change the expected output type and break type safety.
+
+- `query`: a promise for the result of the query.
+
+ - You can use `await` and then mutate the result of this promise, because its value is type-safe. TypeScript catches any unsafe mutations on the object.
+
+### Modify a specific operation in all models of your schema
+
+To extend the queries in all the models of your schema, use `$allModels` instead of a specific model name. For example:
+
+```ts
+const prisma = new PrismaClient().$extends({
+ query: {
+ $allModels: {
+ async findMany({ model, operation, args, query }) {
+ // set `take` and fill with the rest of `args`
+ args = { ...args, take: 100 }
+
+ return query(args)
+ },
+ },
+ },
+})
+```
+
+### Modify all operations in a specific model
+
+Use `$allOperations` to extend all operations in a specific model.
+
+For example, the following code applies a custom query to all operations on the `user` model:
+
+```ts
+const prisma = new PrismaClient().$extends({
+ query: {
+ user: {
+ $allOperations({ model, operation, args, query }) {
+ /* your custom logic here */
+ return query(args)
+ },
+ },
+ },
+})
+```
+
+### Modify all Prisma Client operations
+
+Use the `$allOperations` method to modify all query methods present in Prisma Client. The `$allOperations` can be used on both model operations and raw queries.
+
+You can modify all methods as follows:
+
+```ts
+const prisma = new PrismaClient().$extends({
+ query: {
+ $allOperations({ model, operation, args, query }) {
+ /* your custom logic for modifying all Prisma Client operations here */
+ return query(args)
+ },
+ },
+})
+```
+
+In the event a [raw query](/orm/prisma-client/using-raw-sql/raw-queries) is invoked, the `model` argument passed to the callback will be `undefined`.
+
+For example, you can use the `$allOperations` method to log queries as follows:
+
+```ts
+const prisma = new PrismaClient().$extends({
+ query: {
+ async $allOperations({ operation, model, args, query }) {
+ const start = performance.now()
+ const result = await query(args)
+ const end = performance.now()
+ const time = end - start
+ console.log(
+ util.inspect(
+ { model, operation, args, time },
+ { showHidden: false, depth: null, colors: true }
+ )
+ )
+ return result
+ },
+ },
+})
+```
+
+### Modify all operations in all models of your schema
+
+Use `$allModels` and `$allOperations` to extend all operations in all models of your schema.
+
+To apply a custom query to all operations on all models of your schema:
+
+```ts
+const prisma = new PrismaClient().$extends({
+ query: {
+ $allModels: {
+ $allOperations({ model, operation, args, query }) {
+ /* your custom logic for modifying all operations on all models here */
+ return query(args)
+ },
+ },
+ },
+})
+```
+
+### Modify a top-level raw query operation
+
+To apply custom behavior to a specific top-level raw query operation, use the name of a top-level raw query function instead of a model name:
+
+
+
+
+```ts copy
+const prisma = new PrismaClient().$extends({
+ query: {
+ $queryRaw({ args, query, operation }) {
+ // handle $queryRaw operation
+ return query(args)
+ },
+ $executeRaw({ args, query, operation }) {
+ // handle $executeRaw operation
+ return query(args)
+ },
+ $queryRawUnsafe({ args, query, operation }) {
+ // handle $queryRawUnsafe operation
+ return query(args)
+ },
+ $executeRawUnsafe({ args, query, operation }) {
+ // handle $executeRawUnsafe operation
+ return query(args)
+ },
+ },
+})
+```
+
+
+
+
+```ts copy
+const prisma = new PrismaClient().$extends({
+ query: {
+ $runCommandRaw({ args, query, operation }) {
+ // handle $runCommandRaw operation
+ return query(args)
+ },
+ },
+})
+```
+
+
+
+
+### Mutate the result of a query
+
+You can use `await` and then mutate the result of the `query` promise.
+
+```ts
+const prisma = new PrismaClient().$extends({
+ query: {
+ user: {
+ async findFirst({ model, operation, args, query }) {
+ const user = await query(args)
+
+ if (user.password !== undefined) {
+ user.password = '******'
+ }
+
+ return user
+ },
+ },
+ },
+})
+```
+
+
+
+We include the above example to show that this is possible. However, for performance reasons we recommend that you use the [`result` component type](/orm/prisma-client/client-extensions/result) to override existing fields. The `result` component type usually gives better performance in this situation because it computes only on access. The `query` component type computes after query execution.
+
+
+
+## Wrap a query into a batch transaction
+
+You can wrap your extended queries into a [batch transaction](/orm/prisma-client/queries/transactions). For example, you can use this to enact row-level security (RLS).
+
+The following example extends `findFirst` so that it runs in a batch transaction.
+
+```ts
+const transactionExtension = Prisma.defineExtension((prisma) =>
+ prisma.$extends({
+ query: {
+ user: {
+ // Get the input `args` and a callback to `query`
+ async findFirst({ args, query, operation }) {
+ const [result] = await prisma.$transaction([query(args)]) // wrap the query in a batch transaction, and destructure the result to return an array
+ return result // return the first result found in the array
+ },
+ },
+ },
+ })
+)
+const prisma = new PrismaClient().$extends(transactionExtension)
+```
+
+## Query extensions versus middlewares
+
+You can use query extensions or [middlewares](/6.0/orm/prisma-client/client-extensions/middleware) to hook into the query life-cycle and modify an incoming query or its result. Client extensions and middlewares differ in the following ways:
+
+- Middlewares always apply globally to the same client. Client extensions are isolated, unless you deliberately combine them. [Learn more about client extensions](/orm/prisma-client/client-extensions#about-prisma-client-extensions).
+ - For example, in a row-level security (RLS) scenario, you can keep each user in an entirely separate client. With middlewares, all users are active in the same client.
+- During application execution, with extensions you can choose from one or more extended clients, or the standard Prisma Client. With middlewares, you cannot choose which client to use, because there is only one global client.
+- Extensions benefit from end-to-end type safety and inference, but middlewares don't.
+
+You can use Prisma Client extensions in all scenarios where middlewares can be used.
+
+### If you use the `query` extension component and middlewares
+
+If you use the `query` extension component and middlewares in your project, then the following rules and priorities apply:
+
+- In your application code, you must declare all your middlewares on the main Prisma Client instance. You cannot declare them on an extended client.
+- In situations where middlewares and extensions with a `query` component execute, Prisma Client executes the middlewares before it executes the extensions with the `query` component. Prisma Client executes the individual middlewares and extensions in the order in which you instantiated them with `$use` or `$extends`.
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/130-result.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/130-result.mdx
new file mode 100644
index 0000000000..de3cb7a2b6
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/130-result.mdx
@@ -0,0 +1,223 @@
+---
+title: '`result`: Add custom fields and methods to query results'
+metaTitle: 'Prisma Client extensions: result component'
+metaDescription: 'Extend the functionality of Prisma Client, result component'
+toc_max_heading_level: 4
+---
+
+
+
+
+
+Prisma Client extensions are Generally Available from versions 4.16.0 and later. They were introduced in Preview in version 4.7.0. Make sure you enable the `clientExtensions` Preview feature flag if you are running on a version earlier than 4.16.0.
+
+
+
+You can use the `result` [Prisma Client extensions](/orm/prisma-client/client-extensions) component type to add custom fields and methods to query results.
+
+
+
+Use the `$extends` [client-level method](/6.0/orm/reference/prisma-client-reference#client-methods) to create an _extended client_. An extended client is a variant of the standard Prisma Client that is wrapped by one or more extensions.
+
+To add a custom [field](#add-a-custom-field-to-query-results) or [method](#add-a-custom-method-to-the-result-object) to query results, use the following structure. In this example, we add the custom field `myComputedField` to the result of a `user` model query.
+
+```ts
+const prisma = new PrismaClient().$extends({
+ name?: 'name',
+ result?: {
+ user: { // in this case, we extend the `user` model
+ myComputedField: { // the name of the new computed field
+ needs: { ... },
+ compute() { ... }
+ },
+ },
+ },
+});
+```
+
+The parameters are as follows:
+
+- `name`: (optional) specifies a name for the extension that appears in error logs.
+- `result`: defines new fields and methods to the query results.
+- `needs`: an object which describes the dependencies of the result field.
+- `compute`: a method that defines how the virtual field is computed when it is accessed.
+
+## Add a custom field to query results
+
+You can use the `result` extension component to add fields to query results. These fields are computed at runtime and are type-safe.
+
+In the following example, we add a new virtual field called `fullName` to the `user` model.
+
+```ts
+const prisma = new PrismaClient().$extends({
+ result: {
+ user: {
+ fullName: {
+ // the dependencies
+ needs: { firstName: true, lastName: true },
+ compute(user) {
+ // the computation logic
+ return `${user.firstName} ${user.lastName}`
+ },
+ },
+ },
+ },
+})
+
+const user = await prisma.user.findFirst()
+
+// return the user's full name, such as "John Doe"
+console.log(user.fullName)
+```
+
+In above example, the input `user` of `compute` is automatically typed according to the object defined in `needs`. `firstName` and `lastName` are of type `string`, because they are specified in `needs`. If they are not specified in `needs`, then they cannot be accessed.
+
+## Re-use a computed field in another computed field
+
+The following example computes a user's title and full name in a type-safe way. `titleFullName` is a computed field that reuses the `fullName` computed field.
+
+```ts
+const prisma = new PrismaClient()
+ .$extends({
+ result: {
+ user: {
+ fullName: {
+ needs: { firstName: true, lastName: true },
+ compute(user) {
+ return `${user.firstName} ${user.lastName}`
+ },
+ },
+ },
+ },
+ })
+ .$extends({
+ result: {
+ user: {
+ titleFullName: {
+ needs: { title: true, fullName: true },
+ compute(user) {
+ return `${user.title} (${user.fullName})`
+ },
+ },
+ },
+ },
+ })
+```
+
+### Considerations for fields
+
+- For performance reasons, Prisma Client computes results on access, not on retrieval.
+- You can only create computed fields that are based on scalar fields.
+- You can only use computed fields with `select` and you cannot aggregate them. For example:
+
+ ```ts
+ const user = await prisma.user.findFirst({
+ select: { email: true },
+ })
+ console.log(user.fullName) // undefined
+ ```
+
+## Add a custom method to the result object
+
+You can use the `result` component to add methods to query results. The following example adds a new method, `save` to the result object.
+
+```ts
+const prisma = new PrismaClient().$extends({
+ result: {
+ user: {
+ save: {
+ needs: { id: true },
+ compute(user) {
+ return () =>
+ prisma.user.update({ where: { id: user.id }, data: user })
+ },
+ },
+ },
+ },
+})
+
+const user = await prisma.user.findUniqueOrThrow({ where: { id: someId } })
+user.email = 'mynewmail@mailservice.com'
+await user.save()
+```
+
+## Using `omit` query option with `result` extension component
+
+You can use the [`omit` (Preview) option](/6.0/orm/reference/prisma-client-reference#omit) with [custom fields](#add-a-custom-field-to-query-results) and fields needed by custom fields.
+
+### `omit` fields needed by custom fields from query result
+
+If you `omit` a field that is a dependency of a custom field, it will still be read from the database even though it will not be included in the query result.
+
+The following example omits the `password` field, which is a dependency of the custom field `sanitizedPassword`:
+
+```ts
+const xprisma = prisma.$extends({
+ result: {
+ user: {
+ sanitizedPassword: {
+ needs: { password: true },
+ compute(user) {
+ return sanitize(user.password)
+ },
+ },
+ },
+ },
+})
+
+const user = await xprisma.user.findFirstOrThrow({
+ omit: {
+ password: true,
+ },
+})
+```
+
+In this case, although `password` is omitted from the result, it will still be queried from the database because it is a dependency of the `sanitizedPassword` custom field.
+
+### `omit` custom field and dependencies from query result
+
+To ensure omitted fields are not queried from the database at all, you must omit both the custom field and its dependencies.
+
+The following example omits both the custom field `sanitizedPassword` and the dependent `password` field:
+
+```ts
+const xprisma = prisma.$extends({
+ result: {
+ user: {
+ sanitizedPassword: {
+ needs: { password: true },
+ compute(user) {
+ return sanitize(user.password)
+ },
+ },
+ },
+ },
+})
+
+const user = await xprisma.user.findFirstOrThrow({
+ omit: {
+ sanitizedPassword: true,
+ password: true,
+ },
+})
+```
+In this case, omitting both `password` and `sanitizedPassword` will exclude both from the result as well as prevent the `password` field from being read from the database.
+
+## Limitation
+As of now, Prisma Client's result extension component does not support relation fields. This means that you cannot create custom fields or methods based on related models or fields in a relational relationship (e.g., user.posts, post.author). The needs parameter can only reference scalar fields within the same model. Follow [issue #20091 on GitHub](https://github.com/prisma/prisma/issues/20091).
+
+
+```ts
+const prisma = new PrismaClient().$extends({
+ result: {
+ user: {
+ postsCount: {
+ needs: { posts: true }, // This will not work because posts is a relation field
+ compute(user) {
+ return user.posts.length; // Accessing a relation is not allowed
+ },
+ },
+ },
+ },
+})
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/140-shared-extensions/100-permit-rbac.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/140-shared-extensions/100-permit-rbac.mdx
new file mode 100644
index 0000000000..3c5501d9d4
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/140-shared-extensions/100-permit-rbac.mdx
@@ -0,0 +1,213 @@
+---
+title: 'Fine-Grained Authorization (Permit)'
+metaTitle: ''
+metaDescription: 'Learn how to implement RBAC, ABAC, and ReBAC authorization in your Prisma applications'
+toc_max_heading_level: 4
+---
+
+
+
+Database operations often require careful control over who can access or modify which data. While Prisma ORM excels at data modeling and database access, it doesn't include built-in authorization capabilities. This guide shows how to implement fine-grained authorization in your Prisma applications using the `@permitio/permit-prisma` extension.
+
+Fine-grained authorization (FGA) provides detailed and precise control over what data users can access or modify at a granular level. Without proper authorization, your application might expose sensitive data or allow unauthorized modifications, creating security vulnerabilities.
+
+## Access control models
+
+This extension supports three access control models from Permit.io:
+
+### Role-based Access Control (RBAC)
+
+**What it is**: Users are assigned roles (Admin, Editor, Viewer) with predefined permissions to perform actions on resource types.
+
+**Example**: An "Editor" role can update any document in the system.
+
+**Best for**: Simple permission structures where access is determined by job function or user level.
+
+### Attribute-Based Access Control (ABAC)
+
+**What it is**: Access decisions based on attributes of users, resources, or environment.
+
+**Examples**:
+
+- Allow access if `user.department == document.department`
+- Allow updates if `document.status == "DRAFT"`
+
+**How it works with the extension**: When `enableAttributeSync` is on, resource attributes are automatically synced to Permit.io for policy evaluation.
+
+**Best for**: Dynamic rules that depend on context or data properties.
+
+### Relationship-Based Access Control (ReBAC)
+
+**What it is**: Permissions based on relationships between users and specific resource instances.
+
+**Example**: A user is an "Owner" of document-123 but just a "Viewer" of document-456.
+
+**How it works with the extension**:
+
+- Resource instances are synced to Permit.io (with `enableResourceSync: true`)
+- Permission checks include the specific resource instance ID
+
+**Best for**: Collaborative applications where users need different permissions on different instances of the same resource type.
+
+### Choosing the right model
+
+- **RBAC**: When you need simple, role-based access control
+- **ABAC**: When decisions depend on data properties or contextual information
+- **ReBAC**: When users need different permissions on different instances
+
+## Usage
+
+### Prerequisites
+
+Before implementing fine-grained authorization with Prisma, make sure you have:
+
+- A Prisma application with existing models and queries
+- Basic understanding of authorization concepts
+- Node.js and npm installed
+
+### Installation
+
+Install the extension alongside Prisma Client:
+
+```terminal
+npm install @permitio/permit-prisma @prisma/client
+```
+
+You'll also need to sign up for a [Permit account](https://app.permit.io) to define your authorization policies.
+
+> **Note:**
+> Ensure that the Permit PDP container is running. It is recommended to run it using Docker for better performance, security, and availability. For instructions, refer to the Permit documentation: [Deploy Permit to Production](https://docs.permit.io/how-to/deploy/deploy-to-production/) and [PDP Overview](https://docs.permit.io/concepts/pdp/overview/).
+
+## Basic setup
+
+First, extend your Prisma Client with the Permit extension:
+
+```typescript
+import { PrismaClient } from "@prisma/client";
+import { createPermitClientExtension } from "@permitio/permit-prisma";
+
+const prisma = new PrismaClient().$extends(
+ createPermitClientExtension({
+ permitConfig: {
+ token: process.env.PERMIT_API_KEY, // Your Permit API key
+ pdp: "http://localhost:7766", // PDP address (local or cloud)
+ },
+ enableAutomaticChecks: true // Automatically enforce permissions
+ })
+);
+```
+
+## Implementing RBAC (Role-Based Access Control)
+
+RBAC uses roles to determine access permissions. For example, "Admin" roles can perform all actions while "Viewer" roles can only read data.
+
+1. **Define resources and actions in Permit.io dashboard**:
+ - Create resources matching your Prisma models (e.g., "document")
+ - Define actions (e.g., "create", "read", "update", "delete")
+ - Create roles with permission sets (e.g., "admin", "editor", "viewer")
+2. **Set the active user in your code**:
+ ```typescript
+ // Set the current user context before performing operations
+ prisma.$permit.setUser("john@example.com");
+
+ // All subsequent operations will be checked against this user's permissions
+ const documents = await prisma.document.findMany();
+ ```
+
+## Implementing ABAC (Attribute-Based Access Control)
+
+ABAC extends access control by considering user attributes, resource attributes, and context.
+
+1. **Configure the extension for ABAC**:
+ ```typescript
+ const prisma = new PrismaClient().$extends(
+ createPermitClientExtension({
+ permitConfig: { token: process.env.PERMIT_API_KEY, pdp: "http://localhost:7766" },
+ enableAutomaticChecks: true,
+ })
+ );
+ ```
+2. **Set user with attributes:**
+ ```typescript
+ prisma.$permit.setUser({
+ key: "doctor@hospital.com",
+ attributes: { department: "cardiology" }
+ });
+
+ // Will succeed only if user department matches record department (per policy)
+ const records = await prisma.medicalRecord.findMany({
+ where: { department: "cardiology" }
+ });
+ ```
+
+## Implementing ReBAC (Relationship-Based Access Control)
+
+ReBAC models permissions based on relationships between users and specific resource instances.
+
+1. **Configure the extension for ReBAC**:
+ ```typescript
+ const prisma = new PrismaClient().$extends(
+ createPermitClientExtension({
+ permitConfig: { token: process.env.PERMIT_API_KEY, pdp: "http://localhost:7766" },
+ accessControlModel: "rebac",
+ enableAutomaticChecks: true,
+ enableResourceSync: true, // Sync resource instances with Permit.io
+ enableDataFiltering: true // Filter queries by permissions
+ })
+ );
+ ```
+
+2. ** Access instance-specific resources:**
+ ```typescript
+ prisma.$permit.setUser("owner@example.com");
+
+ // Will only succeed if the user has permission on this specific file
+ const file = await prisma.file.findUnique({
+ where: { id: "file-123" }
+ });
+ ```
+
+## Manual permission checks
+
+For more control, you can perform explicit permission checks:
+
+```typescript
+// Check if user can update a document
+const canUpdate = await prisma.$permit.check(
+ "john@example.com", // user
+ "update", // action
+ "document" // resource
+);
+
+if (canUpdate) {
+ await prisma.document.update({
+ where: { id: "doc-123" },
+ data: { title: "Updated Title" }
+ });
+}
+
+// Or enforce permissions (throws if denied)
+await prisma.$permit.enforceCheck(
+ "john@example.com",
+ "delete",
+ { type: "document", key: "doc-123" }
+);
+```
+
+## Common use cases
+
+Here are some common scenarios where fine-grained authorization is valuable:
+
+- **Multi-tenant applications**: Isolate data between different customers
+- **Healthcare applications**: Ensure patient data is only accessible to authorized staff
+- **Collaborative platforms**: Grant different permissions on shared resources
+- **Content management systems**: Control who can publish, edit, or view content
+
+## Summary
+
+By integrating the `@permitio/permit-prisma` extension with your Prisma ORM application, you can implement sophisticated authorization policies that protect your data and ensure users only access what they're permitted to see. The extension supports all major authorization models (RBAC, ABAC, ReBAC) and provides both automatic and manual permission enforcement.
+
+## Next steps
+
+- [Create a free Permit.io account](https://app.permit.io)
+- [View the full extension documentation](https://github.com/permitio/permit-prisma)
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/140-shared-extensions/index.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/140-shared-extensions/index.mdx
new file mode 100644
index 0000000000..e5328b467d
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/140-shared-extensions/index.mdx
@@ -0,0 +1,154 @@
+---
+title: 'Shared Prisma Client extensions'
+metaTitle: 'Shared Prisma Client extensions'
+metaDescription: 'Share extensions or import shared extensions into your Prisma project'
+toc_max_heading_level: 4
+---
+
+You can share your [Prisma Client extensions](/orm/prisma-client/client-extensions) with other users, either as packages or as modules, and import extensions that other users create into your project.
+
+If you would like to build a shareable extension, we also recommend using the [`prisma-client-extension-starter`](https://github.com/prisma/prisma-client-extension-starter) template.
+
+To explore examples of Prisma's official Client extensions and those made by the community, visit [this](/orm/prisma-client/client-extensions/extension-examples) page.
+
+## Install a shared, packaged extension
+
+In your project, you can install any Prisma Client extension that another user has published to `npm`. To do so, run the following command:
+
+```terminal
+npm install prisma-extension-
+```
+
+For example, if the package name for an available extension is `prisma-extension-find-or-create`, you could install it as follows:
+
+```terminal
+npm install prisma-extension-find-or-create
+```
+
+To import the `find-or-create` extension from the example above, and wrap your client instance with it, you could use the following code. This example assumes that the extension name is `findOrCreate`.
+
+```ts
+import findOrCreate from 'prisma-extension-find-or-create'
+import { PrismaClient } from '../generated/prisma/client'
+const prisma = new PrismaClient()
+const xprisma = prisma.$extends(findOrCreate)
+const user = await xprisma.user.findOrCreate()
+```
+
+When you call a method in an extension, use the constant name from your `$extends` statement, not `prisma`. In the above example, `xprisma.user.findOrCreate` works, but `prisma.user.findOrCreate` does not, because the original `prisma` is not modified.
+
+## Create a shareable extension
+
+When you want to create extensions other users can use, and that are not tailored just for your schema, Prisma ORM provides utilities to allow you to create shareable extensions.
+
+To create a shareable extension:
+
+1. Define the extension as a module using `Prisma.defineExtension`
+2. Use one of the methods that begin with the `$all` prefix such as [`$allModels`](/orm/prisma-client/client-extensions/model#add-a-custom-method-to-all-models-in-your-schema) or [`$allOperations`](/orm/prisma-client/client-extensions/query#modify-all-prisma-client-operations)
+
+### Define an extension
+
+Use the `Prisma.defineExtension` method to make your extension shareable. You can use it to package the extension to either separate your extensions into a separate file or share it with other users as an npm package.
+
+The benefit of `Prisma.defineExtension` is that it provides strict type checks and auto completion for authors of extension in development and users of shared extensions.
+
+### Use a generic method
+
+Extensions that contain methods under `$allModels` apply to every model instead of a specific one. Similarly, methods under `$allOperations` apply to a client instance as a whole and not to a named component, e.g. `result` or `query`.
+
+You do not need to use the `$all` prefix with the [`client`](/orm/prisma-client/client-extensions/client) component, because the `client` component always applies to the client instance.
+
+For example, a generic extension might take the following form:
+
+```ts
+export default Prisma.defineExtension({
+ name: 'prisma-extension-find-or-create', //Extension name
+ model: {
+ $allModels: {
+ // new method
+ findOrCreate(/* args */) {
+ /* code for the new method */
+ return query(args)
+ },
+ },
+ },
+})
+```
+
+Refer to the following pages to learn the different ways you can modify Prisma Client operations:
+
+- [Modify all Prisma Client operations](/orm/prisma-client/client-extensions/query#modify-all-prisma-client-operations)
+- [Modify a specific operation in all models of your schema](/orm/prisma-client/client-extensions/query#modify-a-specific-operation-in-all-models-of-your-schema)
+- [Modify all operations in all models of your schema](/orm/prisma-client/client-extensions/query#modify-all-operations-in-all-models-of-your-schema)
+
+
+ For versions earlier than 4.16.0
+
+The `Prisma` import is available from a different path shown in the snippet below:
+
+```ts
+import { Prisma } from '@prisma/client/scripts/default-index'
+
+export default Prisma.defineExtension({
+ name: 'prisma-extension-',
+})
+```
+
+
+
+### Publishing the shareable extension to npm
+
+You can then share the extension on `npm`. When you choose a package name, we recommend that you use the `prisma-extension-` convention, to make it easier to find and install.
+
+### Call a client-level method from your packaged extension
+
+
+:::warning
+
+There's currently a limitation for extensions that reference a `PrismaClient` and call a client-level method, like the example below.
+
+If you trigger the extension from inside a [transaction](/orm/prisma-client/queries/transactions) (interactive or batched), the extension code will issue the queries in a new connection and ignore the current transaction context.
+
+Learn more in this issue on GitHub: [Client extensions that require use of a client-level method silently ignore transactions](https://github.com/prisma/prisma/issues/20678).
+
+:::
+
+
+In the following situations, you need to refer to a Prisma Client instance that your extension wraps:
+
+- When you want to use a [client-level method](/6.0/orm/reference/prisma-client-reference#client-methods), such as `$queryRaw`, in your packaged extension.
+- When you want to chain multiple `$extends` calls in your packaged extension.
+
+However, when someone includes your packaged extension in their project, your code cannot know the details of the Prisma Client instance.
+
+You can refer to this client instance as follows:
+
+```ts
+Prisma.defineExtension((client) => {
+ // The Prisma Client instance that the extension user applies the extension to
+ return client.$extends({
+ name: 'prisma-extension-',
+ })
+})
+```
+
+For example:
+
+```ts
+export default Prisma.defineExtension((client) => {
+ return client.$extends({
+ name: 'prisma-extension-find-or-create',
+ query: {
+ $allModels: {
+ async findOrCreate({ args, query, operation }) {
+ return (await client.$transaction([query(args)]))[0]
+ },
+ },
+ },
+ })
+})
+```
+
+### Advanced type safety: type utilities for defining generic extensions
+
+You can improve the type-safety of your shared extensions using [type utilities](/orm/prisma-client/client-extensions/type-utilities).
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/150-type-utilities.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/150-type-utilities.mdx
new file mode 100644
index 0000000000..e8086d3c03
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/150-type-utilities.mdx
@@ -0,0 +1,101 @@
+---
+title: 'Type utilities'
+metaTitle: 'Prisma Client Extensions: Type utilities'
+metaDescription: 'Advanced type safety: improve type safety in your custom model methods'
+---
+
+
+
+Several type utilities exist within Prisma Client that can assist in the creation of highly type-safe extensions.
+
+
+
+## Type Utilities
+
+[Prisma Client type utilities](/orm/prisma-client/type-safety) are utilities available within your application and Prisma Client extensions and provide useful ways of constructing safe and extendable types for your extension.
+
+The type utilities available are:
+
+- `Exact`: Enforces strict type safety on `Input`. `Exact` makes sure that a generic type `Input` strictly complies with the type that you specify in `Shape`. It [narrows](https://www.typescriptlang.org/docs/handbook/2/narrowing.html) `Input` down to the most precise types.
+- `Args`: Retrieves the input arguments for any given model and operation. This is particularly useful for extension authors who want to do the following:
+ - Re-use existing types to extend or modify them.
+ - Benefit from the same auto-completion experience as on existing operations.
+- `Result`: Takes the input arguments and provides the result for a given model and operation. You would usually use this in conjunction with `Args`. As with `Args`, `Result` helps you to re-use existing types to extend or modify them.
+- `Payload`: Retrieves the entire structure of the result, as scalars and relations objects for a given model and operation. For example, you can use this to determine which keys are scalars or objects at a type level.
+
+The following example creates a new operation, `exists`, based on `findFirst`. It has all of the arguments that `findFirst`.
+
+```ts
+const prisma = new PrismaClient().$extends({
+ model: {
+ $allModels: {
+ // Define a new `exists` operation on all models
+ // T is a generic type that corresponds to the current model
+ async exists(
+ // `this` refers to the current type, e.g. `prisma.user` at runtime
+ this: T,
+
+ // The `exists` function will use the `where` arguments from the current model, `T`, and the `findFirst` operation
+ where: Prisma.Args['where']
+ ): Promise {
+ // Retrieve the current model at runtime
+ const context = Prisma.getExtensionContext(this)
+
+ // Prisma Client query that retrieves data based
+ const result = await (context as any).findFirst({ where })
+ return result !== null
+ },
+ },
+ },
+})
+
+async function main() {
+ const user = await prisma.user.exists({ name: 'Alice' })
+ const post = await prisma.post.exists({
+ OR: [
+ { title: { contains: 'Prisma' } },
+ { content: { contains: 'Prisma' } },
+ ],
+ })
+}
+```
+
+## Add a custom property to a method
+
+The following example illustrates how you can add custom arguments, to a method in an extension:
+
+```ts highlight=16
+type CacheStrategy = {
+ swr: number
+ ttl: number
+}
+
+const prisma = new PrismaClient().$extends({
+ model: {
+ $allModels: {
+ findMany(
+ this: T,
+ args: Prisma.Exact<
+ A,
+ // For the `findMany` method, use the arguments from model `T` and the `findMany` method
+ // and intersect it with `CacheStrategy` as part of `findMany` arguments
+ Prisma.Args & CacheStrategy
+ >
+ ): Prisma.Result {
+ // method implementation with the cache strategy
+ },
+ },
+ },
+})
+
+async function main() {
+ await prisma.post.findMany({
+ cacheStrategy: {
+ ttl: 360,
+ swr: 60,
+ },
+ })
+}
+```
+
+The example here is only conceptual. For the actual caching to work, you will have to implement the logic. If you're interested in a caching extension/ service, we recommend taking a look at [Prisma Accelerate](https://www.prisma.io/accelerate).
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/200-extension-examples.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/200-extension-examples.mdx
new file mode 100644
index 0000000000..645cdb498d
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/200-extension-examples.mdx
@@ -0,0 +1,69 @@
+---
+title: 'Shared packages & examples'
+metaTitle: 'Prisma Client extensions | Shared packages & examples'
+metaDescription: 'Explore the Prisma Client extensions that have been built by Prisma and its community'
+---
+
+## Extensions made by Prisma
+
+The following is a list of extensions we've built at Prisma:
+
+| Extension | Description |
+| :------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| [`@prisma/extension-accelerate`](https://www.npmjs.com/package/@prisma/extension-accelerate) | Enables [Accelerate](https://www.prisma.io/accelerate), a global database cache available in 300+ locations with built-in connection pooling |
+| [`@prisma/extension-read-replicas`](https://github.com/prisma/extension-read-replicas) | Adds read replica support to Prisma Client |
+
+## Extensions made by Prisma's community
+
+The following is a list of extensions created by the community. If you want to create your own package, refer to the [Shared Prisma Client extensions](/orm/prisma-client/client-extensions/shared-extensions) documentation.
+
+| Extension | Description |
+| :--------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------- |
+| [`prisma-extension-supabase-rls`](https://github.com/dthyresson/prisma-extension-supabase-rls) | Adds support for Supabase Row Level Security with Prisma |
+| [`prisma-extension-bark`](https://github.com/adamjkb/bark) | Implements the Materialized Path pattern that allows you to easily create and interact with tree structures in Prisma |
+| [`prisma-cursorstream`](https://github.com/etabits/prisma-cursorstream) | Adds cursor-based streaming |
+| [`prisma-gpt`](https://github.com/aliyeysides/prisma-gpt) | Lets you query your database using natural language |
+| [`prisma-extension-caching`](https://github.com/isaev-the-poetry/prisma-extension-caching) | Adds the ability to cache complex queries |
+| [`prisma-extension-cache-manager`](https://github.com/random42/prisma-extension-cache-manager) | Caches model queries with any [cache-manager](https://www.npmjs.com/package/cache-manager) compatible cache |
+| [`prisma-extension-random`](https://github.com/nkeil/prisma-extension-random) | Lets you query for random rows in your database |
+| [`prisma-paginate`](https://github.com/sandrewTx08/prisma-paginate) | Adds support for paginating read queries |
+| [`prisma-extension-streamdal`](https://github.com/streamdal/prisma-extension-streamdal) | Adds support for Code-Native data pipelines using Streamdal |
+| [`prisma-rbac`](https://github.com/multipliedtwice/prisma-rbac) | Adds customizable role-based access control |
+| [`prisma-extension-redis`](https://github.com/yxx4c/prisma-extension-redis) | Extensive Prisma extension designed for efficient caching and cache invalidation using Redis and Dragonfly Databases |
+| [`prisma-cache-extension`](https://github.com/Shikhar97/prisma-cache) | Prisma extension for caching and invalidating cache with Redis(other Storage options to be supported) |
+| [`prisma-extension-casl`](https://github.com/dennemark/prisma-extension-casl) | Prisma client extension that utilizes CASL to enforce authorization logic on most simple and nested queries. |
+| [`prisma-emitter-extension`](https://github.com/feggaa/prisma-emitter-extension) | Prisma extension for emit events on CRUD operations based on configurable listeners. |
+
+If you have built an extension and would like to see it featured, feel free to add it to the list by opening a pull request.
+
+## Examples
+
+:::info
+
+The following example extensions are provided as examples only, and without warranty. They are supposed to show how Prisma Client extensions can be created using approaches documented here. We recommend using these examples as a source of inspiration for building your own extensions.
+
+:::
+
+| Example | Description |
+| :------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------ |
+| [`audit-log-context`](https://github.com/prisma/prisma-client-extensions/tree/main/audit-log-context) | Provides the current user's ID as context to Postgres audit log triggers |
+| [`callback-free-itx`](https://github.com/prisma/prisma-client-extensions/tree/main/callback-free-itx) | Adds a method to start interactive transactions without callbacks |
+| [`computed-fields`](https://github.com/prisma/prisma-client-extensions/tree/main/computed-fields) | Adds virtual / computed fields to result objects |
+| [`input-transformation`](https://github.com/prisma/prisma-client-extensions/tree/main/input-transformation) | Transforms the input arguments passed to Prisma Client queries to filter the result set |
+| [`input-validation`](https://github.com/prisma/prisma-client-extensions/tree/main/input-validation) | Runs custom validation logic on input arguments passed to mutation methods |
+| [`instance-methods`](https://github.com/prisma/prisma-client-extensions/tree/main/instance-methods) | Adds Active Record-like methods like `save()` and `delete()` to result objects |
+| [`json-field-types`](https://github.com/prisma/prisma-client-extensions/tree/main/json-field-types) | Uses strongly-typed runtime parsing for data stored in JSON columns |
+| [`model-filters`](https://github.com/prisma/prisma-client-extensions/tree/main/model-filters) | Adds reusable filters that can composed into complex `where` conditions for a model |
+| [`obfuscated-fields`](https://github.com/prisma/prisma-client-extensions/tree/main/obfuscated-fields) | Prevents sensitive data (e.g. `password` fields) from being included in results |
+| [`query-logging`](https://github.com/prisma/prisma-client-extensions/tree/main/query-logging) | Wraps Prisma Client queries with simple query timing and logging |
+| [`readonly-client`](https://github.com/prisma/prisma-client-extensions/tree/main/readonly-client) | Creates a client that only allows read operations |
+| [`retry-transactions`](https://github.com/prisma/prisma-client-extensions/tree/main/retry-transactions) | Adds a retry mechanism to transactions with exponential backoff and jitter |
+| [`row-level-security`](https://github.com/prisma/prisma-client-extensions/tree/main/row-level-security) | Uses Postgres row-level security policies to isolate data a multi-tenant application |
+| [`static-methods`](https://github.com/prisma/prisma-client-extensions/tree/main/static-methods) | Adds custom query methods to Prisma Client models |
+| [`transformed-fields`](https://github.com/prisma/prisma-client-extensions/tree/main/transformed-fields) | Demonstrates how to use result extensions to transform query results and add i18n to an app |
+| [`exists-method`](https://github.com/prisma/prisma-client-extensions/tree/main/exists-fn) | Demonstrates how to add an `exists` method to all your models |
+| [`update-delete-ignore-not-found `](https://github.com/prisma/prisma-client-extensions/tree/main/update-delete-ignore-not-found) | Demonstrates how to add the `updateIgnoreOnNotFound` and `deleteIgnoreOnNotFound` methods to all your models. |
+
+## Going further
+
+- Learn more about [Prisma Client extensions](/orm/prisma-client/client-extensions).
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/500-middleware/100-soft-delete-middleware.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/500-middleware/100-soft-delete-middleware.mdx
new file mode 100644
index 0000000000..159bc9e6fe
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/500-middleware/100-soft-delete-middleware.mdx
@@ -0,0 +1,681 @@
+---
+title: 'Middleware sample: soft delete'
+metaTitle: 'Middleware sample: soft delete (Reference)'
+metaDescription: 'How to use middleware to intercept deletes and set a field value instead of deleting the record.'
+toc_max_heading_level: 4
+---
+
+
+
+The following sample uses [middleware](/6.0/orm/prisma-client/client-extensions/middleware) to perform a **soft delete**. Soft delete means that a record is **marked as deleted** by changing a field like `deleted` to `true` rather than actually being removed from the database. Reasons to use a soft delete include:
+
+- Regulatory requirements that mean you have to keep data for a certain amount of time
+- 'Trash' / 'bin' functionality that allows users to restore content that was deleted
+
+
+
+**Note:** This page demonstrates a sample use of middleware. We do not intend the sample to be a fully functional soft delete feature and it does not cover all edge cases. For example, the middleware does not work with nested writes and therefore won't capture situations where you use `delete` or `deleteMany` as an option e.g. in an `update` query.
+
+
+
+This sample uses the following schema - note the `deleted` field on the `Post` model:
+
+```prisma highlight=28;normal
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+
+generator client {
+ provider = "prisma-client-js"
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ name String?
+ email String @unique
+ posts Post[]
+ followers User[] @relation("UserToUser")
+ user User? @relation("UserToUser", fields: [userId], references: [id])
+ userId Int?
+}
+
+model Post {
+ id Int @id @default(autoincrement())
+ title String
+ content String?
+ user User? @relation(fields: [userId], references: [id])
+ userId Int?
+ tags Tag[]
+ views Int @default(0)
+ //highlight-next-line
+ deleted Boolean @default(false)
+}
+
+model Category {
+ id Int @id @default(autoincrement())
+ parentCategory Category? @relation("CategoryToCategory", fields: [categoryId], references: [id])
+ category Category[] @relation("CategoryToCategory")
+ categoryId Int?
+}
+
+model Tag {
+ tagName String @id // Must be unique
+ posts Post[]
+}
+```
+
+
+
+
+Questions answered in this page
+
+- How to implement soft delete middleware?
+- How to block reads/updates of deleted records?
+- What are trade-offs of middleware-based soft delete?
+
+
+
+## Step 1: Store status of record
+
+Add a field named `deleted` to the `Post` model. You can choose between two field types depending on your requirements:
+
+- `Boolean` with a default value of `false`:
+
+ ```prisma highlight=4;normal
+ model Post {
+ id Int @id @default(autoincrement())
+ ...
+ //highlight-next-line
+ deleted Boolean @default(false)
+ }
+ ```
+
+- Create a nullable `DateTime` field so that you know exactly _when_ a record was marked as deleted - `NULL` indicates that a record has not been deleted. In some cases, storing when a record was removed may be a regulatory requirement:
+
+ ```prisma highlight=4;normal
+ model Post {
+ id Int @id @default(autoincrement())
+ ...
+ //highlight-next-line
+ deleted DateTime?
+ }
+ ```
+
+> **Note**: Using two separate fields (`isDeleted` and `deletedDate`) may result in these two fields becoming out of sync - for example, a record may be marked as deleted but have no associated date.)
+
+This sample uses a `Boolean` field type for simplicity.
+
+## Step 2: Soft delete middleware
+
+Add a middleware that performs the following tasks:
+
+- Intercepts `delete()` and `deleteMany()` queries for the `Post` model
+- Changes the `params.action` to `update` and `updateMany` respectively
+- Introduces a `data` argument and sets `{ deleted: true }`, preserving other filter arguments if they exist
+
+Run the following sample to test the soft delete middleware:
+
+```ts
+import { PrismaClient } from '@prisma/client'
+
+const prisma = new PrismaClient({})
+
+async function main() {
+ /***********************************/
+ /* SOFT DELETE MIDDLEWARE */
+ /***********************************/
+
+ prisma.$use(async (params, next) => {
+ // Check incoming query type
+ if (params.model == 'Post') {
+ if (params.action == 'delete') {
+ // Delete queries
+ // Change action to an update
+ params.action = 'update'
+ params.args['data'] = { deleted: true }
+ }
+ if (params.action == 'deleteMany') {
+ // Delete many queries
+ params.action = 'updateMany'
+ if (params.args.data != undefined) {
+ params.args.data['deleted'] = true
+ } else {
+ params.args['data'] = { deleted: true }
+ }
+ }
+ }
+ return next(params)
+ })
+
+ /***********************************/
+ /* TEST */
+ /***********************************/
+
+ const titles = [
+ { title: 'How to create soft delete middleware' },
+ { title: 'How to install Prisma' },
+ { title: 'How to update a record' },
+ ]
+
+ console.log('\u001b[1;34mSTARTING SOFT DELETE TEST \u001b[0m')
+ console.log('\u001b[1;34m#################################### \u001b[0m')
+
+ let i = 0
+ let posts = new Array()
+
+ // Create 3 new posts with a randomly assigned title each time
+ for (i == 0; i < 3; i++) {
+ const createPostOperation = prisma.post.create({
+ data: titles[Math.floor(Math.random() * titles.length)],
+ })
+ posts.push(createPostOperation)
+ }
+
+ var postsCreated = await prisma.$transaction(posts)
+
+ console.log(
+ 'Posts created with IDs: ' +
+ '\u001b[1;32m' +
+ postsCreated.map((x) => x.id) +
+ '\u001b[0m'
+ )
+
+ // Delete the first post from the array
+ const deletePost = await prisma.post.delete({
+ where: {
+ id: postsCreated[0].id, // Random ID
+ },
+ })
+
+ // Delete the 2nd two posts
+ const deleteManyPosts = await prisma.post.deleteMany({
+ where: {
+ id: {
+ in: [postsCreated[1].id, postsCreated[2].id],
+ },
+ },
+ })
+
+ const getPosts = await prisma.post.findMany({
+ where: {
+ id: {
+ in: postsCreated.map((x) => x.id),
+ },
+ },
+ })
+
+ console.log()
+
+ console.log(
+ 'Deleted post with ID: ' + '\u001b[1;32m' + deletePost.id + '\u001b[0m'
+ )
+ console.log(
+ 'Deleted posts with IDs: ' +
+ '\u001b[1;32m' +
+ [postsCreated[1].id + ',' + postsCreated[2].id] +
+ '\u001b[0m'
+ )
+ console.log()
+ console.log(
+ 'Are the posts still available?: ' +
+ (getPosts.length == 3
+ ? '\u001b[1;32m' + 'Yes!' + '\u001b[0m'
+ : '\u001b[1;31m' + 'No!' + '\u001b[0m')
+ )
+ console.log()
+ console.log('\u001b[1;34m#################################### \u001b[0m')
+ // 4. Count ALL posts
+ const f = await prisma.post.findMany({})
+ console.log('Number of posts: ' + '\u001b[1;32m' + f.length + '\u001b[0m')
+
+ // 5. Count DELETED posts
+ const r = await prisma.post.findMany({
+ where: {
+ deleted: true,
+ },
+ })
+ console.log(
+ 'Number of SOFT deleted posts: ' + '\u001b[1;32m' + r.length + '\u001b[0m'
+ )
+}
+
+main()
+```
+
+The sample outputs the following:
+
+```no-lines
+STARTING SOFT DELETE TEST
+####################################
+Posts created with IDs: 587,588,589
+
+Deleted post with ID: 587
+Deleted posts with IDs: 588,589
+
+Are the posts still available?: Yes!
+
+####################################
+```
+
+:::tip
+
+Comment out the middleware to see the message change.
+
+:::
+
+✔ Pros of this approach to soft delete include:
+
+- Soft delete happens at data access level, which means that you cannot delete records unless you use raw SQL
+
+✘ Cons of this approach to soft delete include:
+
+- Content can still be read and updated unless you explicitly filter by `where: { deleted: false }` - in a large project with a lot of queries, there is a risk that soft deleted content will still be displayed
+- You can still use raw SQL to delete records
+
+:::tip
+
+You can create rules or triggers ([MySQL](https://dev.mysql.com/doc/refman/8.0/en/trigger-syntax.html) and [PostgreSQL](https://www.postgresql.org/docs/8.1/rules-update.html)) at a database level to prevent records from being deleted.
+
+:::
+
+## Step 3: Optionally prevent read/update of soft deleted records
+
+In step 2, we implemented middleware that prevents `Post` records from being deleted. However, you can still read and update deleted records. This step explores two ways to prevent the reading and updating of deleted records.
+
+> **Note**: These options are just ideas with pros and cons, you may choose to do something entirely different.
+
+### Option 1: Implement filters in your own application code
+
+In this option:
+
+- Prisma Client middleware is responsible for preventing records from being deleted
+- Your own application code (which could be a GraphQL API, a REST API, a module) is responsible for filtering out deleted posts where necessary (`{ where: { deleted: false } }`) when reading and updating data - for example, the `getPost` GraphQL resolver never returns a deleted post
+
+✔ Pros of this approach to soft delete include:
+
+- No change to Prisma Client's create/update queries - you can easily request deleted records if you need them
+- Modifying queries in middleware can have some unintended consequences, such as changing query return types (see option 2)
+
+✘ Cons of this approach to soft delete include:
+
+- Logic relating to soft delete maintained in two different places
+- If your API surface is very large and maintained by multiple contributors, it may be difficult to enforce certain business rules (for example, never allow deleted records to be updated)
+
+### Option 2: Use middleware to determine the behavior of read/update queries for deleted records
+
+Option two uses Prisma Client middleware to prevent soft deleted records from being returned. The following table describes how the middleware affects each query:
+
+| **Query** | **Middleware logic** | **Changes to return type** |
+| :------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------- |
+| `findUnique()` | 🔧 Change query to `findFirst` (because you cannot apply `deleted: false` filters to `findUnique()`) 🔧 Add `where: { deleted: false }` filter to exclude soft deleted posts 🔧 From version 5.0.0, you can use `findUnique()` to apply `delete: false` filters since [non unique fields are exposed](/6.0/orm/reference/prisma-client-reference#filter-on-non-unique-fields-with-userwhereuniqueinput). | No change | |
+| `findMany` | 🔧 Add `where: { deleted: false }` filter to exclude soft deleted posts by default 🔧 Allow developers to **explicitly request** soft deleted posts by specifying `deleted: true` | No change |
+| `update` | 🔧 Change query to `updateMany` (because you cannot apply `deleted: false` filters to `update`) 🔧 Add `where: { deleted: false }` filter to exclude soft deleted posts | `{ count: n }` instead of `Post` |
+| `updateMany` | 🔧 Add `where: { deleted: false }` filter to exclude soft deleted posts | No change |
+
+- **Is it not possible to utilize soft delete with `findFirstOrThrow()` or `findUniqueOrThrow()`?**
+ From version [5.1.0](https://github.com/prisma/prisma/releases/5.1.0), you can apply soft delete `findFirstOrThrow()` or `findUniqueOrThrow()` by using middleware.
+- **Why are you making it possible to use `findMany()` with a `{ where: { deleted: true } }` filter, but not `updateMany()`?**
+ This particular sample was written to support the scenario where a user can _restore_ their deleted blog post (which requires a list of soft deleted posts) - but the user should not be able to edit a deleted post.
+- **Can I still `connect` or `connectOrCreate` a deleted post?**
+ In this sample - yes. The middleware does not prevent you from connecting an existing, soft deleted post to a user.
+
+Run the following sample to see how middleware affects each query:
+
+```ts
+import { PrismaClient, Prisma } from '@prisma/client'
+
+const prisma = new PrismaClient({})
+
+async function main() {
+ /***********************************/
+ /* SOFT DELETE MIDDLEWARE */
+ /***********************************/
+
+ prisma.$use(async (params, next) => {
+ if (params.model == 'Post') {
+ if (params.action === 'findUnique' || params.action === 'findFirst') {
+ // Change to findFirst - you cannot filter
+ // by anything except ID / unique with findUnique()
+ params.action = 'findFirst'
+ // Add 'deleted' filter
+ // ID filter maintained
+ params.args.where['deleted'] = false
+ }
+ if (
+ params.action === 'findFirstOrThrow' ||
+ params.action === 'findUniqueOrThrow'
+ ) {
+ if (params.args.where) {
+ if (params.args.where.deleted == undefined) {
+ // Exclude deleted records if they have not been explicitly requested
+ params.args.where['deleted'] = false
+ }
+ } else {
+ params.args['where'] = { deleted: false }
+ }
+ }
+ if (params.action === 'findMany') {
+ // Find many queries
+ if (params.args.where) {
+ if (params.args.where.deleted == undefined) {
+ params.args.where['deleted'] = false
+ }
+ } else {
+ params.args['where'] = { deleted: false }
+ }
+ }
+ }
+ return next(params)
+ })
+
+ prisma.$use(async (params, next) => {
+ if (params.model == 'Post') {
+ if (params.action == 'update') {
+ // Change to updateMany - you cannot filter
+ // by anything except ID / unique with findUnique()
+ params.action = 'updateMany'
+ // Add 'deleted' filter
+ // ID filter maintained
+ params.args.where['deleted'] = false
+ }
+ if (params.action == 'updateMany') {
+ if (params.args.where != undefined) {
+ params.args.where['deleted'] = false
+ } else {
+ params.args['where'] = { deleted: false }
+ }
+ }
+ }
+ return next(params)
+ })
+
+ prisma.$use(async (params, next) => {
+ // Check incoming query type
+ if (params.model == 'Post') {
+ if (params.action == 'delete') {
+ // Delete queries
+ // Change action to an update
+ params.action = 'update'
+ params.args['data'] = { deleted: true }
+ }
+ if (params.action == 'deleteMany') {
+ // Delete many queries
+ params.action = 'updateMany'
+ if (params.args.data != undefined) {
+ params.args.data['deleted'] = true
+ } else {
+ params.args['data'] = { deleted: true }
+ }
+ }
+ }
+ return next(params)
+ })
+
+ /***********************************/
+ /* TEST */
+ /***********************************/
+
+ const titles = [
+ { title: 'How to create soft delete middleware' },
+ { title: 'How to install Prisma' },
+ { title: 'How to update a record' },
+ ]
+
+ console.log('\u001b[1;34mSTARTING SOFT DELETE TEST \u001b[0m')
+ console.log('\u001b[1;34m#################################### \u001b[0m')
+
+ let i = 0
+ let posts = new Array()
+
+ // Create 3 new posts with a randomly assigned title each time
+ for (i == 0; i < 3; i++) {
+ const createPostOperation = prisma.post.create({
+ data: titles[Math.floor(Math.random() * titles.length)],
+ })
+ posts.push(createPostOperation)
+ }
+
+ var postsCreated = await prisma.$transaction(posts)
+
+ console.log(
+ 'Posts created with IDs: ' +
+ '\u001b[1;32m' +
+ postsCreated.map((x) => x.id) +
+ '\u001b[0m'
+ )
+
+ // Delete the first post from the array
+ const deletePost = await prisma.post.delete({
+ where: {
+ id: postsCreated[0].id, // Random ID
+ },
+ })
+
+ // Delete the 2nd two posts
+ const deleteManyPosts = await prisma.post.deleteMany({
+ where: {
+ id: {
+ in: [postsCreated[1].id, postsCreated[2].id],
+ },
+ },
+ })
+
+ const getOnePost = await prisma.post.findUnique({
+ where: {
+ id: postsCreated[0].id,
+ },
+ })
+
+ const getOneUniquePostOrThrow = async () =>
+ await prisma.post.findUniqueOrThrow({
+ where: {
+ id: postsCreated[0].id,
+ },
+ })
+
+ const getOneFirstPostOrThrow = async () =>
+ await prisma.post.findFirstOrThrow({
+ where: {
+ id: postsCreated[0].id,
+ },
+ })
+
+ const getPosts = await prisma.post.findMany({
+ where: {
+ id: {
+ in: postsCreated.map((x) => x.id),
+ },
+ },
+ })
+
+ const getPostsAnDeletedPosts = await prisma.post.findMany({
+ where: {
+ id: {
+ in: postsCreated.map((x) => x.id),
+ },
+ deleted: true,
+ },
+ })
+
+ const updatePost = await prisma.post.update({
+ where: {
+ id: postsCreated[1].id,
+ },
+ data: {
+ title: 'This is an updated title (update)',
+ },
+ })
+
+ const updateManyDeletedPosts = await prisma.post.updateMany({
+ where: {
+ deleted: true,
+ id: {
+ in: postsCreated.map((x) => x.id),
+ },
+ },
+ data: {
+ title: 'This is an updated title (updateMany)',
+ },
+ })
+
+ console.log()
+
+ console.log(
+ 'Deleted post (delete) with ID: ' +
+ '\u001b[1;32m' +
+ deletePost.id +
+ '\u001b[0m'
+ )
+ console.log(
+ 'Deleted posts (deleteMany) with IDs: ' +
+ '\u001b[1;32m' +
+ [postsCreated[1].id + ',' + postsCreated[2].id] +
+ '\u001b[0m'
+ )
+ console.log()
+ console.log(
+ 'findUnique: ' +
+ (getOnePost?.id != undefined
+ ? '\u001b[1;32m' + 'Posts returned!' + '\u001b[0m'
+ : '\u001b[1;31m' +
+ 'Post not returned!' +
+ '(Value is: ' +
+ JSON.stringify(getOnePost) +
+ ')' +
+ '\u001b[0m')
+ )
+ try {
+ console.log('findUniqueOrThrow: ')
+ await getOneUniquePostOrThrow()
+ } catch (error) {
+ if (
+ error instanceof Prisma.PrismaClientKnownRequestError &&
+ error.code == 'P2025'
+ )
+ console.log(
+ '\u001b[1;31m' +
+ 'PrismaClientKnownRequestError is catched' +
+ '(Error name: ' +
+ error.name +
+ ')' +
+ '\u001b[0m'
+ )
+ }
+ try {
+ console.log('findFirstOrThrow: ')
+ await getOneFirstPostOrThrow()
+ } catch (error) {
+ if (
+ error instanceof Prisma.PrismaClientKnownRequestError &&
+ error.code == 'P2025'
+ )
+ console.log(
+ '\u001b[1;31m' +
+ 'PrismaClientKnownRequestError is catched' +
+ '(Error name: ' +
+ error.name +
+ ')' +
+ '\u001b[0m'
+ )
+ }
+ console.log()
+ console.log(
+ 'findMany: ' +
+ (getPosts.length == 3
+ ? '\u001b[1;32m' + 'Posts returned!' + '\u001b[0m'
+ : '\u001b[1;31m' + 'Posts not returned!' + '\u001b[0m')
+ )
+ console.log(
+ 'findMany ( delete: true ): ' +
+ (getPostsAnDeletedPosts.length == 3
+ ? '\u001b[1;32m' + 'Posts returned!' + '\u001b[0m'
+ : '\u001b[1;31m' + 'Posts not returned!' + '\u001b[0m')
+ )
+ console.log()
+ console.log(
+ 'update: ' +
+ (updatePost.id != undefined
+ ? '\u001b[1;32m' + 'Post updated!' + '\u001b[0m'
+ : '\u001b[1;31m' +
+ 'Post not updated!' +
+ '(Value is: ' +
+ JSON.stringify(updatePost) +
+ ')' +
+ '\u001b[0m')
+ )
+ console.log(
+ 'updateMany ( delete: true ): ' +
+ (updateManyDeletedPosts.count == 3
+ ? '\u001b[1;32m' + 'Posts updated!' + '\u001b[0m'
+ : '\u001b[1;31m' + 'Posts not updated!' + '\u001b[0m')
+ )
+ console.log()
+ console.log('\u001b[1;34m#################################### \u001b[0m')
+ // 4. Count ALL posts
+ const f = await prisma.post.findMany({})
+ console.log(
+ 'Number of active posts: ' + '\u001b[1;32m' + f.length + '\u001b[0m'
+ )
+
+ // 5. Count DELETED posts
+ const r = await prisma.post.findMany({
+ where: {
+ deleted: true,
+ },
+ })
+ console.log(
+ 'Number of SOFT deleted posts: ' + '\u001b[1;32m' + r.length + '\u001b[0m'
+ )
+}
+
+main()
+```
+
+The sample outputs the following:
+
+```
+STARTING SOFT DELETE TEST
+####################################
+Posts created with IDs: 680,681,682
+
+Deleted post (delete) with ID: 680
+Deleted posts (deleteMany) with IDs: 681,682
+
+findUnique: Post not returned!(Value is: [])
+findMany: Posts not returned!
+findMany ( delete: true ): Posts returned!
+
+update: Post not updated!(Value is: {"count":0})
+updateMany ( delete: true ): Posts not updated!
+
+####################################
+Number of active posts: 0
+Number of SOFT deleted posts: 95
+```
+
+✔ Pros of this approach:
+
+- A developer can make a conscious choice to include deleted records in `findMany`
+- You cannot accidentally read or update a deleted record
+
+✖ Cons of this approach:
+
+- Not obvious from API that you aren't getting all records and that `{ where: { deleted: false } }` is part of the default query
+- Return type `update` affected because middleware changes the query to `updateMany`
+- Doesn't handle complex queries with `AND`, `OR`, `every`, etc...
+- Doesn't handle filtering when using `include` from another model.
+
+## FAQ
+
+### Can I add a global `includeDeleted` to the `Post` model?
+
+You may be tempted to 'hack' your API by adding a `includeDeleted` property to the `Post` model and make the following query possible:
+
+```ts
+prisma.post.findMany({ where: { includeDeleted: true } })
+```
+
+> **Note**: You would still need to write middleware.
+
+We **✘ do not** recommend this approach as it pollutes the schema with fields that do not represent real data.
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/500-middleware/200-logging-middleware.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/500-middleware/200-logging-middleware.mdx
new file mode 100644
index 0000000000..b13eda09f9
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/500-middleware/200-logging-middleware.mdx
@@ -0,0 +1,90 @@
+---
+title: 'Middleware sample: logging'
+metaTitle: 'Middleware sample: logging (Reference)'
+metaDescription: 'How to use middleware to log the time taken to perform any query.'
+---
+
+
+
+The following example logs the time taken for a Prisma Client query to run:
+
+```ts
+const prisma = new PrismaClient()
+
+prisma.$use(async (params, next) => {
+ const before = Date.now()
+
+ const result = await next(params)
+
+ const after = Date.now()
+
+ console.log(`Query ${params.model}.${params.action} took ${after - before}ms`)
+
+ return result
+})
+
+const create = await prisma.post.create({
+ data: {
+ title: 'Welcome to Prisma Day 2020',
+ },
+})
+
+const createAgain = await prisma.post.create({
+ data: {
+ title: 'All about database collation',
+ },
+})
+```
+
+Example output:
+
+```no-lines
+Query Post.create took 92ms
+Query Post.create took 15ms
+```
+
+The example is based on the following sample schema:
+
+```prisma
+generator client {
+ provider = "prisma-client-js"
+}
+
+datasource db {
+ provider = "mysql"
+ url = env("DATABASE_URL")
+}
+
+model Post {
+ authorId Int?
+ content String?
+ id Int @id @default(autoincrement())
+ published Boolean @default(false)
+ title String
+ user User? @relation(fields: [authorId], references: [id])
+ language String?
+
+ @@index([authorId], name: "authorId")
+}
+
+model User {
+ email String @unique
+ id Int @id @default(autoincrement())
+ name String?
+ posts Post[]
+ extendedProfile Json?
+ role Role @default(USER)
+}
+
+enum Role {
+ ADMIN
+ USER
+ MODERATOR
+}
+```
+
+
+
+## Going further
+
+You can also use [Prisma Client extensions](/orm/prisma-client/client-extensions) to log the time it takes to perform a query. A functional example can be found in [this GitHub repository](https://github.com/prisma/prisma-client-extensions/tree/main/query-logging).
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/500-middleware/300-session-data-middleware.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/500-middleware/300-session-data-middleware.mdx
new file mode 100644
index 0000000000..6893713396
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/500-middleware/300-session-data-middleware.mdx
@@ -0,0 +1,72 @@
+---
+title: 'Middleware sample: session data'
+metaTitle: 'Middleware sample: session data (Reference)'
+metaDescription: 'How to use middleware to set the value taken from session state.'
+hide_table_of_contents: true
+---
+
+
+
+The following example sets the `language` field of each `Post` to the context language (taken, for example, from session state):
+
+```ts
+const prisma = new PrismaClient()
+
+const contextLanguage = 'en-us' // Session state
+
+prisma.$use(async (params, next) => {
+ if (params.model == 'Post' && params.action == 'create') {
+ params.args.data.language = contextLanguage
+ }
+
+ return next(params)
+})
+
+const create = await prisma.post.create({
+ data: {
+ title: 'My post in English',
+ },
+})
+```
+
+The example is based on the following sample schema:
+
+```prisma
+generator client {
+ provider = "prisma-client-js"
+}
+
+datasource db {
+ provider = "mysql"
+ url = env("DATABASE_URL")
+}
+
+model Post {
+ authorId Int?
+ content String?
+ id Int @id @default(autoincrement())
+ published Boolean @default(false)
+ title String
+ user User? @relation(fields: [authorId], references: [id])
+ language String?
+
+ @@index([authorId], name: "authorId")
+}
+
+model User {
+ email String @unique
+ id Int @id @default(autoincrement())
+ name String?
+ posts Post[]
+ extendedProfile Json?
+ role Role @default(USER)
+}
+
+enum Role {
+ ADMIN
+ USER
+ MODERATOR
+}
+```
+
+
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/500-middleware/index.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/500-middleware/index.mdx
new file mode 100644
index 0000000000..e6e6efbcc6
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/500-middleware/index.mdx
@@ -0,0 +1,193 @@
+---
+title: 'Middleware'
+metaTitle: 'Middleware (Reference)'
+metaDescription: 'Prisma Client middleware allows you to perform actions before or after any query on any model with the prisma.$use method.'
+---
+
+
+
+
+
+**Middleware has been removed in [v6.14.0](https://pris.ly/release/6.14.0)** and had been deprecated since [v4.16.0](https://github.com/prisma/prisma/releases/tag/4.16.0).
+
+We recommend using the [Prisma Client extensions `query` component type](/orm/prisma-client/client-extensions/query) as an alternative to middleware. Prisma Client extensions were first introduced into Preview in version 4.7.0 and made Generally Available in 4.16.0.
+
+Prisma Client extensions allow you to create independent Prisma Client instances and bind each client to a specific filter or user. For example, you could bind clients to specific users to provide user isolation. Prisma Client extensions also provide end-to-end type safety.
+
+
+
+Middlewares act as query-level lifecycle hooks, which allow you to perform an action before or after a query runs. Use the [`prisma.$use`](/6.0/orm/reference/prisma-client-reference#use) method to add middleware, as follows:
+
+```ts highlight=4-9,12-17;normal
+const prisma = new PrismaClient()
+
+// Middleware 1
+//highlight-start
+prisma.$use(async (params, next) => {
+ // Manipulate params here
+ const result = await next(params)
+ // See results here
+ return result
+})
+//highlight-end
+
+// Middleware 2
+//highlight-start
+prisma.$use(async (params, next) => {
+ // Manipulate params here
+ const result = await next(params)
+ // See results here
+ return result
+})
+//highlight-end
+
+// Queries here
+```
+
+
+
+Do not invoke `next` multiple times within a middleware when using [batch transactions](/orm/prisma-client/queries/transactions#sequential-prisma-client-operations). This will cause you to break out of the transaction and lead to unexpected results.
+
+
+
+[`params`](/6.0/orm/reference/prisma-client-reference#params) represent parameters available in the middleware, such as the name of the query, and [`next`](/6.0/orm/reference/prisma-client-reference#next) represents [the next middleware in the stack _or_ the original Prisma Client query](#running-order-and-the-middleware-stack).
+
+Possible use cases for middleware include:
+
+- Setting or overwriting a field value - for example, [setting the context language of a blog post comment](/6.0/orm/prisma-client/client-extensions/middleware/session-data-middleware)
+- Validating input data - for example, check user input for inappropriate language via an external service
+- Intercept a `delete` query and change it to an `update` in order to perform a [soft delete](/6.0/orm/prisma-client/client-extensions/middleware/soft-delete-middleware)
+- [Log the time taken to perform a query](/6.0/orm/prisma-client/client-extensions/middleware/logging-middleware)
+
+There are many more use cases for middleware - this list serves as inspiration for the types of problems that middleware is designed to address.
+
+
+
+## Samples
+
+The following sample scenarios show how to use middleware in practice:
+
+
+
+## Where to add middleware
+
+Add Prisma Client middleware **outside the context of the request handler**, otherwise each request adds a new _instance_ of the middleware to the stack. The following example demonstrates where to add Prisma Client middleware in the context of an Express app:
+
+```ts highlight=6-11;normal
+import express from 'express'
+import { PrismaClient } from '@prisma/client'
+
+const prisma = new PrismaClient()
+
+//highlight-start
+prisma.$use(async (params, next) => {
+ // Manipulate params here
+ const result = await next(params)
+ // See results here
+ return result
+})
+//highlight-end
+
+const app = express()
+app.get('/feed', async (req, res) => {
+ // NO MIDDLEWARE HERE
+ const posts = await prisma.post.findMany({
+ where: { published: true },
+ include: { author: true },
+ })
+ res.json(posts)
+})
+```
+
+## Running order and the middleware stack
+
+If you have multiple middlewares, the running order for **each separate query** is:
+
+1. All logic **before** `await next(params)` in each middleware, in descending order
+2. All logic **after** `await next(params)` in each middleware, in ascending order
+
+Depending on where you are in the stack, `await next(params)` either:
+
+- Runs the next middleware (in middlewares #1 and #2 in the example) _or_
+- Runs the original Prisma Client query (in middleware #3)
+
+```ts
+const prisma = new PrismaClient()
+
+// Middleware 1
+prisma.$use(async (params, next) => {
+ console.log(params.args.data.title)
+ console.log('1')
+ const result = await next(params)
+ console.log('6')
+ return result
+})
+
+// Middleware 2
+prisma.$use(async (params, next) => {
+ console.log('2')
+ const result = await next(params)
+ console.log('5')
+ return result
+})
+
+// Middleware 3
+prisma.$use(async (params, next) => {
+ console.log('3')
+ const result = await next(params)
+ console.log('4')
+ return result
+})
+
+const create = await prisma.post.create({
+ data: {
+ title: 'Welcome to Prisma Day 2020',
+ },
+})
+
+const create2 = await prisma.post.create({
+ data: {
+ title: 'How to Prisma!',
+ },
+})
+```
+
+Output:
+
+```no-lines
+Welcome to Prisma Day 2020
+1
+2
+3
+4
+5
+6
+How to Prisma!
+1
+2
+3
+4
+5
+6
+```
+
+## Performance and appropriate use cases
+
+Middleware executes for **every** query, which means that overuse has the potential to negatively impact performance. To avoid adding performance overheads:
+
+- Check the `params.model` and `params.action` properties early in your middleware to avoid running logic unnecessarily:
+
+ ```ts
+ prisma.$use(async (params, next) => {
+ if (params.model == 'Post' && params.action == 'delete') {
+ // Logic only runs for delete action and Post model
+ }
+ return next(params)
+ })
+ ```
+
+- Consider whether middleware is the appropriate solution for your scenario. For example:
+
+ - If you need to populate a field, can you use the [`@default`](/orm/reference/prisma-schema-reference#default) attribute?
+ - If you need to set the value of a `DateTime` field, can you use the `now()` function or the `@updatedAt` attribute?
+ - If you need to perform more complex validation, can you use a `CHECK` constraint in the database itself?
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/index.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/index.mdx
new file mode 100644
index 0000000000..98e0cdddb8
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/300-client-extensions/index.mdx
@@ -0,0 +1,273 @@
+---
+title: 'Extensions'
+metaTitle: 'Prisma Client extensions'
+metaDescription: 'Extend the functionality of Prisma Client'
+toc_max_heading_level: 4
+---
+
+
+
+
+
+Prisma Client extensions are Generally Available from versions 4.16.0 and later. They were introduced in Preview in version 4.7.0. Make sure you enable the `clientExtensions` Preview feature flag if you are running on a version earlier than 4.16.0.
+
+
+
+You can use Prisma Client extensions to add functionality to your models, result objects, and queries, or to add client-level methods.
+
+You can create an extension with one or more of the following component types:
+
+- `model`: [add custom methods or fields to your models](/orm/prisma-client/client-extensions/model)
+- `client`: [add client-level methods to Prisma Client](/orm/prisma-client/client-extensions/client)
+- `query`: [create custom Prisma Client queries](/orm/prisma-client/client-extensions/query)
+- `result`: [add custom fields to your query results](/orm/prisma-client/client-extensions/result)
+
+For example, you might create an extension that uses the `model` and `client` component types.
+
+
+
+## About Prisma Client extensions
+
+When you use a Prisma Client extension, you create an _extended client_. An extended client is a lightweight variant of the standard Prisma Client that is wrapped by one or more extensions. The standard client is not mutated. You can add as many extended clients as you want to your project. [Learn more about extended clients](#extended-clients).
+
+You can associate a single extension, or multiple extensions, with an extended client. [Learn more about multiple extensions](#multiple-extensions).
+
+You can [share your Prisma Client extensions](/orm/prisma-client/client-extensions/shared-extensions) with other Prisma ORM users, and [import Prisma Client extensions developed by other users](/orm/prisma-client/client-extensions/shared-extensions#install-a-shared-packaged-extension) into your Prisma ORM project.
+
+### Extended clients
+
+Extended clients interact with each other, and with the standard client, as follows:
+
+- Each extended client operates independently in an isolated instance.
+- Extended clients cannot conflict with each other, or with the standard client.
+- All extended clients and the standard client communicate with the same [Prisma ORM query engine](/orm/more/under-the-hood/engines).
+- All extended clients and the standard client share the same connection pool.
+
+> **Note**: The author of an extension can modify this behavior since they're able to run arbitrary code as part of an extension. For example, an extension might actually create an entirely new `PrismaClient` instance (including its own query engine and connection pool). Be sure to check the documentation of the extension you're using to learn about any specific behavior it might implement.
+
+### Example use cases for extended clients
+
+Because extended clients operate in isolated instances, they can be a good way to do the following, for example:
+
+- Implement row-level security (RLS), where each HTTP request has its own client with its own RLS extension, customized with session data. This can keep each user entirely separate, each in a separate client.
+- Add a `user.current()` method for the `User` model to get the currently logged-in user.
+- Enable more verbose logging for requests if a debug cookie is set.
+- Attach a unique request id to all logs so that you can correlate them later, for example to help you analyze the operations that Prisma Client carries out.
+- Remove a `delete` method from models unless the application calls the admin endpoint and the user has the necessary privileges.
+
+## Add an extension to Prisma Client
+
+You can create an extension using two primary ways:
+
+- Use the client-level [`$extends`](/6.0/orm/reference/prisma-client-reference#client-methods) method
+
+ ```ts
+ const prisma = new PrismaClient().$extends({
+ name: 'signUp', // Optional: name appears in error logs
+ model: { // This is a `model` component
+ user: { ... } // The extension logic for the `user` model goes inside the curly braces
+ },
+ })
+ ```
+
+- Use the `Prisma.defineExtension` method to define an extension and assign it to a variable, and then pass the extension to the client-level `$extends` method
+
+ ```ts
+ import { Prisma } from '@prisma/client'
+
+ // Define the extension
+ const myExtension = Prisma.defineExtension({
+ name: 'signUp', // Optional: name appears in error logs
+ model: { // This is a `model` component
+ user: { ... } // The extension logic for the `user` model goes inside the curly braces
+ },
+ })
+
+ // Pass the extension to a Prisma Client instance
+ const prisma = new PrismaClient().$extends(myExtension)
+ ```
+
+ :::tip
+
+ This pattern is useful for when you would like to separate extensions into multiple files or directories within a project.
+
+ :::
+
+The above examples use the [`model` extension component](/orm/prisma-client/client-extensions/model) to extend the `User` model.
+
+In your `$extends` method, use the appropriate extension component or components ([`model`](/orm/prisma-client/client-extensions/model), [`client`](/orm/prisma-client/client-extensions/client), [`result`](/orm/prisma-client/client-extensions/result) or [`query`](/orm/prisma-client/client-extensions/query)).
+
+## Name an extension for error logs
+
+You can name your extensions to help identify them in error logs. To do so, use the optional field `name`. For example:
+
+```ts
+const prisma = new PrismaClient().$extends({
+ name: `signUp`, // (Optional) Extension name
+ model: {
+ user: { ... }
+ },
+})
+```
+
+## Multiple extensions
+
+You can associate an extension with an [extended client](#about-prisma-client-extensions) in one of two ways:
+
+- You can associate it with an extended client on its own, or
+- You can combine the extension with other extensions and associate all of these extensions with an extended client. The functionality from these combined extensions applies to the same extended client.
+ Note: [Combined extensions can conflict](#conflicts-in-combined-extensions).
+
+You can combine the two approaches above. For example, you might associate one extension with its own extended client and associate two other extensions with another extended client. [Learn more about how client instances interact](#extended-clients).
+
+### Apply multiple extensions to an extended client
+
+In the following example, suppose that you have two extensions, `extensionA` and `extensionB`. There are two ways to combine these.
+
+#### Option 1: Declare the new client in one line
+
+With this option, you apply both extensions to a new client in one line of code.
+
+```ts
+// First of all, store your original Prisma Client in a variable as usual
+const prisma = new PrismaClient()
+
+// Declare an extended client that has an extensionA and extensionB
+const prismaAB = prisma.$extends(extensionA).$extends(extensionB)
+```
+
+You can then refer to `prismaAB` in your code, for example `prismaAB.myExtensionMethod()`.
+
+#### Option 2: Declare multiple extended clients
+
+The advantage of this option is that you can call any of the extended clients separately.
+
+```ts
+// First of all, store your original Prisma Client in a variable as usual
+const prisma = new PrismaClient()
+
+// Declare an extended client that has extensionA applied
+const prismaA = prisma.$extends(extensionA)
+
+// Declare an extended client that has extensionB applied
+const prismaB = prisma.$extends(extensionB)
+
+// Declare an extended client that is a combination of clientA and clientB
+const prismaAB = prismaA.$extends(extensionB)
+```
+
+In your code, you can call any of these clients separately, for example `prismaA.myExtensionMethod()`, `prismaB.myExtensionMethod()`, or `prismaAB.myExtensionMethod()`.
+
+### Conflicts in combined extensions
+
+When you combine two or more extensions into a single extended client, then the _last_ extension that you declare takes precedence in any conflict. In the example in option 1 above, suppose there is a method called `myExtensionMethod()` defined in `extensionA` and a method called `myExtensionMethod()` in `extensionB`. When you call `prismaAB.myExtensionMethod()`, then Prisma Client uses `myExtensionMethod()` as defined in `extensionB`.
+
+## Type of an extended client
+
+You can infer the type of an extended Prisma Client instance using the [`typeof`](https://www.typescriptlang.org/docs/handbook/2/typeof-types.html) utility as follows:
+
+```ts
+const extendedPrismaClient = new PrismaClient().$extends({
+ /** extension */
+})
+
+type ExtendedPrismaClient = typeof extendedPrismaClient
+```
+
+If you're using Prisma Client as a singleton, you can get the type of the extended Prisma Client instance using the `typeof` and [`ReturnType`](https://www.typescriptlang.org/docs/handbook/utility-types.html#returntypetype) utilities as follows:
+
+```ts
+function getExtendedClient() {
+ return new PrismaClient().$extends({
+ /* extension */
+ })
+}
+
+type ExtendedPrismaClient = ReturnType
+```
+
+## Extending model types with `Prisma.Result`
+
+You can use the `Prisma.Result` type utility to extend model types to include properties added via client extensions. This allows you to infer the type of the extended model, including the extended properties.
+
+### Example
+
+The following example demonstrates how to use `Prisma.Result` to extend the `User` model type to include a `__typename` property added via a client extension.
+
+```ts
+import { PrismaClient, Prisma } from '@prisma/client'
+
+const prisma = new PrismaClient().$extends({
+ result: {
+ user: {
+ __typename: {
+ needs: {},
+ compute() {
+ return 'User'
+ },
+ },
+ },
+ },
+})
+
+type ExtendedUser = Prisma.Result
+
+async function main() {
+ const user: ExtendedUser = await prisma.user.findFirstOrThrow({
+ select: {
+ id: true,
+ __typename: true,
+ },
+ })
+
+ console.log(user.__typename) // Output: 'User'
+}
+
+main()
+```
+
+The `Prisma.Result` type utility is used to infer the type of the extended `User` model, including the `__typename` property added via the client extension.
+
+## Limitations
+
+### Usage of `$on` and `$use` with extended clients
+
+`$on` and `$use` are not available in extended clients. If you would like to continue using these [client-level methods](/6.0/orm/reference/prisma-client-reference#client-methods) with an extended client, you will need to hook them up before extending the client.
+
+```ts
+const prisma = new PrismaClient()
+
+prisma.$use(async (params, next) => {
+ console.log('This is middleware!')
+ return next(params)
+})
+
+const xPrisma = prisma.$extends({
+ name: 'myExtension',
+ model: {
+ user: {
+ async signUp(email: string) {
+ await prisma.user.create({ data: { email } })
+ },
+ },
+ },
+})
+```
+
+To learn more, see our documentation on [`$on`](/6.0/orm/reference/prisma-client-reference#on) and [`$use`](/6.0/orm/reference/prisma-client-reference#use)
+
+### Usage of client-level methods in extended clients
+
+[Client-level methods](/6.0/orm/reference/prisma-client-reference#client-methods) do not necessarily exist on extended clients. For these clients you will need to first check for existence before using.
+
+```ts
+const xPrisma = new PrismaClient().$extends(...);
+
+if (xPrisma.$connect) {
+ xPrisma.$connect()
+}
+```
+
+### Usage with nested operations
+
+The `query` extension type does not support nested read and write operations.
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/400-type-safety/050-prisma-validator.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/400-type-safety/050-prisma-validator.mdx
new file mode 100644
index 0000000000..c55f99d9ff
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/400-type-safety/050-prisma-validator.mdx
@@ -0,0 +1,162 @@
+---
+title: 'Prisma validator'
+metaTitle: 'Prisma validator'
+metaDescription: 'The Prisma validator is a utility function that takes a generated type and returns a type-safe object which adheres to the generated types model fields.'
+---
+
+
+
+The [`Prisma.validator`](/6.0/orm/reference/prisma-client-reference#prismavalidator) is a utility function that takes a generated type and returns a type-safe object which adheres to the generated types model fields.
+
+This page introduces the `Prisma.validator` and offers some motivations behind why you might choose to use it.
+
+
+
+:::warning
+ The `Prisma.validator` API is only available when using the **legacy** `prisma-client-js` generator. It’s **not supported** in the new `prisma-client` generator.
+
+ In most cases, you can achieve the same behavior using TypeScript’s native `satisfies` operator instead of `Prisma.validator`.
+
+ If you previously used `Prisma.validator`, check out this [blog post](https://www.prisma.io/blog/satisfies-operator-ur8ys8ccq7zb) to learn how the new `satisfies` keyword can improve and simplify your Prisma Client workflows.
+ :::
+## Creating a typed query statement
+
+Let's imagine that you created a new `userEmail` object that you wanted to re-use in different queries throughout your application. It's typed and can be safely used in queries.
+
+The below example asks `Prisma` to return the `email` of the user whose `id` is 3, if no user exists it will return `null`.
+
+```ts
+import { Prisma } from '@prisma/client'
+
+const userEmail: Prisma.UserSelect = {
+ email: true,
+}
+
+// Run inside async function
+const user = await prisma.user.findUnique({
+ where: {
+ id: 3,
+ },
+ select: userEmail,
+})
+```
+
+This works well but there is a caveat to extracting query statements this way.
+
+You'll notice that if you hover your mouse over `userEmail` TypeScript won't infer the object's key or value (that is, `email: true`).
+
+The same applies if you use dot notation on `userEmail` within the `prisma.user.findUnique(...)` query, you will be able to access all of the properties available to a `select` object.
+
+If you are using this in one file that may be fine, but if you are going to export this object and use it in other queries, or if you are compiling an external library where you want to control how the user uses this object within their queries then this won't be type-safe.
+
+The object `userEmail` has been created to select only the user's `email`, and yet it still gives access to all the other properties available. **It is typed, but not type-safe**.
+
+`Prisma` has a way to validate generated types to make sure they are type-safe, a utility function available on the namespace called `validator`.
+
+## Using the `Prisma.validator`
+
+The following example passes the `UserSelect` generated type into the `Prisma.validator` utility function and defines the expected return type in much the same way as the previous example.
+
+```ts highlight=3,4,5;delete|7-9;add
+import { Prisma } from '@prisma/client'
+
+//delete-start
+const userEmail: Prisma.UserSelect = {
+ email: true,
+}
+//delete-end
+
+//add-start
+const userEmail = Prisma.validator()({
+ email: true,
+})
+//add-end
+
+// Run inside async function
+const user = await prisma.user.findUnique({
+ where: {
+ id: 3,
+ },
+ select: userEmail,
+})
+```
+
+Alternatively, you can use the following syntax that uses a "selector" pattern using an existing instance of Prisma Client:
+
+```ts
+import { Prisma } from '@prisma/client'
+import prisma from './lib/prisma'
+
+const userEmail = Prisma.validator(
+ prisma,
+ 'user',
+ 'findUnique',
+ 'select'
+)({
+ email: true,
+})
+```
+
+The big difference is that the `userEmail` object is now type-safe. If you hover your mouse over it TypeScript will tell you the object's key/value pair. If you use dot notation to access the object's properties you will only be able to access the `email` property of the object.
+
+This functionality is handy when combined with user defined input, like form data.
+
+## Combining `Prisma.validator` with form input
+
+The following example creates a type-safe function from the `Prisma.validator` which can be used when interacting with user created data, such as form inputs.
+
+> **Note**: Form input is determined at runtime so can't be verified by only using TypeScript. Be sure to validate your form input through other means too (such as an external validation library) before passing that data through to your database.
+
+```ts
+import { Prisma, PrismaClient } from '@prisma/client'
+
+const prisma = new PrismaClient()
+
+// Create a new function and pass the parameters onto the validator
+const createUserAndPost = (
+ name: string,
+ email: string,
+ postTitle: string,
+ profileBio: string
+) => {
+ return Prisma.validator()({
+ name,
+ email,
+ posts: {
+ create: {
+ title: postTitle,
+ },
+ },
+ profile: {
+ create: {
+ bio: profileBio,
+ },
+ },
+ })
+}
+
+const findSpecificUser = (email: string) => {
+ return Prisma.validator()({
+ email,
+ })
+}
+
+// Create the user in the database based on form input
+// Run inside async function
+await prisma.user.create({
+ data: createUserAndPost(
+ 'Rich',
+ 'rich@boop.com',
+ 'Life of Pie',
+ 'Learning each day'
+ ),
+})
+
+// Find the specific user based on form input
+// Run inside async function
+const oneUser = await prisma.user.findUnique({
+ where: findSpecificUser('rich@boop.com'),
+})
+```
+
+The `createUserAndPost` custom function is created using the `Prisma.validator` and passed a generated type, `UserCreateInput`. The `Prisma.validator` validates the functions input because the types assigned to the parameters must match those the generated type expects.
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/400-type-safety/100-operating-against-partial-structures-of-model-types.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/400-type-safety/100-operating-against-partial-structures-of-model-types.mdx
new file mode 100644
index 0000000000..19fef636a4
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/400-type-safety/100-operating-against-partial-structures-of-model-types.mdx
@@ -0,0 +1,135 @@
+---
+title: 'Operating against partial structures of your model types'
+metaTitle: 'Operating against partial structures of your model types'
+metaDescription: 'This page documents various scenarios for using the generated types from the Prisma namespace'
+---
+
+
+
+When using Prisma Client, every model from your [Prisma schema](/orm/prisma-schema) is translated into a dedicated TypeScript type. For example, assume you have the following `User` and `Post` models:
+
+```prisma
+model User {
+ id Int @id
+ email String @unique
+ name String?
+ posts Post[]
+}
+
+model Post {
+ id Int @id
+ author User @relation(fields: [userId], references: [id])
+ title String
+ published Boolean @default(false)
+ userId Int
+}
+```
+
+The Prisma Client code that's generated from this schema contains this representation of the `User` type:
+
+```ts
+export type User = {
+ id: string
+ email: string
+ name: string | null
+}
+```
+
+
+
+## Problem: Using variations of the generated model type
+
+### Description
+
+In some scenarios, you may need a _variation_ of the generated `User` type. For example, when you have a function that expects an instance of the `User` model that carries the `posts` relation. Or when you need a type to pass only the `User` model's `email` and `name` fields around in your application code.
+
+### Solution
+
+As a solution, you can customize the generated model type using Prisma Client's helper types.
+
+The `User` type only contains the model's [scalar](/orm/prisma-schema/data-model/models#scalar-fields) fields, but doesn't account for any relations. That's because [relations are not included by default](/orm/prisma-client/queries/select-fields#return-the-default-fields) in Prisma Client queries.
+
+However, sometimes it's useful to have a type available that **includes a relation** (i.e. a type that you'd get from an API call that uses [`include`](/orm/prisma-client/queries/select-fields#return-nested-objects-by-selecting-relation-fields)). Similarly, another useful scenario could be to have a type available that **includes only a subset of the model's scalar fields** (i.e. a type that you'd get from an API call that uses [`select`](/orm/prisma-client/queries/select-fields#select-specific-fields)).
+
+One way of achieving this would be to define these types manually in your application code:
+
+```ts
+// 1: Define a type that includes the relation to `Post`
+type UserWithPosts = {
+ id: string
+ email: string
+ name: string | null
+ posts: Post[]
+}
+
+// 2: Define a type that only contains a subset of the scalar fields
+type UserPersonalData = {
+ email: string
+ name: string | null
+}
+```
+
+While this is certainly feasible, this approach increases the maintenance burden upon changes to the Prisma schema as you need to manually maintain the types. A cleaner solution to this is to use the `UserGetPayload` type that is generated and exposed by Prisma Client under the `Prisma` namespace in combination with the [`validator`](/orm/prisma-client/type-safety/prisma-validator).
+
+The following example uses the `Prisma.validator` to create two type-safe objects and then uses the `Prisma.UserGetPayload` utility function to create a type that can be used to return all users and their posts.
+
+```ts
+import { Prisma } from '@prisma/client'
+
+// 1: Define a type that includes the relation to `Post`
+const userWithPosts = Prisma.validator()({
+ include: { posts: true },
+})
+
+// 2: Define a type that only contains a subset of the scalar fields
+const userPersonalData = Prisma.validator()({
+ select: { email: true, name: true },
+})
+
+// 3: This type will include a user and all their posts
+type UserWithPosts = Prisma.UserGetPayload
+```
+
+The main benefits of the latter approach are:
+
+- Cleaner approach as it leverages Prisma Client's generated types
+- Reduced maintenance burden and improved type safety when the schema changes
+
+## Problem: Getting access to the return type of a function
+
+### Description
+
+When doing [`select`](/6.0/orm/reference/prisma-client-reference#select) or [`include`](/6.0/orm/reference/prisma-client-reference#include) operations on your models and returning these variants from a function, it can be difficult to gain access to the return type, e.g:
+
+```ts
+// Function definition that returns a partial structure
+async function getUsersWithPosts() {
+ const users = await prisma.user.findMany({ include: { posts: true } })
+ return users
+}
+```
+
+Extracting the type that represents "users with posts" from the above code snippet requires some advanced TypeScript usage:
+
+```ts
+// Function definition that returns a partial structure
+async function getUsersWithPosts() {
+ const users = await prisma.user.findMany({ include: { posts: true } })
+ return users
+}
+
+// Extract `UsersWithPosts` type with
+type ThenArg = T extends PromiseLike ? U : T
+type UsersWithPosts = ThenArg>
+
+// run inside `async` function
+const usersWithPosts: UsersWithPosts = await getUsersWithPosts()
+```
+
+### Solution
+
+You can use native the TypeScript utility type [`Awaited`](https://www.typescriptlang.org/docs/handbook/utility-types.html#awaitedtype) and [`ReturnType`](https://www.typescriptlang.org/docs/handbook/utility-types.html#returntypetype) to solve the problem elegantly:
+
+```ts
+type UsersWithPosts = Awaited>
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/400-type-safety/830-prisma-type-system.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/400-type-safety/830-prisma-type-system.mdx
new file mode 100644
index 0000000000..17a6241106
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/400-type-safety/830-prisma-type-system.mdx
@@ -0,0 +1,165 @@
+---
+title: How to use Prisma ORM's type system
+metaDescription: How to use Prisma ORM's type system
+tocDepth: 3
+---
+
+
+
+This guide introduces Prisma ORM's type system and explains how to introspect existing native types in your database, and how to use types when you apply schema changes to your database with Prisma Migrate or `db push`.
+
+
+
+## How does Prisma ORM's type system work?
+
+Prisma ORM uses _types_ to define the kind of data that a field can hold. To make it easy to get started, Prisma ORM provides a small number of core [scalar types](/orm/reference/prisma-schema-reference#model-field-scalar-types) that should cover most default use cases. For example, take the following blog post model:
+
+```prisma file=schema.prisma showLineNumbers
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+
+model Post {
+ id Int @id
+ title String
+ createdAt DateTime
+}
+```
+
+The `title` field of the `Post` model uses the `String` scalar type, while the `createdAt` field uses the `DateTime` scalar type.
+
+Databases also have their own type system, which defines the type of value that a column can hold. Most databases provide a large number of data types to allow fine-grained control over exactly what a column can store. For example, a database might provide inbuilt support for multiple sizes of integers, or for XML data. The names of these types vary between databases. For example, in PostgreSQL the column type for booleans is `boolean`, whereas in MySQL the `tinyint(1)` type is typically used.
+
+In the blog post example above, we are using the PostgreSQL connector. This is specified in the `datasource` block of the Prisma schema.
+
+### Default type mappings
+
+To allow you to get started with our core scalar types, Prisma ORM provides _default type mappings_ that map each scalar type to a default type in the underlying database. For example:
+
+- by default Prisma ORM's `String` type gets mapped to PostgreSQL's `text` type and MySQL's `varchar` type
+- by default Prisma ORM's `DateTime` type gets mapped to PostgreSQL's `timestamp(3)` type and SQL Server's `datetime2` type
+
+See Prisma ORM's [database connector pages](/orm/overview/databases) for the default type mappings for a given database. For example, [this table](/orm/overview/databases/postgresql#type-mapping-between-postgresql-and-prisma-schema) gives the default type mappings for PostgreSQL.
+To see the default type mappings for all databases for a specific given Prisma ORM type, see the [model field scalar types section](/orm/reference/prisma-schema-reference#model-field-scalar-types) of the Prisma schema reference. For example, [this table](/orm/reference/prisma-schema-reference#float) gives the default type mappings for the `Float` scalar type.
+
+### Native type mappings
+
+Sometimes you may need to use a more specific database type that is not one of the default type mappings for your Prisma ORM type. For this purpose, Prisma ORM provides [native type attributes](/orm/prisma-schema/data-model/models#native-types-mapping) to refine the core scalar types. For example, in the `createdAt` field of your `Post` model above you may want to use a date-only column in your underlying PostgreSQL database, by using the `date` type instead of the default type mapping of `timestamp(3)`. To do this, add a `@db.Date` native type attribute to the `createdAt` field:
+
+```prisma file=schema.prisma showLineNumbers
+model Post {
+ id Int @id
+ title String
+ createdAt DateTime @db.Date
+}
+```
+
+Native type mappings allow you to express all the types in your database. However, you do not need to use them if the Prisma ORM defaults satisfy your needs. This leads to a shorter, more readable Prisma schema for common use cases.
+
+## How to introspect database types
+
+When you [introspect](/orm/prisma-schema/introspection) an existing database, Prisma ORM will take the database type of each table column and represent it in your Prisma schema using the correct Prisma ORM type for the corresponding model field. If the database type is not the default database type for that Prisma ORM scalar type, Prisma ORM will also add a native type attribute.
+
+As an example, take a `User` table in a PostgreSQL database, with:
+
+- an `id` column with a data type of `serial`
+- a `name` column with a data type of `text`
+- an `isActive` column with a data type of `boolean`
+
+You can create this with the following SQL command:
+
+```sql
+CREATE TABLE "public"."User" (
+ id serial PRIMARY KEY NOT NULL,
+ name text NOT NULL,
+ "isActive" boolean NOT NULL
+);
+```
+
+Introspect your database with the following command run from the root directory of your project:
+
+```terminal
+npx prisma db pull
+```
+
+You will get the following Prisma schema:
+
+```prisma file=schema.prisma showLineNumbers
+model User {
+ id Int @id @default(autoincrement())
+ name String
+ isActive Boolean
+}
+```
+
+The `id`, `name` and `isActive` columns in the database are mapped respectively to the `Int`, `String` and `Boolean` Prisma ORM types. The database types are the _default_ database types for these Prisma ORM types, so Prisma ORM does not add any native type attributes.
+
+Now add a `createdAt` column to your database with a data type of `date` by running the following SQL command:
+
+```sql
+ALTER TABLE "public"."User"
+ADD COLUMN "createdAt" date NOT NULL;
+```
+
+Introspect your database again:
+
+```terminal
+npx prisma db pull
+```
+
+Your Prisma schema now includes the new `createdAt` field with a Prisma ORM type of `DateTime`. The `createdAt` field also has a `@db.Date` native type attribute, because PostgreSQL's `date` is not the default type for the `DateTime` type:
+
+```prisma file=schema.prisma highlight=5;add showLineNumbers
+model User {
+ id Int @id @default(autoincrement())
+ name String
+ isActive Boolean
+ //add-next-line
+ createdAt DateTime @db.Date
+}
+```
+
+## How to use types when you apply schema changes to your database
+
+When you apply schema changes to your database using Prisma Migrate or `db push`, Prisma ORM will use both the Prisma ORM scalar type of each field and any native attribute it has to determine the correct database type for the corresponding column in the database.
+
+As an example, create a Prisma schema with the following `Post` model:
+
+```prisma file=schema.prisma showLineNumbers
+model Post {
+ id Int @id
+ title String
+ createdAt DateTime
+ updatedAt DateTime @db.Date
+}
+```
+
+This `Post` model has:
+
+- an `id` field with a Prisma ORM type of `Int`
+- a `title` field with a Prisma ORM type of `String`
+- a `createdAt` field with a Prisma ORM type of `DateTime`
+- an `updatedAt` field with a Prisma ORM type of `DateTime` and a `@db.Date` native type attribute
+
+Now apply these changes to an empty PostgreSQL database with the following command, run from the root directory of your project:
+
+```terminal
+npx prisma db push
+```
+
+You will see that the database has a newly created `Post` table, with:
+
+- an `id` column with a database type of `integer`
+- a `title` column with a database type of `text`
+- a `createdAt` column with a database type of `timestamp(3)`
+- an `updatedAt` column with a database type of `date`
+
+Notice that the `@db.Date` native type attribute modifies the database type of the `updatedAt` column to `date`, rather than the default of `timestamp(3)`.
+
+## More on using Prisma ORM's type system
+
+For further reference information on using Prisma ORM's type system, see the following resources:
+
+- The [database connector](/orm/overview) page for each database provider has a type mapping section with a table of default type mappings between Prisma ORM types and database types, and a table of database types with their corresponding native type attribute in Prisma ORM. For example, the type mapping section for PostgreSQL is [here](/orm/overview/databases/postgresql#type-mapping-between-postgresql-and-prisma-schema).
+- The [model field scalar types](/orm/reference/prisma-schema-reference#model-field-scalar-types) section of the Prisma schema reference has a subsection for each Prisma ORM scalar type. This includes a table of default mappings for that Prisma ORM type in each database, and a table for each database listing the corresponding database types and their native type attributes in Prisma ORM. For example, the entry for the `String` Prisma ORM type is [here](/orm/reference/prisma-schema-reference#string).
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/400-type-safety/index.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/400-type-safety/index.mdx
new file mode 100644
index 0000000000..e5c50d3a3f
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/400-type-safety/index.mdx
@@ -0,0 +1,267 @@
+---
+title: 'Type safety'
+metaTitle: 'Type safety'
+metaDescription: 'Prisma Client provides full type safety for queries, even for partial queries or included relations. This page explains how to leverage the generated types and utilities.'
+tocDepth: 3
+---
+
+
+
+The generated code for Prisma Client contains several helpful types and utilities that you can use to make your application more type-safe. This page describes patterns for leveraging them.
+
+> **Note**: If you're interested in advanced type safety topics with Prisma ORM, be sure to check out this [blog post](https://www.prisma.io/blog/satisfies-operator-ur8ys8ccq7zb) about improving your Prisma Client workflows with the new TypeScript `satisfies` keyword.
+
+
+
+## Importing generated types
+
+You can import the `Prisma` namespace and use dot notation to access types and utilities. The following example shows how to import the `Prisma` namespace and use it to access and use the `Prisma.UserSelect` [generated type](#what-are-generated-types):
+
+```ts
+import { Prisma } from '@prisma/client'
+
+// Build 'select' object
+const userEmail: Prisma.UserSelect = {
+ email: true,
+}
+
+// Use select object
+const createUser = await prisma.user.create({
+ data: {
+ email: 'bob@prisma.io',
+ },
+ select: userEmail,
+})
+```
+
+See also: [Using the `Prisma.UserCreateInput` generated type](/orm/prisma-client/queries/crud#create-a-single-record-using-generated-types)
+
+## What are generated types?
+
+Generated types are TypeScript types that are derived from your models. You can use them to create typed objects that you pass into top-level methods like `prisma.user.create(...)` or `prisma.user.update(...)`, or options such as `select` or `include`.
+
+For example, `select` accepts an object of type `UserSelect`. Its object properties match those that are supported by `select` statements according to the model.
+
+The first tab below shows the `UserSelect` generated type and how each property on the object has a type annotation. The second tab shows the original schema from which the type was generated.
+
+
+
+
+
+```ts
+type Prisma.UserSelect = {
+ id?: boolean | undefined;
+ email?: boolean | undefined;
+ name?: boolean | undefined;
+ posts?: boolean | Prisma.PostFindManyArgs | undefined;
+ profile?: boolean | Prisma.ProfileArgs | undefined;
+}
+```
+
+
+
+
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ posts Post[]
+ profile Profile?
+}
+```
+
+
+
+
+
+In TypeScript the concept of [type annotations](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#type-annotations-on-variables) is when you declare a variable and add a type annotation to describe the type of the variable. See the below example.
+
+```ts
+const myAge: number = 37
+const myName: string = 'Rich'
+```
+
+Both of these variable declarations have been given a type annotation to specify what primitive type they are, `number` and `string` respectively. Most of the time this kind of annotation is not needed as TypeScript will infer the type of the variable based on how its initialized. In the above example `myAge` was initialized with a number so TypeScript guesses that it should be typed as a number.
+
+Going back to the `UserSelect` type, if you were to use dot notation on the created object `userEmail`, you would have access to all of the fields on the `User` model that can be interacted with using a `select` statement.
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ posts Post[]
+ profile Profile?
+}
+```
+
+```ts
+import { Prisma } from '@prisma/client'
+
+const userEmail: Prisma.UserSelect = {
+ email: true,
+}
+
+// properties available on the typed object
+userEmail.id
+userEmail.email
+userEmail.name
+userEmail.posts
+userEmail.profile
+```
+
+In the same mould, you can type an object with an `include` generated type then your object would have access to those properties on which you can use an `include` statement.
+
+```ts
+import { Prisma } from '@prisma/client'
+
+const userPosts: Prisma.UserInclude = {
+ posts: true,
+}
+
+// properties available on the typed object
+userPosts.posts
+userPosts.profile
+```
+
+> See the [model query options](/6.0/orm/reference/prisma-client-reference#model-query-options) reference for more information about the different types available.
+
+### Generated `UncheckedInput` types
+
+The `UncheckedInput` types are a special set of generated types that allow you to perform some operations that Prisma Client considers "unsafe", like directly writing [relation scalar fields](/orm/prisma-schema/data-model/relations). You can choose either the "safe" `Input` types or the "unsafe" `UncheckedInput` type when doing operations like `create`, `update`, or `upsert`.
+
+For example, this Prisma schema has a one-to-many relation between `User` and `Post`:
+
+```prisma
+model Post {
+ id Int @id @default(autoincrement())
+ title String @db.VarChar(255)
+ content String?
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
+}
+
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ posts Post[]
+}
+```
+
+The first tab shows the `PostUncheckedCreateInput` generated type. It contains the `authorId` property, which is a relation scalar field. The second tab shows an example query that uses the `PostUncheckedCreateInput` type. This query will result in an error if a user with an `id` of `1` does not exist.
+
+
+
+
+
+```ts
+type PostUncheckedCreateInput = {
+ id?: number
+ title: string
+ content?: string | null
+ authorId: number
+}
+```
+
+
+
+
+```ts
+prisma.post.create({
+ data: {
+ title: 'First post',
+ content: 'Welcome to the first post in my blog...',
+ authorId: 1,
+ },
+})
+```
+
+
+
+
+
+The same query can be rewritten using the "safer" `PostCreateInput` type. This type does not contain the `authorId` field but instead contains the `author` relation field.
+
+
+
+
+
+```ts
+type PostCreateInput = {
+ title: string
+ content?: string | null
+ author: UserCreateNestedOneWithoutPostsInput
+}
+
+type UserCreateNestedOneWithoutPostsInput = {
+ create?: XOR<
+ UserCreateWithoutPostsInput,
+ UserUncheckedCreateWithoutPostsInput
+ >
+ connectOrCreate?: UserCreateOrConnectWithoutPostsInput
+ connect?: UserWhereUniqueInput
+}
+```
+
+
+
+
+```ts
+prisma.post.create({
+ data: {
+ title: 'First post',
+ content: 'Welcome to the first post in my blog...',
+ author: {
+ connect: {
+ id: 1,
+ },
+ },
+ },
+})
+```
+
+
+
+
+
+This query will also result in an error if an author with an `id` of `1` does not exist. In this case, Prisma Client will give a more descriptive error message. You can also use the [`connectOrCreate`](/6.0/orm/reference/prisma-client-reference#connectorcreate) API to safely create a new user if one does not already exist with the given `id`.
+
+We recommend using the "safe" `Input` types whenever possible.
+
+## Type utilities
+
+
+
+This feature is available from Prisma ORM version 4.9.0 upwards.
+
+
+
+To help you create highly type-safe applications, Prisma Client provides a set of type utilities that tap into input and output types. These types are fully dynamic, which means that they adapt to any given model and schema. You can use them to improve the auto-completion and developer experience of your projects.
+
+This is especially useful in [validating inputs](/orm/prisma-client/type-safety/prisma-validator) and [shared Prisma Client extensions](/orm/prisma-client/client-extensions/shared-extensions).
+
+The following type utilities are available in Prisma Client:
+
+- `Exact`: Enforces strict type safety on `Input`. `Exact` makes sure that a generic type `Input` strictly complies with the type that you specify in `Shape`. It [narrows](https://www.typescriptlang.org/docs/handbook/2/narrowing.html) `Input` down to the most precise types.
+- `Args`: Retrieves the input arguments for any given model and operation. This is particularly useful for extension authors who want to do the following:
+ - Re-use existing types to extend or modify them.
+ - Benefit from the same auto-completion experience as on existing operations.
+- `Result`: Takes the input arguments and provides the result for a given model and operation. You would usually use this in conjunction with `Args`. As with `Args`, `Result` helps you to re-use existing types to extend or modify them.
+- `Payload`: Retrieves the entire structure of the result, as scalars and relations objects for a given model and operation. For example, you can use this to determine which keys are scalars or objects at a type level.
+
+As an example, here's a quick way you can enforce that the arguments to a function matches what you will pass to a `post.create`:
+
+```ts
+type PostCreateBody = Prisma.Args['data']
+
+const addPost = async (postBody: PostCreateBody) => {
+ const post = await prisma.post.create({ data: postBody })
+ return post
+}
+
+await addPost(myData)
+// ^ guaranteed to match the input of `post.create`
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/450-testing/100-unit-testing.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/450-testing/100-unit-testing.mdx
new file mode 100644
index 0000000000..931d78b14c
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/450-testing/100-unit-testing.mdx
@@ -0,0 +1,352 @@
+---
+title: 'Unit testing'
+metaTitle: 'Unit testing with Prisma ORM'
+metaDescription: 'Learn how to setup and run unit tests with Prisma Client'
+tocDepth: 3
+---
+
+
+
+Unit testing aims to isolate a small portion (unit) of code and test it for logically predictable behaviors. It generally involves mocking objects or server responses to simulate real world behaviors. Some benefits to unit testing include:
+
+- Quickly find and isolate bugs in code.
+- Provides documentation for each module of code by way of indicating what certain code blocks should be doing.
+- A helpful gauge that a refactor has gone well. The tests should still pass after code has been refactored.
+
+In the context of Prisma ORM, this generally means testing a function which makes database calls using Prisma Client.
+
+A single test should focus on how your function logic handles different inputs (such as a null value or an empty list).
+
+This means that you should aim to remove as many dependencies as possible, such as external services and databases, to keep the tests and their environments as lightweight as possible.
+
+
+
+> **Note**: This [blog post](https://www.prisma.io/blog/testing-series-2-xPhjjmIEsM) provides a comprehensive guide to implementing unit testing in your Express project with Prisma ORM. If you're looking to delve into this topic, be sure to give it a read!
+
+## Prerequisites
+
+This guide assumes you have the JavaScript testing library [`Jest`](https://jestjs.io/) and [`ts-jest`](https://github.com/kulshekhar/ts-jest) already setup in your project.
+
+## Mocking Prisma Client
+
+To ensure your unit tests are isolated from external factors you can mock Prisma Client, this means you get the benefits of being able to use your schema (**_type-safety_**), without having to make actual calls to your database when your tests are run.
+
+This guide will cover two approaches to mocking Prisma Client, a singleton instance and dependency injection. Both have their merits depending on your use cases. To help with mocking Prisma Client the [`jest-mock-extended`](https://github.com/marchaos/jest-mock-extended) package will be used.
+
+```terminal
+npm install jest-mock-extended@2.0.4 --save-dev
+```
+
+
+
+At the time of writing, this guide uses `jest-mock-extended` version `^2.0.4`.
+
+
+
+### Singleton
+
+The following steps guide you through mocking Prisma Client using a singleton pattern.
+
+1. Create a file at your projects root called `client.ts` and add the following code. This will instantiate a Prisma Client instance.
+
+ ```ts file=client.ts
+ import { PrismaClient } from '@prisma/client'
+
+ const prisma = new PrismaClient()
+ export default prisma
+ ```
+
+2. Next create a file named `singleton.ts` at your projects root and add the following:
+
+ ```ts file=singleton.ts
+ import { PrismaClient } from '@prisma/client'
+ import { mockDeep, mockReset, DeepMockProxy } from 'jest-mock-extended'
+
+ import prisma from './client'
+
+ jest.mock('./client', () => ({
+ __esModule: true,
+ default: mockDeep(),
+ }))
+
+ beforeEach(() => {
+ mockReset(prismaMock)
+ })
+
+ export const prismaMock = prisma as unknown as DeepMockProxy
+ ```
+
+The singleton file tells Jest to mock a default export (the Prisma Client instance in `./client.ts`), and uses the `mockDeep` method from `jest-mock-extended` to enable access to the objects and methods available on Prisma Client. It then resets the mocked instance before each test is run.
+
+Next, add the `setupFilesAfterEnv` property to your `jest.config.js` file with the path to your `singleton.ts` file.
+
+```js file=jest.config.js highlight=5;add showLineNumbers
+module.exports = {
+ clearMocks: true,
+ preset: 'ts-jest',
+ testEnvironment: 'node',
+ //add-next-line
+ setupFilesAfterEnv: ['/singleton.ts'],
+}
+```
+
+### Dependency injection
+
+Another popular pattern that can be used is dependency injection.
+
+1. Create a `context.ts` file and add the following:
+
+ ```ts file=context.ts
+ import { PrismaClient } from '@prisma/client'
+ import { mockDeep, DeepMockProxy } from 'jest-mock-extended'
+
+ export type Context = {
+ prisma: PrismaClient
+ }
+
+ export type MockContext = {
+ prisma: DeepMockProxy
+ }
+
+ export const createMockContext = (): MockContext => {
+ return {
+ prisma: mockDeep(),
+ }
+ }
+ ```
+
+:::tip
+
+If you find that you're seeing a circular dependency error highlighted through mocking Prisma Client, try adding `"strictNullChecks": true`
+to your `tsconfig.json`.
+
+:::
+
+2. To use the context, you would do the following in your test file:
+
+ ```ts
+ import { MockContext, Context, createMockContext } from '../context'
+
+ let mockCtx: MockContext
+ let ctx: Context
+
+ beforeEach(() => {
+ mockCtx = createMockContext()
+ ctx = mockCtx as unknown as Context
+ })
+ ```
+
+This will create a new context before each test is run via the `createMockContext` function. This (`mockCtx`) context will be used to make a mock call to Prisma Client and run a query to test. The `ctx` context will be used to run a scenario query that is tested against.
+
+## Example unit tests
+
+A real world use case for unit testing Prisma ORM might be a signup form. Your user fills in a form which calls a function, which in turn uses Prisma Client to make a call to your database.
+
+All of the examples that follow use the following schema model:
+
+```prisma file=schema.prisma showLineNumbers
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+ acceptTermsAndConditions Boolean
+}
+```
+
+The following unit tests will mock the process of
+
+- Creating a new user
+- Updating a users name
+- Failing to create a user if terms are not accepted
+
+The functions that use the dependency injection pattern will have the context injected (passed in as a parameter) into them, whereas the functions that use the singleton pattern will use the singleton instance of Prisma Client.
+
+```ts file=functions-with-context.ts
+import { Context } from './context'
+
+interface CreateUser {
+ name: string
+ email: string
+ acceptTermsAndConditions: boolean
+}
+
+export async function createUser(user: CreateUser, ctx: Context) {
+ if (user.acceptTermsAndConditions) {
+ return await ctx.prisma.user.create({
+ data: user,
+ })
+ } else {
+ return new Error('User must accept terms!')
+ }
+}
+
+interface UpdateUser {
+ id: number
+ name: string
+ email: string
+}
+
+export async function updateUsername(user: UpdateUser, ctx: Context) {
+ return await ctx.prisma.user.update({
+ where: { id: user.id },
+ data: user,
+ })
+}
+```
+
+```ts file=functions-without-context.ts
+import prisma from './client'
+
+interface CreateUser {
+ name: string
+ email: string
+ acceptTermsAndConditions: boolean
+}
+
+export async function createUser(user: CreateUser) {
+ if (user.acceptTermsAndConditions) {
+ return await prisma.user.create({
+ data: user,
+ })
+ } else {
+ return new Error('User must accept terms!')
+ }
+}
+
+interface UpdateUser {
+ id: number
+ name: string
+ email: string
+}
+
+export async function updateUsername(user: UpdateUser) {
+ return await prisma.user.update({
+ where: { id: user.id },
+ data: user,
+ })
+}
+```
+
+The tests for each methodology are fairly similar, the difference is how the mocked Prisma Client is used.
+
+The **_dependency injection_** example passes the context through to the function that is being tested as well as using it to call the mock implementation.
+
+The **_singleton_** example uses the singleton client instance to call the mock implementation.
+
+```ts file=__tests__/with-singleton.ts
+import { createUser, updateUsername } from '../functions-without-context'
+import { prismaMock } from '../singleton'
+
+test('should create new user ', async () => {
+ const user = {
+ id: 1,
+ name: 'Rich',
+ email: 'hello@prisma.io',
+ acceptTermsAndConditions: true,
+ }
+
+ prismaMock.user.create.mockResolvedValue(user)
+
+ await expect(createUser(user)).resolves.toEqual({
+ id: 1,
+ name: 'Rich',
+ email: 'hello@prisma.io',
+ acceptTermsAndConditions: true,
+ })
+})
+
+test('should update a users name ', async () => {
+ const user = {
+ id: 1,
+ name: 'Rich Haines',
+ email: 'hello@prisma.io',
+ acceptTermsAndConditions: true,
+ }
+
+ prismaMock.user.update.mockResolvedValue(user)
+
+ await expect(updateUsername(user)).resolves.toEqual({
+ id: 1,
+ name: 'Rich Haines',
+ email: 'hello@prisma.io',
+ acceptTermsAndConditions: true,
+ })
+})
+
+test('should fail if user does not accept terms', async () => {
+ const user = {
+ id: 1,
+ name: 'Rich Haines',
+ email: 'hello@prisma.io',
+ acceptTermsAndConditions: false,
+ }
+
+ prismaMock.user.create.mockImplementation()
+
+ await expect(createUser(user)).resolves.toEqual(
+ new Error('User must accept terms!')
+ )
+})
+```
+
+```ts file=__tests__/with-dependency-injection.ts
+import { MockContext, Context, createMockContext } from '../context'
+import { createUser, updateUsername } from '../functions-with-context'
+
+let mockCtx: MockContext
+let ctx: Context
+
+beforeEach(() => {
+ mockCtx = createMockContext()
+ ctx = mockCtx as unknown as Context
+})
+
+test('should create new user ', async () => {
+ const user = {
+ id: 1,
+ name: 'Rich',
+ email: 'hello@prisma.io',
+ acceptTermsAndConditions: true,
+ }
+ mockCtx.prisma.user.create.mockResolvedValue(user)
+
+ await expect(createUser(user, ctx)).resolves.toEqual({
+ id: 1,
+ name: 'Rich',
+ email: 'hello@prisma.io',
+ acceptTermsAndConditions: true,
+ })
+})
+
+test('should update a users name ', async () => {
+ const user = {
+ id: 1,
+ name: 'Rich Haines',
+ email: 'hello@prisma.io',
+ acceptTermsAndConditions: true,
+ }
+ mockCtx.prisma.user.update.mockResolvedValue(user)
+
+ await expect(updateUsername(user, ctx)).resolves.toEqual({
+ id: 1,
+ name: 'Rich Haines',
+ email: 'hello@prisma.io',
+ acceptTermsAndConditions: true,
+ })
+})
+
+test('should fail if user does not accept terms', async () => {
+ const user = {
+ id: 1,
+ name: 'Rich Haines',
+ email: 'hello@prisma.io',
+ acceptTermsAndConditions: false,
+ }
+
+ mockCtx.prisma.user.create.mockImplementation()
+
+ await expect(createUser(user, ctx)).resolves.toEqual(
+ new Error('User must accept terms!')
+ )
+})
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/450-testing/150-integration-testing.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/450-testing/150-integration-testing.mdx
new file mode 100644
index 0000000000..2f38c90604
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/450-testing/150-integration-testing.mdx
@@ -0,0 +1,481 @@
+---
+title: 'Integration testing'
+metaTitle: 'Integration testing with Prisma'
+metaDescription: 'Learn how to setup and run integration tests with Prisma and Docker'
+tocDepth: 3
+---
+
+
+
+Integration tests focus on testing how separate parts of the program work together. In the context of applications using a database, integration tests usually require a database to be available and contain data that is convenient to the scenarios intended to be tested.
+
+One way to simulate a real world environment is to use [Docker](https://www.docker.com/get-started/) to encapsulate a database and some test data. This can be spun up and torn down with the tests and so operate as an isolated environment away from your production databases.
+
+
+
+> **Note:** This [blog post](https://www.prisma.io/blog/testing-series-2-xPhjjmIEsM) offers a comprehensive guide on setting up an integration testing environment and writing integration tests against a real database, providing valuable insights for those looking to explore this topic.
+
+## Prerequisites
+
+This guide assumes you have [Docker](https://docs.docker.com/get-started/get-docker/) and [Docker Compose](https://docs.docker.com/compose/install/) installed on your machine as well as `Jest` setup in your project.
+
+The following ecommerce schema will be used throughout the guide. This varies from the traditional `User` and `Post` models used in other parts of the docs, mainly because it is unlikely you will be running integration tests against your blog.
+
+
+
+Ecommerce schema
+
+```prisma file=schema.prisma showLineNumbers
+// Can have 1 customer
+// Can have many order details
+model CustomerOrder {
+ id Int @id @default(autoincrement())
+ createdAt DateTime @default(now())
+ customer Customer @relation(fields: [customerId], references: [id])
+ customerId Int
+ orderDetails OrderDetails[]
+}
+
+// Can have 1 order
+// Can have many products
+model OrderDetails {
+ id Int @id @default(autoincrement())
+ products Product @relation(fields: [productId], references: [id])
+ productId Int
+ order CustomerOrder @relation(fields: [orderId], references: [id])
+ orderId Int
+ total Decimal
+ quantity Int
+}
+
+// Can have many order details
+// Can have 1 category
+model Product {
+ id Int @id @default(autoincrement())
+ name String
+ description String
+ price Decimal
+ sku Int
+ orderDetails OrderDetails[]
+ category Category @relation(fields: [categoryId], references: [id])
+ categoryId Int
+}
+
+// Can have many products
+model Category {
+ id Int @id @default(autoincrement())
+ name String
+ products Product[]
+}
+
+// Can have many orders
+model Customer {
+ id Int @id @default(autoincrement())
+ email String @unique
+ address String?
+ name String?
+ orders CustomerOrder[]
+}
+```
+
+
+
+The guide uses a singleton pattern for Prisma Client setup. Refer to the [singleton](/orm/prisma-client/testing/unit-testing#singleton) docs for a walk through of how to set that up.
+
+## Add Docker to your project
+
+
+
+With Docker and Docker compose both installed on your machine you can use them in your project.
+
+1. Begin by creating a `docker-compose.yml` file at your projects root. Here you will add a Postgres image and specify the environments credentials.
+
+```yml file=docker-compose.yml
+# Set the version of docker compose to use
+version: '3.9'
+
+# The containers that compose the project
+services:
+ db:
+ image: postgres:13
+ restart: always
+ container_name: integration-tests-prisma
+ ports:
+ - '5433:5432'
+ environment:
+ POSTGRES_USER: prisma
+ POSTGRES_PASSWORD: prisma
+ POSTGRES_DB: tests
+```
+
+> **Note**: The compose version used here (`3.9`) is the latest at the time of writing, if you are following along be sure to use the same version for consistency.
+
+The `docker-compose.yml` file defines the following:
+
+- The Postgres image (`postgres`) and version tag (`:13`). This will be downloaded if you do not have it locally available.
+- The port `5433` is mapped to the internal (Postgres default) port `5432`. This will be the port number the database is exposed on externally.
+- The database user credentials are set and the database given a name.
+
+2. To connect to the database in the container, create a new connection string with the credentials defined in the `docker-compose.yml` file. For example:
+
+```env file=.env.test
+DATABASE_URL="postgresql://prisma:prisma@localhost:5433/tests"
+```
+
+
+
+The above `.env.test` file is used as part of a multiple `.env` file setup. Checkout the [using multiple .env files.](/orm/more/development-environment/environment-variables) section to learn more about setting up your project with multiple `.env` files
+
+
+
+3. To create the container in a detached state so that you can continue to use the terminal tab, run the following command:
+
+```terminal
+docker compose up -d
+```
+
+4. Next you can check that the database has been created by executing a `psql` command inside the container. Make a note of the container id.
+
+
+
+
+
+ ```
+ docker ps
+ ```
+
+
+
+
+
+ ```code no-copy
+ CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
+ 1322e42d833f postgres:13 "docker-entrypoint.s…" 2 seconds ago Up 1 second 0.0.0.0:5433->5432/tcp integration-tests-prisma
+ ```
+
+
+
+
+
+> **Note**: The container id is unique to each container, you will see a different id displayed.
+
+5. Using the container id from the previous step, run `psql` in the container, login with the created user and check the database is created:
+
+
+
+
+
+ ```
+ docker exec -it 1322e42d833f psql -U prisma tests
+ ```
+
+
+
+
+
+ ```code no-copy
+ tests=# \l
+ List of databases
+ Name | Owner | Encoding | Collate | Ctype | Access privileges
+
+ postgres | prisma | UTF8 | en_US.utf8 | en_US.utf8 |
+ template0 | prisma | UTF8 | en_US.utf8 | en_US.utf8 | =c/prisma +
+ | | | | | prisma=CTc/prisma
+ template1 | prisma | UTF8 | en_US.utf8 | en_US.utf8 | =c/prisma +
+ | | | | | prisma=CTc/prisma
+ tests | prisma | UTF8 | en_US.utf8 | en_US.utf8 |
+ (4 rows)
+ ```
+
+
+
+
+
+## Integration testing
+
+Integration tests will be run against a database in a **dedicated test environment** instead of the production or development environments.
+
+### The flow of operations
+
+The flow for running said tests goes as follows:
+
+1. Start the container and create the database
+1. Migrate the schema
+1. Run the tests
+1. Destroy the container
+
+Each test suite will seed the database before all the test are run. After all the tests in the suite have finished, the data from all the tables will be dropped and the connection terminated.
+
+### The function to test
+
+The ecommerce application you are testing has a function which creates an order. This function does the following:
+
+- Accepts input about the customer making the order
+- Accepts input about the product being ordered
+- Checks if the customer has an existing account
+- Checks if the product is in stock
+- Returns an "Out of stock" message if the product doesn't exist
+- Creates an account if the customer doesn't exist in the database
+- Create the order
+
+An example of how such a function might look can be seen below:
+
+```ts file=create-order.ts
+import prisma from '../client'
+
+export interface Customer {
+ id?: number
+ name?: string
+ email: string
+ address?: string
+}
+
+export interface OrderInput {
+ customer: Customer
+ productId: number
+ quantity: number
+}
+
+/**
+ * Creates an order with customer.
+ * @param input The order parameters
+ */
+export async function createOrder(input: OrderInput) {
+ const { productId, quantity, customer } = input
+ const { name, email, address } = customer
+
+ // Get the product
+ const product = await prisma.product.findUnique({
+ where: {
+ id: productId,
+ },
+ })
+
+ // If the product is null its out of stock, return error.
+ if (!product) return new Error('Out of stock')
+
+ // If the customer is new then create the record, otherwise connect via their unique email
+ await prisma.customerOrder.create({
+ data: {
+ customer: {
+ connectOrCreate: {
+ create: {
+ name,
+ email,
+ address,
+ },
+ where: {
+ email,
+ },
+ },
+ },
+ orderDetails: {
+ create: {
+ total: product.price,
+ quantity,
+ products: {
+ connect: {
+ id: product.id,
+ },
+ },
+ },
+ },
+ },
+ })
+}
+```
+
+### The test suite
+
+The following tests will check if the `createOrder` function works as it should do. They will test:
+
+- Creating a new order with a new customer
+- Creating an order with an existing customer
+- Show an "Out of stock" error message if a product doesn't exist
+
+Before the test suite is run the database is seeded with data. After the test suite has finished a [`deleteMany`](/6.0/orm/reference/prisma-client-reference#deletemany) is used to clear the database of its data.
+
+:::tip
+
+Using `deleteMany` may suffice in situations where you know ahead of time how your schema is structured. This is because the operations need to be executed in the correct order according to how the model relations are setup.
+
+However, this doesn't scale as well as having a more generic solution that maps over your models and performs a truncate on them. For those scenarios and examples of using raw SQL queries see [Deleting all data with raw SQL / `TRUNCATE`](/orm/prisma-client/queries/crud#deleting-all-data-with-raw-sql--truncate)
+
+:::
+
+```ts file=__tests__/create-order.ts
+import prisma from '../src/client'
+import { createOrder, Customer, OrderInput } from '../src/functions/index'
+
+beforeAll(async () => {
+ // create product categories
+ await prisma.category.createMany({
+ data: [{ name: 'Wand' }, { name: 'Broomstick' }],
+ })
+
+ console.log('✨ 2 categories successfully created!')
+
+ // create products
+ await prisma.product.createMany({
+ data: [
+ {
+ name: 'Holly, 11", phoenix feather',
+ description: 'Harry Potters wand',
+ price: 100,
+ sku: 1,
+ categoryId: 1,
+ },
+ {
+ name: 'Nimbus 2000',
+ description: 'Harry Potters broom',
+ price: 500,
+ sku: 2,
+ categoryId: 2,
+ },
+ ],
+ })
+
+ console.log('✨ 2 products successfully created!')
+
+ // create the customer
+ await prisma.customer.create({
+ data: {
+ name: 'Harry Potter',
+ email: 'harry@hogwarts.io',
+ address: '4 Privet Drive',
+ },
+ })
+
+ console.log('✨ 1 customer successfully created!')
+})
+
+afterAll(async () => {
+ const deleteOrderDetails = prisma.orderDetails.deleteMany()
+ const deleteProduct = prisma.product.deleteMany()
+ const deleteCategory = prisma.category.deleteMany()
+ const deleteCustomerOrder = prisma.customerOrder.deleteMany()
+ const deleteCustomer = prisma.customer.deleteMany()
+
+ await prisma.$transaction([
+ deleteOrderDetails,
+ deleteProduct,
+ deleteCategory,
+ deleteCustomerOrder,
+ deleteCustomer,
+ ])
+
+ await prisma.$disconnect()
+})
+
+it('should create 1 new customer with 1 order', async () => {
+ // The new customers details
+ const customer: Customer = {
+ id: 2,
+ name: 'Hermione Granger',
+ email: 'hermione@hogwarts.io',
+ address: '2 Hampstead Heath',
+ }
+ // The new orders details
+ const order: OrderInput = {
+ customer,
+ productId: 1,
+ quantity: 1,
+ }
+
+ // Create the order and customer
+ await createOrder(order)
+
+ // Check if the new customer was created by filtering on unique email field
+ const newCustomer = await prisma.customer.findUnique({
+ where: {
+ email: customer.email,
+ },
+ })
+
+ // Check if the new order was created by filtering on unique email field of the customer
+ const newOrder = await prisma.customerOrder.findFirst({
+ where: {
+ customer: {
+ email: customer.email,
+ },
+ },
+ })
+
+ // Expect the new customer to have been created and match the input
+ expect(newCustomer).toEqual(customer)
+ // Expect the new order to have been created and contain the new customer
+ expect(newOrder).toHaveProperty('customerId', 2)
+})
+
+it('should create 1 order with an existing customer', async () => {
+ // The existing customers email
+ const customer: Customer = {
+ email: 'harry@hogwarts.io',
+ }
+ // The new orders details
+ const order: OrderInput = {
+ customer,
+ productId: 1,
+ quantity: 1,
+ }
+
+ // Create the order and connect the existing customer
+ await createOrder(order)
+
+ // Check if the new order was created by filtering on unique email field of the customer
+ const newOrder = await prisma.customerOrder.findFirst({
+ where: {
+ customer: {
+ email: customer.email,
+ },
+ },
+ })
+
+ // Expect the new order to have been created and contain the existing customer with an id of 1 (Harry Potter from the seed script)
+ expect(newOrder).toHaveProperty('customerId', 1)
+})
+
+it("should show 'Out of stock' message if productId doesn't exit", async () => {
+ // The existing customers email
+ const customer: Customer = {
+ email: 'harry@hogwarts.io',
+ }
+ // The new orders details
+ const order: OrderInput = {
+ customer,
+ productId: 3,
+ quantity: 1,
+ }
+
+ // The productId supplied doesn't exit so the function should return an "Out of stock" message
+ await expect(createOrder(order)).resolves.toEqual(new Error('Out of stock'))
+})
+```
+
+## Running the tests
+
+This setup isolates a real world scenario so that you can test your applications functionality against real data in a controlled environment.
+
+You can add some scripts to your projects `package.json` file which will setup the database and run the tests, then afterwards manually destroy the container.
+
+:::warning
+
+If the test doesn't work for you, you'll need to ensure the test database is properly set up and ready, as explained in this [blog](https://www.prisma.io/blog/testing-series-3-aBUyF8nxAn#make-the-script-wait-until-the-database-server-is-ready).
+
+:::
+
+```json file=package.json
+ "scripts": {
+ "docker:up": "docker compose up -d",
+ "docker:down": "docker compose down",
+ "test": "yarn docker:up && yarn prisma migrate deploy && jest -i"
+ },
+```
+
+The `test` script does the following:
+
+1. Runs `docker compose up -d` to create the container with the Postgres image and database.
+1. Applies the migrations found in `./prisma/migrations/` directory to the database, this creates the tables in the container's database.
+1. Executes the tests.
+
+Once you are satisfied you can run `yarn docker:down` to destroy the container, its database and any test data.
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/450-testing/Docker_Diagram_V1.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/450-testing/Docker_Diagram_V1.png
new file mode 100644
index 0000000000..e2bc67509d
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/450-testing/Docker_Diagram_V1.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/450-testing/index.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/450-testing/index.mdx
new file mode 100644
index 0000000000..0a910771a7
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/450-testing/index.mdx
@@ -0,0 +1,14 @@
+---
+title: 'Testing'
+metaTitle: 'Testing with Prisma ORM'
+metaDescription: 'How to implement unit and integration testing with Prisma ORM'
+hide_table_of_contents: true
+---
+
+
+
+This section describes how to approach testing an application that uses Prisma Client.
+
+
+
+
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/001-deploy-prisma.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/001-deploy-prisma.mdx
new file mode 100644
index 0000000000..c34fff370e
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/001-deploy-prisma.mdx
@@ -0,0 +1,62 @@
+---
+title: 'Deploy Prisma ORM'
+metaTitle: 'Deploying Prisma ORM-based projects'
+metaDescription: 'Learn more about the different deployment paradigms for Node.js applications and how they affect deploying an application using Prisma Client.'
+tocDepth: 2
+---
+
+Projects using Prisma Client can be deployed to many different cloud platforms. Given the variety of cloud platforms and different names, it's noteworthy to mention the different deployment paradigms, as they affect the way you deploy an application using Prisma Client.
+
+:::tip Use Prisma ORM without Rust binaries
+
+If Prisma ORM's Rust engine binaries cause large bundle sizes, slow builds, or deployment issues (for example, in serverless or edge environments), you can use it without them using this configuration of your `generator` block:
+
+```prisma
+generator client {
+ provider = "prisma-client-js" // or "prisma-client"
+ engineType = "client"
+}
+```
+
+Prisma ORM without Rust binaries has been [Generally Available](/orm/more/releases#generally-available-ga) since [v6.16.0](https://pris.ly/release/6.16.0).
+
+Note that you need to use a [driver adapter](/orm/overview/databases/database-drivers#driver-adapters) in this case.
+
+When using this architecture:
+
+- No Rust query engine binary is downloaded or shipped.
+- The database connection pool is maintained by the native JS database driver you install (e.g., `@prisma/adapter-pg` for PostgreSQL).
+
+This setup can simplify deployments in serverless or edge runtimes. Learn more in the [docs here](/orm/prisma-client/setup-and-configuration/no-rust-engine).
+
+Curious why we moved away from the Rust engine? Take a look at why we transitioned from Rust binary engines to an all-TypeScript approach for a faster, lighter Prisma ORM in this [blog post](https://www.prisma.io/blog/prisma-orm-without-rust-latest-performance-benchmarks).
+
+:::
+
+## Deployment paradigms
+
+Each paradigm has different tradeoffs that affect the performance, scalability, and operational costs of your application.
+
+Moreover, the user traffic pattern of your application is also an important factor to consider. For example, any application with consistent user traffic may be better suited for a [continuously running paradigm](#traditional-servers), whereas an application with sudden spikes may be better suited to [serverless](#serverless-functions).
+
+### Traditional servers
+
+Your application is [traditionally deployed](/orm/prisma-client/deployment/traditional) if a Node.js process is continuously running and handles multiple requests at the same time. Your application could be deployed to a Platform-as-a-Service (PaaS) like [Heroku](/orm/prisma-client/deployment/traditional/deploy-to-heroku), [Koyeb](/orm/prisma-client/deployment/traditional/deploy-to-koyeb), or [Render](/orm/prisma-client/deployment/traditional/deploy-to-render); as a Docker container to Kubernetes; or as a Node.js process on a virtual machine or bare metal server.
+
+See also: [Connection management in long-running processes](/orm/prisma-client/setup-and-configuration/databases-connections#long-running-processes)
+
+### Serverless Functions
+
+Your application is [serverless](/orm/prisma-client/deployment/serverless) if the Node.js processes of your application (or subsets of it broken into functions) are started as requests come in, and each function only handles one request at a time. Your application would most likely be deployed to a Function-as-a-Service (FaaS) offering, such as [AWS Lambda](/orm/prisma-client/deployment/serverless/deploy-to-aws-lambda) or [Azure Functions](/orm/prisma-client/deployment/serverless/deploy-to-azure-functions)
+
+Serverless environments have the concept of warm starts, which means that for subsequent invocations of the same function, it may use an already existing container that has the allocated processes, memory, file system (`/tmp` is writable on AWS Lambda), and even DB connection still available.
+
+Typically, any piece of code [outside the handler](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) remains initialized.
+
+See also: [Connection management in serverless environments](/orm/prisma-client/setup-and-configuration/databases-connections#serverless-environments-faas)
+
+### Edge Functions
+
+Your application is [edge deployed](/orm/prisma-client/deployment/edge) if your application is [serverless](#serverless-functions) and the functions are distributed across one or more regions close to the user.
+
+Typically, edge environments also have a different runtime than a traditional or serverless environment, leading to common APIs being unavailable.
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/200-deploy-to-heroku.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/200-deploy-to-heroku.mdx
new file mode 100644
index 0000000000..d45ffd8200
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/200-deploy-to-heroku.mdx
@@ -0,0 +1,290 @@
+---
+title: 'Deploy to Heroku'
+metaTitle: 'Deploy a Prisma app to Heroku'
+metaDescription: 'Learn how to deploy a Node.js server that uses Prisma ORM to Heroku.'
+---
+
+
+
+In this guide, you will set up and deploy a Node.js server that uses Prisma ORM with PostgreSQL to [Heroku](https://www.heroku.com). The application exposes a REST API and uses Prisma Client to handle fetching, creating, and deleting records from a database.
+
+Heroku is a cloud platform as a service (PaaS). In contrast to the popular serverless deployment model, with Heroku, your application is constantly running even if no requests are made to it. This has several benefits due to the connection limits of a PostgreSQL database. For more information, check out the [general deployment documentation](/orm/prisma-client/deployment/deploy-prisma)
+
+Typically Heroku integrates with a Git repository for automatic deployments upon commits. You can deploy to Heroku from a GitHub repository or by pushing your source to a [Git repository that Heroku creates per app](https://devcenter.heroku.com/articles/git). This guide uses the latter approach whereby you push your code to the app's repository on Heroku, which triggers a build and deploys the application.
+
+The application has the following components:
+
+- **Backend**: Node.js REST API built with Express.js with resource endpoints that use Prisma Client to handle database operations against a PostgreSQL database (e.g., hosted on Heroku).
+- **Frontend**: Static HTML page to interact with the API.
+
+
+
+The focus of this guide is showing how to deploy projects using Prisma ORM to Heroku. The starting point will be the [Prisma Heroku example](https://github.com/prisma/prisma-examples/tree/latest/deployment-platforms/heroku), which contains an Express.js server with a couple of preconfigured REST endpoints and a simple frontend.
+
+> **Note:** The various **checkpoints** throughout the guide allowing you to validate whether you performed the steps correctly.
+
+
+
+## A note on deploying GraphQL servers to Heroku
+
+While the example uses REST, the same principles apply to a GraphQL server, with the main difference being that you typically have a single GraphQL API endpoint rather than a route for every resource as with REST.
+
+## Prerequisites
+
+- [Heroku](https://www.heroku.com) account.
+- [Heroku CLI](https://devcenter.heroku.com/articles/heroku-cli) installed.
+- Node.js installed.
+- PostgreSQL CLI `psql` installed.
+
+> **Note:** Heroku doesn't provide a free plan, so billing information is required.
+
+## Prisma ORM workflow
+
+At the core of Prisma ORM is the [Prisma schema](/orm/prisma-schema) – a declarative configuration where you define your data model and other Prisma ORM-related configuration. The Prisma schema is also a single source of truth for both Prisma Client and Prisma Migrate.
+
+In this guide, you will use [Prisma Migrate](/orm/prisma-migrate) to create the database schema. Prisma Migrate is based on the Prisma schema and works by generating `.sql` migration files that are executed against the database.
+
+Migrate comes with two primary workflows:
+
+- Creating migrations and applying during local development with `prisma migrate dev`
+- Applying generated migration to production with `prisma migrate deploy`
+
+For brevity, the guide does not cover how migrations are created with `prisma migrate dev`. Rather, it focuses on the production workflow and uses the Prisma schema and SQL migration that are included in the example code.
+
+You will use Heroku's [release phase](https://devcenter.heroku.com/articles/release-phase) to run the `prisma migrate deploy` command so that the migrations are applied before the application starts.
+
+To learn more about how migrations are created with Prisma Migrate, check out the [start from scratch guide](/getting-started/setup-prisma/start-from-scratch/relational-databases-typescript-postgresql)
+
+## 1. Download the example and install dependencies
+
+Open your terminal and navigate to a location of your choice. Create the directory that will hold the application code and download the example code:
+
+```no-lines wrap
+mkdir prisma-heroku
+cd prisma-heroku
+curl https://codeload.github.com/prisma/prisma-examples/tar.gz/latest | tar -xz --strip=3 prisma-examples-latest/deployment-platforms/heroku
+```
+
+**Checkpoint:** `ls -1` should show:
+
+```no-lines
+ls -1
+Procfile
+README.md
+package.json
+prisma
+public
+src
+```
+
+Install the dependencies:
+
+```no-lines
+npm install
+```
+
+> **Note:** The `Procfile` tells Heroku the command needed to start the application, i.e. `npm start`, and the command to run during the release phase, i.e., `npx prisma migrate deploy`
+
+## 2. Create a Git repository for the application
+
+In the previous step, you downloaded the code. In this step, you will create a repository from the code so that you can push it to Heroku for deployment.
+
+To do so, run `git init` from the source code folder:
+
+```no-lines
+git init
+> Initialized empty Git repository in /Users/alice/prisma-heroku/.git/
+```
+
+To use the `main` branch as the default branch, run the following command:
+
+```no-lines
+git branch -M main
+```
+
+With the repository initialized, add and commit the files:
+
+```no-lines
+git add .
+git commit -m 'Initial commit'
+```
+
+**Checkpoint:** `git log -1` should show the commit:
+
+```no-lines
+git log -1
+commit 895534590fdd260acee6396e2e1c0438d1be7fed (HEAD -> main)
+```
+
+## 3. Heroku CLI login
+
+Make sure you're logged in to Heroku with the CLI:
+
+```no-lines
+heroku login
+```
+
+This will allow you to deploy to Heroku from the terminal.
+
+**Checkpoint:** `heroku auth:whoami` should show your username:
+
+```no-lines
+heroku auth:whoami
+> your-email
+```
+
+## 4. Create a Heroku app
+
+To deploy an application to Heroku, you need to create an app. You can do so with the following command:
+
+```no-lines
+heroku apps:create your-app-name
+```
+
+> **Note:** Use a unique name of your choice instead of `your-app-name`.
+
+**Checkpoint:** You should see the URL and the repository for your Heroku app:
+
+```no-lines wrap
+heroku apps:create your-app-name
+> Creating ⬢ your-app-name... done
+> https://your-app-name.herokuapp.com/ | https://git.heroku.com/your-app-name.git
+```
+
+Creating the Heroku app will add the git remote Heroku created to your local repository. Pushing commits to this remote will trigger a deploy.
+
+**Checkpoint:** `git remote -v` should show the Heroku git remote for your application:
+
+```no-lines
+heroku https://git.heroku.com/your-app-name.git (fetch)
+heroku https://git.heroku.com/your-app-name.git (push)
+```
+
+If you don't see the heroku remote, use the following command to add it:
+
+```no-lines
+heroku git:remote --app your-app-name
+```
+
+## 5. Add a PostgreSQL database to your application
+
+Heroku allows your to provision a PostgreSQL database as part of an application.
+
+Create the database with the following command:
+
+```no-lines
+heroku addons:create heroku-postgresql:hobby-dev
+```
+
+**Checkpoint:** To verify the database was created you should see the following:
+
+```no-lines
+Creating heroku-postgresql:hobby-dev on ⬢ your-app-name... free
+Database has been created and is available
+ ! This database is empty. If upgrading, you can transfer
+ ! data from another database with pg:copy
+Created postgresql-parallel-73780 as DATABASE_URL
+```
+
+> **Note:** Heroku automatically sets the `DATABASE_URL` environment variable when the app is running on Heroku. Prisma ORM uses this environment variable because it's declared in the _datasource_ block of the Prisma schema (`prisma/schema.prisma`) with `env("DATABASE_URL")`.
+
+## 6. Push to deploy
+
+Deploy the app by pushing the changes to the Heroku app repository:
+
+```no-lines
+git push heroku main
+```
+
+This will trigger a build and deploy your application to Heroku. Heroku will also run the `npx prisma migrate deploy` command which executes the migrations to create the database schema before deploying the app (as defined in the `release` step of the `Procfile`).
+
+**Checkpoint:** `git push` will emit the logs from the build and release phase and display the URL of the deployed app:
+
+```no-lines wrap
+remote: -----> Launching...
+remote: ! Release command declared: this new release will not be available until the command succeeds.
+remote: Released v5
+remote: https://your-app-name.herokuapp.com/ deployed to Heroku
+remote:
+remote: Verifying deploy... done.
+remote: Running release command...
+remote:
+remote: Prisma schema loaded from prisma/schema.prisma
+remote: Datasource "db": PostgreSQL database "your-db-name", schema "public" at "your-db-host.compute-1.amazonaws.com:5432"
+remote:
+remote: 1 migration found in prisma/migrations
+remote:
+remote: The following migration have been applied:
+remote:
+remote: migrations/
+remote: └─ 20210310152103_init/
+remote: └─ migration.sql
+remote:
+remote: All migrations have been successfully applied.
+remote: Waiting for release.... done.
+```
+
+> **Note:** Heroku will also set the `PORT` environment variable to which your application is bound.
+
+## 7. Test your deployed application
+
+You can use the static frontend to interact with the API you deployed via the preview URL.
+
+Open up the preview URL in your browser, the URL should like this: `https://APP_NAME.herokuapp.com`. You should see the following:
+
+
+
+The buttons allow you to make requests to the REST API and view the response:
+
+- **Check API status**: Will call the REST API status endpoint that returns `{"up":true}`.
+- **Seed data**: Will seed the database with a test `user` and `post`. Returns the created users.
+- **Load feed**: Will load all `users` in the database with their related `profiles`.
+
+For more insight into Prisma Client's API, look at the route handlers in the `src/index.js` file.
+
+You can view the application's logs with the `heroku logs --tail` command:
+
+```no-lines wrap
+2020-07-07T14:39:07.396544+00:00 app[web.1]:
+2020-07-07T14:39:07.396569+00:00 app[web.1]: > prisma-heroku@1.0.0 start /app
+2020-07-07T14:39:07.396569+00:00 app[web.1]: > node src/index.js
+2020-07-07T14:39:07.396570+00:00 app[web.1]:
+2020-07-07T14:39:07.657505+00:00 app[web.1]: 🚀 Server ready at: http://localhost:12516
+2020-07-07T14:39:07.657526+00:00 app[web.1]: ⭐️ See sample requests: http://pris.ly/e/ts/rest-express#3-using-the-rest-api
+2020-07-07T14:39:07.842546+00:00 heroku[web.1]: State changed from starting to up
+```
+
+## Heroku specific notes
+
+There are some implementation details relating to Heroku that this guide addresses and are worth reiterating:
+
+- **Port binding**: web servers bind to a port so that they can accept connections. When deploying to Heroku The `PORT` environment variable is set by Heroku. Ensure you bind to `process.env.PORT` so that your application can accept requests once deployed. A common pattern is to try binding to try `process.env.PORT` and fallback to a preset port as follows:
+
+```js
+const PORT = process.env.PORT || 3000
+const server = app.listen(PORT, () => {
+ console.log(`app running on port ${PORT}`)
+})
+```
+
+- **Database URL**: As part of Heroku's provisioning process, a `DATABASE_URL` config var is added to your app’s configuration. This contains the URL your app uses to access the database. Ensure that your `schema.prisma` file uses `env("DATABASE_URL")` so that Prisma Client can successfully connect to the database.
+
+* **Disable SSL certificate validation**: When using the `PrismaPg` adapter with `DATABASE_URL`, make sure to disable SSL certificate validation in line with [Heroku's guidelines](https://devcenter.heroku.com/articles/connecting-heroku-postgres#connecting-in-node-js). Failing to do so can result in a `P1010 DriverAdapterError: DatabaseAccessDenied` error. You can handle this conditionally based on whether the database is local or hosted on Heroku:
+
+```js
+const isSecureDb = !process.env.DATABASE_URL.includes("@127.0.0.1")
+
+export const db = new PrismaClient({
+ adapter: new PrismaPg({
+ connectionString: process.env.DATABASE_URL + (isSecureDb ? `?sslmode=no-verify` : "")
+ })
+})
+```
+
+## Summary
+
+Congratulations! You have successfully deployed a Node.js app with Prisma ORM to Heroku.
+
+You can find the source code for the example in [this GitHub repository](https://github.com/prisma/prisma-examples/tree/latest/deployment-platforms/heroku).
+
+For more insight into Prisma Client's API, look at the route handlers in the `src/index.js` file.
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/225-deploy-to-render.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/225-deploy-to-render.mdx
new file mode 100644
index 0000000000..41526c1bd8
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/225-deploy-to-render.mdx
@@ -0,0 +1,134 @@
+---
+title: 'Deploy to Render'
+metaTitle: 'Deploy a Prisma app to Render'
+metaDescription: 'Learn how to deploy a Node.js server that uses Prisma ORM to Render.'
+---
+
+
+This guide explains how to deploy a Node.js server that uses Prisma ORM and PostgreSQL to Render.
+
+
+Questions answered in this page
+
+- How to deploy Prisma apps on Render?
+- How to run migrations before start?
+- What Render settings are recommended?
+
+
+
+The [Prisma Render deployment example](https://github.com/prisma/prisma-examples/tree/latest/deployment-platforms/render) contains an Express.js application with REST endpoints and a simple frontend. This app uses Prisma Client to fetch, create, and delete records from its database.
+
+## About Render
+
+[Render](https://render.com) is a cloud application platform that lets developers easily deploy and scale full-stack applications. For this example, it's helpful to know:
+- Render lets you deploy long-running, "serverful" full-stack applications. You can configure Render services to [autoscale](https://docs.render.com/scaling) based on CPU and/or memory usage. This is one of several [deployment paradigms](/orm/prisma-client/deployment/deploy-prisma) you can choose from.
+- Render natively supports [common runtimes](https://docs.render.com/language-support), including Node.js and Bun. In this guide, we'll use the Node.js runtime.
+- Render [integrates with Git repos](https://docs.render.com/github) for automatic deployments upon commits. You can deploy to Render from GitHub, GitLab, or Bitbucket. In this guide, we'll deploy from a Git repository.
+
+
+## Prerequisites
+
+- Sign up for a [Render](https://render.com) account
+
+## Get the example code
+Download the [example code](https://github.com/prisma/prisma-examples/tree/latest/deployment-platforms/render) to your local machine.
+```terminal
+curl https://codeload.github.com/prisma/prisma-examples/tar.gz/latest | tar -xz --strip=2 prisma-examples-latest/deployment-platforms/render
+cd render
+```
+
+## Understand the example
+
+Before we deploy the app, let's take a look at the example code.
+
+### Web application
+
+The logic for the Express app is in two files:
+- `src/index.js`: The API. The endpoints use Prisma Client to fetch, create, and delete data from the database.
+- `public/index.html`: The web frontend. The frontend calls a few of the API endpoints.
+
+### Prisma schema and migrations
+
+The Prisma components of this app are in two files:
+- `prisma/schema.prisma`: The data model of this app. This example defines two models, `User` and `Post`. The format of this file follows the [Prisma schema](/orm/prisma-schema/overview).
+- `prisma/migrations//migration.sql`: The SQL commands that construct this schema in a PostgreSQL database. You can auto-generate migration files like this one by running [`prisma migrate dev`](/orm/prisma-migrate/understanding-prisma-migrate/mental-model#what-is-prisma-migrate).
+
+### Render Blueprint
+
+The `render.yaml` file is a [Render blueprint](https://docs.render.com/infrastructure-as-code). Blueprints are Render's Infrastructure as Code format. You can use a Blueprint to programmatically create and modify services on Render.
+
+A `render.yaml` defines the services that will be spun up on Render by a Blueprint. In this `render.yaml`, we see:
+- **A web service that uses a Node runtime**: This is the Express app.
+- **A PostgreSQL database**: This is the database that the Express app uses.
+
+The format of this file follows the [Blueprint specification](https://docs.render.com/blueprint-spec).
+
+### How Render deploys work with Prisma Migrate
+
+In general, you want all your database migrations to run before your web app is started. Otherwise, the app may hit errors when it queries a database that doesn't have the expected tables and rows.
+
+You can use the Pre-Deploy Command setting in a Render deploy to run any commands, such as database migrations, before the app is started.
+
+For more details about the Pre-Deploy Command, see [Render's deploy guide](https://docs.render.com/deploys#deploy-steps).
+
+In our example code, the `render.yaml` shows the web service's build command, pre-deploy command, and start command. Notably, `npx prisma migrate deploy` (the pre-deploy command) will run before `npm run start` (the start command).
+
+| **Command** | **Value** |
+| :----------------- | :--------------------------- |
+| Build Command | `npm install --production=false` |
+| Pre-Deploy Command | `npx prisma migrate deploy` |
+| Start Command | `npm run start` |
+
+
+
+## Deploy the example
+
+### 1. Initialize your Git repository
+
+1. Download [the example code](https://github.com/prisma/prisma-examples/tree/latest/deployment-platforms/render) to your local machine.
+2. Create a new Git repository on GitHub, GitLab, or BitBucket.
+3. Upload the example code to your new repository.
+
+### 2. Deploy manually
+1. In the Render Dashboard, click **New** > **PostgreSQL**. Provide a database name, and select a plan. (The Free plan works for this demo.)
+2. After your database is ready, look up its [internal URL](https://docs.render.com/postgresql-creating-connecting#internal-connections).
+3. In the Render Dashboard, click **New** > **Web Service** and connect the Git repository that contains the example code.
+4. Provide the following values during service creation:
+
+| **Setting** | **Value** |
+| :-------------------- | :--------------------------- |
+| Language | `Node` |
+| Build Command | `npm install --production=false` |
+| Pre-Deploy Command (Note: this may be in the "Advanced" tab) | `npx prisma migrate deploy` |
+| Start Command | `npm run start` |
+| Environment Variables | Set `DATABASE_URL` to the internal URL of the database |
+
+That’s it. Your web service will be live at its `onrender.com` URL as soon as the build finishes.
+
+### 3. (optional) Deploy with Infrastructure as Code
+
+You can also deploy the example using the Render Blueprint. Follow Render's [Blueprint setup guide] and use the `render.yaml` in the example.
+
+## Bonus: Seed the database
+
+Prisma ORM includes a framework for [seeding the database](/orm/prisma-migrate/workflows/seeding) with starter data. In our example, `prisma/seed.js` defines some test users and posts.
+
+To add these users to the database, we can either:
+1. Add the seed script to our Pre-Deploy Command, or
+2. Manually run the command on our server via an SSH shell
+
+### Method 1: Pre-Deploy Command
+If you manually deployed your Render services:
+1. In the Render dashboard, navigate to your web service.
+2. Select **Settings**.
+3. Set the Pre-Deploy Command to: `npx prisma migrate deploy; npx prisma db seed`
+
+If you deployed your Render services using the Blueprint:
+1. In your `render.yaml` file, change the `preDeployCommand` to: `npx prisma migrate deploy; npx prisma db seed`
+2. Commit the change to your Git repo.
+
+### Method 2: SSH
+
+Render allows you to SSH into your web service.
+1. Follow [Render's SSH guide](https://docs.render.com/ssh) to connect to your server.
+2. In the shell, run: `npx prisma db seed`
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/250-deploy-to-koyeb.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/250-deploy-to-koyeb.mdx
new file mode 100644
index 0000000000..e6f3e9ac75
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/250-deploy-to-koyeb.mdx
@@ -0,0 +1,200 @@
+---
+title: 'Deploy to Koyeb'
+metaTitle: 'Deploy a Prisma ORM app to Koyeb'
+metaDescription: 'Learn how to deploy a Node.js server that uses Prisma ORM to Koyeb Serverless Platform.'
+---
+
+
+
+In this guide, you will set up and deploy a Node.js server that uses Prisma ORM with PostgreSQL to [Koyeb](https://www.koyeb.com/). The application exposes a REST API and uses Prisma Client to handle fetching, creating, and deleting records from a database.
+
+Koyeb is a developer-friendly serverless platform to deploy apps globally. The platform lets you seamlessly run Docker containers, web apps, and APIs with git-based deployment, TLS encryption, native autoscaling, a global edge network, and built-in service mesh & discovery.
+
+When using the [Koyeb git-driven deployment](https://www.koyeb.com/docs/build-and-deploy/build-from-git) method, each time you push code changes to a GitHub repository a new build and deployment of the application are automatically triggered on the Koyeb Serverless Platform.
+This guide uses the latter approach whereby you push your code to the app's repository on GitHub.
+
+The application has the following components:
+
+- **Backend**: Node.js REST API built with Express.js with resource endpoints that use Prisma Client to handle database operations against a PostgreSQL database (e.g., hosted on Heroku).
+- **Frontend**: Static HTML page to interact with the API.
+
+
+
+The focus of this guide is showing how to deploy projects using Prisma ORM to Koyeb. The starting point will be the [Prisma Koyeb example](https://github.com/koyeb/example-prisma), which contains an Express.js server with a couple of preconfigured REST endpoints and a simple frontend.
+
+> **Note:** The various **checkpoints** throughout the guide allow you to validate whether you performed the steps correctly.
+
+
+
+## Prerequisites
+
+- Hosted PostgreSQL database and a URL from which it can be accessed, e.g. `postgresql://username:password@your_postgres_db.cloud.com/db_identifier` (you can use Supabase, which offers a [free plan](https://dev.to/prisma/set-up-a-free-postgresql-database-on-supabase-to-use-with-prisma-3pk6)).
+- [GitHub](https://github.com) account with an empty public repository we will use to push the code.
+- [Koyeb](https://www.koyeb.com) account.
+- Node.js installed.
+
+## Prisma ORM workflow
+
+At the core of Prisma ORM is the [Prisma schema](/orm/prisma-schema) – a declarative configuration where you define your data model and other Prisma ORM-related configuration. The Prisma schema is also a single source of truth for both Prisma Client and Prisma Migrate.
+
+In this guide, you will create the database schema with [Prisma Migrate](/orm/prisma-migrate) to create the database schema. Prisma Migrate is based on the Prisma schema and works by generating `.sql` migration files that are executed against the database.
+
+Migrate comes with two primary workflows:
+
+- Creating migrations and applying them during local development with `prisma migrate dev`
+- Applying generated migration to production with `prisma migrate deploy`
+
+For brevity, the guide does not cover how migrations are created with `prisma migrate dev`. Rather, it focuses on the production workflow and uses the Prisma schema and SQL migration that are included in the example code.
+
+You will use Koyeb's [build step](https://www.koyeb.com/docs/build-and-deploy/build-from-git#the-buildpack-build-process) to run the `prisma migrate deploy` command so that the migrations are applied before the application starts.
+
+To learn more about how migrations are created with Prisma Migrate, check out the [start from scratch guide](/getting-started/setup-prisma/start-from-scratch/relational-databases-typescript-postgresql)
+
+## 1. Download the example and install dependencies
+
+Open your terminal and navigate to a location of your choice. Create the directory that will hold the application code and download the example code:
+
+```no-lines wrap
+mkdir prisma-on-koyeb
+cd prisma-on-koyeb
+curl https://github.com/koyeb/example-prisma/tarball/main/latest | tar xz --strip=1
+```
+
+**Checkpoint:** Executing the `tree` command should show the following directories and files:
+
+```no-lines
+.
+├── README.md
+├── package.json
+├── prisma
+│ ├── migrations
+│ │ ├── 20210310152103_init
+│ │ │ └── migration.sql
+│ │ └── migration_lock.toml
+│ └── schema.prisma
+├── public
+│ └── index.html
+└── src
+ └── index.js
+
+5 directories, 8 files
+```
+
+Install the dependencies:
+
+```no-lines
+npm install
+```
+
+## 2. Initialize a Git repository and push the application code to GitHub
+
+In the previous step, you downloaded the code. In this step, you will create a repository from the code so that you can push it to a GitHub repository for deployment.
+
+To do so, run `git init` from the source code folder:
+
+```no-lines
+git init
+> Initialized empty Git repository in /Users/edouardb/prisma-on-koyeb/.git/
+```
+
+With the repository initialized, add and commit the files:
+
+```no-lines
+git add .
+git commit -m 'Initial commit'
+```
+
+**Checkpoint:** `git log -1` should show the commit:
+
+```no-lines
+git log -1
+commit 895534590fdd260acee6396e2e1c0438d1be7fed (HEAD -> main)
+```
+
+Then, push the code to your GitHub repository by adding the remote
+
+```no-lines
+git remote add origin git@github.com:/.git
+git push -u origin main
+```
+
+## 3. Deploy the application on Koyeb
+
+On the [Koyeb Control Panel](https://app.koyeb.com), click the **Create App** button.
+
+You land on the Koyeb App creation page where you are asked for information about the application to deploy such as the deployment method to use, the repository URL, the branch to deploy, the build and run commands to execute.
+
+Pick GitHub as the deployment method and select the GitHub repository containing your application and set the branch to deploy to `main`.
+
+> **Note:** If this is your first time using Koyeb, you will be prompted to install the Koyeb app in your GitHub account.
+
+In the **Environment variables** section, create a new environment variable `DATABASE_URL` that is type Secret. In the value field, click **Create Secret**, name your secret `prisma-pg-url` and set the PostgreSQL database connection string as the secret value which should look as follows: `postgresql://__USER__:__PASSWORD__@__HOST__/__DATABASE__`.
+[Koyeb Secrets](https://www.koyeb.com/docs/reference/secrets) allow you to securely store and retrieve sensitive information like API tokens, database connection strings. They enable you to secure your code by removing hardcoded credentials and let you pass environment variables securely to your applications.
+
+Last, give your application a name and click the **Create App** button.
+
+**Checkpoint:** Open the deployed app by clicking on the screenshot of the deployed app. Once the page loads, click on the **Check API status** button, which should return: `{"up":true}`
+
+
+
+Congratulations! You have successfully deployed the app to Koyeb.
+
+Koyeb will build and deploy the application. Additional commits to your GitHub repository will trigger a new build and deployment on Koyeb.
+
+**Checkpoint:** Once the build and deployment are completed, you can access your application by clicking the App URL ending with koyeb.app in the Koyeb control panel. Once on the app page loads, Once the page loads, click on the **Check API status** button, which should return: `{"up":true}`
+
+## 4. Test your deployed application
+
+You can use the static frontend to interact with the API you deployed via the preview URL.
+
+Open up the preview URL in your browser, the URL should like this: `https://APP_NAME-ORG_NAME.koyeb.app`. You should see the following:
+
+
+
+The buttons allow you to make requests to the REST API and view the response:
+
+- **Check API status**: Will call the REST API status endpoint that returns `{"up":true}`.
+- **Seed data**: Will seed the database with a test `user` and `post`. Returns the created users.
+- **Load feed**: Will load all `users` in the database with their related `profiles`.
+
+For more insight into Prisma Client's API, look at the route handlers in the `src/index.js` file.
+
+You can view the application's logs clicking the `Runtime logs` tab on your app service from the Koyeb control panel:
+
+```no-lines wrap
+node-72d14691 stdout > prisma-koyeb@1.0.0 start
+node-72d14691 stdout > node src/index.js
+node-72d14691 stdout 🚀 Server ready at: http://localhost:8080
+node-72d14691 stdout ⭐️ See sample requests: http://pris.ly/e/ts/rest-express#3-using-the-rest-api
+```
+
+## Koyeb specific notes
+
+### Build
+
+By default, for applications using the Node.js runtime, if the `package.json` contains a `build` script, Koyeb automatically executes it after the dependencies installation.
+In the example, the `build` script is used to run `prisma generate && prisma migrate deploy && next build`.
+
+### Deployment
+
+By default, for applications using the Node.js runtime, if the `package.json` contains a `start` script, Koyeb automatically executes it to launch the application.
+In the example, the `start` script is used to run `node src/index.js`.
+
+### Database migrations and deployments
+
+In the example you deployed, migrations are applied using the `prisma migrate deploy` command during the Koyeb build (as defined in the `build` script in `package.json`).
+
+### Additional notes
+
+In this guide, we kept pre-set values for the region, instance size, and horizontal scaling. You can customize them according to your needs.
+
+> **Note:** The Ports section is used to let Koyeb know which port your application is listening to and properly route incoming HTTP requests. A default `PORT` environment variable is set to `8080` and incoming HTTP requests are routed to the `/` path when creating a new application.
+> If your application is listening on another port, you can define another port to route incoming HTTP requests.
+
+## Summary
+
+Congratulations! You have successfully deployed a Node.js app with Prisma ORM to Koyeb.
+
+You can find the source code for the example in [this GitHub repository](https://github.com/koyeb/example-prisma).
+
+For more insight into Prisma Client's API, look at the route handlers in the `src/index.js` file.
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/275-deploy-to-sevalla.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/275-deploy-to-sevalla.mdx
new file mode 100644
index 0000000000..9fa67b4dc8
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/275-deploy-to-sevalla.mdx
@@ -0,0 +1,85 @@
+---
+title: 'Deploy to Sevalla'
+metaTitle: 'Deploy a Prisma app to Sevalla'
+metaDescription: 'Learn how to deploy a Node.js server that uses Prisma ORM to Sevalla.'
+---
+
+This guide explains how to deploy a Node.js server that uses Prisma ORM and PostgreSQL to [Sevalla](https://sevalla.com). The app exposes a REST API and uses Prisma Client to query a PostgreSQL database. Both the app and database will be hosted on Sevalla.
+
+Sevalla is a developer-focused PaaS platform designed to simplify application and server deployment. You can easily host your applications, databases, object storage and static sites.
+
+It supports Git-based deployments, Dockerfiles, and Procfiles and runs on Google Kubernetes Engine with global delivery via Cloudflare.
+
+For this example, it's helpful to know:
+
+* Sevalla supports long-running “serverful” applications with built-in autoscaling and flexible pod sizes.
+* Git-based deployments are integrated with GitHub, GitLab, and Bitbucket.
+* PostgreSQL, MySQL, MariaDB, Redis, and Valkey databases are natively supported.
+* Applications and databases can be securely connected through private networking with automatic environment variable injection.
+
+## Prerequisites
+
+To get started, all you need is:
+
+* A [Sevalla account](https://sevalla.com) (comes with $50 in free credits)
+* A GitHub repository with your application code.
+
+> **Note:** If you don't have a project ready, you can use our [example Prisma project](https://github.com/sevalla-templates/express-prisma-demo). It's a simple Express.js application that uses Prisma ORM and includes a REST API, a frontend for testing endpoints, a defined Prisma schema with migrations, and an optional database seeding script.
+
+## Create an app on Sevalla
+
+First, create a new application on your Sevalla dashboard. Click **Applications** on the sidebar and then click the **Create an app** button, as shown below.
+
+
+
+Next, select your Git repository. Sevalla supports deploying from both private and public repositories. If you're using our example project, there's no need to fork — simply enter the URL `https://github.com/sevalla-templates/express-prisma-demo`.
+
+
+
+Choose the appropriate branch (usually `main` or `master`), set your application's name, select the desired deployment region, and pick your pod size. (You can start with 0.5 CPU / 1GB RAM using your free credits)
+
+
+
+Click **Create**, but skip the deploy step for now, so it does not fail since we have not added the database.
+
+## Set up the database on Sevalla
+
+On your Sevalla dashboard, click **Databases** \> **Add database**. Select **PostgreSQL** (or your preferred configured database type), and then provide a database name, username, and password, or simply use the default generated details.
+
+
+
+Next, give the database a recognizable name for easy identification within your Sevalla dashboard. Ensure you select the **same region** as your application, choose an appropriate database size, and click **Create**.
+
+Once your database has been created, scroll down to the **Connected Applications** section and click **Add Connection**.
+
+Select the application you created previously and enable "Add environment variables". Make sure the variable name is set to `DATABASE_URL` (if it defaults to `DB_URL`, change it accordingly).
+
+
+
+Finally, click **Add connection**. This securely links your application to your database and configures the necessary environment variable.
+
+## Trigger deployment
+
+Now that your application and database are connected, return to your application's **Deployment** tab and click **Deploy**.
+
+> **Note:** Sevalla automatically builds your application using Nixpacks, detecting your project's `package.json` and `start` script. If you'd rather use a Dockerfile or Buildpacks, navigate to **Settings** \> **Build**, and click **Update Settings** under the **Build environment** section to customize your build method.
+
+## Seed the database (optional)
+
+If your project includes a seed script (typically located at `prisma/seed.js`), you can populate your database with initial or demo data after deploying your application.
+
+To do this, navigate to your application's **Web Terminal** (under **Applications** \> **\[Your App\]** \> **Web Terminal**) and run the following command:
+
+```shell
+npx prisma db seed
+```
+
+This is what the web terminal looks like:
+
+
+
+Once this is done, you can manage and interact with your database directly via Sevalla's built-in interactive studio. As shown below, we can see the seeded data:
+
+
+
+Congratulations\! You've successfully deployed a Node.js application using Prisma ORM to Sevalla. Your app and database are now connected, secure, and production-ready\!
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/300-deploy-to-flyio.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/300-deploy-to-flyio.mdx
new file mode 100644
index 0000000000..f40cb0e33f
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/300-deploy-to-flyio.mdx
@@ -0,0 +1,56 @@
+---
+title: 'Deploy to Fly.io'
+metaTitle: 'Deploy a Prisma app to Fly.io'
+metaDescription: 'Learn how to deploy a Node.js server that uses Prisma ORM to Fly.io.'
+---
+
+
+This guide explains how to deploy a Node.js server that uses Prisma ORM and PostgreSQL to Fly.io.
+
+The [Prisma Render deployment example](https://github.com/prisma/prisma-examples/tree/latest/deployment-platforms/render) contains an Express.js application with REST endpoints and a simple frontend. This app uses Prisma Client to fetch, create, and delete records from its database.
+This guide will show you how to deploy the same application, without modification, on Fly.io.
+
+## About Fly.io
+
+[fly.io](https://fly.io/) is a cloud application platform that lets developers easily deploy and scale full-stack applications that start on request near on machines near to users. For this example, it's helpful to know:
+- Fly.io lets you deploy long-running, "serverful" full-stack applications in [35 regions around the world](https://fly.io/docs/reference/regions/). By default, applications are configured to to [auto-stop](https://fly.io/docs/launch/autostop-autostart/) when not in use, and auto-start as needed as requests come in.
+- Fly.io natively supports a wide variety of [languages and frameworks](https://fly.io/docs/languages-and-frameworks/), including Node.js and Bun. In this guide, we'll use the Node.js runtime.
+- Fly.io can [launch apps directly from GitHub](https://fly.io/speedrun). When run from the CLI, `fly launch` will automatically configure applications hosted on GitHub to deploy on push.
+
+
+## Prerequisites
+
+- Sign up for a [Fly.io](https://fly.io/docs/getting-started/launch/) account
+
+## Get the example code
+Download the [example code](https://github.com/prisma/prisma-examples/tree/latest/deployment-platforms/render) to your local machine.
+```terminal
+curl https://codeload.github.com/prisma/prisma-examples/tar.gz/latest | tar -xz --strip=2 prisma-examples-latest/deployment-platforms/render
+cd render
+```
+
+## Understand the example
+
+Before we deploy the app, let's take a look at the example code.
+
+### Web application
+
+The logic for the Express app is in two files:
+- `src/index.js`: The API. The endpoints use Prisma Client to fetch, create, and delete data from the database.
+- `public/index.html`: The web frontend. The frontend calls a few of the API endpoints.
+
+### Prisma schema and migrations
+
+The Prisma components of this app are in three files:
+- `prisma/schema.prisma`: The data model of this app. This example defines two models, `User` and `Post`. The format of this file follows the [Prisma schema](/orm/prisma-schema/overview).
+- `prisma/migrations//migration.sql`: The SQL commands that construct this schema in a PostgreSQL database. You can auto-generate migration files like this one by running [`prisma migrate dev`](/orm/prisma-migrate/understanding-prisma-migrate/mental-model#what-is-prisma-migrate).
+- `prisma/seed.js`: defines some test users and postsPrisma, used to [seed the database](/orm/prisma-migrate/workflows/seeding) with starter data.
+
+
+## Deploy the example
+
+### 1. Run `fly launch` and accept the defaults
+
+That’s it. Your web service will be live at its `fly.dev` URL as soon as the deploy completes. Optionally [scale](https://fly.io/docs/launch/scale-count/) the size, number, and placement of machines as desired. [`fly console`](https://fly.io/docs/flyctl/console/) can be used to ssh into a new or existing machine.
+
+More information can be found on in the [fly.io documentation](https://fly.io/docs/js/prisma/).
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/325-deploy-to-railway.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/325-deploy-to-railway.mdx
new file mode 100644
index 0000000000..6f3ffc6fa8
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/325-deploy-to-railway.mdx
@@ -0,0 +1,87 @@
+---
+title: 'Deploy to Railway'
+metaTitle: 'Deploy a Prisma app to Railway'
+metaDescription: 'Learn how to deploy an app that uses Prisma ORM and Prisma Postgres to Railway.'
+---
+
+This guide explains how to deploy an app that uses Prisma ORM and Prisma Postgres to [Railway](https://railway.com?utm_medium=integration&utm_source=docs&utm_campaign=prisma). The app exposes a REST API and uses Prisma Client to query a Prisma Postgres database. Your app will run on Railway and connect to a managed Prisma Postgres database.
+
+Railway is a deployment platform that simplifies the software development lifecycle with instant deployments, built-in observability, and effortless scaling. It supports code repositories and container images from popular registries. Railway handles configuration management, environment variables, and provides private networking between services.
+
+To get a pre-wired Next.js Project with Prisma ORM, Prisma Postgres, and Railway, use the [Official Prisma Railway Template](https://railway.com/deploy/prisma-postgres?utm_medium=integration&utm_source=docs&utm_campaign=prisma).
+
+This template automates the provisioning and setup of a Prisma Postgres database, linking it directly to your Next.js application upon deployment, making the entire project ready with just one click.
+
+## Prerequisites
+
+To get started, all you need is:
+
+* A [Railway account](https://railway.com?utm_medium=integration&utm_source=docs&utm_campaign=prisma)
+* A GitHub repository with your application code.
+
+:::note
+If you don't have a project ready, you can use our [example Prisma project](https://github.com/prisma/prisma-examples/tree/latest/deployment-platforms/railway). It's a simple Hono application that uses Prisma ORM and includes a REST API, a frontend for testing endpoints, and a defined Prisma schema with migrations.
+:::
+
+## Deploy your application
+
+### 1. Create a new Railway project
+
+1. Go to the [Railway dashboard](https://railway.com/dashboard?utm_medium=integration&utm_source=docs&utm_campaign=prisma)
+2. Click **Create a New Project**
+3. Select **GitHub Repo**
+4. Click **Configure GitHub App** and authorize Railway
+5. Select your repository
+
+Your application is now deploying to Railway, but it won't properly run without a database connection.
+
+In the next section, you'll configure a database and set the `DATABASE_URL` environment variable in Railway.
+
+
+
+## Configure your database
+
+### 1. Get your database connection string
+
+You'll need a Prisma Postgres connection string. There are two ways to obtain one:
+
+- Create a new database on [Prisma Data Platform](https://console.prisma.io)
+- Run `npx create-db` for a temporary database _(no account required)_
+
+### 2. Add the database URL to Railway
+
+1. In your Railway project, open your service
+2. Go to the **Variables** tab
+3. Click **New Variable**
+4. Set the name to `DATABASE_URL`
+5. Paste your database connection string as the value
+6. Click **Deploy** to redeploy your application with the new environment variable
+
+
+
+### 3. Access your application
+
+Once the deployment completes with the database URL configured:
+
+1. Navigate to the **Settings** tab
+2. Under **Networking**, click **Generate Domain**
+3. Your application will be available at the generated URL
+
+
+
+Go to the generated URL and you'll see your deployed app!
+
+If you used the example project, you should see three api endpoints already set up:
+- Check API status (`/api`)
+- Load feed (`/api/feed`)
+- Seed data (`/api/seed`)
+
+
+
+If you see any errors:
+- Wait a minute and refresh
+- Ensure `DATABASE_URL` is set
+- Check the service logs
+- Redeploy
+
+To learn more about the various features Railway offers for your application, visit the [Railway documentation](https://docs.railway.app?utm_medium=integration&utm_source=docs&utm_campaign=prisma).
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/heroku-architecture.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/heroku-architecture.png
new file mode 100644
index 0000000000..f501852e4c
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/heroku-architecture.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/heroku-deployed.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/heroku-deployed.png
new file mode 100644
index 0000000000..fb52deba4b
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/heroku-deployed.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/koyeb-app-creation.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/koyeb-app-creation.png
new file mode 100644
index 0000000000..87aeeacbf9
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/koyeb-app-creation.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/koyeb-architecture.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/koyeb-architecture.png
new file mode 100644
index 0000000000..c9b98c4707
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/koyeb-architecture.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/koyeb-deployed.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/koyeb-deployed.png
new file mode 100644
index 0000000000..29c3b606b1
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/koyeb-deployed.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/railway-deploying.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/railway-deploying.png
new file mode 100644
index 0000000000..54738245bb
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/railway-deploying.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/railway-env-vars.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/railway-env-vars.png
new file mode 100644
index 0000000000..e4cf17c4fd
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/railway-env-vars.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/railway-final-product.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/railway-final-product.png
new file mode 100644
index 0000000000..64ff8b61b7
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/railway-final-product.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/railway-networking.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/railway-networking.png
new file mode 100644
index 0000000000..b6081c69c5
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/railway-networking.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/sevalla-app-creation.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/sevalla-app-creation.png
new file mode 100644
index 0000000000..f7f694b156
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/sevalla-app-creation.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/sevalla-app-internal-connection.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/sevalla-app-internal-connection.png
new file mode 100644
index 0000000000..003cc556b7
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/sevalla-app-internal-connection.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/sevalla-choose-repository.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/sevalla-choose-repository.png
new file mode 100644
index 0000000000..47fd16a546
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/sevalla-choose-repository.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/sevalla-create-database.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/sevalla-create-database.png
new file mode 100644
index 0000000000..bee25ed52c
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/sevalla-create-database.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/sevalla-database-studio.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/sevalla-database-studio.png
new file mode 100644
index 0000000000..83f0589953
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/sevalla-database-studio.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/sevalla-name-application.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/sevalla-name-application.png
new file mode 100644
index 0000000000..01e2946ee5
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/sevalla-name-application.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/sevalla-web-terminal.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/sevalla-web-terminal.png
new file mode 100644
index 0000000000..d94a28580b
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/images/sevalla-web-terminal.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/index.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/index.mdx
new file mode 100644
index 0000000000..b0b4a564ae
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/101-traditional/index.mdx
@@ -0,0 +1,16 @@
+---
+title: 'Traditional servers'
+metaTitle: 'Deploy Prisma ORM apps to traditional (PaaS) servers'
+metaDescription: 'Learn how to deploy your Prisma-backed apps to PaaS providers like Heroku, Koyeb, or AWS EC2'
+tocDepth: 2
+---
+
+
+
+If your application is deployed via a Platform-as-a-Service (PaaS) provider, whether containerized or not, it is a traditionally-deployed app. Common deployment examples include [Heroku](/orm/prisma-client/deployment/traditional/deploy-to-heroku) and [Koyeb](/orm/prisma-client/deployment/traditional/deploy-to-koyeb).
+
+
+
+## Traditional (PaaS) guides
+
+
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/150-deploy-to-azure-functions.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/150-deploy-to-azure-functions.mdx
new file mode 100644
index 0000000000..5e2970c44e
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/150-deploy-to-azure-functions.mdx
@@ -0,0 +1,64 @@
+---
+title: 'Deploy to Azure Functions'
+metaTitle: 'How to deploy an app using Prisma ORM to Azure Functions'
+metaDescription: 'Learn how to deploy a Prisma Client based REST API to Azure Functions and connect to an Azure SQL database'
+---
+
+This guide explains how to avoid common issues when deploying a Node.js-based function app to Azure using [Azure Functions](https://azure.microsoft.com/en-us/products/functions/).
+
+Azure Functions is a serverless deployment platform. You do not need to maintain infrastructure to deploy your code. With Azure Functions, the fundamental building block is the [function app](https://learn.microsoft.com/en-us/azure/azure-functions/functions-reference?tabs=blob&pivots=programming-language-typescript). A function app provides an execution context in Azure in which your functions run. It is comprised of one or more individual functions that Azure manages, deploys, and scales together. You can organize and collectively manage multiple functions as a single logical unit.
+
+:::tip Use Prisma ORM without Rust binaries
+
+If Prisma ORM's Rust engine binaries cause large bundle sizes, slow builds, or deployment issues (for example, in serverless or edge environments), you can use it without them using this configuration of your `generator` block:
+
+```prisma
+generator client {
+ provider = "prisma-client-js" // or "prisma-client"
+ engineType = "client"
+}
+```
+
+Prisma ORM without Rust binaries has been [Generally Available](/orm/more/releases#generally-available-ga) since [v6.16.0](https://pris.ly/release/6.16.0).
+
+Note that you need to use a [driver adapter](/orm/overview/databases/database-drivers#driver-adapters) in this case.
+
+When using this architecture:
+
+- No Rust query engine binary is downloaded or shipped.
+- The database connection pool is maintained by the native JS database driver you install (e.g., `@prisma/adapter-pg` for PostgreSQL).
+
+This setup can simplify deployments in serverless or edge runtimes. Learn more in the [docs here](/orm/prisma-client/setup-and-configuration/no-rust-engine).
+
+Curious why we moved away from the Rust engine? Take a look at why we transitioned from Rust binary engines to an all-TypeScript approach for a faster, lighter Prisma ORM in this [blog post](https://www.prisma.io/blog/prisma-orm-without-rust-latest-performance-benchmarks).
+
+:::
+
+
+## Prerequisites
+
+- An existing function app project with Prisma ORM
+
+## Things to know
+
+While Prisma ORM works well with Azure functions, there are a few things to take note of before deploying your application.
+
+### Define multiple binary targets
+
+When deploying a function app, the operating system that Azure functions runs a remote build is different from the one used to host your functions. Therefore, we recommend specifying the following [`binaryTargets` options](/orm/reference/prisma-schema-reference#binarytargets-options) in your Prisma schema:
+
+```prisma file=schema.prisma highlight=3;normal showLineNumbers
+generator client {
+ provider = "prisma-client-js"
+ //highlight-next-line
+ binaryTargets = ["native", "debian-openssl-1.1.x"]
+}
+```
+
+### Connection pooling
+
+Generally, when you use a FaaS (Function as a Service) environment to interact with a database, every function invocation can result in a new connection to the database. This is not a problem with a constantly running Node.js server. Therefore, it is beneficial to pool DB connections to get better performance. To solve this issue, you can use the [Prisma Accelerate](/accelerate). For other solutions, see the [connection management guide for serverless environments](/orm/prisma-client/setup-and-configuration/databases-connections#serverless-environments-faas).
+
+## Summary
+
+For more insight into Prisma Client's API, explore the function handlers and check out the [Prisma Client API Reference](/orm/reference/prisma-client-reference)
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/300-deploy-to-vercel.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/300-deploy-to-vercel.mdx
new file mode 100644
index 0000000000..69ab730c37
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/300-deploy-to-vercel.mdx
@@ -0,0 +1,160 @@
+---
+title: 'Deploy to Vercel'
+metaTitle: 'Deploy to Vercel'
+metaDescription: 'Learn how to deploy a Next.js application based on Prisma Client to Vercel.'
+---
+
+This guide takes you through the steps to set up and deploy a serverless application that uses Prisma to [Vercel](https://vercel.com/).
+
+Vercel is a cloud platform that hosts static sites, serverless, and edge functions. You can integrate a Vercel project with a GitHub repository to allow you to deploy automatically when you make new commits.
+
+We created an [example application](https://github.com/prisma/deployment-example-vercel) using Next.js you can use as a reference when deploying an application using Prisma to Vercel.
+
+While our examples use Next.js, you can deploy other applications to Vercel. See [Using Express with Vercel](https://vercel.com/guides/using-express-with-vercel) and [Nuxt on Vercel](https://vercel.com/docs/frameworks/nuxt) as examples of other options.
+
+:::tip Use Prisma ORM without Rust binaries
+
+If Prisma ORM's Rust engine binaries cause large bundle sizes, slow builds, or deployment issues (for example, in serverless or edge environments), you can use it without them using this configuration of your `generator` block:
+
+```prisma
+generator client {
+ provider = "prisma-client-js" // or "prisma-client"
+ engineType = "client"
+}
+```
+
+Prisma ORM without Rust binaries has been [Generally Available](/orm/more/releases#generally-available-ga) since [v6.16.0](https://pris.ly/release/6.16.0).
+
+Note that you need to use a [driver adapter](/orm/overview/databases/database-drivers#driver-adapters) in this case.
+
+When using this architecture:
+
+- No Rust query engine binary is downloaded or shipped.
+- The database connection pool is maintained by the native JS database driver you install (e.g., `@prisma/adapter-pg` for PostgreSQL).
+
+This setup can simplify deployments in serverless or edge runtimes. Learn more in the [docs here](/orm/prisma-client/setup-and-configuration/no-rust-engine).
+
+Curious why we moved away from the Rust engine? Take a look at why we transitioned from Rust binary engines to an all-TypeScript approach for a faster, lighter Prisma ORM in this [blog post](https://www.prisma.io/blog/prisma-orm-without-rust-latest-performance-benchmarks).
+
+
+:::
+
+## Build configuration
+
+### Updating Prisma Client during Vercel builds
+
+Vercel will automatically cache dependencies on deployment. For most applications, this will not cause any issues. However, for Prisma ORM, it may result in an outdated version of Prisma Client on a change in your Prisma schema. To avoid this issue, add `prisma generate` to the `postinstall` script of your application:
+
+```json file=package.json showLineNumbers
+{
+ ...
+ "scripts": {
+ //add-next-line
+ "postinstall": "prisma generate"
+ }
+ ...
+}
+```
+
+This will re-generate Prisma Client at build time so that your deployment always has an up-to-date client.
+
+:::info
+
+If you see `prisma: command not found` errors during your deployment to Vercel, you are missing `prisma` in your dependencies. By default, `prisma` is a dev dependency and may need to be moved to be a standard dependency.
+
+:::
+
+Another option to avoid an outdated Prisma Client is to use [a custom output path](/orm/prisma-client/setup-and-configuration/generating-prisma-client#using-a-custom-output-path) and check your client into version control. This way each deployment is guaranteed to include the correct Prisma Client.
+
+```prisma file=schema.prisma showLineNumbers
+generator client {
+ provider = "prisma-client-js"
+ //add-next-line
+ output = "./generated/client"
+}
+```
+
+### Deploying Prisma in Monorepos on Vercel
+
+If you are using Prisma inside a monorepo (e.g., with TurboRepo) and deploying to Vercel, you may encounter issues where required files—such as `libquery_engine-rhel-openssl-3.0.x.so.node` are missing from the deployed bundle. This is because Vercel aggressively optimizes serverless deployments, sometimes stripping out necessary Prisma files. To resolve this, use the [@prisma/nextjs-monorepo-workaround-plugin](https://www.npmjs.com/package/@prisma/nextjs-monorepo-workaround-plugin) plugin, which ensures that Prisma engine files are correctly included in the final bundle.
+For more details on how Prisma interacts with different bundlers like Webpack and Parcel, see our [Module bundlers](/orm/prisma-client/deployment/module-bundlers#overview) page.
+
+The usage of this plugin becomes obsolet if:
+- you are using [Prisma ORM without Rust engines](/orm/prisma-client/setup-and-configuration/no-rust-engine) (via `engineType = "client` on your `generator` block)
+- you are using the [new `prisma-client` generator](/6.0/orm/prisma-schema/overview/generators#prisma-client)
+
+### CI/CD workflows
+
+In a more sophisticated CI/CD environment, you may additonally want to update the database schema with any migrations you have performed during local development. You can do this using the [`prisma migrate deploy`](/orm/reference/prisma-cli-reference#migrate-deploy) command.
+
+In that case, you could create a custom build command in your `package.json` (e.g. called `vercel-build`) that looks as follows:
+
+```json file=package.json
+{
+ ...
+ "scripts" {
+ //add-next-line
+ "vercel-build": "prisma generate && prisma migrate deploy && next build",
+ }
+ ...
+}
+```
+
+You can invoke this script inside your CI/CD pipeline using the following command:
+
+```terminal
+npm run vercel-build
+```
+
+## Add a separate database for preview deployments
+
+By default, your application will have a single _production_ environment associated with the `main` git branch of your repository. If you open a pull request to change your application, Vercel creates a new _preview_ environment.
+
+Vercel uses the `DATABASE_URL` environment variable you define when you import the project for both the production and preview environments. This causes problems if you create a pull request with a database schema migration because the pull request will change the schema of the production database.
+
+To prevent this, use a _second_ hosted database to handle preview deployments. Once you have that connection string, you can add a `DATABASE_URL` for your preview environment using the Vercel dashboard:
+
+1. Click the **Settings** tab of your Vercel project.
+
+2. Click **Environment variables**.
+
+3. Add an environment variable with a key of `DATABASE_URL` and select only the **Preview** environment option:
+
+ 
+
+4. Set the value to the connection string of your second database:
+
+ ```code
+ postgresql://dbUsername:dbPassword@myhost:5432/mydb
+ ```
+
+5. Click **Save**.
+
+## Connection pooling
+
+When you use a Function-as-a-Service provider, like Vercel Serverless functions, every invocation may result in a new connection to your database. This can cause your database to quickly run out of open connections and cause your application to stall. For this reason, pooling connections to your database is essential.
+
+You can use [Accelerate](/accelerate) for connection pooling or [Prisma Postgres](/postgres), which has built-in connection pooling, to reduce your Prisma Client bundle size, and to avoid cold starts.
+
+For more information on connection management for serverless environments, refer to our [connection management guide](/orm/prisma-client/setup-and-configuration/databases-connections#serverless-environments-faas).
+
+## Using Prisma ORM with Vercel Fluid
+
+[Fluid compute](https://vercel.com/fluid) is a compute model from Vercel that combines the flexibility of serverless with the stability of servers, making it ideal for dynamic workloads such as streaming data and AI APIs. Vercel's Fluid compute [supports both edge and Node.js runtimes](https://vercel.com/docs/fluid-compute#available-runtime-support). A common challenge in traditional serverless platforms is leaked database connections when functions are suspended and pools can't close idle connections. Fluid provides [`attachDatabasePool`](https://vercel.com/blog/the-real-serverless-compute-to-database-connection-problem-solved) to ensure idle connections are released before a function is suspended.
+
+Use `attachDatabasePool` together with [Prisma's driver adapters](/orm/overview/databases/database-drivers) to safely manage connections in Fluid:
+
+```ts
+import { Pool } from 'pg'
+import { attachDatabasePool } from '@vercel/functions'
+import { PrismaPg } from '@prisma/adapter-pg'
+import { PrismaClient } from '@prisma/client'
+
+const pool = new Pool({ connectionString: process.env.POSTGRES_URL })
+
+attachDatabasePool(pool)
+
+const prisma = new PrismaClient({
+ adapter: new PrismaPg(pool),
+})
+```
\ No newline at end of file
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/400-deploy-to-aws-lambda.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/400-deploy-to-aws-lambda.mdx
new file mode 100644
index 0000000000..fc386c5aa4
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/400-deploy-to-aws-lambda.mdx
@@ -0,0 +1,374 @@
+---
+title: 'Deploy to AWS Lambda'
+metaTitle: 'Deploy your application using Prisma ORM to AWS Lambda'
+metaDescription: 'Learn how to deploy your Prisma ORM-backed applications to AWS Lambda with AWS SAM, Serverless Framework, or SST'
+tocDepth: 3
+---
+
+
+This guide explains how to avoid common issues when deploying a project using Prisma ORM to [AWS Lambda](https://aws.amazon.com/lambda/).
+
+
+Questions answered in this page
+
+- How to deploy Prisma to AWS Lambda?
+- Which binaryTargets should I configure?
+- How to handle connection pooling on Lambda?
+
+
+
+While a deployment framework is not required to deploy to AWS Lambda, this guide covers deploying with:
+
+- [AWS Serverless Application Model (SAM)](https://aws.amazon.com/serverless/sam/) is an open-source framework from AWS that can be used in the creation of serverless applications. AWS SAM includes the [AWS SAM CLI](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-reference.html#serverless-sam-cli), which you can use to build, test, and deploy your application.
+- [Serverless Framework](https://www.serverless.com/framework) provides a CLI that helps with workflow automation and AWS resource provisioning. While Prisma ORM works well with the Serverless Framework "out of the box", there are a few improvements that can be made within your project to ensure a smooth deployment and performance. There is also additional configuration that is needed if you are using the [`serverless-webpack`](https://www.npmjs.com/package/serverless-webpack) or [`serverless-bundle`](https://www.npmjs.com/package/serverless-bundle) libraries.
+- [SST](https://sst.dev/) provides tools that make it easy for developers to define, test, debug, and deploy their applications. Prisma ORM works well with SST but must be configured so that your schema is correctly packaged by SST.
+
+
+:::tip Use Prisma ORM without Rust binaries
+
+If Prisma ORM's Rust engine binaries cause large bundle sizes, slow builds, or deployment issues (for example, in serverless or edge environments), you can use it without them using this configuration of your `generator` block:
+
+```prisma
+generator client {
+ provider = "prisma-client-js" // or "prisma-client"
+ engineType = "client"
+}
+```
+
+Prisma ORM without Rust binaries has been [Generally Available](/orm/more/releases#generally-available-ga) since [v6.16.0](https://pris.ly/release/6.16.0).
+
+Note that you need to use a [driver adapter](/orm/overview/databases/database-drivers#driver-adapters) in this case.
+
+When using this architecture:
+
+- No Rust query engine binary is downloaded or shipped.
+- The database connection pool is maintained by the native JS database driver you install (e.g., `@prisma/adapter-pg` for PostgreSQL).
+
+This setup can simplify deployments in serverless or edge runtimes. Learn more in the [docs here](/orm/prisma-client/setup-and-configuration/no-rust-engine).
+
+Curious why we moved away from the Rust engine? Take a look at why we transitioned from Rust binary engines to an all-TypeScript approach for a faster, lighter Prisma ORM in this [blog post](https://www.prisma.io/blog/prisma-orm-without-rust-latest-performance-benchmarks).
+
+:::
+
+
+
+## General considerations when deploying to AWS Lambda
+
+This section covers changes you will need to make to your application, regardless of framework. After following these steps, follow the steps for your framework.
+
+- [Deploying with AWS SAM](#deploying-with-aws-sam)
+- [Deploying with the Serverless Framework](#deploying-with-the-serverless-framework)
+- [Deploying with SST](#deploying-with-sst)
+
+### Define binary targets in Prisma Schema
+
+Depending on the version of Node.js, your Prisma schema should contain either `rhel-openssl-1.0.x` or `rhel-openssl-3.0.x` in the `generator` block:
+
+
+
+
+
+```prisma
+binaryTargets = ["native", "rhel-openssl-1.0.x"]
+```
+
+
+
+
+```prisma
+binaryTargets = ["native", "rhel-openssl-3.0.x"]
+```
+
+
+
+
+
+This is necessary because the runtimes used in development and deployment differ. Add the [`binaryTarget`](/orm/reference/prisma-schema-reference#binarytargets-options) to make the compatible Prisma ORM engine file available.
+
+#### Lambda functions with arm64 architectures
+
+Lambda functions that use [arm64 architectures (AWS Graviton2 processor)](https://docs.aws.amazon.com/lambda/latest/dg/foundation-arch.html#foundation-arch-adv) must use an `arm64` precompiled engine file.
+
+In the `generator` block of your `schema.prisma` file, add the following:
+
+```prisma file=schema.prisma showLineNumbers
+binaryTargets = ["native", "linux-arm64-openssl-1.0.x"]
+```
+
+### Prisma CLI binary targets
+
+While we do not recommend running migrations within AWS Lambda, some applications will require it. In these cases, you can use the [PRISMA_CLI_BINARY_TARGETS](/orm/reference/environment-variables-reference#prisma_cli_binary_targets) environment variable to make sure that Prisma CLI commands, including `prisma migrate`, have access to the correct schema engine.
+
+In the case of AWS lambda, you will have to add the following environment variable:
+
+```env file=.env showLineNumbers
+PRISMA_CLI_BINARY_TARGETS=native,rhel-openssl-1.0.x
+```
+
+:::info
+
+`prisma migrate` is a command in the `prisma` package. Normally, this package is installed as a dev dependency. Depending on your setup, you may need to install this package as a dependency instead so that it is included in the bundle or archive that is uploaded to Lambda and executed.
+
+:::
+
+### Connection pooling
+
+In a Function as a Service (FaaS) environment, each function invocation typically creates a new database connection. Unlike a continuously running Node.js server, these connections aren't maintained between executions. For better performance in serverless environments, implement connection pooling to reuse existing database connections rather than creating new ones for each function call.
+
+You can use [Accelerate](/accelerate) for connection pooling or [Prisma Postgres](/postgres), which has built-in connection pooling, to solve this issue. For other solutions, see the [connection management guide for serverless environments](/orm/prisma-client/setup-and-configuration/databases-connections#serverless-environments-faas).
+
+## Deploying with AWS SAM
+
+### Loading environment variables
+
+AWS SAM does not directly support loading values from a `.env` file. You will have to use one of AWS's services to store and retrieve these parameters. [This guide](https://medium.com/bip-xtech/a-practical-guide-to-surviving-aws-sam-d8ab141b3d25) provides a great overview of your options and how to store and retrieve values in Parameters, SSM, Secrets Manager, and more.
+
+### Loading required files
+
+AWS SAM uses [esbuild](https://esbuild.github.io/) to bundle your TypeScript code. However, the full esbuild API is not exposed and esbuild plugins are not supported. This leads to problems when using Prisma ORM in your application as certain files (like `schema.prisma`) must be available at runtime.
+
+To get around this, you need to directly reference the needed files in your code to bundle them correctly. In your application, you could add the following lines to your application where Prisma ORM is instantiated.
+
+```ts file=app.ts showLineNumbers
+import schema from './prisma/schema.prisma'
+import x from './node_modules/.prisma/client/libquery_engine-rhel-openssl-1.0.x.so.node'
+
+if (process.env.NODE_ENV !== 'production') {
+ console.debug(schema, x)
+}
+```
+
+## Deploying with the Serverless Framework
+
+### Loading environment variables via a `.env` file
+
+Your functions will need the `DATABASE_URL` environment variable to access the database. The `serverless-dotenv-plugin` will allow you to use your `.env` file in your deployments.
+
+First, make sure that the plugin is installed:
+
+```terminal
+npm install -D serverless-dotenv-plugin
+```
+
+Then, add `serverless-dotenv-plugin` to your list of plugins in `serverless.yml`:
+
+```code file=serverless.yml no-copy showLineNumbers
+plugins:
+ - serverless-dotenv-plugin
+```
+
+The environment variables in your `.env` file will now be automatically loaded on package or deployment.
+
+
+
+
+```terminal
+serverless package
+```
+
+
+
+
+```terminal no-copy
+Running "serverless" from node_modules
+DOTENV: Loading environment variables from .env:
+ - DATABASE_URL
+
+Packaging deployment-example-sls for stage dev (us-east-1)
+.
+.
+.
+```
+
+
+
+
+### Deploy only the required files
+
+To reduce your deployment footprint, you can update your deployment process to only upload the files your application needs. The Serverless configuration file, `serverless.yml`, below shows a `package` pattern that includes only the Prisma ORM engine file relevant to the Lambda runtime and excludes the others. This means that when Serverless Framework packages your app for upload, it includes only one engine file. This ensures the packaged archive is as small as possible.
+
+```code file=serverless.yml no-copy showLineNumbers
+package:
+ patterns:
+ - '!node_modules/.prisma/client/libquery_engine-*'
+ - 'node_modules/.prisma/client/libquery_engine-rhel-*'
+ - '!node_modules/prisma/libquery_engine-*'
+ - '!node_modules/@prisma/engines/**'
+ - '!node_modules/.cache/prisma/**' # only required for Windows
+```
+
+If you are deploying to [Lambda functions with ARM64 architecture](#lambda-functions-with-arm64-architectures) you should update the Serverless configuration file to package the `arm64` engine file, as follows:
+
+```code file=serverless.yml highlight=4;normal showLineNumbers
+package:
+ patterns:
+ - '!node_modules/.prisma/client/libquery_engine-*'
+ //highlight-next-line
+ - 'node_modules/.prisma/client/libquery_engine-linux-arm64-*'
+ - '!node_modules/prisma/libquery_engine-*'
+ - '!node_modules/@prisma/engines/**'
+```
+
+If you use `serverless-webpack`, see [Deployment with serverless webpack](#deployment-with-serverless-webpack) below.
+
+### Deployment with `serverless-webpack`
+
+If you use `serverless-webpack`, you will need additional configuration so that your `schema.prisma` is properly bundled. You will need to:
+
+1. Copy your `schema.prisma` with [`copy-webpack-plugin`](https://www.npmjs.com/package/copy-webpack-plugin).
+2. Run `prisma generate` via `custom > webpack > packagerOptions > scripts` in your `serverless.yml`.
+3. Only package the correct Prisma ORM engine file to save more than 40mb of capacity.
+
+#### 1. Install webpack specific dependencies
+
+First, ensure the following webpack dependencies are installed:
+
+```terminal
+npm install --save-dev webpack webpack-node-externals copy-webpack-plugin serverless-webpack
+```
+
+#### 2. Update `webpack.config.js`
+
+In your `webpack.config.js`, make sure that you set `externals` to `nodeExternals()` like the following:
+
+```javascript file=webpack.config.js highlight=1,5;normal; showLineNumbers
+const nodeExternals = require('webpack-node-externals')
+
+module.exports = {
+ // ... other configuration
+ //highlight-next-line
+ externals: [nodeExternals()],
+ // ... other configuration
+}
+```
+
+Update the `plugins` property in your `webpack.config.js` file to include the `copy-webpack-plugin`:
+
+```javascript file=webpack.config.js highlight=2,7-13;normal; showLineNumbers
+const nodeExternals = require('webpack-node-externals')
+//highlight-next-line
+const CopyPlugin = require('copy-webpack-plugin')
+
+module.exports = {
+ // ... other configuration
+ externals: [nodeExternals()],
+ //highlight-start
+ plugins: [
+ new CopyPlugin({
+ patterns: [
+ { from: './node_modules/.prisma/client/schema.prisma', to: './' }, // you may need to change `to` here.
+ ],
+ }),
+ ],
+ //highlight-end
+ // ... other configuration
+}
+```
+
+This plugin will allow you to copy your `schema.prisma` file into your bundled code. Prisma ORM requires that your `schema.prisma` be present in order make sure that queries are encoded and decoded according to your schema. In most cases, bundlers will not include this file by default and will cause your application to fail to run.
+
+:::info
+
+Depending on how your application is bundled, you may need to copy the schema to a location other than `./`. Use the `serverless package` command to package your code locally so you can review where your schema should be put.
+
+:::
+
+Refer to the [Serverless Webpack documentation](https://www.serverless.com/plugins/serverless-webpack) for additional configuration.
+
+#### 3. Update `serverless.yml`
+
+In your `serverless.yml` file, make sure that the `custom > webpack` block has `prisma generate` under `packagerOptions > scripts` as follows:
+
+```yaml file=serverless.yml showLineNumbers
+custom:
+ webpack:
+ packagerOptions:
+ scripts:
+ - prisma generate
+```
+
+This will ensure that, after webpack bundles your code, the Prisma Client is generated according to your schema. Without this step, your app will fail to run.
+
+Lastly, you will want to exclude [Prisma ORM query engines](/orm/more/under-the-hood/engines) that do not match the AWS Lambda runtime. Update your `serverless.yml` by adding the following script that makes sure only the required query engine, `rhel-openssl-1.0.x`, is included in the final packaged archive.
+
+```yaml file=serverless.yml highlight=6;add showLineNumbers
+custom:
+ webpack:
+ packagerOptions:
+ scripts:
+ - prisma generate
+ //add-next-line
+ -- find . -name "libquery_engine-*" -not -name "libquery_engine-rhel-openssl-*" | xargs rm
+```
+
+If you are deploying to [Lambda functions with ARM64 architecture](#lambda-functions-with-arm64-architectures) you should update the `find` command to the following:
+
+```yaml file=serverless.yml highlight=6;add showLineNumbers
+custom:
+ webpack:
+ packagerOptions:
+ scripts:
+ - prisma generate
+ //add-next-line
+ -- find . -name "libquery_engine-*" -not -name "libquery_engine-arm64-openssl-*" | xargs rm
+```
+
+#### 4. Wrapping up
+
+You can now re-package and re-deploy your application. To do so, run `serverless deploy`. Webpack output will show the schema being moved with `copy-webpack-plugin`:
+
+
+
+
+```terminal
+serverless package
+```
+
+
+
+
+```terminal no-copy
+Running "serverless" from node_modules
+DOTENV: Loading environment variables from .env:
+ - DATABASE_URL
+
+Packaging deployment-example-sls for stage dev (us-east-1)
+
+asset handlers/posts.js 713 bytes [emitted] [minimized] (name: handlers/posts)
+ asset schema.prisma 293 bytes [emitted] [from: node_modules/.prisma/client/schema.prisma] [copied]
+ ./handlers/posts.ts 745 bytes [built] [code generated]
+ external "@prisma/client" 42 bytes [built] [code generated]
+ webpack 5.88.2 compiled successfully in 685 ms
+Package lock found - Using locked versions
+Packing external modules: @prisma/client@^5.1.1
+
+✔ Service packaged (5s)
+```
+
+
+
+
+## Deploying with SST
+
+### Working with environment variables
+
+While SST supports `.env` files, [it is not recommended](https://v2.sst.dev/config#should-i-use-configsecret-or-env-for-secrets). SST recommends using `Config` to access these environment variables in a secure way.
+
+The SST guide [available here](https://v2.sst.dev/config#overview) is a step-by-step guide to get started with `Config`. Assuming you have created a new secret called `DATABASE_URL` and have [bound that secret to your app](https://v2.sst.dev/config#bind-the-config), you can set up `PrismaClient` with the following:
+
+```ts file=prisma.ts showLineNumbers
+import { PrismaClient } from '@prisma/client'
+import { Config } from 'sst/node/config'
+
+const globalForPrisma = global as unknown as { prisma: PrismaClient }
+
+export const prisma =
+ globalForPrisma.prisma ||
+ new PrismaClient({
+ datasourceUrl: Config.DATABASE_URL,
+ })
+
+if (process.env.NODE_ENV !== 'production') globalForPrisma.prisma = prisma
+
+export default prisma
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/500-deploy-to-netlify.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/500-deploy-to-netlify.mdx
new file mode 100644
index 0000000000..92b1124412
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/500-deploy-to-netlify.mdx
@@ -0,0 +1,137 @@
+---
+title: 'Deploy to Netlify'
+metaTitle: 'Deploy to Netlify'
+metaDescription: 'Learn how to deploy Node.js and TypeScript applications that are using Prisma Client to Netlify.'
+---
+
+This guide covers the steps you will need to take in order to deploy your application that uses Prisma ORM to [Netlify](https://www.netlify.com/).
+
+Netlify is a cloud platform for continuous deployment, static sites, and serverless functions. Netlify integrates seamlessly with GitHub for automatic deployments upon commits. When you follow the steps below, you will use that approach to create a CI/CD pipeline that deploys your application from a GitHub repository.
+
+:::tip Use Prisma ORM without Rust binaries
+
+If Prisma ORM's Rust engine binaries cause large bundle sizes, slow builds, or deployment issues (for example, in serverless or edge environments), you can use it without them using this configuration of your `generator` block:
+
+```prisma
+generator client {
+ provider = "prisma-client-js" // or "prisma-client"
+ engineType = "client"
+}
+```
+
+Prisma ORM without Rust binaries has been [Generally Available](/orm/more/releases#generally-available-ga) since [v6.16.0](https://pris.ly/release/6.16.0).
+
+Note that you need to use a [driver adapter](/orm/overview/databases/database-drivers#driver-adapters) in this case.
+
+When using this architecture:
+
+- No Rust query engine binary is downloaded or shipped.
+- The database connection pool is maintained by the native JS database driver you install (e.g., `@prisma/adapter-pg` for PostgreSQL).
+
+This setup can simplify deployments in serverless or edge runtimes. Learn more in the [docs here](/orm/prisma-client/setup-and-configuration/no-rust-engine).
+
+Curious why we moved away from the Rust engine? Take a look at why we transitioned from Rust binary engines to an all-TypeScript approach for a faster, lighter Prisma ORM in this [blog post](https://www.prisma.io/blog/prisma-orm-without-rust-latest-performance-benchmarks).
+
+:::
+
+
+## Prerequisites
+
+Before you can follow this guide, you will need to set up your application to begin deploying to Netlify. We recommend the ["Get started with Netlify"](https://docs.netlify.com/get-started/) guide for a quick overview and ["Deploy functions"](https://docs.netlify.com/functions/deploy/?fn-language=ts) for an in-depth look at your deployment options.
+
+## Binary targets in `schema.prisma`
+
+Since your code is being deployed to Netlify's environment, which isn't necessarily the same as your development environment, you will need to set [`binaryTargets`](/orm/reference/prisma-schema-reference#binarytargets-options) in order to download the query engine that is compatible with the Netlify runtime during your build step. If you do not set this option, your deployed code will have an incorrect query engine deployed with it and will not function.
+
+Depending on the version of Node.js, your Prisma schema should contain either `rhel-openssl-1.0.x` or `rhel-openssl-3.0.x` in the `generator` block:
+
+
+
+
+
+```prisma
+binaryTargets = ["native", "rhel-openssl-1.0.x"]
+```
+
+
+
+
+```prisma
+binaryTargets = ["native", "rhel-openssl-3.0.x"]
+```
+
+
+
+
+
+## Store environment variables in Netlify
+
+We recommend keeping `.env` files in your `.gitignore` in order to prevent leakage of sensitive connection strings. Instead, you can use the Netlify CLI to [import values into netlify directly](https://docs.netlify.com/environment-variables/get-started/#import-variables-with-the-netlify-cli).
+
+
+Assuming you have a file like the following:
+
+```bash file=.env
+# Connect to DB
+DATABASE_URL="postgresql://postgres:__PASSWORD__@__HOST__:__PORT__/__DB_NAME__"
+```
+
+You can upload the file as environment variables using the `env:import` command:
+
+
+
+
+```terminal no-break-terminal
+netlify env:import .env
+```
+
+
+
+
+```no-break-terminal
+site: my-very-very-cool-site
+---------------------------------------------------------------------------------.
+ Imported environment variables |
+---------------------------------------------------------------------------------|
+ Key | Value |
+--------------|------------------------------------------------------------------|
+ DATABASE_URL | postgresql://postgres:__PASSWORD__@__HOST__:__PORT__/__DB_NAME__ |
+---------------------------------------------------------------------------------'
+```
+
+
+
+
+
+If you are not using an `.env` file
+
+If you are storing your database connection string and other environment variables in a different method, you will need to manually upload your environment variables to Netlify. These options are [discussed in Netlify's documentation](https://docs.netlify.com/environment-variables/get-started/) and one method, uploading via the UI, is described below.
+
+1. Open the Netlify admin UI for the site. You can use Netlify CLI as follows:
+ ```terminal
+ netlify open --admin
+ ```
+2. Click **Site settings**:
+ 
+3. Navigate to **Build & deploy** in the sidebar on the left and select **Environment**.
+4. Click **Edit variables** and create a variable with the key `DATABASE_URL` and set its value to your database connection string.
+ 
+5. Click **Save**.
+
+
+
+Now start a new Netlify build and deployment so that the new build can use the newly uploaded environment variables.
+
+```terminal
+netlify deploy
+```
+
+You can now test the deployed application.
+
+## Connection pooling
+
+When you use a Function-as-a-Service provider, like Netlify, it is beneficial to pool database connections for performance reasons. This is because every function invocation may result in a new connection to your database which can quickly run out of open connections.
+
+You can use [Accelerate](/accelerate) for connection pooling or [Prisma Postgres](/postgres), which has built-in connection pooling, to reduce your Prisma Client bundle size, and to avoid cold starts.
+
+For more information on connection management for serverless environments, refer to our [connection management guide](/orm/prisma-client/setup-and-configuration/databases-connections#serverless-environments-faas).
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-00-deploy-to-vercel-architecture.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-00-deploy-to-vercel-architecture.png
new file mode 100644
index 0000000000..87cab2d012
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-00-deploy-to-vercel-architecture.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-10-deploy-to-vercel-deploy-button.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-10-deploy-to-vercel-deploy-button.png
new file mode 100644
index 0000000000..affde53fdf
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-10-deploy-to-vercel-deploy-button.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-10-deploy-to-vercel-deploy-button.snagx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-10-deploy-to-vercel-deploy-button.snagx
new file mode 100644
index 0000000000..f866b57bff
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-10-deploy-to-vercel-deploy-button.snagx differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-20-deploy-to-vercel-select-github.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-20-deploy-to-vercel-select-github.png
new file mode 100644
index 0000000000..111f6a9ce2
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-20-deploy-to-vercel-select-github.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-20-deploy-to-vercel-select-github.snagx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-20-deploy-to-vercel-select-github.snagx
new file mode 100644
index 0000000000..0feecdb56b
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-20-deploy-to-vercel-select-github.snagx differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-30-deploy-to-vercel-create-git-repo.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-30-deploy-to-vercel-create-git-repo.png
new file mode 100644
index 0000000000..a4966e9bc7
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-30-deploy-to-vercel-create-git-repo.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-30-deploy-to-vercel-create-git-repo.snagx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-30-deploy-to-vercel-create-git-repo.snagx
new file mode 100644
index 0000000000..8125ce49b4
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-30-deploy-to-vercel-create-git-repo.snagx differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-40-deploy-to-vercel-configure-project.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-40-deploy-to-vercel-configure-project.png
new file mode 100644
index 0000000000..84f9f2117e
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-40-deploy-to-vercel-configure-project.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-40-deploy-to-vercel-configure-project.snagx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-40-deploy-to-vercel-configure-project.snagx
new file mode 100644
index 0000000000..ebdf0f53d1
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-40-deploy-to-vercel-configure-project.snagx differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-50-deploy-to-vercel-success.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-50-deploy-to-vercel-success.png
new file mode 100644
index 0000000000..a0dabfc0c3
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-50-deploy-to-vercel-success.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-50-deploy-to-vercel-success.snagx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-50-deploy-to-vercel-success.snagx
new file mode 100644
index 0000000000..8f7c5c7095
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-50-deploy-to-vercel-success.snagx differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-60-deploy-to-vercel-preview-environment-variable.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-60-deploy-to-vercel-preview-environment-variable.png
new file mode 100644
index 0000000000..9d107a1046
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-60-deploy-to-vercel-preview-environment-variable.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-60-deploy-to-vercel-preview-environment-variable.snagx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-60-deploy-to-vercel-preview-environment-variable.snagx
new file mode 100644
index 0000000000..409dae8ce8
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-60-deploy-to-vercel-preview-environment-variable.snagx differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-70-deploy-to-vercel-environment-variables.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-70-deploy-to-vercel-environment-variables.png
new file mode 100644
index 0000000000..c004aab78c
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-70-deploy-to-vercel-environment-variables.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-70-deploy-to-vercel-environment-variables.snagx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-70-deploy-to-vercel-environment-variables.snagx
new file mode 100644
index 0000000000..e27fb6a167
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/300-70-deploy-to-vercel-environment-variables.snagx differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-01-deploy-to-netlify-architecture.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-01-deploy-to-netlify-architecture.png
new file mode 100644
index 0000000000..f332cc8d3b
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-01-deploy-to-netlify-architecture.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-02-deploy-to-netlify-example-repo-click-fork.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-02-deploy-to-netlify-example-repo-click-fork.png
new file mode 100644
index 0000000000..cb7ce5c427
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-02-deploy-to-netlify-example-repo-click-fork.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-02-deploy-to-netlify-example-repo-click-fork.snagx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-02-deploy-to-netlify-example-repo-click-fork.snagx
new file mode 100644
index 0000000000..6851b49d96
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-02-deploy-to-netlify-example-repo-click-fork.snagx differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-03-deploy-to-netlify-example-repo-create-fork-page.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-03-deploy-to-netlify-example-repo-create-fork-page.png
new file mode 100644
index 0000000000..50dbe8d37f
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-03-deploy-to-netlify-example-repo-create-fork-page.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-03-deploy-to-netlify-example-repo-create-fork-page.snagx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-03-deploy-to-netlify-example-repo-create-fork-page.snagx
new file mode 100644
index 0000000000..9d97a156f3
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-03-deploy-to-netlify-example-repo-create-fork-page.snagx differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-04-deploy-to-netlify-copy-supabase-connection-string.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-04-deploy-to-netlify-copy-supabase-connection-string.png
new file mode 100644
index 0000000000..90fb67a218
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-04-deploy-to-netlify-copy-supabase-connection-string.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-04-deploy-to-netlify-copy-supabase-connection-string.snagx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-04-deploy-to-netlify-copy-supabase-connection-string.snagx
new file mode 100644
index 0000000000..e5338f1afb
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-04-deploy-to-netlify-copy-supabase-connection-string.snagx differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-05-deploy-to-netlify-netlify-init-configure-site.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-05-deploy-to-netlify-netlify-init-configure-site.png
new file mode 100644
index 0000000000..2989a7c882
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-05-deploy-to-netlify-netlify-init-configure-site.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-05-deploy-to-netlify-netlify-init-configure-site.snagx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-05-deploy-to-netlify-netlify-init-configure-site.snagx
new file mode 100644
index 0000000000..2267e16b13
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-05-deploy-to-netlify-netlify-init-configure-site.snagx differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-06-deploy-to-netlify-site-settings.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-06-deploy-to-netlify-site-settings.png
new file mode 100644
index 0000000000..9ddf171eca
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-06-deploy-to-netlify-site-settings.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-06-deploy-to-netlify-site-settings.snagx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-06-deploy-to-netlify-site-settings.snagx
new file mode 100644
index 0000000000..f9ae9c525d
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-06-deploy-to-netlify-site-settings.snagx differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-07-deploy-to-netlify-environment-variables-settings.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-07-deploy-to-netlify-environment-variables-settings.png
new file mode 100644
index 0000000000..97f8d42ae8
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-07-deploy-to-netlify-environment-variables-settings.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-07-deploy-to-netlify-environment-variables-settings.snagx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-07-deploy-to-netlify-environment-variables-settings.snagx
new file mode 100644
index 0000000000..64d550ac63
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-07-deploy-to-netlify-environment-variables-settings.snagx differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-08-deploy-to-netlify-application-deployed.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-08-deploy-to-netlify-application-deployed.png
new file mode 100644
index 0000000000..050c85a379
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-08-deploy-to-netlify-application-deployed.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-08-deploy-to-netlify-application-deployed.snagx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-08-deploy-to-netlify-application-deployed.snagx
new file mode 100644
index 0000000000..941c2310b7
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-08-deploy-to-netlify-application-deployed.snagx differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-09-deploy-to-netlify-application-deployed-call-result.png b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-09-deploy-to-netlify-application-deployed-call-result.png
new file mode 100644
index 0000000000..c86a0a2bed
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-09-deploy-to-netlify-application-deployed-call-result.png differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-09-deploy-to-netlify-application-deployed-call-result.snagx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-09-deploy-to-netlify-application-deployed-call-result.snagx
new file mode 100644
index 0000000000..936008bc12
Binary files /dev/null and b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/images/500-09-deploy-to-netlify-application-deployed-call-result.snagx differ
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/index.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/index.mdx
new file mode 100644
index 0000000000..f38833a555
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/201-serverless/index.mdx
@@ -0,0 +1,46 @@
+---
+title: 'Serverless functions'
+metaTitle: 'Deploy Prisma ORM apps to serverless function (FaaS) providers'
+metaDescription: 'Learn how to deploy your Prisma ORM-backed apps to FaaS providers like AWS Lambda, Netlify, or Vercel Serverless Functions'
+tocDepth: 2
+---
+
+If your application is deployed via a "Serverless Function" or "Function-as-a-Service (FaaS)" offering and uses a standard Node.js runtime, it is a serverless app. Common deployment examples include [AWS Lambda](/orm/prisma-client/deployment/serverless/deploy-to-aws-lambda) and [Vercel Serverless Functions](/orm/prisma-client/deployment/serverless/deploy-to-vercel).
+
+:::tip Use Prisma ORM without Rust binaries
+
+If Prisma ORM's Rust engine binaries cause large bundle sizes, slow builds, or deployment issues (for example, in serverless or edge environments), you can use it without them using this configuration of your `generator` block:
+
+```prisma
+generator client {
+ provider = "prisma-client-js" // or "prisma-client"
+ engineType = "client"
+}
+```
+
+Prisma ORM without Rust binaries has been [Generally Available](/orm/more/releases#generally-available-ga) since [v6.16.0](https://pris.ly/release/6.16.0).
+
+Note that you need to use a [driver adapter](/orm/overview/databases/database-drivers#driver-adapters) in this case.
+
+When using this architecture:
+
+- No Rust query engine binary is downloaded or shipped.
+- The database connection pool is maintained by the native JS database driver you install (e.g., `@prisma/adapter-pg` for PostgreSQL).
+
+This setup can simplify deployments in:
+
+* Serverless functions
+* Edge runtimes
+* Read-only filesystem environments
+* CI/CD pipelines with strict size limits
+
+
+This setup can simplify deployments in serverless or edge runtimes. Learn more in the [docs here](/orm/prisma-client/setup-and-configuration/no-rust-engine).
+
+Curious why we moved away from the Rust engine? Take a look at why we transitioned from Rust binary engines to an all-TypeScript approach for a faster, lighter Prisma ORM in this [blog post](https://www.prisma.io/blog/prisma-orm-without-rust-latest-performance-benchmarks).
+
+:::
+
+## Guides for Serverless Function providers
+
+
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/301-edge/100-overview.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/301-edge/100-overview.mdx
new file mode 100644
index 0000000000..3463416c74
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/301-edge/100-overview.mdx
@@ -0,0 +1,109 @@
+---
+title: 'Deploying edge functions with Prisma ORM'
+metaTitle: 'Overview: Deploy Prisma ORM at the Edge'
+metaDescription: 'Learn how to deploy your Prisma-backed apps to edge functions like Cloudflare Workers or Vercel Edge Functions'
+sidebar_label: 'Overview'
+tocDepth: 2
+---
+
+You can deploy an application that uses Prisma ORM to the edge. Depending on which edge function provider and which database you use, there are different considerations and things to be aware of.
+
+
+Questions answered in this page
+
+- Which database drivers work on edge?
+- How do driver adapters affect connections?
+- When to use Prisma Postgres or Accelerate?
+
+
+
+Here is a brief overview of all the edge function providers that are currently supported by Prisma ORM:
+
+| Provider / Product | Supported natively with Prisma ORM | Supported with Prisma Postgres (and Prisma Accelerate)|
+| ---------------------- | ------------------------------------------------------- | -------------------------------- |
+| Vercel Edge Functions | ✅ (Preview; only compatible drivers) | ✅ |
+| Vercel Edge Middleware | ✅ (Preview; only compatible drivers) | ✅ |
+| Cloudflare Workers | ✅ (Preview; only compatible drivers) | ✅ |
+| Cloudflare Pages | ✅ (Preview; only compatible drivers) | ✅ |
+| Deno Deploy | [Not yet](https://github.com/prisma/prisma/issues/2452) | ✅ |
+
+Deploying edge functions that use Prisma ORM on Cloudflare and Vercel is currently in [Preview](/orm/more/releases#preview).
+
+:::note
+
+If Prisma ORM's Rust engine binaries cause large bundle sizes, slow builds, or deployment issues (for example, in serverless or edge environments), you can use it without them using this configuration of your `generator` block:
+
+```prisma
+generator client {
+ provider = "prisma-client-js" // or "prisma-client"
+ engineType = "client"
+}
+```
+
+Prisma ORM without Rust binaries has been [Generally Available](/orm/more/releases#generally-available-ga) since [v6.16.0](https://pris.ly/release/6.16.0).
+
+Note that you need to use a [driver adapter](/orm/overview/databases/database-drivers#driver-adapters) in this case.
+
+When using this architecture:
+
+- No Rust query engine binary is downloaded or shipped.
+- The database connection pool is maintained by the native JS database driver you install (e.g., `@prisma/adapter-pg` for PostgreSQL).
+
+This setup can simplify deployments in:
+
+- Serverless functions
+- Edge runtimes
+- Read-only filesystem environments
+- CI/CD pipelines with strict size limits
+
+This setup can simplify deployments in serverless or edge runtimes. Learn more in the [docs here](/orm/prisma-client/setup-and-configuration/no-rust-engine).
+
+Curious why we moved away from the Rust engine? Take a look at why we transitioned from Rust binary engines to an all-TypeScript approach for a faster, lighter Prisma ORM in this [blog post](https://www.prisma.io/blog/prisma-orm-without-rust-latest-performance-benchmarks).
+
+:::
+
+
+## Edge-compatibility of database drivers
+
+### Why are there limitations around database drivers in edge functions?
+
+Edge functions typically don't use the standard Node.js runtime. For example, Vercel Edge Functions and Cloudflare Workers are running code in [V8 isolates](https://v8docs.nodesource.com/node-0.8/d5/dda/classv8_1_1_isolate.html). Deno Deploy is using the [Deno](https://deno.com/) JavaScript runtime. As a consequence, these edge functions only have access to a small subset of the standard Node.js APIs and also have constrained computing resources (CPU and memory).
+
+In particular, the constraint of not being able to freely open TCP connections makes it difficult to talk to a traditional database from an edge function. While Cloudflare has introduced a [`connect()`](https://developers.cloudflare.com/workers/runtime-apis/tcp-sockets/) API that enables limited TCP connections, this still only enables database access using specific database drivers that are compatible with that API.
+
+:::note
+
+We recommend using [Prisma Postgres](/postgres). It is fully supported on edge runtimes and does not require a specialized edge-compatible driver. For other databases, [Prisma Accelerate](/accelerate) extends edge compatibility so you can connect to _any_ database from _any_ edge function provider.
+
+:::
+
+### Which database drivers are edge-compatible?
+
+Here is an overview of the different database drivers and their compatibility with different edge function offerings:
+
+- [Neon Serverless](https://neon.tech/docs/serverless/serverless-driver) uses HTTP to access the database. It works with Cloudflare Workers and Vercel Edge Functions.
+- [PlanetScale Serverless](https://planetscale.com/docs/tutorials/planetscale-serverless-driver) uses HTTP to access the database. It works with Cloudflare Workers and Vercel Edge Functions.
+- [`node-postgres`](https://node-postgres.com/) (`pg`) uses Cloudflare's `connect()` (TCP) to access the database. It is only compatible with Cloudflare Workers, not with Vercel Edge Functions.
+- [`@libsql/client`](https://github.com/tursodatabase/libsql-client-ts) is used to access Turso databases. It works with Cloudflare Workers and Vercel Edge Functions.
+- [Cloudflare D1](https://developers.cloudflare.com/d1/) is used to access D1 databases. It is only compatible with Cloudflare Workers, not with Vercel Edge Functions.
+- [Prisma Postgres](/postgres) is used to access a PostgreSQL database built on bare-metal using unikernels. It is supported on both Cloudflare Workers and Vercel.
+
+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.
+
+You can use all of these drivers with Prisma ORM using the respective [driver adapters](/orm/overview/databases/database-drivers).
+
+Depending on which deployment provider and database/driver you use, there may be special considerations. Please take a look at the deployment docs for your respective scenario to make sure you can deploy your application successfully:
+
+- Cloudflare
+ - [PostgreSQL (traditional)](/orm/prisma-client/deployment/edge/deploy-to-cloudflare#postgresql-traditional)
+ - [PlanetScale](/orm/prisma-client/deployment/edge/deploy-to-cloudflare#planetscale)
+ - [Neon](/orm/prisma-client/deployment/edge/deploy-to-cloudflare#neon)
+ - [Cloudflare D1](/guides/cloudflare-d1)
+ - [Prisma Postgres](https://developers.cloudflare.com/workers/tutorials/using-prisma-postgres-with-workers)
+- Vercel
+ - [Vercel Postgres](/orm/prisma-client/deployment/edge/deploy-to-vercel#vercel-postgres)
+ - [Neon](/orm/prisma-client/deployment/edge/deploy-to-vercel#neon)
+ - [PlanetScale](/orm/prisma-client/deployment/edge/deploy-to-vercel#planetscale)
+ - [Prisma Postgres](/guides/nextjs)
+
+If you want to deploy an app using Turso, you can follow the instructions [here](/orm/overview/databases/turso).
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/301-edge/450-deploy-to-cloudflare.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/301-edge/450-deploy-to-cloudflare.mdx
new file mode 100644
index 0000000000..c12f9ddf1e
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/301-edge/450-deploy-to-cloudflare.mdx
@@ -0,0 +1,647 @@
+---
+title: 'Deploy to Cloudflare Workers & Pages'
+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.'
+sidebar_label: Deploy to Cloudflare
+tocDepth: 3
+---
+
+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).
+
+
+Questions answered in this page
+
+- How to deploy Prisma to Cloudflare Workers?
+- Which drivers work on Workers/Pages?
+- How to configure DATABASE_URL and envs?
+
+
+
+:::tip Use Prisma ORM without Rust binaries
+
+If Prisma ORM's Rust engine binaries cause large bundle sizes, slow builds, or deployment issues (for example, in serverless or edge environments), you can use it without them using this configuration of your `generator` block:
+
+```prisma
+generator client {
+ provider = "prisma-client-js" // or "prisma-client"
+ engineType = "client"
+}
+```
+
+Prisma ORM without Rust binaries has been [Generally Available](/orm/more/releases#generally-available-ga) since [v6.16.0](https://pris.ly/release/6.16.0).
+
+Note that you need to use a [driver adapter](/orm/overview/databases/database-drivers#driver-adapters) in this case.
+
+When using this architecture:
+
+- No Rust query engine binary is downloaded or shipped.
+- The database connection pool is maintained by the native JS database driver you install (e.g., `@prisma/adapter-pg` for PostgreSQL).
+
+This setup can simplify deployments in serverless or edge runtimes. Learn more in the [docs here](/orm/prisma-client/setup-and-configuration/no-rust-engine).
+
+Curious why we moved away from the Rust engine? Take a look at why we transitioned from Rust binary engines to an all-TypeScript approach for a faster, lighter Prisma ORM in this [blog post](https://www.prisma.io/blog/prisma-orm-without-rust-latest-performance-benchmarks).
+
+:::
+## 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 Prisma Postgres
+
+You can use Prisma Postgres and deploy to Cloudflare Workers.
+
+After you create a Worker, run:
+
+```terminal
+npx prisma@latest init --db
+```
+
+Enter a name for your project and choose a database region.
+
+This command:
+
+- Connects your CLI to your [Prisma Data Platform](https://console.prisma.io) account. If you're not logged in or don't have an account, your browser will open to guide you through creating a new account or signing into your existing one.
+- Creates a `prisma` directory containing a `schema.prisma` file for your database models.
+- Creates a `.env` file with your `DATABASE_URL` (e.g., for Prisma Postgres it should have something similar to `DATABASE_URL="prisma+postgres://accelerate.prisma-data.net/?api_key=eyJhbGciOiJIUzI..."`).
+
+You'll need to install the Client extension required to use Prisma Postgres:
+
+```terminal
+npm i @prisma/extension-accelerate
+```
+
+And extend `PrismaClient` with the extension in your application code:
+
+```typescript
+import { PrismaClient } from "@prisma/client/edge";
+import { withAccelerate } from "@prisma/extension-accelerate";
+
+export interface Env {
+ DATABASE_URL: string;
+}
+
+export default {
+ async fetch(request, env, ctx) {
+ const prisma = new PrismaClient({
+ datasourceUrl: env.DATABASE_URL,
+ }).$extends(withAccelerate());
+
+ const users = await prisma.user.findMany();
+ const result = JSON.stringify(users);
+ return new Response(result);
+ },
+} satisfies ExportedHandler;
+```
+
+Then setup helper scripts to perform migrations and generate `PrismaClient` as [shown in this section](/orm/prisma-client/deployment/edge/deploy-to-cloudflare#development).
+
+:::note
+
+You need to have the `dotenv-cli` package installed as Cloudflare Workers does not support `.env` files. You can do this by running the following command to install the package locally in your project: `npm install -D dotenv-cli`.
+
+:::
+
+### 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) 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
+
+If your application uses PostgreSQL, we recommend using [Prisma Postgres](/postgres). It is fully supported on edge runtimes and does not require a specialized edge-compatible driver. For other databases, [Prisma Accelerate](/accelerate) extends edge compatibility so you can connect to _any_ database from _any_ edge function provider.
+
+:::
+
+### 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/#local-development-with-secrets) 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 3 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.
+
+### 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/nextjs/ssr/get-started/) 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?utm_source=docs&utm_medium=inline_text) 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 && npm install @prisma/client
+npx prisma init --output ../generated/prisma
+```
+
+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 (learn more [here](/orm/overview/databases/postgresql#using-the-node-postgres-driver))
+- set `node_compat = true` in `wrangler.toml` (see the [Cloudflare docs](https://developers.cloudflare.com/workers/runtime-apis/nodejs/))
+
+#### 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:
+
+```prisma file=schema.prisma
+generator client {
+ provider = "prisma-client-js"
+}
+
+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
+```
+
+#### 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'
+
+export default {
+ async fetch(request, env, ctx) {
+ const adapter = new PrismaPg({ connectionString: env.DATABASE_URL })
+ 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 (learn more [here](/orm/overview/databases/planetscale#how-to-use-the-planetscale-serverless-driver-with-prisma-orm-preview))
+- manually remove the conflicting `cache` field:
+
+ ```ts
+ export default {
+ async fetch(request, env, ctx) {
+ const adapter = new PrismaPlanetScale({
+ url: env.DATABASE_URL,
+ // see https://github.com/cloudflare/workerd/issues/698
+ fetch(url, init) {
+ delete init['cache']
+ return fetch(url, init)
+ },
+ })
+ 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:
+
+```prisma file=schema.prisma
+generator client {
+ provider = "prisma-client-js"
+}
+
+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
+```
+
+#### 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'
+
+export default {
+ async fetch(request, env, ctx) {
+ const adapter = new PrismaPlanetScale({
+ url: env.DATABASE_URL,
+ // see https://github.com/cloudflare/workerd/issues/698
+ fetch(url, init) {
+ delete init['cache']
+ return fetch(url, init)
+ },
+ })
+ 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 (learn more [here](/orm/overview/databases/neon#how-to-use-neons-serverless-driver-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:
+
+```prisma file=schema.prisma
+generator client {
+ provider = "prisma-client-js"
+}
+
+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
+```
+
+#### 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'
+
+export default {
+ async fetch(request, env, ctx) {
+ const adapter = new PrismaNeon({ connectionString: env.DATABASE_URL })
+ 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.
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/301-edge/485-deploy-to-vercel.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/301-edge/485-deploy-to-vercel.mdx
new file mode 100644
index 0000000000..bab4e03d21
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/301-edge/485-deploy-to-vercel.mdx
@@ -0,0 +1,552 @@
+---
+title: 'Deploy to Vercel Edge Functions & Middleware'
+metaTitle: 'Deploy to Vercel Edge Functions & Middleware'
+metaDescription: 'Learn the things you need to know in order to deploy an Edge function that uses Prisma Client for talking to a database.'
+sidebar_label: 'Deploy to Vercel'
+tocDepth: 3
+sidebar_class_name: preview-badge
+---
+
+This page covers everything you need to know to deploy an app that uses Prisma Client for talking to a database in [Vercel Edge Middleware](https://vercel.com/docs/functions/edge-middleware) or a [Vercel Function](https://vercel.com/docs/functions) deployed to the [Vercel Edge Runtime](https://vercel.com/docs/functions/runtimes/edge-runtime).
+
+
+Questions answered in this page
+
+- How to deploy Prisma on Vercel Edge?
+- Which database drivers are supported?
+- How to configure env and postinstall?
+
+
+
+Vercel supports both Node.js and edge runtimes for Vercel Functions. The Node.js runtime is the default and recommended for most use cases.
+
+:::note
+
+By default, Vercel Functions use the Node.js runtime. You can explicitly set the runtime if needed:
+
+```typescript
+export const runtime = 'edge'; // 'nodejs' is the default
+
+export function GET(request: Request) {
+ return new Response(`I am a Vercel Function!`, {
+ status: 200,
+ });
+}
+```
+
+:::
+
+:::tip Use Prisma ORM without Rust binaries
+
+If Prisma ORM's Rust engine binaries cause large bundle sizes, slow builds, or deployment issues (for example, in serverless or edge environments), you can use it without them using this configuration of your `generator` block:
+
+```prisma
+generator client {
+ provider = "prisma-client-js" // or "prisma-client"
+ engineType = "client"
+}
+```
+
+Prisma ORM without Rust binaries has been [Generally Available](/orm/more/releases#generally-available-ga) since [v6.16.0](https://pris.ly/release/6.16.0).
+
+Note that you need to use a [driver adapter](/orm/overview/databases/database-drivers#driver-adapters) in this case.
+
+When using this architecture:
+
+- No Rust query engine binary is downloaded or shipped.
+- The database connection pool is maintained by the native JS database driver you install (e.g., `@prisma/adapter-pg` for PostgreSQL).
+
+This setup can simplify deployments in serverless or edge runtimes. Learn more in the [docs here](/orm/prisma-client/setup-and-configuration/no-rust-engine).
+
+Curious why we moved away from the Rust engine? Take a look at why we transitioned from Rust binary engines to an all-TypeScript approach for a faster, lighter Prisma ORM in this [blog post](https://www.prisma.io/blog/prisma-orm-without-rust-latest-performance-benchmarks).
+
+:::
+## General considerations when deploying to Vercel Edge Functions & Edge Middleware
+
+### Using Prisma Postgres
+
+You can use Prisma Postgres in Vercel's edge runtime. Follow this guide for an end-to-end tutorial on [deploying an application to Vercel using Prisma Postgres](/guides/nextjs).
+
+### Using an edge-compatible driver
+
+Vercel's Edge Runtime currently only supports a limited set of database drivers:
+
+- [Neon Serverless](https://neon.tech/docs/serverless/serverless-driver) uses HTTP to access the database (also compatible with [Vercel Postgres](https://vercel.com/docs/storage/vercel-postgres))
+- [PlanetScale Serverless](https://planetscale.com/docs/tutorials/planetscale-serverless-driver) uses HTTP to access the database
+- [`@libsql/client`](https://github.com/tursodatabase/libsql-client-ts) is used to access Turso databases
+
+Note that [`node-postgres`](https://node-postgres.com/) (`pg`) is currently _not_ supported on Vercel Edge Functions.
+
+When deploying a Vercel Edge Function that uses Prisma ORM, you need to use one of these [edge-compatible drivers](/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.
+
+:::note
+
+If your application uses PostgreSQL, we recommend using [Prisma Postgres](/postgres). It is fully supported on edge runtimes and does not require a specialized edge-compatible driver. For other databases, [Prisma Accelerate](/accelerate) extends edge compatibility so you can connect to _any_ database from _any_ edge function provider.
+
+:::
+
+### 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 in **development**, you can configure your database connection via the `DATABASE_URL` environment variable (e.g. [using `.env` files](/orm/more/development-environment/environment-variables)).
+
+#### Production
+
+When deploying your Edge Function to **production**, you'll need to set the database connection using the `vercel` CLI:
+
+```terminal
+npx vercel env add DATABASE_URL
+```
+
+This command is interactive and will ask you to select environments and provide the value for the `DATABASE_URL` in subsequent steps.
+
+Alternatively, you can configure the environment variable [via the UI](https://vercel.com/docs/projects/environment-variables#creating-environment-variables) of your project in the Vercel Dashboard.
+
+### Generate Prisma Client in `postinstall` hook
+
+In your `package.json`, you should add a `"postinstall"` section as follows:
+
+```js file=package.json showLineNumbers
+{
+ // ...,
+ "postinstall": "prisma generate"
+}
+```
+
+### Size limits on free accounts
+
+Vercel has a [size limit of 1 MB on free accounts](https://vercel.com/docs/functions/limitations). If your application bundle with Prisma ORM exceeds that size, we recommend upgrading to a paid account or using Prisma Accelerate to deploy your application.
+
+## Database-specific considerations & examples
+
+This section provides database-specific instructions for deploying a Vercel Edge Functions with Prisma ORM.
+
+### Prerequisites
+
+As a prerequisite for the following section, you need to have a Vercel Edge Function (which typically comes in the form of a Next.js API route) running locally and the Prisma and Vercel CLIs installed.
+
+If you don't have that yet, you can run these commands to set up a Next.js app from scratch (following the instructions of the [Vercel Functions Quickstart](https://vercel.com/docs/functions/quickstart)):
+
+```terminal
+npm install -g vercel
+npx create-next-app@latest
+npm install prisma --save-dev && npm install @prisma/client
+npx prisma init --output ../app/generated/prisma
+```
+
+We'll use the default `User` model for the example below:
+
+```prisma
+model User {
+ id Int @id @default(autoincrement())
+ email String @unique
+ name String?
+}
+```
+
+### Vercel Postgres
+
+If you are using Vercel Postgres, you need to:
+
+- use the `@prisma/adapter-neon` database adapter because Vercel Postgres uses [Neon](https://neon.tech/) under the hood
+- be aware that Vercel by default calls the environment variable for the database connection string `POSTGRES_PRISMA_URL` while the default name used in the Prisma docs is typically `DATABASE_URL`; using Vercel's naming, you need to set the following fields on your `datasource` block:
+ ```prisma
+ datasource db {
+ provider = "postgresql"
+ url = env("POSTGRES_PRISMA_URL") // uses connection pooling
+ directUrl = env("POSTGRES_URL_NON_POOLING") // uses a direct connection
+ }
+ ```
+
+#### 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 Next.js app 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 `POSTGRES_PRISMA_URL` and the `directUrl` to the `POSTGRES_URL_NON_POOLING` environment variable:
+
+```prisma file=schema.prisma showLineNumbers
+generator client {
+ provider = "prisma-client-js"
+}
+
+datasource db {
+ provider = "postgresql"
+ url = env("POSTGRES_PRISMA_URL") // uses connection pooling
+ directUrl = env("POSTGRES_URL_NON_POOLING") // uses a direct connection
+}
+```
+
+Next, you need to set the `POSTGRES_PRISMA_URL` and `POSTGRES_URL_NON_POOLING` environment variable to the values of your database connection.
+
+If you ran `npx prisma init`, you can use the `.env` file that was created by this command to set these:
+
+```bash file=.env showLineNumbers
+POSTGRES_PRISMA_URL="postgres://user:password@host-pooler.region.postgres.vercel-storage.com:5432/name?pgbouncer=true&connect_timeout=15"
+POSTGRES_URL_NON_POOLING="postgres://user:password@host.region.postgres.vercel-storage.com:5432/name"
+```
+
+#### 2. Install dependencies
+
+Next, install the required packages:
+
+```terminal
+npm install @prisma/adapter-neon
+```
+
+#### 3. Configure `postinstall` hook
+
+Next, add a new key to the `scripts` section in your `package.json`:
+
+```js file=package.json
+{
+ // ...
+ "scripts": {
+ // ...
+ //add-next-line
+ "postinstall": "prisma generate"
+ }
+}
+```
+
+#### 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
+npx prisma migrate dev --name init
+```
+
+#### 5. Use Prisma Client in your Vercel Edge Function to send a query to the database
+
+If you created the project from scratch, you can create a new edge function as follows.
+
+First, create a new API route, e.g. by using these commands:
+
+```terminal
+mkdir src/app/api
+mkdir src/app/api/edge
+touch src/app/api/edge/route.ts
+```
+
+Here is a sample code snippet that you can use to instantiate `PrismaClient` and send a query to your database in the new `app/api/edge/route.ts` file you just created:
+
+```ts file=app/api/edge/route.ts showLineNumbers
+import { NextResponse } from 'next/server'
+import { PrismaClient } from '@prisma/client'
+import { PrismaNeon } from '@prisma/adapter-neon'
+
+export const runtime = 'nodejs' // can also be set to 'edge'
+
+export async function GET(request: Request) {
+ const adapter = new PrismaNeon({ connectionString: process.env.POSTGRES_PRISMA_URL })
+ const prisma = new PrismaClient({ adapter })
+
+ const users = await prisma.user.findMany()
+
+ return NextResponse.json(users, { status: 200 })
+}
+```
+
+#### 6. Run the Edge Function locally
+
+Run the app with the following command:
+
+```terminal
+npm run dev
+```
+
+You can now access the Edge Function via this URL: [`http://localhost:3000/api/edge`](http://localhost:3000/api/edge).
+
+#### 7. Set the `POSTGRES_PRISMA_URL` environment variable and deploy the Edge Function
+
+Run the following command to deploy your project with Vercel:
+
+```terminal
+npx vercel deploy
+```
+
+Note that once the project was created on Vercel, you will need to set the `POSTGRES_PRISMA_URL` environment variable (and if this was your first deploy, it likely failed). You can do this either via the Vercel UI or by running the following command:
+
+```
+npx vercel env add POSTGRES_PRISMA_URL
+```
+
+At this point, you can get the URL of the deployed application from the Vercel Dashboard and access the edge function via the `/api/edge` route.
+
+### PlanetScale
+
+If you are using a PlanetScale database, you need to:
+
+- use the `@prisma/adapter-planetscale` database adapter (learn more [here](/orm/overview/databases/planetscale#how-to-use-the-planetscale-serverless-driver-with-prisma-orm-preview))
+
+#### 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 Next.js app 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:
+
+```prisma file=schema.prisma showLineNumbers
+generator client {
+ provider = "prisma-client-js"
+}
+
+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 in your `.env` file that's used both by Prisma and Next.js to read your env vars:
+
+```bash file=.env
+DATABASE_URL="mysql://32qxa2r7hfl3102wrccj:password@us-east.connect.psdb.cloud/demo-cf-worker-ps?sslaccept=strict"
+```
+
+#### 2. Install dependencies
+
+Next, install the required packages:
+
+```terminal
+npm install @prisma/adapter-planetscale
+```
+
+#### 3. Configure `postinstall` hook
+
+Next, add a new key to the `scripts` section in your `package.json`:
+
+```js file=package.json
+{
+ // ...
+ "scripts": {
+ // ...
+ //add-next-line
+ "postinstall": "prisma generate"
+ }
+}
+```
+
+#### 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
+npx prisma db push
+```
+
+#### 5. Use Prisma Client in an Edge Function to send a query to the database
+
+If you created the project from scratch, you can create a new edge function as follows.
+
+First, create a new API route, e.g. by using these commands:
+
+```terminal
+mkdir src/app/api
+mkdir src/app/api/edge
+touch src/app/api/edge/route.ts
+```
+
+Here is a sample code snippet that you can use to instantiate `PrismaClient` and send a query to your database in the new `app/api/edge/route.ts` file you just created:
+
+```ts file=app/api/edge/route.ts showLineNumbers
+import { NextResponse } from 'next/server'
+import { PrismaClient } from '@prisma/client'
+import { PrismaPlanetScale } from '@prisma/adapter-planetscale'
+
+export const runtime = 'nodejs' // can also be set to 'edge'
+
+export async function GET(request: Request) {
+ const adapter = new PrismaPlanetScale({ url: process.env.DATABASE_URL })
+ const prisma = new PrismaClient({ adapter })
+
+ const users = await prisma.user.findMany()
+
+ return NextResponse.json(users, { status: 200 })
+}
+```
+
+#### 6. Run the Edge Function locally
+
+Run the app with the following command:
+
+```terminal
+npm run dev
+```
+
+You can now access the Edge Function via this URL: [`http://localhost:3000/api/edge`](http://localhost:3000/api/edge).
+
+#### 7. Set the `DATABASE_URL` environment variable and deploy the Edge Function
+
+Run the following command to deploy your project with Vercel:
+
+```terminal
+npx vercel deploy
+```
+
+Note that once the project was created on Vercel, you will need to set the `DATABASE_URL` environment variable (and if this was your first deploy, it likely failed). You can do this either via the Vercel UI or by running the following command:
+
+```
+npx vercel env add DATABASE_URL
+```
+
+At this point, you can get the URL of the deployed application from the Vercel Dashboard and access the edge function via the `/api/edge` route.
+
+### Neon
+
+If you are using a Neon database, you need to:
+
+- use the `@prisma/adapter-neon` database adapter (learn more [here](/orm/overview/databases/neon#how-to-use-neons-serverless-driver-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 Next.js app 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:
+
+```prisma file=schema.prisma showLineNumbers
+generator client {
+ provider = "prisma-client-js"
+}
+
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+```
+
+Next, you need to set the `DATABASE_URL` environment variable in your `.env` file that's used both by Prisma and Next.js to read your env vars:
+
+```bash file=.env showLineNumbers
+DATABASE_URL="postgresql://janedoe:password@ep-nameless-pond-a23b1mdz.eu-central-1.aws.neon.tech/neondb?sslmode=require"
+```
+
+#### 2. Install dependencies
+
+Next, install the required packages:
+
+```terminal
+npm install @prisma/adapter-neon
+```
+
+#### 3. Configure `postinstall` hook
+
+Next, add a new key to the `scripts` section in your `package.json`:
+
+```js file=package.json
+{
+ // ...
+ "scripts": {
+ // ...
+ //add-next-line
+ "postinstall": "prisma generate"
+ }
+}
+```
+
+#### 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
+npx prisma migrate dev --name init
+```
+
+#### 5. Use Prisma Client in an Edge Function to send a query to the database
+
+If you created the project from scratch, you can create a new edge function as follows.
+
+First, create a new API route, e.g. by using these commands:
+
+```terminal
+mkdir src/app/api
+mkdir src/app/api/edge
+touch src/app/api/edge/route.ts
+```
+
+Here is a sample code snippet that you can use to instantiate `PrismaClient` and send a query to your database in the new `app/api/edge/route.ts` file you just created:
+
+```ts file=app/api/edge/route.ts showLineNumbers
+import { NextResponse } from 'next/server'
+import { PrismaClient } from '@prisma/client'
+import { PrismaNeon } from '@prisma/adapter-neon'
+
+export const runtime = 'nodejs' // can also be set to 'edge'
+
+export async function GET(request: Request) {
+ const adapter = new PrismaNeon({ connectionString: process.env.DATABASE_URL })
+ const prisma = new PrismaClient({ adapter })
+
+ const users = await prisma.user.findMany()
+
+ return NextResponse.json(users, { status: 200 })
+}
+```
+
+#### 6. Run the Edge Function locally
+
+Run the app with the following command:
+
+```terminal
+npm run dev
+```
+
+You can now access the Edge Function via this URL: [`http://localhost:3000/api/edge`](http://localhost:3000/api/edge).
+
+#### 7. Set the `DATABASE_URL` environment variable and deploy the Edge Function
+
+Run the following command to deploy your project with Vercel:
+
+```terminal
+npx vercel deploy
+```
+
+Note that once the project was created on Vercel, you will need to set the `DATABASE_URL` environment variable (and if this was your first deploy, it likely failed). You can do this either via the Vercel UI or by running the following command:
+
+```
+npx vercel env add DATABASE_URL
+```
+
+At this point, you can get the URL of the deployed application from the Vercel Dashboard and access the edge function via the `/api/edge` route.
+
+## Using Prisma ORM with Vercel Fluid
+
+[Fluid compute](https://vercel.com/fluid) is a compute model from Vercel that combines the flexibility of serverless with the stability of servers, making it ideal for dynamic workloads such as streaming data and AI APIs. Vercel's Fluid compute [supports both edge and Node.js runtimes](https://vercel.com/docs/fluid-compute#available-runtime-support). A common challenge in traditional serverless platforms is leaked database connections when functions are suspended and pools can't close idle connections. Fluid provides [`attachDatabasePool`](https://vercel.com/blog/the-real-serverless-compute-to-database-connection-problem-solved) to ensure idle connections are released before a function is suspended.
+
+Use `attachDatabasePool` together with [Prisma's driver adapters](/orm/overview/databases/database-drivers) to safely manage connections in Fluid:
+
+```ts
+import { Pool } from 'pg'
+import { attachDatabasePool } from '@vercel/functions'
+import { PrismaPg } from '@prisma/adapter-pg'
+import { PrismaClient } from '@prisma/client'
+
+const pool = new Pool({ connectionString: process.env.POSTGRES_URL })
+
+attachDatabasePool(pool)
+
+const prisma = new PrismaClient({
+ adapter: new PrismaPg(pool),
+})
+```
diff --git a/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/301-edge/550-deploy-to-deno-deploy.mdx b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/301-edge/550-deploy-to-deno-deploy.mdx
new file mode 100644
index 0000000000..bf83af3f4e
--- /dev/null
+++ b/versioned_docs/version-6.0.0/200-orm/200-prisma-client/500-deployment/301-edge/550-deploy-to-deno-deploy.mdx
@@ -0,0 +1,313 @@
+---
+title: 'Deploy to Deno Deploy'
+metaTitle: 'Deploy to Deno Deploy'
+metaDescription: 'Learn how to deploy a TypeScript application to Deno Deploy.'
+---
+
+
+
+With this guide, you can learn how to build and deploy a simple application to [Deno Deploy](https://deno.com/deploy). The application uses Prisma ORM to save a log of each request to a [Prisma Postgres](/postgres) database.
+
+This guide covers the use of Prisma CLI with Deno CLI, Deno Deploy, Prisma Client, and Prisma Postgres.
+
+:::info
+
+This guide demonstrates how to deploy an application to Deno Deploy with a Prisma Postgres database, but you can also use [your own database with Prisma Accelerate](/accelerate/getting-started#prerequisites).
+
+:::
+
+:::tip Use Prisma ORM without Rust binaries
+
+If Prisma ORM's Rust engine binaries cause large bundle sizes, slow builds, or deployment issues (for example, in serverless or edge environments), you can use it without them using this configuration of your `generator` block:
+
+```prisma
+generator client {
+ provider = "prisma-client-js" // or "prisma-client"
+ engineType = "client"
+}
+```
+
+Prisma ORM without Rust binaries has been [Generally Available](/orm/more/releases#generally-available-ga) since [v6.16.0](https://pris.ly/release/6.16.0).
+
+Note that you need to use a [driver adapter](/orm/overview/databases/database-drivers#driver-adapters) in this case.
+
+When using this architecture:
+
+- No Rust query engine binary is downloaded or shipped.
+- The database connection pool is maintained by the native JS database driver you install (e.g., `@prisma/adapter-pg` for PostgreSQL).
+
+This setup can simplify deployments in serverless or edge runtimes. Learn more in the [docs here](/orm/prisma-client/setup-and-configuration/no-rust-engine).
+
+Curious why we moved away from the Rust engine? Take a look at why we transitioned from Rust binary engines to an all-TypeScript approach for a faster, lighter Prisma ORM in this [blog post](https://www.prisma.io/blog/prisma-orm-without-rust-latest-performance-benchmarks).
+
+:::
+
+
+## Prerequisites
+
+- a free [Prisma Data Platform](https://console.prisma.io/login) account
+- a free [Deno Deploy](https://deno.com/deploy) account
+- Node.js & npm installed
+- Deno v1.29.4 or later installed. [Learn more](https://docs.deno.com/runtime/#install-deno).
+- (Recommended) Latest version of Prisma ORM.
+- (Recommended) Deno extension for VS Code. [Learn more](https://docs.deno.com/runtime/reference/vscode/).
+
+## 1. Set up your application and database
+
+To start, you create a directory for your project, and then use `deno run` to initialize your application with `prisma init` as an [npm package with npm specifiers](https://docs.deno.com/runtime/fundamentals/node/).
+
+To set up your application, open your terminal and navigate to a location of your choice. Then, run the following commands to set up your application:
+
+```terminal
+mkdir prisma-deno-deploy
+cd prisma-deno-deploy
+npx prisma@latest init --db
+```
+
+Enter a name for your project and choose a database region.
+
+This command:
+
+- Connects your CLI to your [Prisma Data Platform](https://console.prisma.io) account. If you're not logged in or don't have an account, your browser will open to guide you through creating a new account or signing into your existing one.
+- Creates a `prisma` directory containing a `schema.prisma` file for your database models.
+- Creates a `.env` file with your `DATABASE_URL` (e.g., for Prisma Postgres it should have something similar to `DATABASE_URL="prisma+postgres://accelerate.prisma-data.net/?api_key=eyJhbGciOiJIUzI..."`).
+
+Edit the `prisma/schema.prisma` file to define a `Log` model, add a custom `output` path and [the `prisma-client` generator](/6.0/orm/prisma-schema/overview/generators#prisma-client) with `deno` as the `runtime`:
+
+```prisma file=schema.prisma highlight=3-4,12-23;add showLineNumbers
+generator client {
+ // delete-start
+ provider = "prisma-client-js"
+ // delete-end
+ //add-start
+ provider = "prisma-client"
+ output = "../generated/prisma"
+ runtime = "deno"
+ //add-end
+}
+
+datasource db {
+ provider = "postgresql"
+ url = env("DATABASE_URL")
+}
+
+//add-start
+model Log {
+ id Int @id @default(autoincrement())
+ level Level
+ message String
+ meta Json
+}
+
+enum Level {
+ Info
+ Warn
+ Error
+}
+//add-end
+```
+
+Then, install Prisma Client:
+
+```terminal
+deno install npm:@prisma/client
+```
+
+Then, install [the Client extension](https://www.npmjs.com/package/@prisma/extension-accelerate) required to use Prisma Postgres:
+
+```terminal
+deno install npm:@prisma/extension-accelerate
+```
+
+Prisma Client does not read `.env` files by default on Deno, so you must also install `dotenv-cli` locally:
+
+```terminal
+deno install npm:dotenv-cli
+```
+
+## 2. Create the database schema
+
+With the data model in place and your database connection configured, you can now apply the data model to your database.
+
+```terminal
+deno run -A npm: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
+
+At this point, the command has an additional side effects. The command installs Prisma Client and creates the `package.json` file for the project.
+
+## 3. Create your application
+
+You can now create a local Deno application. Create `index.ts` in the root folder of your project and add the content below:
+
+```ts file=index.ts
+import { serve } from "https://deno.land/std@0.140.0/http/server.ts";
+import { withAccelerate } from "npm:@prisma/extension-accelerate";
+import { PrismaClient } from "./generated/prisma/client.ts";
+
+const prisma = new PrismaClient().$extends(withAccelerate());
+
+async function handler(request: Request) {
+ // Ignore /favicon.ico requests:
+ const url = new URL(request.url);
+ if (url.pathname === "/favicon.ico") {
+ return new Response(null, { status: 204 });
+ }
+
+ const log = await prisma.log.create({
+ data: {
+ level: "Info",
+ message: `${request.method} ${request.url}`,
+ meta: {
+ headers: JSON.stringify(request.headers),
+ },
+ },
+ });
+ const body = JSON.stringify(log, null, 2);
+ return new Response(body, {
+ headers: { "content-type": "application/json; charset=utf-8" },
+ });
+}
+
+serve(handler);
+```
+
+:::info
+
+**VS Code error: `An import path cannot end with a '.ts' extension`**