The Prisma Schema File

Objectives

By the end of this lesson, you should be able to:

• Explain the purpose of the generator and datasource blocks
• Read a basic model block, and map it back to a SQL table
• Explain where models fit into the overall Prisma workflow

💡 Why this matters: schema.prisma is the single source of truth for a Prisma project, every model, every migration (Module 4), and the generated client (this module) all come from this one file.

⚠️ A note on verification: as in the last lesson, the Prisma CLI can’t run inside this course’s own sandboxed tooling (no route to its engine download). The schema syntax below is Prisma’s stable, current, documented syntax, unchanged across recent versions. Try it against your own database, following the setup from the last lesson.

The Three Parts of a Schema File

// prisma/schema.prisma
generator client {
  provider = "prisma-client-js"
}

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

model Student {
  id    Int    @id @default(autoincrement())
  name  String
  grade Int
}

The generator Block

generator client {
  provider = "prisma-client-js"
}

This tells Prisma what to generate from the schema, prisma-client-js produces the JavaScript/TypeScript client this course imports and calls starting in Module 4. Running npx prisma generate regenerates it any time the schema changes.

The datasource Block

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

provider names the database (postgresql throughout this course). url = env("DATABASE_URL") reads the connection string from .env, exactly the pattern from Module 1, Lesson 5, credentials never hard-coded directly into the schema file.

A model Block

model Student {
  id    Int    @id @default(autoincrement())
  name  String
  grade Int
}

Each model maps to one database table. Reading it field by field:

• id Int @id @default(autoincrement()), an integer primary key (@id) that auto-increments, the Prisma equivalent of SERIAL PRIMARY KEY from Module 1.
• name String, a required text field (Prisma’s String maps to PostgreSQL’s TEXT).
• grade Int, a required integer field.

This one model is equivalent to the students table created by hand in Module 1:

CREATE TABLE students (
  id SERIAL PRIMARY KEY,
  name TEXT NOT NULL,
  grade INTEGER NOT NULL
);

Model names are singular and PascalCase by convention (Student, not students), Prisma maps the model to a lowercase, pluralized table name (students) by default when a migration creates it, covered in the next module.

Try It

1. In your own schema.prisma, add a Student model matching the one above.
2. Add a second model, Book, with id, title (String), and available (Boolean) fields.
3. For each field in your Book model, write out, in words, what SQL column and type it corresponds to.
4. Explain what @id and @default(autoincrement()) each do, separately.

Recap

• schema.prisma has three parts: generator (what to generate), datasource (which database), and one or more model blocks (the tables).
• Each model maps to a table, each field maps to a column, with a type and optional attributes like @id and @default(...).
• Nothing has touched the actual database yet, the next lesson turns this schema into real tables with a migration.

Next lesson: Prisma Client, the generated library this schema produces.