Support for splitting Prisma schema into multiple files

Problem
Prisma currently only supports one single Prisma Schema file. Developers want more flexibility for managing their Prisma Schema files.
Motivations:

breaking up large schema files to make them more manageable
flexible integration with certain architectures, i.e. each module has its own self-contained logic including its schema

Solution
Support importing additional schema files, i.e. import "user.schema", import models/*.prisma or import modules/**/*.prisma.
Alternatives
Not researched at this time.
Additional context
https://github.com/prisma/prisma/issues/92

Like prisma one ... there was a feature like this implemented.

Appreciate prioritisation of this. It is really painful to write all the schema in one file.

badly need this feature. currently I have to cat a.prisma b.prisma > schema.prisma. it works but is so clumsy.

Any update on this?

Any update on this? 🚀

Any movement on this? Really looking for this solution.

It's a dealbreaker for me...

Urgent need

need this badly

until this is part of the prisma cli, we extracted a small script which we use internally into this tiny cli prisma-merge. its nothing fancy but works for us currently. feel free to use it or copy the source and tailor it to your needs.

Ideally, I'd like my models to live near their/in modules in Nest.

Ideally, I'd like my models to live near their/in modules in Nest.

Would be a nice feature. A single file is not maintainable.

Would be a nice feature. A single file is not maintainable.

Seriously, this ORM does not have something as important and essential as the file division?
When I took the quick start guide I loved the ORM, but I know that everything good has its flaw, but this is more of a flaw, I hope they do something about it, it's not good you have thousands and thousands of lines of code in a same file just to define schema

Seriously, this ORM does not have something as important and essential as the file division?
When I took the quick start guide I loved the ORM, but I know that everything good has its flaw, but this is more of a flaw, I hope they do something about it, it's not good you have thousands and thousands of lines of code in a same file just to define schema

Please, don't be so hostile.
I would love to see this feature as well coming to Prisma 2. There is a workaround (we used in some projects) which might help:
cat *.part.prisma > schema.prisma
yarn prisma generate

Please, don't be so hostile.
I would love to see this feature as well coming to Prisma 2. There is a workaround (we used in some projects) which might help:
cat *.part.prisma > schema.prisma
yarn prisma generate

I think this is a "basic" feature for any project. Many months passed now, and there is no update on this.
I can't believe Iit is so hard to make a modular schema file and that would actually take almost a year and no progress on this basic matter

I agree that this is really needed, but npx prisma-merge provides a great workaround.
Thank you guys and looking foward to this implementation :)

Good workarounds exist and have been proposed, but one basic modular use case that is holding me back is this one:
Module A:
type Story {
  id: ID!
}

Module B:
type Product {
  id: ID!
  relatedStories: [Story!]!
}

extend type Story {
  relatedProducts: [Product!]!
}

This wasn't possible in Prisma 1 either, but it would be amazing if the Prisma devs could make that happen.

Good workarounds exist and have been proposed, but one basic modular use case that is holding me back is this one:
Module A:

type Story {

  id: ID!

}

Module B:

type Product {

  id: ID!

  relatedStories: [Story!]!

}

extend type Story {

  relatedProducts: [Product!]!

}

This wasn't possible in Prisma 1 either, but it would be amazing if the Prisma devs could make that happen.

This would be very very awesome 👏 👏👏

+1

Good workarounds exist and have been proposed, but one basic modular use case that is holding me back is this one:
Module A:
type Story {
  id: ID!
}

Module B:
type Product {
  id: ID!
  relatedStories: [Story!]!
}

extend type Story {
  relatedProducts: [Product!]!
}

This wasn't possible in Prisma 1 either, but it would be amazing if the Prisma devs could make that happen.

Here's the open issue #1291 for that.

As this feature sadly didn't make it in milestone 2.18.0, 2.19.0 and 2.20.0, I've came up with a simple solution by using a script.
There is a little hack to keep the linters happy by simply adding the relations below the // GENERATE-PRISMA-SCHEMA-DELETE // line.

scripts/generate-prisma-schema.ts
// Generates a single prisma schema, as the current prisma version doesnt support multiple schemas.
// https://github.com/prisma/prisma/issues/2377
import fs from 'fs';
import glob from 'glob';
import path from 'path';

const schemas = glob.sync(path.join(__dirname, '../src/modules/**/*.prisma'));

const schema = schemas.reduce((currentSchema, filename) => {
  const partialSchama = fs.readFileSync(filename).toString();
  const cleanSchema = partialSchama.split('// GENERATE-PRISMA-SCHEMA-DELETE //')[0];
  return `${currentSchema}\n// ${filename}\n${cleanSchema}`;
}, '');

fs.writeFileSync(path.join(__dirname, '../src/generated/schema.prisma'), schema);

src/modules/users/database/schema.prisma
model User {
  id Int @default(autoincrement()) @id
  uuid String @default(uuid()) @unique @map(name: "uuid")
  firstName String @map(name: "first_name")
  lastName String @map(name: "last_name")
  email String @unique @map(name: "email")
  password String @map(name: "password")
  createdAt DateTime @default(now()) @map(name: "created_at")
  updatedAt DateTime @updatedAt @map(name: "updated_at")

  posts Post[]
  postComments PostComment[]

  @@map(name: "users")
}

// GENERATE-PRISMA-SCHEMA-DELETE //
model Post {
  id Int @default(autoincrement()) @id
  userId Int
  user User @relation(fields: userId, references: id)
}

model PostComment {
  id Int @default(autoincrement()) @id
  userId Int
  user User @relation(fields: userId, references: id)
}

src/modules/posts/database/schema.prisma
model Post {
  id Int @default(autoincrement()) @id
  uuid String @default(uuid())
  userId Int @map(name: "user_id")

  user User @relation(fields: userId, references: id)
  postComments PostComment[]

  @@map(name: "posts")
}

model PostComment {
  id Int @default(autoincrement()) @id
  uuid String @default(uuid())
  postId Int @map(name: "post_id")
  userId Int @map(name: "user_id")
  comment String @map(name: "comment")

  post Post @relation(fields: postId, references: id)
  user User @relation(fields: userId, references: id)

  @@map(name: "post__comments")
}

// GENERATE-PRISMA-SCHEMA-DELETE //
model User {
  id Int @id
  posts Post[]
  postComments PostComment[]
}

src/generate/schema.prisma
// /Users/kevin/github/prisma-multischema-demo/packages/server/src/modules/posts/database/schema.prisma
model Post {
  id Int @default(autoincrement()) @id
  uuid String @default(uuid())
  userId Int @map(name: "user_id")

  user User @relation(fields: userId, references: id)
  postComments PostComment[]

  @@map(name: "posts")
}

model PostComment {
  id Int @default(autoincrement()) @id
  uuid String @default(uuid())
  postId Int @map(name: "post_id")
  userId Int @map(name: "user_id")
  comment String @map(name: "comment")

  post Post @relation(fields: postId, references: id)
  user User @relation(fields: userId, references: id)

  @@map(name: "post__comments")
}

// /Users/kevin/github/prisma-multischema-demo/packages/server/src/modules/users/database/schema.prisma
model User {
  id Int @default(autoincrement()) @id
  uuid String @default(uuid()) @unique @map(name: "uuid")
  firstName String @map(name: "first_name")
  lastName String @map(name: "last_name")
  email String @unique @map(name: "email")
  password String @map(name: "password")
  createdAt DateTime @default(now()) @map(name: "created_at")
  updatedAt DateTime @updatedAt @map(name: "updated_at")

  posts Post[]
  postComments PostComment[]

  @@map(name: "users")
}

I must say that the more I dig into Prisma the faster its initial appeal diminishes, I keep on searching the documentation for almost basic things like this or multiple schema support just to discover GitHub issue tickets for feature requests. I presume that's the charm of being an early adopter, but how is MongoDB support in the works when support for SQL databases lacks so many key features?
I don't mean any of the above in a hostile way, I'm just bummed out as I'm spending more time fighting with the ORM than using the ORM and ultimately I'm ending up with lots of raw SQL and python scripts doing the lifting an ORM should've done... and there goes the "build faster" and "make fewer errors" that Prisma promised.

Limited resources, and tradeoffs, as you can imagine @kpdud. But this is being looked into right now (see the milestone assignment), and there is no question a solution will be implemented. We feel this pain ourselves regularly and want to get rid of it.

Hey folks, we came up with some ideas on how to solve this and would love your feedback.
Do you have any preferences? Would you solve this in a different way?
Feel free to reply in this thread. I'm also happy to jump on a quick call to discuss your ideas and answer any questions you might have.

Problem
Prisma currently only supports one single Prisma Schema file. Developers want more flexibility for managing their Prisma Schema files.
Why?
Breaking up large schema files to make them more manageable and easier to understand.
Current Workarounds

Write a script like: cat *.prisma > schema.prisma or similar
Use a tool from our community like https://github.com/smcelhinney/prisma-merge-schema

While these do solve the problem, it seems fairly obvious that we should support this feature natively.
Design Goals

You can combine multiple schema files across directories in your project together.
IDE integration should be able to validation relationships and jump-to-definition should work across multi-file schemas

Ideas
1. Extend the schema parser to support import "<path>"
Imports are essentially placeholders for sub-schemas. The imports get resolved into one big concatenated schema.
Given the following directory structure:
├─ schema.prisma
└─ models
    ├─ post.prisma
    └─ user.prisma

schema.prisma
import "./models/post.prisma"

datasource pg {
  provider = "postgres"
  url = env("DATABASE_URL")
}

import "./models/user.prisma"

enum Visibility {
  Draft
  Live
}

models/post.prisma

model Post {
  id Int @id
  title String @pg.Varchar(200)
}

models/user.prisma
model User {
  id Int @id
}

The resolved schema would look like this:
model Post {
  id Int @id
  title String @pg.Varchar(200)
}

datasource pg {
  provider = "postgres"
  url = env("DATABASE_URL")
}

model User {
  id Int @id
}

enum Visibility {
  Draft
  Live
}

2. Add a New schema Block
This is similar to Idea 1. but allows us to not need to extend the parser. We'd add a new block instead. Something like.
schema {
  import = [
    "./models/post.prisma",
    "./models/*.prisma"
  ]
}

provider pg {
  provider = "postgres"
  url = env("DATABASE_URL")
}

enum Visibility {
  Draft
  Live
}

3. Glob *.prisma files inside a directory
Instead of introducing imports, we could glob all the files within a directory together. Maybe this directory is the prisma directory or maybe just the project root. This works because order doesn't matter in PSL.
├─ schema.prisma
└─ models
    ├─ post.prisma
    └─ user.prisma

We would need to have hueristics to avoid searching all of node_modules, .git, etc.
4. Introduce an import keyword
Introduce an import { block... } from "<path>" into the Prisma Schema language.
schema.prisma
import { Post, pg, Visibility } from "./post.prisma"
import { User } from "./user/user.prisma"
import { Tag } from "/tmp/tag.prisma"

model Comment {
  id   Int @id @pg.VarChar(10)
  user User
  visibility Visibility @default(Visibility.Draft)
}

post.prisma
import { Tag } from "/tmp/tag.prisma"

datasource pg {
  provider = "postgres"
  url = env("DATABASE_URL")
}

model Post {
  id Int @id
  title String @pg.Varchar(200)
}

enum Visibility {
  Draft
  Live
}

tag.prisma
model Tag {
  id Int @id
}

user.prisma
model User {
  id Int @id
}

Personally Idea 2 is my favourite as I was initially looking for something like that.
I am unsure about Idea 3 as currently if we wish to have multiple data sources we must create X number of prisma schema files with their own data source blocks, generator blocks, schemas etc. If all .prisma files were to be stitched into one, it would prevent us from using multiple data sources... therefore I believe it's better to give developers control over what prisma files are to be stitched into a single schema.

I currently don't have a large project where I would need multiple schema files. So I currently don't have a preference for one idea over another, I want to leave this decision to people who regularly work with it and have a better feeling which would be the best option for Prisma schema files.
But if you go for any solution with import (e.g. 1, 2, 4) I would like to throw in the idea to add a possibility to define paths relative to project root (like tsconfig paths). For node projects this would be the directory with the package.json / node_modules. I don't know if something like this would also be possible for the Go client? cc @steebchen
Given a project structure similiar to
├── node_modules
├── package.json
├── prisma
│   └── schema.prisma
└── src
    ├── auth
    │   └── models
    │       └── user.prisma
    ├── cms
    │   └── models
    │       ├── comment.prisma
    │       └── post.prisma
    └── common
        └── models
            └── visibility.prisma

you would be able to write something like this in any .prisma file:
import { Visibility } from "~src/common/models/visibility.prisma"

instead of
import { Visibility } from "../../common/models/visibility.prisma"

This also makes moving schema files to another directory depth much easier as you can adjust the path with a global search-replace.
Maybe the root path could also be made configurable in schema.prisma or package.json.

I think Idea 3 is the best solution, as this is how common technologies such as GraphQL and Terraform (in some way at least) work. It is extremely simple it just stitches everything together and doesn't need to deal with common import problems such as parsing, cyclic imports, import paths, and so on. It also doesn't need any config which makes it even more beginner-friendly.

