Database mapping

Map collection / table names

As an example, when you introspect a database with a table named comments, the resulting Prisma model will look like this:

model comments {
  // Fields
}

However, you can still choose Comment as the name of the model (e.g. to follow the naming convention) without renaming the underlying comments table in the database by using the @@map attribute:

model Comment {
  // Fields

  @@map("comments")
}

With this modified model definition, Prisma automatically maps the Comment model to the comments table in the underlying database.

Map field / column names

You can also @map a column/field name:

model Comment {
  content String @map("comment_text")
  email   String @map("commenter_email")
  type    Enum   @map("comment_type")

  @@map("comments")
}

This way the comment_text column is not available under prisma.comment.comment_text in the Prisma Client API, but can be accessed via prisma.comment.content.

Map enum names and values

You can also @map an enum value, or @@map an enum:

enum Type {
  Blog,
  Twitter @map("comment_twitter")

  @@map("comment_source_enum")
}

Use cases for named constraints

Some use cases for explicitly named constraints include:

• Company policy
• Conventions of other tools

Using default constraint names

When no explicit names are provided via map arguments Prisma will assume they follow the default naming convention.

If you introspect a database the names for indexes and constraints will be added to your schema unless they follow Prisma's naming convention. If they do, the names are not rendered to keep the schema more readable. When you migrate such a schema Prisma will infer the default names and persist them in the database.

model User {
  id    Int    @id @default(autoincrement())
  name  String @unique
  posts Post[]
}

model Post {
  id         Int    @id @default(autoincrement())
  title      String
  authorName String @default("Anonymous")
  author     User?  @relation(fields: [authorName], references: [name])

  @@index([title, authorName])
}

Prisma's default naming conventions for indexes and constraints

If you introspect a database the names for indexes and constraints will be added to your schema unless they follow Prisma's naming convention. If they do, the names are not rendered to keep the schema more readable. When you migrate such a schema Prisma will infer the default names and persist them in the database.

We chose our naming convention to align with PostgreSQL since it is deterministic and helps us maximize the amount of times where we do not need to render names because they already align with the convention.

Using custom constraint / index names

You can use the map argument to define custom constraint and index names in the underlying database.

model User {
  id    Int    @id(map: "Custom_Primary_Key_Constraint_Name") @default(autoincrement())
  name  String @unique
  posts Post[]
}

model Post {
  id         Int    @id @default(autoincrement())
  title      String
  authorName String @default("Anonymous")
  author     User?  @relation(fields: [authorName], references: [name])

  @@index([title, authorName], map: "My_Custom_Index_Name")
}

Related: Naming indexes and primary keys for Prisma Client

Additionally to map, the @@id and @@unique attributes take an optional name argument that allows you to customize your Prisma Client API.

On a model like:

model User {
  firstName String
  lastName  String

  @@id([firstName, lastName])
}

the default API for selecting on that primary key uses a generated combination of the fields:

const user = await prisma.user.findUnique({
  where: {
    firstName_lastName: {
      firstName: 'Paul',
      lastName: 'Panther',
    },
  },
})

Specifying @@id([firstName, lastName], name: "fullName") will change the Prisma Client API to this instead:

const user = await prisma.user.findUnique({
  where: {
    fullName: {
      firstName: 'Paul',
      lastName: 'Panther',
    },
  },
})