Existing schema adoption

Playstack can determine whether an existing Prisma schema physically satisfies a selected package artifact without connecting to a database or claiming semantic equivalence.

Run the read-only preflight

npx playstack database compatibility --database=primary
npx playstack database compatibility --database=primary --json

The report compares incoming artifacts with application .prisma files and other selected package artifacts. It checks:

• logical model and enum declarations;
• physical @@map, @map, constraint, and relation identities;
• scalar field names, types, optionality, defaults, and native database annotations;
• primary, unique, and index guarantees; and
• unmanaged files already occupying a managed artifact destination.

The result is deterministic and field-specific so an application migration or adapter can be reviewed before database sync writes anything.

Declare exact satisfaction

Use existingArtifacts only when the existing storage must satisfy the package's full physical contract:

{
  "databases": {
    "primary": {
      "adapter": "prisma",
      "target": "prisma/playstack",
      "packages": {
        "@playstack/accounts": {
          "existingArtifacts": ["accounts.prisma"]
        }
      }
    }
  }
}

Adoption is fail-closed. The CLI skips accounts.prisma only when model or table identity, fields, mappings, relations, constraints, enums, and safe extra-column rules all pass. A near match remains a reported incompatibility.

Mapped names are supported when Prisma annotations resolve to the artifact's exact storage identities. Provider-native types are checked separately: compatible PostgreSQL defaults can be normalized, materially different types remain incompatible, and annotations are reported as unverified when the datasource provider cannot be determined.

Use an application adapter for semantic equivalence

An existing AccountInvitation table is not automatically the same contract as a packaged AccountInvite model merely because the records have similar meaning. If the physical schema differs:

1. omit that package artifact from the database target's explicit artifact allowlist;
2. implement the package persistence interface in the application composition root; and
3. translate identifiers, reads, writes, coexistence, and migration behavior there.

That application-owned adapter may support rolling reads, shadow writes, or record migration. The CLI deliberately does not invent those semantics or claim that the packaged Prisma adapter can operate against a different schema.

Keep migrations application-owned

After a compatible sync or a reviewed schema change, use Prisma, Drizzle Kit, or the repository's chosen migration tooling. Playstack does not generate migration histories, run schema push, introspect a live database, or apply migrations.