PostgreSQL CHECK verification rejects equivalent `NOT IN` and `<> ALL` expressions

Package and version

Prisma CLI: 8.0.0-rc.11 @prisma/orm-postgres: 8.0.0-rc.11

What happened?

Observed Defect Evidence

In an independently verified PostgreSQL case, valid migration SQL completed successfully and PostgreSQL created the intended physical schema.

Schema verification then reported exactly four CHECK-expression differences. Each difference was representation-only:

Expected: NOT IN (...) Observed: <> ALL (ARRAY[...])

No unrelated schema discrepancy was identified. The migration runner uses the same verification comparison path.

Standalone Reproduction Status

The neutral Prisma RC.11 standalone package has demonstrated:

• Valid model-level CHECK authoring.
• Successful contract emission.
• Successful migration planning.
• Preservation of the CHECK expression in generated contract and migration artifacts.

The standalone project has not been migrated to PostgreSQL, and standalone schema verification has not been run. It is therefore not claimed as a completed end-to-end reproduction of the PostgreSQL verification failure.

What did you expect to happen?

Schema verification should recognize semantically equivalent PostgreSQL CHECK predicates, including normal catalog rewrites such as NOT IN (...) and <> ALL (ARRAY[...]), instead of reporting them as schema differences.

Minimal reproduction

The prepared neutral package contains the three files shown below.

After installing the pinned direct dependencies, the following commands successfully demonstrate the preparation path:

./node_modules/.bin/prisma contract emit
./node_modules/.bin/prisma migration plan --name check-reproduction

The migration plan preserves the CHECK expression in the generated migration artifact.

This package is intentionally not presented as a completed standalone end-to-end reproduction. The observed verifier failure comes from the independently verified PostgreSQL case described above.

package.json

{
  "name": "prisma-check-normalization-repro",
  "private": true,
  "dependencies": {
    "prisma": "8.0.0-rc.11",
    "@prisma/orm-postgres": "8.0.0-rc.11"
  }
}

prisma.config.ts

import { definePrismaConfig } from "prisma/config";
import { defineConfig as ormConfig } from "@prisma/orm-postgres/config";

export default definePrismaConfig({
  orm: ormConfig({
    contract: "./prisma/contract.prisma",
  }),
});

prisma/contract.prisma

model Example {
  id     Int    @id
  status String

  @@check(
    expression: "status NOT IN ('A', 'B')",
    map: "example_status_check"
  )
}

Environment

OS: macOS Node.js: v24.19.0 npm: 11.17.0 PostgreSQL: 16.15 (Homebrew)

Prisma CLI: 8.0.0-rc.11 @prisma/orm-postgres: 8.0.0-rc.11

Additional context

The standalone migration plan produced exactly two additive operations:

1. Create schema public.
2. Create table example.

The table contains two non-null columns, a primary key, and one mapped CHECK constraint. No indexes, unique constraints, foreign keys, or defaults were generated.

No standalone database migration or schema verification has been performed. No data loss, corruption, production impact, or verified upstream fix is being claimed.