Consider this (internal) Notion doc.

Considering this schema.prisma:

generator client {
  provider = "prisma-client-js"
  engineType = "library"
  previewFeatures = ["driverAdapters"]
}

datasource db {
  provider = "postgres"
  url      = env("DATABASE_URL")
}

The schema clearly uses the postgres provider.

Now consider a TypeScript snippet in which we load planetscale's Driver Adapter:

import { connect } from '@planetscale/database'
import { PrismaPlanetScale } from '@prisma/adapter-planetscale'
import { PrismaClient } from '@prisma/client'

const connectionString = `${process.env.DATABASE_URL}`

const connection = connect({ url: connectionString })
const adapter = new PrismaPlanetScale(connection)
const prisma = new PrismaClient({ adapter })

// use Prisma as usual on any model, e.g., `user`
await prisma.user.findMany()

The schema clearly uses the postgres provider, yet we are allowed to load the planetscale's Driver Adapter, which should required the mysql provider. One can construct a particularly dangerous example in which, as long as the remote mysql-based database has the same table definitions as the ones inferred in TypeScript from the Prisma schema, the user could accidentally write to the wrong database, and Prisma Client would give absolutely no indication of this mishap.

So, we're missing a runtime validation error, which could be phrased as:

The Driver Adapter `PlanetScale` is not compatible with the `postgres` provider specified in the schema. You should either load a Driver Adapter based on `postgres`, or update the `datasource` block in the schema to use the `mysql` provider instead.

In particular, one can check that adapter.flavour === 'mysql' (see code).

Edge case: Both postgresql and postgres are valid providers in the datasource block, but only postgres is a valid value for the flavour property of any DriverAdapter' class.

Prisma: 5.5.2