Prisma Optional Fields to SQL Nullable Columns

Optional (Nullable) Field Conversion

In Prisma, a ? suffix on a type makes the field optional (nullable). This is the inverse of SQL's default, where columns are nullable unless NOT NULL is specified.

Example Prisma Schema

model Employee {
  id         Int      @id @default(autoincrement())
  firstName  String   @map("first_name")
  lastName   String   @map("last_name")
  middleName String?  @map("middle_name")
  email      String   @unique
  phone      String?
  bio        String?
  hireDate   DateTime @map("hire_date")
  termDate   DateTime? @map("term_date")

  @@map("employees")
}

Generated SQL

CREATE TABLE employees (
  id SERIAL PRIMARY KEY,
  first_name VARCHAR(255) NOT NULL,
  last_name VARCHAR(255) NOT NULL,
  middle_name VARCHAR(255),
  email VARCHAR(255) NOT NULL UNIQUE,
  phone VARCHAR(255),
  bio VARCHAR(255),
  hire_date TIMESTAMP NOT NULL,
  term_date TIMESTAMP
);

Mapping Rules

Prisma	SQL
String (required)	VARCHAR(255) NOT NULL
String? (optional)	VARCHAR(255) (nullable)
Int (required)	INTEGER NOT NULL
Int? (optional)	INTEGER (nullable)

Why the Difference Matters

• Prisma default: Fields are required (non-nullable). You must explicitly opt in to nullability with ?.
• SQL default: Columns are nullable. You must explicitly add NOT NULL to make them required.

The converter correctly translates between these two conventions, adding NOT NULL for required Prisma fields and omitting it for optional fields.

Optional Fields with Defaults

You can combine optionality with defaults. For example, status String? @default("active") generates a nullable column with a default value: status VARCHAR(255) DEFAULT 'active'. This means new rows get "active" by default, but the column can still be explicitly set to NULL.