So happy progress is being made on this front! One thing I'd like to call out is the importance of the VSCode prisma extension for linting and autocomplete. As a new user to prisma I found that extension to be incredibly helpful, and even now that I'm comfortable with the syntax it still offers a nice productivity boost. I'd want to make sure that regardless of the chosen solution, the prisma extension would continue to offer the same level of integration.

I think Idea 3 is the best solution, as this is how common technologies such as GraphQL and Terraform (in some way at least) work. It is extremely simple it just stitches everything together and doesn't need to deal with common import problems such as parsing, cyclic imports, import paths, and so on. It also doesn't need any config which makes it even more beginner-friendly.

As @steebchen said, to me Idea 3 is better. I agree that sometimes the developer will want to use lots of subfoders, so, like in Go, Prisma could use as default the schema.prisma's root folder (which will be the root "module"), and in case of import from subdirectories, the schame.prisma file should be updated with Idea 2.
I know, this seem a little complicated, but for a beginner, the use of Idea 3 makes everything easier, and for most advanced users, the merge of Ideas 2 & 3 can give more freedom in a architecture way

we have a project where we need to work with 2 databases. so we have 2 generated prisma clients with respective models. I think Idea 3 would not be flexible enough to support this. Where with Idea 2 you could basically achieve the same just with a <project_root>/**/*.prisma glob (which could be the default /recommended setting for the schema block). I know its quite an edge case to have multiple prisma clients / db's, but nonetheless i would appreciate if it would support that.
Or maybe just use Idea 3 if there is no schema block, if there is one, use idea 2. Either that or only Idea 2 would be my vote.
Thanks for moving this forward!

Thanks for the feedback!
@cudba what's your file structure look like right now for the two clients? Is it:
.
├── mysql
│   ├── models
│   │   ├── post.prisma
│   │   └── user.prisma
│   └── schema.prisma
└── postgres
    ├── models
    │   ├── post.prisma
    │   └── user.prisma
    └── schema.prisma

?
If so, I think 3. would still work if we scope the search to the root schemas:mysql/schema.prisma and postgres/schema.prisma.
So if you run npx prisma --schema=./postgres/schema.prisma it only searchs in postgres/ and it's children.

Hi, we got a use case in our company that the prisma schema could be store inside node module register in our main package.json that we want to extend it into our main prisma.schema file. I am not sure about the Idea 2 to be able to resolve this use case but the keyword import should be ok to extend schema from node_modules via import.

@matthewmueller yea we have basically this file structure. so you're right, this should work
we have no shared models between the 2 clients, but assume that it could be an edge case someone would not be angry to see supported ;)

I think Idea 3 is the best solution, as this is how common technologies such as GraphQL and Terraform (in some way at least) work. It is extremely simple it just stitches everything together and doesn't need to deal with common import problems such as parsing, cyclic imports, import paths, and so on. It also doesn't need any config which makes it even more beginner-friendly.

As @steebchen said, to me Idea 3 is better. I agree that sometimes the developer will want to use lots of subfoders, so, like in Go, Prisma could use as default the schema.prisma's root folder (which will be the root "module"), and in case of import from subdirectories, the schame.prisma file should be updated with Idea 2.
I know, this seem a little complicated, but for a beginner, the use of Idea 3 makes everything easier, and for most advanced users, the merge of Ideas 2 & 3 can give more freedom in a architecture way

A mix of Idea 2 and Idea 3 also sounds like a good solution to me but if I had to choose I'd prefer Idea 2. Especially when working with nexus and nexus-prisma it would make sense to me to co-locate the schema files with the nexus types, resolvers and so on in one folder. I assume that especially in bigger projects this would make life easier.

@matthewmueller  Glad to see that finally the team is making some progress on this long awaited issue. Will this finally be part of 2.22.0 release ? If yes, what is the expected timeline for the rollout of this feature ?

Can't wait for this!

How would each solution behave whenever facing clashing model names?
I suspect we would simply reject at parsing time saying there's a duplicate model?
When looking at simply breaking up a schema into multiple parts that you own, there shouldn't be any specific problem, but whenever considering importing schemas from modules you don't own, you can find yourself in a situation where you'd be required to rename a model to make the composition work.
This calls for ensuring that the solution we go for offers a path forward to resolve clashing model names (e.g. applying a prefix to imported model names, or aliasing models etc.)

Would reusing typescript import { x as y } from '' syntax be useful?

How would each solution behave whenever facing clashing model names?
I suspect we would simply reject at parsing time saying there's a duplicate model?
When looking at simply breaking up a schema into multiple parts that you own, there shouldn't be any specific problem, but whenever considering importing schemas from modules you don't own, you can find yourself in a situation where you'd be required to rename a model to make the composition work.
This calls for ensuring that the solution we go for offers a path forward to resolve clashing model names (e.g. applying a prefix to imported model names, or aliasing models etc.)

If suppose the default behavior should be that models with the same name will be merged. If some field names are also the same there should be a simple rule which field definition wins (normally project definition should win over definitions from node_modules).
Renaming or prefixing a model can lead to failures with relations. E.g. if there is a model with a relation to User and we have two other files with User models (one renamed to User2), how can we determine which is the right User model for the relation?
A possible solution could be an extension of idea 2, to allow also an object syntax for the import:
schema {
  import = [
    {
       path: "./models/post.prisma",
       rename: [{"User": "User2"}, {"Post": "prefixPost"}]
    },
    {
      path: "npmPackage/models/*.prisma",
      rename: [{"User": "User2"}, {"Post": "PostWithSuffix"}]
    },
    "./models/*.prisma",
<EMAIL_ADDRESS>  ]
}

provider pg {
  provider = "postgres"
  url = env("DATABASE_URL")
}

enum Visibility {
  Draft
  Live
}

This way all model names and relations inside an import entry will use the renamed model name for all schema files in the given path (maybe there a better names for "path" and "rename").

Yep, that's an interesting consideration overall.

Renaming or prefixing a model can lead to failures with relations. E.g. if there is a model with a relation to User and we have two other files with User models (one renamed to User2), how can we determine which is the right User model for the relation?

I assume relations could also be adapted according to a renamed that's expressed. I suppose this would mean for the data model parsing to be scoped at file level first, so a certain behavior could be applied (e.g. renaming a model along with update matching relations, or merging).
I could also see how merging models could lead to other kinds of unexpected results (mismatching primary keys leading to broken migrations at best).
By default, I'd reject to leave the option for users to choose what to do about it.
I personally like the short notation coming with Idea 1, as the additional schema block feels slightly more bloated to me, but that's more of a personal taste and I'd leave the group see what works best.

I personally like the short notation coming with Idea 1, as the additional schema block feels slightly more bloated to me, but that's more of a personal taste and I'd leave the group see what works best.

What about placeholders? Would something like this be possible in idea 1?
import  "./models/*.prisma"
import<EMAIL_ADDRESS>
import "./models/post.prisma"

datasource pg {
  provider = "postgres"
  url = env("DATABASE_URL")
}

import "./models/user.prisma"

enum Visibility {
  Draft
  Live
}

Up to the team to say, but I would consider that doable and desirable

Hi, with splitting the schema can we also extend it as ncirkle proposed here ? if not, did anyone open a request for it ?
Module A:

type Story {
  id: ID!
}

Module B:

type Product {
  id: ID!
  relatedStories: [Story!]!
}

extend type Story {
  relatedProducts: [Product!]!
}

Please always go for the most simple solution. Idea 1 or 3 please.

Number 3 seems really clean and easy. Would prefer that and then either 1 or 4.

First of all, I really like that this is happening!! I have been waiting for this for a long time, and gave it quite some thought!
Schema locations
For my apps, I would love it if it would work like this:
libs/comment/src/comment-schema.prisma
libs/post/src/post-schema.prisma
libs/user/src/user-schema..prisma

So basically solution 3, but for multiple folders, or simply the libs folder but it would do a 'deep' search.
From a configuration point, I think it makes sense to support something like this, that would take an array of paths, either to a file (where it would read that file specifically) or a folder where it would recurse down the whole folder.
In this example it would traverse libs for any files that have the .prisma extension, and add the single file prisma/schema.prisma.
 "prisma": {
    "schemas": ["libs", "prisma/schema.prisma"]
  }

Schema merging
Another thing that would be essential for this to work on large scale apps (hundreds of models) is that the models will be merged together.
So my User can be created here:
# libs/user/src/user-schema..prisma
model User {
  id           String     @id @default(cuid())
  createdAt    DateTime   @default(now())
  updatedAt    DateTime   @default(now()) @updatedAt
  role         Role
  username     String     @unique
  password     String?
}

enum Role {
  Admin
  User
}

The Post model can augment the user model with the relation like so:
# libs/post/src/post-schema..prisma
model Post {
  id           String     @id @default(cuid())
  createdAt    DateTime   @default(now())
  updatedAt    DateTime   @default(now()) @updatedAt
  status       PostStatus
  slug         String     @unique
  title        String
  content      String
  author       User       @relation(name: "Post_belongsTo_Author", fields: [author], references: [id])
  authorId     String

}

enum PostStatus {
  Draft
  Published
}

model User {
  post Posts[] @relation(name: "Post_belongsTo_Author")
}

And a more advanced example of the above, where Comment extends both Post and User by relating to them.
# libs/comment/src/comment-schema..prisma
model Comment {
  id           String     @id @default(cuid())
  createdAt    DateTime   @default(now())
  updatedAt    DateTime   @default(now()) @updatedAt
  content      String
  post         User       @relation(name: "Post_hasMany_Comment", fields: [postId], references: [id])
  postId       String
  author       User       @relation(name: "Post_belongsTo_Author", fields: [authorId], references: [id])
  authorId     String
}

model Post {
  comment Comments[] @relation(name: "Post_hasMany_Comment")
}
model User {
  post Posts[] @relation(name: "Post_belongsTo_Author")
}

Having this would allow us to extend the schema by changing things at one place, allowing for huge scalability. I also thing that prisma format and other related scripts should throw an ERROR if you try to do something illegal like re-defining an existing relation.

Personally I think idea 3 would introduce more problems in a large project than it would solve.
If we ever want things like being able to implement things like multi-schema databases and segmenting into multiple user/credential perspectives on a single subset of model objects, then things need to be at least a little bit explicit in what models are included.
Since Prisma files do rely more on a global scope than typescript does, perhaps a middle-ground would make sense.
e.g.
Idea 3.5 ) Glob imports
Have sort of the best of both worlds and let people do idea 3 by just doing a glob import at the root for everything in the folder of their choice, but that still technically makes it explicit, so additional usage cases can make use of more precise imports while not requiring much more work for those that don't need it.
schema.prisma
import * from "./*.prisma"

model Comment {
  id   Int @id @pg.VarChar(10)
  user User
  visibility Visibility @default(Visibility.Draft)
}

post.prisma
import { Tag } from "/tmp/tag.prisma"

datasource pg {
  provider = "postgres"
  url = env("DATABASE_URL")
}

model Post {
  id Int @id
  title String @pg.Varchar(200)
}

enum Visibility {
  Draft
  Live
}

tag.prisma
model Tag {
  id Int @id
}

user.prisma
model User {
  id Int @id
}

That'd be really nice to have @josh-hemphill  +1 for your idea

Still waiting for that to be released

