Nikolas from the Prisma team here! > It seems to take a lot of inspiration from the mongo api That's an interesting comment but I'm not sure it's quite accura

Nikolas from the Prisma team here! > It seems to take a lot of inspiration from the mongo api That's an interesting comment but I'm not sure it's quite accurate. I think where we're taking quite a bit of inspiration from MongoDB is the idea of "thinking in objects" because this is much closer to the mental model developers have when they work with data. We are currently already working on an improved API of Prisma Client [1] that looks less like MongoDB but should feel a lot more ergonomic. Regarding your example of removing the `where` from a `findOne` call. In this case it's needed because you can also select/include [2] fields and/or relations: await prisma.users.findOne({ where: { id: 1 }, include: { posts: true } }) But we're aware that the API is quite verbose at times, so we're already working on slimming it down. Here's the proposal from the new API spec: await prisma.users.findOne(1).load({ include: { posts: true } }) > There is a hard limit of where ORMs try to take over too many of the things you do in SQL and become slow and complex and a big black hole. I just want to stress that Prisma is not an ORM! ORMs are characterized by the fact that classes are mapped to tables and you have complex model instances that carry logic for storage, retrieval, serialization, deserialization and often custom business logic. Prisma does none of that! It provides an auto-generated and fully type-safe database client that's tailored to your database schema. Any data you'll ever retrieve is fully typed and comes in the form of plain old JS objects that a are easy to reason about. > prisma tries to do migrations, table creation, etc, etc. These things rarely work properly. I'd love to learn more about where you think Prisma's migrations approach falls short! IMHO moving towards a dclarative migration system based on an intuitive data modelling language is much closer to how developers are thinking about their data than using SQL migrations. One of our users once described it like this: "What Prisma does for migrations is essentially what React does for rendering. A user need only describe the current state, but not the operations to get to that state. So, thank you for doing this to databases as React (and others) has for UIs!" > Lazy loading never works. Somewhere litered in your code you access a field that is outside the scope of the pulled in data and it is in a loop and suddenly you have 100 requests. Do you mind elaborating how/where you see this problem happening in Prisma? > There are security issues with ORMs that traverse and save relationships, as github itself found out. Again, Prisma is not an ORM and I have a hard time seeing how this applies to it. > ORMS should just be for fairly simple, single table tasks. That way they get out of the road and don't become some big complex thing that ruins performance and adds its own complexity. I fully agree with this poinit and it's one of the core desiign goals of Prisma. If you feel Prisma doesn't achieve this, we're doing something wrong... All that being said, I really appreciate your thoughts and feedback and would love to see you in the Prisma Slack [3] and sharing your thoughts in our GitHub issues. [1] https://github.com/prisma/specs/issues/356 https://github.com/prisma/specs/issues/356 [2] https://github.com/prisma/prisma2/blob/master/docs/prisma-client-js/api.md#field-selection https://github.com/prisma/prisma2/blob/master/docs/prisma-cl... [3] https://slack.prisma.io https://slack.prisma.io