Prisma Schema Design & Migration Strategy

What this prompt does

This prompt asks the AI to design a complete Prisma schema for a [app_type] built around your [entities], then plan how to evolve it safely in production. It produces model definitions with fields, types, and constraints; 1:1, 1:N, and M:N relations with explicit join tables where needed; composite indexes tuned for your [query_patterns]; enums for [enum_fields]; a soft-delete pattern; audit-trail fields with middleware; full-text search config; multi-tenant isolation via [tenant_strategy]; a seed script sized to [seed_count]; and a zero-downtime plan for a [risky_migration].

The structure works because the schema is the most expensive part of a SaaS to get wrong, and this prompt forces the decisions that are painful to reverse — relations, indexes, and tenancy — to be made up front. Tying indexes to your real [query_patterns] keeps them purposeful rather than guessed, and asking for a zero-downtime path for [risky_migration] means a risky column change is rehearsed before it touches live traffic instead of discovered during an outage. The soft-delete and audit-trail requirements also bake consistency into every model, so you are not retrofitting deletedAt columns and createdBy tracking later once data has accumulated.

When to use it

• You are starting a new SaaS and want the data model reasoned through before writing application code.
• You need multi-tenant isolation and want it baked into the schema rather than bolted on later.
• Your queries are slow and you suspect missing or wrong composite indexes for your [query_patterns].
• You are about to run a risky migration (renaming or dropping a column in use) and want a safe sequence.
• You want consistent soft-delete and audit-trail behavior across every model.
• You need realistic seed data to develop and demo against.

Example output

Expect a complete schema.prisma file with your models, relations, enums, and indexes, plus a seed script and the migration commands to run. The zero-downtime section reads as an ordered, multi-step plan (expand, backfill, switch reads, contract) for the [risky_migration], with the reasoning for each step rather than a single destructive migration. You also get the middleware code that populates audit fields and a soft-delete query filter, so the patterns are wired in rather than left as a description.

Pro tips

• List [entities] in dependency order and name the relationships you expect, so the AI maps join tables and cascades correctly.
• Make [query_patterns] specific (for example, tasks by project and status) — that is what drives the composite-index choices.
• Choose [tenant_strategy] deliberately; row-level isolation with an organizationId differs a lot from a database-per-tenant approach in the generated code.
• Set [enum_fields] only for values that are genuinely closed sets, since enums are harder to change later than a lookup table.
• Describe [risky_migration] precisely so the zero-downtime plan addresses your actual change, not a generic example.
• Keep [seed_count] modest while iterating; large seeds slow the feedback loop during schema development.