Yeah, same :(

Any Updates on this?

Any Updates on this?

From the roadmap (here)[https://www.notion.so/Prisma-Roadmap-50766227b779464ab98899accb98295f], it looks like its on the slab but not quite being worked on yet

I have seen GitHub Issues, StackOverflow questions, and forum posts like this one that was talking about this concept from 2 years ago @dominichadfield. ... I don't know I may stop using Prisma if this feature remains unimplemented for any longer...

@MichaelGrigoryan25

What I'm saying is that there are some essential features that are crucial to have on a regular basis.

The thing is, that there are many essential features and setting up priorities for them isn't easy. For example cascading deletes also is an essential feature which just got implemented and was released yesterday. So are JSON filtering, more native database types support, aggregate and groupBy, ... to just name a few which all have been implemented in the last 3 months. It's not like the prisma team is hanging around doing nothing.
And if you would have read this issue you would know that there is already an ongoing request for feedback on how the schema-splitting should be implemented, which of course must be defined first.
See: https://github.com/prisma/prisma/issues/2377#issuecomment-821203725
So if you have valuable feedback or own ideas of how this should be implemented feel free to post them!

Also you can find workarounds in this issue you can use until this feature is implemented.

https://github.com/prisma/prisma/issues/2377#issuecomment-767404421
https://github.com/prisma/prisma/issues/2377#issuecomment-735591530
https://github.com/prisma/prisma/issues/2377#issuecomment-810536806

Understandable, thanks for elaborating.
My suggestion is somewhat similar to others'. Maybe a get {} from "path" syntax? Looks nice IMO.
Here's an example:
schema.prisma
get { Foo } from "/path/foo.prisma"

datasource pg {
  provider = "postgres"
  url = env("DATABASE_URL")
}

model Something {
    id   String @id
    foo Foo
    bar Bar
}

foo.prisma
get { Something } from "/path/schema.prisma"

model Foo {
    id          String      @id
    something   Something
}

And I think all schemas should be available globally without exporting.

Thanks for the feedback.
Believe me, we know how bad a lot of people want this, and we want it too!
The reality is that this feature comes with a lot of complexity to make right.
Here are considerations we are discussing:

What happens if you introspect a database schema that's split across multiple files? Do we have a "main" file where we put models which don't exist yet and update other files where models were pre-existing?
Related: do we need to distinguish included files from main entry-point ones to that end or not?
How does the VSCode plugin cope with distributed files when it comes to managing autocompletion of relations?
How does that affect generators other people have built on top of the PSL?
...and that list goes on

The ramifications of such a change are far from trivial so we want to be careful with both providing a great experience while not getting into a massive initiative alongside other large undertakings such as the MongoDB connector.
All your feedback is immensely valuable though and helps us ensure we'll nail a design that can suit most people's needs.
We'll keep people updated, but I want to be clear that you shouldn't expect that to land before another 3 to 6 months minimum given our current capacity.
Thanks for your understanding.

cat command did the tricky for me.

just run cat src/prisma/docs.prisma src/prisma/schema.prisma > src/prisma/schema.prisma.new && mv src/prisma/schema.prisma.new src/prisma/schema.prisma before prisma generate command.

Hi! i just finished my schematic with prisma, it has 1320 lines and generates 63 models, i don't know if it's a problem with Prisma or vs-code, but it doesn't autocomplete the code anymore, it keeps thinking all the time. what is the limitation of Prisma regarding the number of models it can handle? thank you very much!

@KOD3X That sounds like a bug report or discussion - please report this separately. We can't have a discussion about this here with 43 other participants in the GitHub issue (each comment will send notifications to all of them). Thanks.

I have a solution...
I came across this thread earlier today while researching if I could split up my Prisma schema for a monorepo setup, in my case I have a bunch of libs that act as building blocks for a server, each lib will need its own data schema.
Obviously the biggest issue here that is not solved by prisma-merge is data relations between files, so I wrote a little tool called "Prismix" to merge schemas automatically with support for model relations across files.
yarn add prismix --dev
Hopefully this helps some of you guys while we wait for Prisma to include this functionality.
https://github.com/jamiepine/prismix

One motivation not mentioned in the roadmap is that libraries could ship schemas that could be imported.
i sketched the idea here: https://github.com/prisma/prisma/issues/2977
Maybe that would additionally require that prisma schema supports interfaces and/or extending models.

prismix

I use your solution but I am getting the error Prismix: mixing your schemas - Type "Post" is neither a built-in type, nor refers to another model, custom type, or enum.... 🍹. Which directory do you place the prismix.config.json file

I use your solution but I am getting the error Prismix: mixing your schemas - Type "Post" is neither a built-in type, nor refers to another model, custom type, or enum.... 🍹.

This happens when you forget to include an "alias model" in your extended schema, otherwise your Post model will be undefined when we run your schema through Prisma's SDK to parse it. I mentioned this briefly in the readme, however I have just published a more detailed readme along with a much clearer error report.

Which directory do you place the prismix.config.json file
This file goes in the root of your project, it doesn't look like you put this in the wrong place judging by the error.

Here's the exact section I added in the readme to solve your issue: https://github.com/jamiepine/prismix#cross-file-relations
Released 1.0.16 on NPM & here's the commit with my changes: https://github.com/jamiepine/prismix/commit/566f871a0cf5c2acfe51c3161f62b2e5bc327b71

+1 for separately entities. Especially to use with modules in nestjs

+1 for separately entities. Especially to use with modules in nestjs

agree, should be able to tell prisma where the files are and process them

Or process all *.prisma in entire project

+1 for separately entities. Especially to use with modules in nestjs

agree, should be able to tell prisma where the files are and process them

Or process all *.prisma in entire project

This works for most projects, but it becomes an issue in monorepos where you want to have separate Prisma instances.
Today you can point it to a single file which allows for separate Prisma instances. I think we should be able to provide it an array of globs to be most flexible.
Then if you want to enable what you suggest the glob could be */*.prisma.

Still waiting, please fix it. or at least give us some a deadline.
this is a very hard to maintenance where the projects has a lot of nested entities!

@mosheboker1 feel free to submit a PR with those features yourself. There are also a few workarounds in this issue you could use.

@beeman I see your point. I've tried this approach with gorm.io in Go, but the issue there is the relationships. You can split the files, but it will depend on each other as you have to import the relationships. I don't think this is a good idea as in the end it's not really decoupled. The DB is just one, so in my opinion it should be coupled together. But this should not prevent you from importing the client to multiple projects.

they all merge into one but with a catch
the naming will be bassed on the file name and path relatively from it parent
fex:

shemas

index.shema᲼᲼᲼᲼᲼᲼᲼᲼---> main file
User.shema᲼᲼᲼᲼᲼᲼᲼᲼᲼---> sub file .. it can be like this
Post᲼᲼᲼᲼᲼᲼᲼᲼᲼᲼᲼᲼᲼᲼᲼---> or like this where more sub sub files can branch

index.shema᲼᲼᲼᲼---> main file for the post
Content.shema᲼᲼---> subsub file

# shemas/index.shema

model Something{
     user         User
     content    PostContent
     content2  PostContentC2
}

# shemas/User.shema

model default {
     name      String
}

# shemas/Post/index.shema

model default {
     name      String
     content   PostContent
}

# shemas/Post/Content.shema

model default {
      name       String
      content2  C2
}

model C2{
     name      String
}

my little idee for that
in package.json or conf file add paths/regex to select all schemas
use extend like :
model book {
  id    Int    @id @unique @default(autoincrement())
  title String
}

extend model book {
  Price Float
}

im dont know how this work behind actualy
but like this parse to multiple object and merge extend with good object and if y have 2 time the same object wihout extend simply throw an error refer to two lines

Hi all,
Here's what I'm using to get around this:
project-root
  ↳ database.prisma
  ↳ prisma/
    ↳ models/
      ↳ *.prisma
    ↳ schema.prisma // generated

"scripts": {
  "prisma:schema:_init": "cat database.prisma > ./prisma/schema.prisma",
  "prisma:schema:_merge": "cat ./prisma/models/*.prisma >> ./prisma/schema.prisma",
  "prisma:schema:merge": "yarn run prisma:schema:_init && yarn run prisma:schema:_merge",
  "prisma:schema:generate": "yarn run prisma format && yarn run prisma generate",
  "prisma:schema:migrate:dev": "yarn run prisma:schema:generate && yarn run prisma migrate dev",
  "prisma:schema:migrate:prod": "yarn run prisma:schema:generate && yarn run prisma migrate prod"
}

Hey everyone 👋  several community members have built tools for this workflow that can be used as workarounds for the time where Prisma doesn't support it natively. To all authors, feel free to plug your tools here in this issue 🙂
I recently came across this tool by @sabinadams: https://github.com/sabinadams/aurora

Before you you use a community solution, first check if your using a linter or if your editor uses Prisma's language server.
I had to revert using a community solution as I couldn't get my editor to stop complaining and it broken autocomplete/autofix.

Just wanted to share a syntax proposal:
interface AuditRecords {
  createdAt     DateTime   @default(now())
  createdBy     String
  updatedAt     DateTime   @updatedAt
  updatedBy     String
}

model Record extends AuditRecords {

}

-or-
model Record {
  ...AuditRecords
}

@@extends is also cool

I'm going to drop this here for the lazy.
Given:
-prisma
  - src
    - models
      - Base.prisma #datasource and generators here.
      - User.prisma # user schema
      - Post.prisma # posts schema
  - schema.prisma # combined schema

Stich this into your npm/yarn hook
ls prisma/src/models/*.prisma | while read f; do cat $f >> prisma/src/schema.prisma; done

using makefile to generated schema.prisma
project-root
↳ prisma/
↳ main/
↳ *.prisma
↳ datasource/
↳ main.prisma
↳ schema.prisma // generated
makefile
DATA_SOURCE ?= main
MIGRATION_NAME ?= init

catDatasourceFile:
	cat ./prisma/datasource/$(DATA_SOURCE).prisma >> ./prisma/schema.prisma

catMultiPrismaFile: catDatasourceFile
	cat ./prisma/$(DATA_SOURCE)/*.prisma >> ./prisma/schema.prisma

migrate: catMultiPrismaFile
	prisma migrate dev --schema prisma/schema.prisma --name $(DATA_SOURCE)_$(MIGRATION_NAME)
	rm -rf prisma/schema.prisma

you can run MIGRATION_NAME=multi_prisma make migrate to generated schema.prisma and migrate

Hey, for those still waiting, I'd recommend trying prismix. It's based on the prisma sdk, which doesn't natively support every feature that the prisma client does, but it works well. Yesterday I added custom support for several of these missing features (@map, @db.Types, @@index, relation onUpdate), and those changes should be reflected in the next release (I'm not the package maintainer).
I tried aurora but couldn't get it to work. Given that prismix did work for me, I didn't take the time to debug, but I suspect something in our schema was too complicated for aurora to handle.

Hey! If you get a chance, would you mind creating an issue on the Aurora repo with your schema?
All the attributes you mentioned should be supported so I'd be curious to see what the error was 😁

Yeah will do!
On Fri, Feb 18, 2022, 12:42 PM Sabin Adams @.***> wrote:

Hey, for those still waiting, I'd recommend trying prismix
https://github.com/jamiepine/prismix. It's based on the prisma sdk,
which doesn't natively support every feature that the prisma client does,
but it works well. Yesterday I added custom support for several of these
missing features @.***, @db.Types, @@index, relation onUpdate), and those
changes should be reflected in the next release (I'm not the package
maintainer).
I tried aurora https://github.com/sabinadams/aurora but couldn't get it
to work. Given that prismix did work for me, I didn't take the time to
debug, but I suspect something in our schema was too complicated for
aurora to handle.
Hey! If you get a chance, would you mind creating an issue on the Aurora
repo with your schema?
All the attributes you mentioned should be supported so I'd be curious to
see what the error was 😁
—
Reply to this email directly, view it on GitHub
https://github.com/prisma/prisma/issues/2377#issuecomment-1044900348,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB2LTSDECGUZNC3AD34AY3DU32AGRANCNFSM4MZZ7WBQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.Message ID:
@.***>

are there any updates for multi config with prisma dep only?

@alexn-s unfortunately not yet - we currently prioritise features which can not be mitigated otherwise. Hopefully we get to this in the next several months but we don't know yet.

thanks for the heads up.
btw as an idea: why not use the third party tools as an official and "sanctioned" way in prisma and use them in the background?

 If you want what your doing to last, make sure
it can stand on it's own.
Thanks,
Dallas

Director of Engineering @ Microventures
Professional leader of highly performant engineering teams
512.923.4426 | Github  https://github.com/codeninja| Twitter
https://twitter.com/dallaspool| Linkedin
https://linkedin.com/in/dallaspool
On Wed, Mar 30, 2022 at 3:44 AM Alex @.***> wrote:

thanks for the heads up.
btw as an idea: why not use the third party tools as an official and
"sanctioned" way in prisma and use them in the background?
—
Reply to this email directly, view it on GitHub
https://github.com/prisma/prisma/issues/2377#issuecomment-1082796421,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAADUQSL7B4MJD3QQ2OEOVTVCQH7XANCNFSM4MZZ7WBQ
.
You are receiving this because you commented.Message ID:
@.***>

i think, splitting schema bad idea it is antipatter and spaggeti code, if you want split schema, you must split databases to different db or schemas with isolated entity and generate standalone prisma client for used database or schema
please close this issue)

prisma schema - it is state of database in current moment, why people want append logic with extends to state of data base) you crazy?

i think, splitting schema bad idea it is antipatter and spaggeti code, if you want split schema, you must split databases to different db or schemas with isolated entity and generate standalone prisma client for used database or schema
please close this issue)

@EndyKaufman, I don't mean to be too mean, but that might be the worst comment I've ever seen on this site

if schema inheritance was a good idea or universal for all databases, then this discussion would not exist)

I have 5 clients, for 2 databases and for 4 schemas of 3 databases, I split everything into microservices and nestjs modules and decomposed the code
though it all started by subscribing to this thread and looking for solutions

@EndyKaufman I think you may be conflating the prisma schema with the purpose of migration or snapshot files. You can still have your immutable snapshots, schemas, or migration files, but the prisma schema is for authoring your database but still being able to update it back from the state of a database.

@josh-hemphill at the moment i use prisma only to generate SDK for work with database from existing database (my small post about it https://dev.to/endykaufman/add-prisma-orm-to-kaufmanbot-nestjs-telegram-bot-application-3e8b)

We wanted that feature to assign specifics github codeowners to enforce having specifics people approve pieces of the data model update.
We liked the idea to have some more serious core schemas like the auth part (user, role, permissions, ...)  to be protected like that and we would be less restrictive over features schemas models.
Maybe it's not a good code approach as some mentioned here, but we are solving some problems we had with our process.

all this can be solved in other ways, for example, a protobuff specification, but there are many problems - cross-scheme inheritance, cross-scheme keys, indexes, cross-scheme stored procedures, cross-scheme triggers
this task is very long and of no use, people will write spaghetti code instead of solving architectural problems
Therefore, I propose to close the topic with multi-schemes altogether)

because database is not only tables as excel file)

Therefore, I propose to close the topic with multi-schemes altogether)

But this issue isn't just about multi-schemas, pretty sure that got split out into other issues. Much of this issue thread is about a single schema split between files so that the different components can be logically organized for the developers working with it in their dev environment.

Therefore, I propose to close the topic with multi-schemes altogether)

Right - just because you can't grasp the use case of another or you know how to throw a bunch of buzzwords in a GitHub issue we might as well close it.
How about you simply unsubscribe from this issue and leave it up to people who do see the use case?

So from what i gathered the implementation can be:
1- having an import export (also default export will be nice) functionality:
Pros:

it will be easy organise and work with naming components
it will be easy to seperate dev and production files (in case it's needed).
Cons:
it will be hard to implement for the language and even for the vscode extension aswell.
it will be more proccess demanding (vscode extension)

2- having all files act as if they're one:
Pros:

easy to implement
Cons:
naming things and file management will be meaningless because you will have to give it a unique name on top of the unique file name ... etc
Wouldn't be able to seperate dev and production. At least the vscode wouldn't reconize which it should look for.

3- another way is just use something that is already made like .. typescript to organize the database structure. And have it generates the prisma file on build time. Which will have the pros of the first implementation without it being difficult to implement
:)

If you're going with the third option i would recommend somehow merging it with the seed script. That would be interesting to see

Therefore, I propose to close the topic with multi-schemes altogether)

But this issue isn't just about multi-schemas, pretty sure that got split out into other issues. Much of this issue thread is about a single schema split between files so that the different components can be logically organized for the developers working with it in their dev environment.

I have 5 prisma schema files, for different logic in my application
If I want, I may build standalone lib for npm register and include prisma schem or include files generated with any prisma generator
https://github.com/prisma/prisma/issues/2377#issuecomment-1083608497

@EndyKaufman: I have 5 prisma schema files, for different logic in my application
I'm curious about this solution.

I wonder how it works for models references between the schemas. Do you keep the reference as plain string/id or maybe you design the split so they don't hold any references to other schemas?
I see some issue with having to deal with many clients/binaries. In our case, using lambda and layer for the binary, I feel it brings more risks than what we're solving (see comment: https://github.com/prisma/prisma/issues/2377#issuecomment-1083614618).
Right now, we are interested in doing something like npm: prisma-aurora but we'd much prefer something supported by prisma if other people are interested as well.
I get your point though, but it seems pretty complex and risky for our simple use-case.

We wanted that feature to assign specifics github codeowners to enforce having specifics people approve pieces of the data model update.
We liked the idea to have some more serious core schemas like the auth part (user, role, permissions, ...) to be protected like that and we would be less restrictive over features schemas models.
Maybe it's not a good code approach as some mentioned here, but we are solving some problems we had with our process.

My previous comment on the topic might help in your case.
https://github.com/prisma/prisma/issues/2377#issuecomment-1029169197
Through this you could restrict access to files in Git (etc) through file matchers.

I think the schema is the state of the database schema

So, this is exactly the problem I was trying to solve. I needed a source of truth for my application for the data model logic that would span the database, graphql, and the application. A single entity which defines how all three are expected to interact with my data model.
Without such an SSOT for the data structures, the structure would need to be duplicated for each layer. Requiring multiple passes through code, careful syncing, ultimately for large teams this poses problems at scale.
We wanted to define the shape of our data once, then pivot off that model for the application ORM, the Graphql schema and infrastructure, and the physical data storage in Postgres.
My solution to that was to define each prisma schema in it's own schema file and be able to load the library up in various compilations. We ultimately achieved a version of this with my post above.
https://github.com/prisma/prisma/issues/2377#issuecomment-1029169197****

That's a good idea, at least it seems to do the job for now. We went with aurora and we'll see how it goes for now. Though I don't like that we don't get proper intelissense and schema validation unless we duplicate parts of model for the references.
Might not be too troublesome for some time, but maybe later. Good thing is we can remove this package from our pipeline quite easily.
question With this:
stitch: "ls prisma/src/models/*.prisma | while read f; do cat $f >> prisma/src/schema.prisma; done"

You cannot get the power of this thing right?

cc: @codeninja

So, actually, yes. But it took extra steps.
Compile your partials and fragments in prisma/src/models/*.prisma
I used Husky to call the compile script in a pre-commit hook.
yarn prisma:stitch # => prisma/src/schema.prisma
We pointed prisma to the prisma/src/schema.prisma
I  then used the VSCode extension RunOnSave to watch the files in
prisma/src/modes for changes. Any change to the model triggers the stitch
script and a couple of others to keep things in sync with the source.
They may be hoops of fire but it works.
Thanks,
Dallas

Director of Engineering @ Microventures
Professional leader of highly performant engineering teams
512.923.4426 | Github  https://github.com/codeninja| Twitter
https://twitter.com/dallaspool| Linkedin
https://linkedin.com/in/dallaspool
On Fri, Apr 1, 2022 at 7:53 AM maxeber @.***> wrote:

That's a good idea, at least it seems to do the job for now. We went with
aurora and we'll see how it goes for now. Though I don't like that we
don't get proper intelissense and schema validation unless we duplicate
parts of model for the references.
Might not be too troublesome for some time, but maybe later. Good thing is
we can remove this package from our pipeline quite easily.
question With this:
stitch: "ls prisma/src/models/*.prisma | while read f; do cat $f >> prisma/src/schema.prisma; done"
You cannot get the power of this thing right?
[image: image]
https://user-images.githubusercontent.com/16073961/161267251-23651fd7-f639-456b-ba03-588bd3bf2263.png
cc: @codeninja https://github.com/codeninja
—
Reply to this email directly, view it on GitHub
https://github.com/prisma/prisma/issues/2377#issuecomment-1085862452,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAADUQTUS7XYWOEG3FXQ4BTVC3WTHANCNFSM4MZZ7WBQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

This would be nice! Especially when you want to categorize by feature/domain which is quite common.

It must be added. It is not possible to maintain a database with 500+ tables and 50+ columns each with single file.

It must be added. It is not possible to maintain a database with 500+ tables and 50+ columns each with single file.

You can't demand new features without paying the development team behind them. In the meantime you can use either Prismix (https://www.npmjs.com/package/prismix) or Aurora (https://www.npmjs.com/package/prisma-aurora).

Been following this thread for a bit & wasn't feeling the patching tooling that's currently out there - so I made a TypeScript CDK for Prisma over a couple of weekends:
https://gitlab.com/cxss/refract
Here's a quick example:
// Enums
const Role = Enum('Role', ['USER', 'ADMIN'] as const);

// Define models first for circular relations
const Post = Model('Post');
const User = Model('User');

// Mixins (think inheritance)
const Timestamps = Mixin()
  .Field('createdAt', DateTime(Default('now()')))
  .Field('updatedAt', DateTime(UpdatedAt));

User
  .Field("id",          Int(Index, Default("autoincrement()")))
  .Field("email",       Varchar(Unique))
  .Field("name",        Varchar(Nullable))
  .Field("role",        Role("USER"))
  .Relation("posts",    OneToMany(Post))
  // Use a mixin, adds createdAt & updatedAt columns to Model
  .Mixin(Timestamps);

Post
  .Field("id",          Int(Index, Default("autoincrement()")))
  // Defaults are type-safe
  .Field("published",   Boolean(Default(false)))
  .Field("title",       Varchar(Limit(255)))
  .Field("authorId",    Int(Nullable))
  // All kinds of relationships
  .Relation("author",   ManyToOne(User, Pk("id").Fk("authorId"), Nullable))
  .Mixin(Timestamps)
  // Escape hatch into raw Prisma
  .Raw(`@@map("comments")`);

Refract({
  datasource: {
    provider: 'postgresql',
    url: process.env.PG_URL,
    shadowDatabaseUrl: process.env.PG_SHADOW_URL,
    referentialIntegrity: 'prisma',
  },
  generators: [
    {
      provider: 'prisma-client-js',
      previewFeatures: ['referentialIntegrity'],
      engineType: 'library',
      binaryTargets: ['native'],
    },
  ],
  output: path.join(process.cwd(), "myschema.prisma"),
  schema: [Roles, User, Posts],
});

Supports most things but not feature complete, I've been adding to it as I convert over a fairly large Prisma file into it, but happy to take suggestions & PRs :)

I've also been following this thread for quite a while.
As many of my own Prisma schema's have begun to reach out the 2000+ lines, and since some of my projects tend to be very data-heavy, so I decided to have my own go at a sort of Prisma segmentation library. I needed something a little blunt & cut-and-dry so moving everything over is swift, so I made Schemix.
You can instantiate a Prisma schema as follows:
// _schema.ts
import { createSchema } from "schemix";

export const PrismaSchema = createSchema({
  datasource: {
    provider: "postgresql",
    url: "env(DATABASE_URL)",
  },
  generator: {
    provider: "prisma-client-js",
  },
});

export const UserModel = PrismaSchema.createModel("User");
export const PostModel = PrismaSchema.createModel("Post");
export const PostTypeEnum = PrismaSchema.createEnum("PostType");

import "./models/Post.model";
import "./models/User.model";
import "./enums/PostType.enum";

PrismaSchema.export("./", "schema");

Then register fields as follows...
// models/User.model.ts

import { UserModel, PostModel, PostTypeEnum } from "../_schema";

UserModel
  .string("id", { id: true, default: { uuid: true } })
  .int("registrantNumber", { default: { autoincrement: true } })
  .boolean("isBanned", { default: false })
  .relation("posts", PostModel, { list: true })
  .enum("postType", PostTypeEnum, { default: "COMMENT" })
  .raw('@@map("service_user")');

// models/Post.model.ts

import { UserModel, PostModel } from "../_schema";

PostModel
  .string("id", { id: true, default: { uuid: true } })
  .int("postNumber", { default: { autoincrement: true } })
  .string("content", { raw: "@database.VarChar(240)" })
  .boolean("isDeleted", { default: false })
  .relation("author", UserModel, {
    optional: true,
    fields: ["authorId"],
    references: ["id"],
  })
  .string("authorId", { optional: true });

// enums/PostType.enum.ts

import { PostTypeEnum } from "../_schema";

PostTypeEnum
  .addValue("FEED", { map: "feed" })
  .addValue("COMMENT", {
    map: "comment",
  });

I'll be adding the rest of the types later. What it has now has been enough to translate my schemas over, contributions are welcome.

It would be amazing, currently my schema.prisma file is so long and it keeps growing which makes it harder to manage.

I have put my thoughts in this situation as well. I have a quite specific use case but ended up coming with a slightly different approach.
I have created objects like this:
`const modelName = 'Post';
export const PostSchema = {
name: model.name,
mixins: [general(modelName)],
relations: {
one: [User],
oneOptional: [],
many: [
Comment,
[
Post,
{ name: 'related', relationName: 'RelatedPost' },
],
],
},
fields: [
{
name: 'title',
type: 'String',
db: { varchar: 400 },
optional: true
},
],
} as Model;`
Where Mixins are simply regular models, in the example general(modelName) is just a helper function to inject the model name inside the mixin (it is useful for things like auto generating custom ManyToMany relations like PostToUser or somethings of the like.
The tool got quite custom as fairly complex but the gist of it is reading the models with something like this:
export const model = (model: Model) => {     writeLine(        model ${_.replace(
_.startCase(model.name),
new RegExp(' ', 'g'),
''
)} {     );     // writeLine();     if (model.mixins) loadMixins(model.mixins);     if (model.relations) loadRelations(model.relations);     writeLine();     if (model.fields) model.fields.forEach((f) => field(f));     writeLine(});     writeLine(); };
and this:
 export const field = ({     name,     type,     optional,     unique,     id,     default: defaultValue, }: Field) => {     token(name);     token(type);     if (optional) _optional();     if (id) token('@id');     if (unique) token('@unique');     if (defaultValue) token(@default(${defaultValue}));     writeLine(); };
And finally using trivial writing functions like:
export const token = (value: string, showTab: boolean = true) => {     print((showTab ? tab : '') + value); };
export const writeLine = (text: string = '') => {     print(text + newline); };
Where newline and tabs are constants representing \n and \t.
I am not willing to write a custom package for direct consume but just wanted to share a different approach on writing the models as objects instead of functions, since that is what works best for me: Allowing for all kinds of readings and injections later on.
The last thing that I felt that worked well was keeping tabs on the generated relations on one side and auto generating the other relations later on (by injecting it on the model object). It is useful for things like Users that might have many relations with of objects.
Anyway, I am not really used to write these kind of posts, but I felt that this really helped me and was wondering if it might do the same for somebody else. Thanks for the amazing Prisma tool! =D
Obs: I could not manage to improve the code parts, please be free to edit this comment if it is worth it!

I need this feature because I connect to multiple databases in my project

🤔

Any update on this??

Any update on this??

Just we waiting response 😕

Currently the third-party solutions for this are:

ridafkih/schemix
cwqt/refract
jamiepine/prismix
prisma-aurora

Schemix and Refract both use TypeScript to create the schema, which in my opinion works much better because you can have some configuration safety, versus the others having no supporting extensions, so to prevent redfiles you have to uninstall or disable Prisma's extension tooling.
With Schemix and Refract, you can build your schema with decent safety in TypeScript, and then use the Prisma extensions to ensure safety in edge-cases after compilation.

Dear all,
please take a look at this package here:
https://github.com/prisma-utils/prisma-utils/tree/main/libs/prismerge
You can split your large schema.prisma file into multiple smaller *.prisma files, and link them all together in a configuration file. It also supports some kind of mixins, where you can re-use repetitive declarations (i.e., for id, createdAt and updatedAt) that need to be added to nearly all of your models.
The package follows a very simple approach (i.e., all files are just concatenated / merged). See the docs for more infos.
For all of you guys, that are using nrwl/nx:
Of course it also works with nx - and i also offer some pre-defined generators for you to automagically do the work for you ;)
Give it a try

@johannesschobel Nice! Like the mixins idea. We went with aurora but will keep an eye on this one for sure!

@maxeber thanks.. I have my own lib in 2 apps in use, and its quite handy.

+++++++++++++ for native support

Prisma v4 and yet a simple feature like splitting Prisma schema into multiple files is not implemented ?

Dear @younes-alouani , pretty sure you could create a PR to address this issue.
However, as the prisma team mentioned - this is not an issue with "its hard to implement" but rather an issue with the syntax and features to be supported..
However, in the meantime, you could use my library @prisma-utils/prismerge ( https://github.com/prisma-utils/prisma-utils/tree/main/libs/prismerge ) .
All the best

Dear @younes-alouani , pretty sure you could create a PR to address this issue. However, as the prisma team mentioned - this is not an issue with "its hard to implement" but rather an issue with the syntax and features to be supported..
However, in the meantime, you could use my library @prisma-utils/prismerge ( https://github.com/prisma-utils/prisma-utils/tree/main/libs/prismerge ) .
All the best

prismerge works but doesn't have native syntax highlight support in vscode so you end up with errors in files and limited autocomplete support. It really would be lovely to have it natively supported on all levels (starting from prisma ending with vscode extension)

Dear @npwork . Prismerge lacks vscode syntax highlighting support, you are right. But that was not the goal of this solution. The main goal is to provide a working solution and generators to be used in combination with nrwl/nx

Dear @younes-alouani , pretty sure you could create a PR to address this issue.

While this is true of most open source projects, can we stop pretending this project is maintained out of the blood sweat and tears and kindness of the teams' hearts?
The Prisma team has received over $56 million in funding to date. It's fine to say things like "they have other priorities at this time." But this issue is a legitimate one with a lot of activity and it really would be nice to see this get some first class attention, support, and tooling as the schema is such a core component of Prisma.

Dear @younes-alouani , pretty sure you could create a PR to address this issue. However, as the prisma team mentioned - this is not an issue with "its hard to implement" but rather an issue with the syntax and features to be supported..
However, in the meantime, you could use my library @prisma-utils/prismerge ( https://github.com/prisma-utils/prisma-utils/tree/main/libs/prismerge ) .
All the best

prismerge works but doesn't have native syntax highlight support in vscode so you end up with errors in files and limited autocomplete support. It really would be lovely to have it natively supported on all levels (starting from prisma ending with vscode extension)

have you tried with files.associations vscode settings?

As you can use whatever file extension you want for PrisMerge and, hence, syntax highlighting, autocomplete, ... does work as expected.
However, as PrisMerge does not use proper syntax (i.e., for mixins/fragments), or missing relationship models.
All the best

I'm just getting into prisma for the first time because some of the devs at my company use it for the backends I work with. I saw the giant .prisma file and was thinking about telling my workmate to refactor because of course one giant file is simply not maintainable and leads to bad developer experience.
As it turns out, prisma simply requires you to do so. Very strange indeed.
This is a considerable shortcoming of this tool, I personally feel it should be a top priority because I would enjoy very much being able to create a good, modular project structure with this tool.

Hey All 👋
Unfortunately we don't have an updated timeline for this feature.
We currently prioritizing true gaps in our offering (full text search, GIS, multi schema, views etc. to name a few). We know large schema files are painful and we definitely want to do something here once we have some bandwidth!
I hope this sounds reasonable and thanks for all the participation in this issue!

Please consider polling prisma.io account holders on priorities of these topics. I personally have not considered any of the aforementioned features, yet I have been watching this thread for months.

Adding my name to the petition here :)

+me

+me

one more looking for this :disappointed:

me as well

What would we need to make this happen?
The VS Code extension/language server are open to contribution, right (here)?
This may be too simple, but does the language server only need to know about all the fragments and glob them together so it would appear to the server, that it still would be one single .prisma file? 🤷♂

Dear @oddcelot ,
Take a look at @prisma-utils/prismerge to solve your issues with multiple files :)
All the best,
Johannes

Also interested in native support.
For those using Nx and/or NestJS, here's a guide for a monorepo that supports schema splitting and more than one schema/database/client (if there is a use for that).

Wraps the Prisma CLI to provide the necessary environment variables for each schema's database connection, including docker secrets
For each schema, concatenates a base.prisma with a glob of matching files, like *.pg.prisma
Nx commands listed in the guide enforce dependencies (e.g., build depends on merge and lint), cache output, and can be used by other Nx projects (e.g., building the backend depends on building the Prisma client)

See workspace.json and libs/prisma for the code at troncali/nest-vue.

Once again, the third party solutions are as follows:

ridafkih/schemix
cwqt/refract
jamiepine/prismix
prisma-aurora
prisma-utils/prismerge

The first two use in-script generation (my preference) while the rest use schema concatenation with some added features.
If a few of the people here want to take some time to investigate what it takes to implement native support, I'd be willing to organize a group to do so. Just @ me and say you're in, and I'll contact you using the e-mail listed on your profile.

Dear @troncali ,
love that you're using PrisMerge in your repo ❤

Please consider polling prisma.io account holders on priorities of these topics. I personally have not considered any of the aforementioned features, yet I have been watching this thread for months.

Poll sent out this morning, everyone here should fill out if they have it (regardless of your feature priorities).

@zpg6

everyone here should fill out if they have it (regardless of your feature priorities).

Is this only for paying customer though?

Is this only for paying customer though?

I am not paid member, but I do have an account (how they have my email).

@zpg6 thanks for the clarification.

i’d love to see this

It's been more than a year?? 😮
@AfrazHussain have you seen my suggestion for something in-between options 3 and 4 (3.5)? Option 3 is really nice, but by itself will eventually lead to issues for people with huge codebases to maintain.

Last time Prisma team is not progressing. you are not listening to community and that's not good, folks.

Just want to give a heads up that there is a roadmap and that this feature is in the backlog. Why it's not getting lifted out of there I don't know, but at least it's there: https://prismaio.notion.site/Prisma-Roadmap-50766227b779464ab98899accb98295f?p=83867e7f70ce40038cdfa9eb32ed4449&pm=s

It's been more than two years, we are very interested in using the prism in our projects, but this current way of keeping everything in the same file is extremely horrible, maybe we use some external library to help with the separation, but after all this time, a tool famous as prism not having implemented a solution for this is somewhat disappointing

I did want to swing in here quickly and just note that I just updated schemix, my third-party solution to this problem to make it significantly easier to use. This eliminates all of the i-e-i import-export shenanigans from before, and just makes it a real pleasure to use. Plus, here's a neat little upgraded graphic for it too. 😛

Since the usage pattern changed quite a bit, I created a small example usage as part of the repository which you can view here.
I also just want to pop in and say that while I too am looking forward to the native version of this feature, let's find more effective ways of expressing and contributing than aggressively hassling the Prisma developers in an issue. This feature isn't being de-prioritized as a result of neglect, or malice, it's because while we are all cheering on this one feature because it is going to be very useful to us, there are a ton of other different feature requests with just as many equally excited (and sometimes angry) people ready to see them complete.
Be kind, y'all! Cheers.

Note for additional context: I randomly found out that atlas (go database toolkit) had the same issue, and they went for the following approach:
https://atlasgo.io/atlas-schema/projects

Project files provide a convenient way to describe and interact with multiple environments when working with Atlas. A project file is a file named atlas.hcl and contains one or more env blocks. For example:

// Define an environment named "local"
env "local" {
  // Declare where the schema definition resides.
  // Also supported:
  //   src = "./dir/with/schema"
  //   src = ["multi.hcl", "file.hcl"] (<----- THIS HERE -----)
  src = "./project/schema.hcl"

  // Define the URL of the database which is managed in
  // this environment.
  url = "mysql://localhost:3306"

  // Define the URL of the Dev Database for this environment
  // See: https://atlasgo.io/concepts/dev-database
  dev = "mysql://localhost:3307"

  // The schemas in the database that are managed by Atlas.
  schemas = ["users", "admin"] (-- and here the multi db schema --)
}

env "dev" {
  // ... a different env
}

Dear @Jolg42 ,
the solution provided by atlas, however, is the complete opposite, of what we would like to have, right? The atlas solution merges multiple environments in one big file.. we would like to have multiple smaller files (i.e., one per model) that are automatically merged into one file that can be read by prisma..
Like the solution i have provided with PrisMerge ( https://github.com/prisma-utils/prisma-utils/tree/main/libs/prismerge ).
All the best

@johannesschobel I just posted that to add more context to the issue. For Prisma we probably need a different solution. Something to figure out.
Note that splitting Prisma schema files and keeping the same developer experience brings some challenges: it potentially impacts how everything works: CLI, Client, Migrate, language-server / VS Code extension, Data Platform, Data Proxy. It's not an easy task.
Something like PrisMerge is interesting, however, the language-server / VS Code extension features will not work. (only on the final schema.prisma output).
How do you work with that currently?

Dear @Jolg42 ,
yeah, i can imagine that there is a lot of hassle and pain around that feature. Especially when considering all different aspects of the prisma ecosystem.
Note that the solution provided by PrisMerge works for me - at the moment - and i am quite happy with it. Currently, i do not rely on the language server / syntax highlighting" features provided by VS Code with the Prismaplugin. Simple stuff (like autocomplete) works out of the box (because it is a.prismafile), however, it cannot reference other models (i.e., when you reference a model from a different file). That is ok for me, because i know that everything will be fine in the masterschema.prisma` file.
Not pretty, but it does the job, haha

Yes, I think you pointed out the most important thing. As long as a
solution brings up an unique prisma file, we have the feedback instantly
(if we are using something like vscode) because we have a standard.
.prisma file that is generated programmatically.
It is the same with my custom solution, it is not ideal, but gets the
job done.
On Thu, Aug 25, 2022, 5:49 AM Johannes Schobel @.***>
wrote:

Dear @Jolg42 https://github.com/Jolg42 ,
yeah, i can imagine that there is a lot of hassle and pain around that
feature. Especially when considering all different aspects of the prisma
ecosystem.
Note that the solution provided by PrisMerge works for me - at the moment

and i am quite happy with it. Currently, i do not rely on the language
server / syntax highlighting" features provided by VS Code with the Prismaplugin.
Simple stuff (like autocomplete) works out of the box (because it is a
.prismafile), however, it cannot reference other models (i.e., when you
reference a model from a different file). That is ok for me, because i know
that everything will be fine in the masterschema.prisma` file.

Not pretty, but it does the job, haha
—
Reply to this email directly, view it on GitHub
https://github.com/prisma/prisma/issues/2377#issuecomment-1226969095,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEL2SSR5UCQZZ7IIV43O66LV24XQRANCNFSM4MZZ7WBQ
.
You are receiving this because you commented.Message ID:
@.***>

A similar experience to GraphQL schema would work well.

This issue is only growing and more needed. Prisma is great but if we want to grow bigger, this issue should be prioritized. I   put up with it but newcomers will consider it a deal breaker.

This issue is only growing and more needed. Prisma is great but if we want to grow bigger, this issue should be prioritized. I put up with it but newcomers will consider it a deal breaker.

It's not and shouldn't be a deal breaker. It's a basic feature everything should have.

I think the prisma maintainers have stopped maintaining this project thinking that it has became mature.

No @ShinanTc, we are just dealing with and working on the many, many other issues that exist and that often keep people from using Prisma at all - vs. this one which is more a developer experience problem. We are very aware this is a need as well, of course, which is why this issue exists, we are looking for more information on your needs and use cases, and we will get to as soon as we have the capacity to do so.

Hi @nimas0, this is a built-in feature of Prisma Util. My solution also solves naming conflicts and version 1.3.0 is scheduled to release soon, coming with code generated schemas and YAML configuration instead of .env. It also allows model inheritance and remapping of cross-file relations.

@codeninja Forgot to ping you as well ^

Dear @codeninja , you could also use PrisMerge for this scenario ( https://github.com/prisma-utils/prisma-utils/blob/main/libs/prismerge/README.md ).
Just run
npm I -D @prisma-utils/prismerge

npx prismerge -g

and you are ready to go :)
Give it a try
All the best

does this tool have IDE support(extension)
to help with error correction and auto completion.
thats what is really a deal breaker

I think that your best option is to do same as you do with these alternative solutions.
You add a custom script in package.json to handle all the changes, something like: "prisma:merge": "prisma-utils & prisma format"
And add this script to run on every change of a file with the ".prisma" extension
With this you won't have error highlights on the files themselves but you will have on the final prisma schema.
In the end I totally agree with the prisma engineers, this is essentially a developer experience issue, you will have to choose between having to deal with a gigantic schema file that you make your self manually, or one that is generated automatically by scripts. I chose the last option, but with a custom js solution.

does this tool have IDE support(extension) to help with error correction and auto completion. thats what is really a deal breaker

@haouarihk . no it does not. However, as @FredericoGauz states, i created a custom npm script in my package.json file that basically runs npx prismerge && npx prisma generate at once. Running npx prismerge creates the single prisma files, which can be easily checked for errors. The latter, however, must be fixed in the respective schema files and merged again..

In the end I totally agree with the prisma engineers, this is essentially a developer experience issue

It being an experience issue is pretty important when the entire project exists to solve developer experience issues with doing it directly.

Hey everyone I just publish a small package in npm in a attempt to solve this.
Prisma Schema Generator
https://www.npmjs.com/package/prisma-schema-generator
It use prisma-aurora under the hood in order to make relations between files so you will need to take a look at it if you haven't:
https://github.com/sabinadams/aurora
When using this package you can have a file structure like this one:

Any suggestions or issues please let me know!

Currently, we use several approaches to solve the import problem. The one I have used the most, when working on a single file is impossible, is concatenation (a simple script that does the job).
But by using this approach, we lost all the features of the Prisma extension for VS Code, like linting, autocomplete and others.
I thought for a while and came to the conclusion that, at least for now, an interim solution can be implemented quickly to at least partially solve the problem.
It would simply be enough to implement an import syntax recognized by the Prisma extension in VS Code, in order to keep all the features of the extension between the imported files. And, of course, implement a simple "merge" / concatenation feature, in the extension (and not directly in the Prisma engine), that does the build work for a single final file (which would be effectively used by Prisma).
This solution could probably be implemented with a few hundred lines of code, and with it it would be possible to solve the current problem for developers using Prisma, without having to go through the trouble of making more abrupt changes to the engine.
Please @janpio and @millsp check this.

I'm impressed that this hasn't been resolved in 2 years. And the most amazing thing is how all developers need this feature because it is impossible to work on a single file. It's totally unfeasible.
Is it so insanely difficult to do this that it takes 2 years to do? Prisma is the best tool today, but according to this open topic, I'm already in doubt if I'll continue using it in other projects.

2.5 years later, let's simply mark this one "Won't Fix," close it, and everyone stops replying, please.

2.5years why

Well, which of you have tried to make a PR fixing it?

Well, which of you have tried to make a PR fixing it?

That's such a weird fanboy reply, honestly. This isn't some open source project maintained out of the kindness of someone's heart. This is a company that has raised $50 million dollars. Third party solutions are fine and dandy, but this issue deserves first class support.

@ekwoka

Well, which of you have tried to make a PR fixing it?

First you have to establish the spec for the PR (right?). This requires a lot of buy in from the author's themselves before you even get to the point of meeting the various needs of community users. So, unless an author has laid out "we'd accept a PR that achieves this or that", trying to "fix it" is quite hard for the average user. It doesn't take long to realise that the author's of Prisma have their own ideas about how their product should progress (and that's fine), and this issue is obviously out of their circle of interest, which ultimately means it's a waste of time for anyone to guess what a PR should or could look like. Then of course there's the little issue of how the heck Prisma works under the hood anyway :) (minor technical detail).

Please, everyone, keep it civil. We know this is desired by many, and we also know this issue has been open for quite some time. As soon as we see an opportunity to work on this, we will put it on our roadmap and share that with you. Right now that is unfortunately not the case as we are still busy with other things (that other users desire).
Until then, we are still (as always) interested in your concrete problems and use cases where things currently do not work for you. When we start digging into this topic, we will read all of the replies here again and will use that to inform our design. Thanks.

For those who need fields reuse, I write a prisma preprocessor prisma-include that focus on fields mixin by @import and @include comments.
///@import {user} from "prisma/mixins.prisma"

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

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

model profile {
  ///@include(user)
  email String @unique @default("") @db.VarChar(100)
}

ridafkih/schemix has some snazzy new features and is taking contributions and feature requests although I must say, @xiangnanscu, really like the approach you took with the commented imports. Might have to make some contributions myself.

as we are still busy with other things (that other users desire)

What do you call this then? is this something that users don't desire?
my schema.prisma file is almost 1k lines long, and I do not want to resort to third party libraries.
I'm so sorry, but it absolutely boggles my mind how this isn't at the top of your priorities.
This thread has been active for the past 2.5 years now, and the reasoning for pushing it aside has been that DX isn't as important.
Excuse me?
I, along with the majority of prisma users, HEAVILY desire this.

For the most part Github is a wonderful community. However sometimes I come across threads like this and am incredibly disheartened.
I'm new to Prisma and found this is isn't supported after stumbling here - nice to have but honestly not a big deal.
However the amount of self entitlement in this thread is just something else. A lot of people saying "I can't believe this is such a basic feature and it's been so long" yet seemingly do nothing about it. It's literally open source, if you feel so strongly about it, I highly recommend you consider contributing yourself than simply whining about your expectations.
If you're not willing to do that, then you don't get to make such statements, period.
A couple of other statements from observations here:

If your editor can't open 3000 loc without it being slow then that's on you. We took man to the moon with what, 1/1000th of the processing power that you're currently using..? Probably less to be honest.
If this is a deal breaker for you because you can't have a single file and don't want to use a single cat statement then I'm really not sure how you even get by as an engineer.

Thanks for all your hard work to those that do contribute or respectfully ask for features, I'm finding Prisma wonderful.

If your editor can't open 3000 loc without it being slow then that's on you. We took man to the moon with what, 1/1000th of the processing power that you're currently using..? Probably less to be honest.

Very assumptive statement.
My problem is not that it is slowing down - it is that I don't want to scroll through LOC.
yes, I can ctrl+f, but that assumes that I know the entire data model off the top of my head, sometimes I don't and I just want to glance at certain models.
Modularizing it into separate files can alleviate this problem immediately.

If this is a deal breaker for you because you can't have a single file and don't want to use a single cat statement then I'm really not sure how you even get by as an engineer.

You lose intellisense if you do this.
I've resorted to prismix as the short term solution.
I hope prisma can get this resolved soon.

here is a snippet of what my models look like
https://gist.github.com/f-kb24/1b300c1b49d1d838bc7faf649b061e8b
now, this is just for NBA, I have MLB, NFL, NHL as well.
data fields are a mix of PascalCase and camelCase, as PascalCase is how it is done in the third party API and I want it to be consistent; camelCase for my own data fields, so don't give me flak about that.
Passive aggressive comments and attacking my ability as an engineer is just as disruptive, btw.

@f-kb24 With ridafkih/schemix, you could do some pretty neat stuff with this schema, for example you could compute adding properties to your model, such as plentiful repeated properties. For example...
Create our mixins/StatFieldsMixin.mixin.ts, and populate it with the following code.
import { createMixin } from "schemix";

const statFields = [
  "FantasyPoints",
  "FieldGoalsMade",
  "FieldGoalsAttempted",
  "FieldGoalsPercentage",
  "TwoPointersMade",
  // ...
]

export default createMixin((StatFieldsMixin) => {
  for (const fieldName of statFields) {
    StatFieldsMixin
      .decimal(fieldName, { optional: true, raw: "@database.Decimal(4, 1)" });
  };
});

After that, we could create our models/LastFiveGameAveragesModel.model.ts file and populate it with the unique properties, and consume the computer mixin from before.
import { createModel } from "schemix";
import PlayerModel from "./Player.model";
import StatFieldsMixin from "../mixins/StatFieldsMixin";

export default createModel((LastFiveGameAveragesModel) => {
  LastFiveGameAveragesModel
    .int("PlayerID", { id: true })
    .relation("player", PlayerModel, { fields: ["PlayerID"], references: ["PlayerID"] })
    .int("Minutes", { optional: true })
    .mixin(StatFieldsMixin);
});

This would result in the following model layout...
model LastFiveGameAverages {
  PlayerID                Int      @id
  player                  Player   @relation(fields: [PlayerID], references: [PlayerID])
  Minutes                 Int?
  FantasyPoints           Decimal? @database.Decimal(4, 1)
  FieldGoalsMade          Decimal? @database.Decimal(4, 1)
  FieldGoalsAttempted     Decimal? @database.Decimal(4, 1)
  FieldGoalsPercentage    Decimal? @database.Decimal(4, 1)
  TwoPointersMade         Decimal? @database.Decimal(4, 1)
  // ...
}

Everything would be segmented into their own files, nice and clean!

Is there any update, guys? 😢

Is there any update, guys? 😢

Come on guys / girls. Do we really need to comment on this issue every 2-3 days?
I think, the prisma team is aware that this feature is requested by many devs. And i am pretty sure that they will work on a proper solution to address this issue.
However, the prisma dev team has made it clear that they have currently other issues they are dealing with.
All the best

Is there any update, guys? 😢

Come on guys / girls. Do we really need to comment on this issue every 2-3 days?
I think, the prisma team is aware that this feature is requested by many devs. And i am pretty sure that they will work on a proper solution to address this issue.
However, the prisma dev team has made it clear that they have currently other issues they are dealing with.
All the best

I did not have any intention to make any inconvenience to the Prisma team at all. Today was the first day I was trying Prisma out, and I was fascinated by how it really made a lot of things easier (Kudos to the incredible team behind it). I just was actually wondering if splitting Prisma schemas was actually a thing and was bumped into this issue and it kept me wonder.
Appreciating the massively great work by the Prisma team and hope the best to all!

Until then, we are still (as always) interested in your concrete problems and use cases where things currently do not work for you. When we start digging into this topic, we will read all of the replies here again and will use that to inform our design. Thanks.

For us, this kind of feature would simply make it more convenient to organize schemas into library and project specific code. Think many small/medium projects per year with a substantial amount of shared code and schemas. But it's not a huge deal. Mostly because the step of working on queries is separated anyway, so concatenating a bunch of files before that doesn't seem all that bad.
The way I would expect it to work would be something like include/import statements, but since we're not in JS land with .prisma files, some of the affordances of that ecosystem might not work as well or at all. Think build/organizational tools around npm/monorepos etc.

Agreed with the discussion above that there are clearly ways we can use to "join" schemas, but that it would cause the "split out" schema files to lose autocompletion/etc provided by the VSCode extension, which would indeed be a big deal given that Prisma's schema-first approach was specifically designed to keep things "safe"; by splitting out files, you lose said safety (unless the VSCode extension could be extended (hah) to provide autocomplete/highlight for the split out *.prisma files as well).

There isn't really any reason the extension couldn't be updated to do that.

I begun working on this feature, and the rabbit hole. Despite the plethora of people who have built third party solutions to this problem, including myself, it's requires much more change than meets the eye when it comes to the current implementation.
I've begun work on this feature myself, as I don't believe anyone else has decided to take the plunge. I'm very busy at work, but I will clean up my code and push it to my GitHub by the end of the next week or two. That way we can get some community-driven support for this feature. I'm not horribly familiar with Rust, nor have I worked with the VSCode language server API, so having a few people who are familiar with those would be awesome.
Despite that, I'll keep working on it in my spare time. Not sure if this is being worked on by the official Prisma team yet, so if someone from there could let me know before I sink a lot of time into this that'd be great.
All I've done so far as added import as valid syntax for the Rust AST parser, as well as prisma-fmt, no actual logic to merging the schema with the files that are imported has actually been done yet.

Is there any update, guys? 😢

Come on guys / girls. Do we really need to comment on this issue every 2-3 days?
I think, the prisma team is aware that this feature is requested by many devs. And i am pretty sure that they will work on a proper solution to address this issue.
However, the prisma dev team has made it clear that they have currently other issues they are dealing with.
All the best

I believe it is quite important. Sure, it must be quite a pain to have so many people requesting this feature but the sheer number of comments being received should also be received. I understand it's not easy to make changes and that it's an open source project, so people are (generally) willing to wait. However, please do not dismiss the people commenting.
If you build an open-source project that you want people to adopt because it's an amazing piece of kit, then you shouldn't be offended when it gets wide adoption and the community get passionate about features that will change their workflow for the better. There's a number of people in here who are downright rude, for sure - a lot of people are just asking for updates. Prisma is quickly becoming a core component to a large number of products that an even larger number of people depend on.
If the core team are busy working on other priorities, surely a short page showcasing workarounds built by the community is a reasonable compromise whilst it's in the backlog? You can post a final comment here with the link, close this thread and manage the request internally if it's causing issues.

Is there any update, guys? 😢

Come on guys / girls. Do we really need to comment on this issue every 2-3 days?

I think, the prisma team is aware that this feature is requested by many devs. And i am pretty sure that they will work on a proper solution to address this issue.

However, the prisma dev team has made it clear that they have currently other issues they are dealing with.

All the best

I believe it is quite important. Sure, it must be quite a pain to have so many people requesting this feature but the sheer number of comments being received should also be acknowledged. I understand it's not easy to make changes and that it's an open source project, so people are (generally) willing to wait. However, please do not dismiss the people commenting.
If you build an open-source project that you want people to adopt because it's an amazing piece of kit, then you shouldn't be offended when it gets wide adoption and the community get passionate about features that will change their workflow for the better. There's a number of people in here who are downright rude, for sure - a lot of people are just asking for updates. Prisma is quickly becoming a core component to a large number of products that an even larger number of people depend on.
If the core team are busy working on other priorities, surely a short page showcasing workarounds built by the community is a reasonable compromise whilst it's in the backlog? You can post a final comment here with the link, close this thread and manage the request internally if it's causing issues.

I'd just like to clarify that the post you referred to was not by a Prisma team member.
We definitely appreciate the continued discussion here and hope to work this into the roadmap when time allows.

This is a very very very ugly solution BUT you can create a custom folder where you have *.prisma files with your separate schemas. You can have a node scrip that concatenates all of those files. I'm sure folks have already done this out there

I have just released prisma-import in an attempt to temporarily address this issue.
I have refactored both the Prisma VSCode extension and the Language Server to understand import statements, as well as written a small library to merge all schemas into one that Prisma understands. Here's what it can do:
https://user-images.githubusercontent.com/57961822/208277040-1ee7293c-1288-4371-8207-ffc1d9f75aaf.mov
The extension is available here and essentially what it does is take care of parsing import statements and resolving a schema that can be fed to the Prisma formatter and linter. Here are some of the features:
All existing features in the official extension, plus:

Import syntax highlighting
Linting

Find errors within your import statements

Code Completion

Completion within import statements for schema paths and importable blocks
Completion for importable blocks and automatic import upon selection

Symbols for import blocks
Go to definition

Jump or peak an imported model, enum or type and open the schema that contains it

Formatting

Document formatting manually or on save
Format across schemas, like automatically adding missing relations on models

If you want to know more about how it works internally, the import syntax and an in-depth description of the project, you can read more here.
Hope it helps both us devs, and the Prisma team to get a feel of how imports could look like 🙌🏼
Happy holidays ahead!

@ajmnz hi, handsome, your repo link is 404

@ajmnz hi, handsome, your repo link is 404

hehe, forgot to make it public. You can find it here https://github.com/ajmnz/prisma-import

@ajmnz Very well done, well executed extension and proof of concept. Big enhancements to the DX in this regard.

I have just released prisma-import in an attempt to temporarily address this issue.
I have refactored both the Prisma VSCode extension and the Language Server to understand import statements, as well as written a small library to merge all schemas into one that Prisma understands. Here's what it can do:
https://user-images.githubusercontent.com/57961822/208277040-1ee7293c-1288-4371-8207-ffc1d9f75aaf.mov
The extension is available here and essentially what it does is take care of parsing import statements and resolving a schema that can be fed to the Prisma formatter and linter. Here are some of the features:
All existing features in the official extension, plus:

Import syntax highlighting

Linting

Find errors within your import statements

Code Completion

Completion within import statements for schema paths and importable blocks

Completion for importable blocks and automatic import upon selection

Symbols for import blocks

Go to definition

Jump or peak an imported model, enum or type and open the schema that contains it

Formatting

Document formatting manually or on save

Format across schemas, like automatically adding missing relations on models

If you want to know more about how it works internally, the import syntax and an in-depth description of the project, you can read more here.
Hope it helps both us devs, and the Prisma team to get a feel of how imports could look like 🙌🏼
Happy holidays ahead!

This is amazing ❤

I have just released prisma-import in an attempt to temporarily address this issue.
I have refactored both the Prisma VSCode extension and the Language Server to understand import statements, as well as written a small library to merge all schemas into one that Prisma understands. Here's what it can do:
https://user-images.githubusercontent.com/57961822/208277040-1ee7293c-1288-4371-8207-ffc1d9f75aaf.mov
The extension is available here and essentially what it does is take care of parsing import statements and resolving a schema that can be fed to the Prisma formatter and linter. Here are some of the features:
All existing features in the official extension, plus:

Import syntax highlighting

Linting

Find errors within your import statements

Code Completion

Completion within import statements for schema paths and importable blocks

Completion for importable blocks and automatic import upon selection

Symbols for import blocks

Go to definition

Jump or peak an imported model, enum or type and open the schema that contains it

Formatting

Document formatting manually or on save

Format across schemas, like automatically adding missing relations on models

If you want to know more about how it works internally, the import syntax and an in-depth description of the project, you can read more here.
Hope it helps both us devs, and the Prisma team to get a feel of how imports could look like 🙌🏼
Happy holidays ahead!

I'd love to try this out along with Aurora 💡

@ajmnz Very well done, well executed extension and proof of concept. Big enhancements to the DX in this regard. Would it be possible for you to add a license to that codebase so contributors and users know where to go from there?

Thanks!
Each package has its own. The ones that are a cloned from Prisma maintain their original one (I think Apache x) and the CLI is MIT licensed. I'll try to make it more clear.

Hi @ajmnz is there a way to install your package via npm?

I saw this issue was on the Prisma roadmap. Thank you for your hard working! Also wanna bump up the model inheritance (#1291 & #2506) to here for better consideration.

Hi @Yiak. I don't see it on the roadmap anymore:
https://prismaio.notion.site/Prisma-Roadmap-50766227b779464ab98899accb98295f
Do you think it was removed?

@mwanago Last time I saw the roadmap it was under the Planned section. So yes, I think they removed it from the roadmap recently. 😢

@mwanago @Yiak Thank you for your comments!
Some quick terminology:

a candidate is an initiative we consider very valuable. Candidates are prioritized against other initiatives during quarterly planning. A candidate might not make it to planned for an extended time period as long as there is more important work.
a planned initiative is part of a quarterly plan and hence the teams have committed working on them

Unfortunately, this initiative still hasn't made it to "planned". We know its in high demand and we kindly ask for your patience.
Regarding the roadmap: We recently removed the "candidates" from the roadmap and this is where issue #2377 was sitting. We felt the candidates did more harm than good as they often come with the expectation to be actually "planned". We know it would be great to know exactly what we are working on in the mid and long term but that is not how we want to build software. We need to be able to adapt and hence only commit to a ~3 months period.
It's still one of our best candidates but in the current quarter we are fully booked on improving the serverless experience with Prisma and other high demand gaps such as views and multi-schema support.
I really hope we get to this soon but we can't make any promises - I hope for your understanding 🙇

2023, and this is still not possible.
I wrote my own solution to split up the SCHEMA file which is also not possible by default.
Took me 1 hours and 1 hour to fine grain it.

That's cool that it took you a few hours to write a solution that stitches files together, but let's not grill the Prisma staff as if it would take a similarly tiny effort to implement it into the real thing. I've dove into the codebase before and begun an implementation, and the rabbit hole goes deep. ridafkih/schemix took a few hours to get a prototype up and running, but it would be disingenuous of me to cast that onto the Prisma staff.
Let's be respectful, remember the fact that everything that is needed to implement this into Prisma itself is open-source and available for anyone to add, the reason it hasn't been done by the community and has been deprioritized by Prisma is because it is a large effort.

This is no rant against Prisma but I don't understand why this simple feature request is not implemented?

It is not a simple feature. It is simple to think about and desire, but far less so to implement.  Treating schemas after the fact is much easier than implementing the functionality and tooling this would require in reality. As far as I know @ajmnz, who created prisma-import and I are the only ones who have begun and (perhaps) abandoned the effort of building the native-solution due to the fact that I doubt either of us have the free time needed to volunteer dedicating building it out. You are free to give it a go if it's as simple as your comment would leave one to believe. I'd be happy to point you in the right direction if you want a little head-start.

I've been patiently waiting for this to be supported for close the a year now haha, and will continue to be patient because god knows I can almost fathom how complicated it is to implement. Prismix has served us well for the longest time but it's since been archived by the owner. So outside of taking over maintenecne of it, my dream of the perfect dev setup resides solely on this issue 🤩
Reason I'm writing is that I wanted to throw another use case into the mix, as I believe this feature would vastly expand the usefulness of prisma into realms not fully explored yet.
What we've been trying to use prisma+prismix for is to have a monorepo containing a bunch of packages, all geared towards authoring one-off websites. One of the packages is '@company/core-schema' from which all website prisma schemas extend from (contains things needed for every website's CMS ie users auth, mulitsite functionality, page building, sitemap, asset management etc.), while some of the other packages are for smaller featuresets that could be optionally added to a web build e.g. '@company/schema-articles', '@company/schema-events'.
Each of these packages also contain CMS components, nextJS handlers etc. too.
So within each new web build that uses these packages there can be schema customizations on top of those combined prefab schemas.
We've even been able to automate the process of having migration files copied over from published packages if core schemas are updated. It still kind of boggles my mind at times just thinking of the absurdity of how all this was handled before prisma.
The concept of being able to extend schemas is extremely powerful, and I'm not sure if its application has been considered outside of just wanting to keep a single project's schema more tidy by splitting it into different files.
Just know there's a small team of devs over in Brisbane, Australia that would be extremely grateful if this was put back on the roadmap ♥♥

Damn, this should be the first thing Prisma team should focus on. How this cannot be a priority ?

Desiring to see this. My first models are all authentication related and I'd love to keep them organized together, outside the main schema file.

Damn, this should be the first thing Prisma team should focus on. How this cannot be a priority ?

Bit harsh, let the team providing an amazing open-source ORM do their work. If this gets enough traction it will be implemented, and there are temporary workarounds you can use in the meantime, such as https://github.com/prisma/prisma/issues/2377#issuecomment-1356629361.

Damn, this should be the first thing Prisma team should focus on. How this cannot be a priority ?

Bit harsh, let the team providing an amazing open-source ORM do their work. If this gets enough traction it will be implemented, and there are temporary workarounds you can use in the meantime, such as #2377 (comment).

In a flow, I wrote that, never wanted that to be harsh. thanks for pointing out, updated my comment.

Almost 3 years. Not implemented yet. c'mom

Not solved yet?☹

Damn, this should be the first thing Prisma team should focus on. How this cannot be a priority ?

Bit harsh, let the team providing an amazing open-source ORM do their work. If this gets enough traction it will be implemented, and there are temporary workarounds you can use in the meantime, such as #2377 (comment).

Let's be honest, it has enough traction. This is the first issue when you sort by like. Now I've read that the implementation is not as easy as it seems. I hear that, but having a single file with all models for a big-scale application is simply not a good idea. It should indeed be a priority.
Thanks to the dev for providing such a nice tool, and I hope you'll continue to have all the support you need! 💪

It's okay that the core team is prioritizing other issues, but it would be helpful if they could at least decide upon the high-level details (e.g. import syntax, configuration options, etc). There have been different proposal by the community, even some concrete implementations, and the ball is now in the core team's court to decide which way to go. I'm not saying that the core team should implement this feature, but if the design details would be fixed then the community could provide contributions implementing certain aspects in the ecosystem. For example, the vscode extension could be updated to include support of the to-be-decided import syntax independent of the support in the prisma client code. But currently every momentum to make progress on this is stopped by the missing design specification.

Please implement this feature.

I, and possibly up to 123 other participants, would be very happy if this issue could be locked for now. Recently the comments here are only noise notifying a lot of people.
I think the Prisma team sees the high demand for this feature and they will work toward implementing this as soon as possible.
Here's the last official statement: https://github.com/prisma/prisma/issues/2377#issuecomment-1383777754
I think creating a discussion for valuable feedback like use cases and such and locking this issue for now would be appropriate.
cc @floelhoeffel

Please, do not lock this issue.
I've been following this thing since day one, and people can easily manage the notifications.
It is helpful to ask for status from time to time and locking this would be the first step to completely forgetting about it. The result will be people creating duplicated issues asking the same thing.
Thanks!

Locking but keeping it open will still keep it up the issue list when ordering by reactions. The thing is I want notifications for status updates, but not "+1" like comments every day/week. Asking for status could be done in the mentioned discussion.

Locking but keeping it open will still keep it up the issue list when ordering by reactions. The thing is I want notifications for status updates, but not "+1" like comments every day/week. Asking for status could be done in the mentioned discussion.

If people are leaving +1 comments they're able to be muted/blocked from doing that again. This should remain open.
Every single time I've seen issues be locked that's it. They're basically dead as no one ever mentions them again and all similar issues are swiftly locked.

(Sorry for another meta comment, but the previous comments make it necessary)
First, a definition: "Lock conversation" means that no one besides members of the repository can post comments. It is different from "closing an issue" which removes it from the list of open issues and generally makes issues less visible.
That being out of the way:

We don't usually lock issues here at Prisma, at all (except when they are really not for commenting, e.g. here). We don't want to start doing that.
We close feature request issues when they are resolved, or if we disagree with their content and will not consider implementing them.
If we did lock issues though, it would also not mean that the issue's importance is forgotten. We are taking your feedback seriously. I am. That's my job as Product Manager of Prisma ORM. I can not always make everyone happy, but I do listen and hence am very aware which issues are active or not. (Which is also why I am here, posting this now!)
We ask people to please only leave relevant comments that add something to the discussion and feature request.

That mostly works, and sometimes does not, visible as +1 comments or similar that most people just perceive as noise.
We want people to leave 👍 reactions to the feature request issue instead to indicate their agreement instead if they are not adding relevant information.
We, unfortunately, do not have a way to moderate responses before they are posted. If there was, we might. Especially if we could turn it on e.g. only for popular feature request issues.
Retroactively hiding individual +1 comments does not undo the damage of notifications and emails to subscribed users, but only keeps people from seeing this as an ok way to interact with an issue. (There is a nuclear option to prevent someone from interacting with a repository including its issues, but we have never used that - and it would also only be retroactively and not avoid the notifications.)

We know how important this request to be able to split Prisma schema files is for many of our users, and promise (as we did before, above) that we will look into it as soon as it fits our priorities and capacity.
If anyone wants to continue this discussion around locking issues, please open a GitHub discussion and @ mention me or the person you are replying to, to avoid notifying the other 126+ people who subscribe to this feature request issue. (We will not continue the discussion about this topic here.) Thanks.

Member

bumping for visibiliity - small startup here and schema file's already at 60 models ... 1000+ lines...

Bumping this here as well. Over 1100 lines for configuring an ORM mapping is unacceptable. Great technology overall, but this is sorely missing!

Bumping this here as well. Over 1100 lines in one file for configuring an ORM mapping is unacceptable.

2000+ lines of pain here. Get on my level!

To temporarily solve this problem in a simple and quick way without having to use a third-party lib, I followed this procedure:
In my project I separated my files with the following structure:
src:
…/database
..……………/prisma
……………../models
Inside the prisma folder I put two files: ["index.prisma", "schema.prisma" ]
The "index.prisma" file is my base prism configuration file:
generator client {
 provider        = "prisma-client-js"
}

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

The "schema.prisma" file is my file that will be generated with the union of my Models:
Ex:
In the Models folder I create my Models separately:
"user.prisma"
model User {
 id    Int     @id @default(autoincrement())
 email String  @unique
 name  String?
}

"profile.prisma"
model Profile {
   id    Int     @id @default(autoincrement())
   user_id Int @unique
   user User @relation(fields: [user_id], references: [id])
}

Then when I want to generate a new version of my db I use a command to get all my models and unify them in a file next to the "index.prisma" file
Command I'm currently using:
"prisma:create-schema": "rm ./src/database/prisma/schema.prisma && cat ./src/database/prisma/index.prisma ./src/database/schemas/*.prisma > ./src/database/prisma/schema.prisma",
It is important to remember that if you change your schema.prisma file location, you must inform this in your package.json at:
 "prisma": {
   "schema": "./src/database/prisma/schema.prisma"
 },

So far I haven't had any problems with this implementation, but it's worth mentioning that I'm testing it on a small project, probably as the project grows I should come across some scenarios, but if that happens, I've been bringing more updates here in order to make the community curious.

@thulioxavier this is excellent and exactly how I’d like to see it work out of the box. Config in one file, each model in its own file. We just need prisms to generate the combined file when we run generate! Very nice.

To temporarily solve this problem in a simple and quick way without having to use a third-party lib, I followed this procedure:

Technically this works but it doesn't play nice with IDEs, specifically (in my case) VSCode using the Prisma extension. Your workflow would result in VSCode spitting out errors in the individual model files that the necessary relations don't exist.

Para resolver temporariamente esse problema de forma simples e rápida sem precisar usar uma lib de terceiros, segui este procedimento:

Tecnicamente, isso funciona, mas não funciona bem com IDEs, especificamente (no meu caso) VSCode usando a extensão Prisma. Eu tentei essa abordagem inicialmente também. Isso resulta em VSCode cuspindo erros nos arquivos de modelo individuais que as relações necessárias não existem.
Definitivamente não é o ideal.

This is the second point that I am working on a solution, but it should take about 2 months to complete.
As soon as I arrive at a suitable solution for this part I will update here.

Bumping this here as well. Over 1100 lines in one file for configuring an ORM mapping is unacceptable.

2000+ lines of pain here. Get on my level!

4800+ lines here. Hope this makes the near-future roadmap.

I have start work today the first time with prisma. Project, Documentation and so on, looks very nice. But i really miss the feature, to split the schema files for each one model in a own file. Its very important for the maintainable, readable and understanding of all my backend projects. I will try the solution from @thulioxavier (thx for this) but its a dsl and need always to explain.

I have start work today the first time with prisma. Project, Documentation and so on, looks very nice. But i really miss the feature, to split the schema files for each one model in a own file. Its very important for the maintainable, readable and understanding of all my backend projects. I will try the solution from @thulioxavier (thx for this) but its a dsl and need always to explain.

Agree, I was also starting with Prisma, but this was the first turn-off for me. 😅

I just wrote a simple bash script
mkdir -p ./src/db/temp

for file in ./src/db/models/*.prisma; do
    sed '/\/\/@relations/,$d' "$file" > "./src/db/temp/$(basename "$file")"
done

cat ./src/db/root.prisma ./src/db/temp/*.prisma > ./src/db/schema.prisma
rm -rf ./src/db/temp

So in your prisma folder structure will look like:
├── models
│   ├── post.prisma
│   └── user.prisma
├── root.prisma
└── schema.prisma
Also you need to add some sort of notation like //@relations so script can cut files properly
root.prisma
generator client {
  provider = "prisma-client-js"
}

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

models/user.prisma
model User {
    id    Int     @id @default(autoincrement())
    email String  @unique
    name  String?
    Post  Post[]
}

//@relations
model Post {
    id       Int  @id @default(autoincrement())
    author   User @relation(fields: [authorId], references: [id])
    authorId Int
}

models/post.prisma
model Post {
    id       Int    @id @default(autoincrement())
    content  String
    author   User   @relation(fields: [authorId], references: [id])
    authorId Int
}

//@relations
model User {
    id   Int    @id
    Post Post[]
}

As an alternative, you may want to take a look at a Prisma extension library ZenStack that we are currently working on. The schema is fully compatible with the Prisma schema and would be converted to the schema.prisma under the hood.
Besides supporting importing other schema files, we also support model inheritance to make your scheme DRY(Don’t repeat yourself). For example, you can have separate schema files, as demonstrated below (highlighting is not functional in markdown, but it works seamlessly with the Zmodel VScode extension):

base.zmodel

abstract model Base {
    id String @id
    createdAt DateTime @default(now())
    updatedAt DateTime @updatedAt
    // author has full access
    @@allow('all', auth() == author)
}

main.zmodel

import "base"
model User extends Basic {
    name String
}

model User extends Basic {
    name String
}

The generated prisma.schema would be like this:
/// @@allow('create,read', true)
/// @@allow('update,delete', auth() == this)
model User {
    name String
    id String @id()
    createdAt DateTime @default(now())
    updatedAt DateTime @updatedAt()
}

/// @@allow('create,read', true)
/// @@allow('update,delete', auth() == this)
model Post {
    title String
    id String @id()
    createdAt DateTime @default(now())
    updatedAt DateTime @updatedAt()
}

I’ve been a loyal Prisma user from the very start and it’s been such a joy watching it grow and improve.
That being said, I’ve also been following this issue right from the start, so I would like to wish this issue a happy birthday.
Keep up the fantastic work!
Cheers from Brazil.

Just chiming in to link to my comment on the issue #1122, in which I explain my use case concerning multiple schemas, with one schema per file. I really hope both issues will soon be resolved.

My schema for Benji reached 2000 lines. I'm begging you.

@kitze  There is a user adopted ZenStack only to modularize prisma schema file :

I use ZenStack because I can modularize the schemas and also extend from the Base model. Also saw some options in the documentation that I liked but have not implemented yet. I don't know if you are referring to an extension to this I told you about
abstract model Base {
    id Int @id @default(autoincrement())
    createdAt DateTime @default(now())
    updatedAt DateTime @default(now()) @updatedAt
    deletedAt DateTime?
}

Perhaps you could also consider giving it a try?

for real? almost 3 years of people asking for this feature and it was not implemented?
It should have high prio by now, need it badly as well.

it does more harm than good if it is introduced into the core
my opinion

@EndyKaufman In your opinion, how does it do more harm than good if introduced into the core?
I think having the ability to split the models into separate *.prisma files within ./prisma/models/ directory would be beneficial to developers that have large datasets.

I’d love to hear this justification. I can’t possibly see how doing this is harmful. It would take some work to update the vscode plugin to do validation across files instead of one but that doesn’t seem like a reason to not do it?

@synsa @eavonius
The schema is a representation of the database, if it is divided into pieces, then it will be necessary to keep these files in mind when generating migration and db-pull.
When processing keys for communication between tables, you will also need to keep everything in mind, synchronizing pieces in both directions from the schema to the database and from the database to the schema is a complex logic.
I don't mind files, yes - they are more convenient, but how to program it all into the core of the system, there will have to write a lot of code that can ruin what already exists.
There are problems what to do if a file with a piece of the scheme was deleted from the project, the system kernel should generate a migration to this.
Or if the file was renamed and the entities were left original, you need to understand that there was no deletion + creation of tables.
In my projects, I do not make a monolith base with one schema, I create functional independent modules with their databases and I do not have one giant file with a schema.
Yes - I don't have a relational relationship between modules, but I also don't have a physical relationship between module tables.
If such logic is introduced into prisma, people will want oop with inheritance, which will inflate the kernel code even more, which can lead to errors on many levels.
Open source solutions for a specific problem of collapsing and splitting schemes, I think the most ideal way to solve this problem.
This is my opinion)

@EndyKaufman thanks for your reply and expanding on your reasoning.
I may be misunderstanding some internal workings of the code, but here's what I'd envision may work around that.
What if there were simply a prisma\schema directory (parallel to prisma\migrations), and if this folder is not empty, any existing prisma commands would first run a piece of code that appends any models in it (say prisma\schema\MyTable.prisma) to the end of the existing main schema file in memory, and then writes the resulting file into prisma\schema\build\schema.prisma. This build directory would be excluded with .gitignore.
When you detect this file, all existing code that works off of the existing schema would simply use this copy instead of the original one. All existing error handling, key management, etc. would not have to deal with separate files.
The vscode plugin would still need to be updated to handle providing the same help for identifying missing relationships across files, but the main operation of prisma and all its commands seem like they would be minimally impacted.

when data is received from the database, a schema merge is started, there is no problem, since the schema is synchronized with what is in the database

in case of conflict two meta can resolve in my mind all case
@priority(1)  // in case of conflit overide with highter value
@merge // to try to merge as much as possible between two same name column or table
by default not try to merge and throw an error
or use that in comment of model
"""extend user
# xxxx priority 10
"""
model Product {
 xxxx Datetime
 title ...... @..... @...... @merge
}

this product is turning into a big joke. it is not a problem in any other ORM to split schemas, but prisma for years is refusing to implement it.
that is the reason am not using it on daily basis and am discouraging every client to use it. it just happened that i have a client right now who got it implemented by some other team before, if not that i would be not working with this either.
that should give you something to digest
most of features which are available in other ORM's in prisma are a big no, or are in feature requests for years, basic things are a big issue to achieve - in many cases you are ending up writing raw queries with prisma. anyway, you guys have fun. you could have way bigger market share if you wouldn't be so stubborn with inventing a wheel once again.

this product is turning into a big joke. it is not a problem in any other ORM to split schemas, but prisma for years is refusing to implement it.
that is the reason am not using it on daily basis and am discouraging every client to use it. it just happened that i have a client right now who got it implemented by some other team before, if not that i would be not working with this either.
that should give you something to digest
most of features which are available in other ORM's in prisma are a big no, or are in feature requests for years, basic things are a big issue to achieve - in many cases you are ending up writing raw queries with prisma. anyway, you guys have fun. you could have way bigger market share if you wouldn't be so stubborn with inventing a wheel once again.
your projects are small. try to make enterprise grade solution with this orm, you will be cursing non stop

This is not the place to vent your frustration, this is a github issue to discuss a feature enhancement. If you don't have anything to add to this, please avoid polluting the discussion. There are forums everywhere on the internet where you can go and vent. Again, this is not the place.

I'll bite @AfrazHussain:
We are aware of the feature request and the need behind it. It really is hard to overlook when spending time in our GitHub issues 😆 We have understood the different needs and suggestions and have some designs in mind that might solve some of these (mainly the primary one of just being able to split your Prisma schema file into multiple files).
Right now, this is not being worked on though, as we are busy with other things. So I can not give you an ETA or any concrete updates. When our capacity opens up, this issue is obviously close to the top of our list.