---
title: "Existing schema adoption"
description: "Compare Playstack Prisma artifacts with a mature application schema and choose explicit managed or application-owned persistence."
tags: ["cli","database","prisma","compatibility","migration","existing-schema"]
---

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

```sh
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:

```json
{
  "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.