Prisma is a new kind of ORM that - like any other tool - comes with its own tradeoffs. This page explains when Prisma would be a good fit, and provides alternatives for other scenarios.
This is the main use case for Prisma. Server-side applications typically are API servers that expose data operations via technologies like REST, GraphQL or gRPC. They are commonly built as microservices or monolithic apps and deployed via long-running servers or serverless functions. Prisma is a great fit for all of these application and deployment models.
Productivity and developer experience are core to how we're building our tools. We're looking to build developer-friendly abstractions for tasks that are complex, error-prone and time-consuming when performed manually.
No matter if you're a SQL newcomer or veteran, Prisma will give you a significant productivity boost for the most common database workflows.
Here are a couple of the guiding principles and general practices we apply when designing and building our tools:
Prisma shines especially when used in collaborative environments.
The declarative Prisma schema provides an overview of the current state of the database that's easy to understand for everyone. This is a major improvement to traditional workflows where developers have to dig through migration files to understand the current table structure.
Prisma Client's minimal API surface enables developers to pick it up quickly without much learning overhead, so onboarding new developers to a team becomes a lot smoother.
The Prisma Migrate workflows are designed in a way to cover database schema changes in collaborative environments. From the initial schema creation up to the point of deploying schema changes to production and resolving conflicts that were introduced by parallel modifications, Prisma Migrate has you covered.
Prisma is a lot more than "just another ORM". We are building a database toolkit that covers the daily workflows of application developers that interact with databases. A few examples are:
Prisma is the only fully type-safe ORM in the TypeScript ecosystem. The generated Prisma Client ensure typed query results even for partial queries and relations. You can learn more about this in the type-safety comparison with TypeORM.
Development of Prisma's open source tools is happening in the open. Most of it happens directly on GitHub in the main
- issues and PRs in our repos are triaged and prioritized (usually within 1-2 days)
- there is a public roadmap that is kept up to date with our plans
- new releases with new features and improvements are issued every two weeks
- we have a dedicated support team that responds to questions on Slack and GitHub
- our product team is always eager to talk to you in the
#product-feedbackchannel on Slack to get your feedback about Prisma
Prisma is an abstraction. As such, an inherent tradeoff of Prisma is a reduced amount of control in exchange for higher productivity. This means, the Prisma Client API might have less capabilities in some scenarios than you get with plain SQL.
While Prisma does allow you to send plain SQL queries to your database, there might still be cases where this is not enough (e.g. when you absolutely need a long-running transaction or when you need special control over the database connection).
If your application has requirements for database queries that Prisma does not provide and the workarounds are too costly, you might be better off with a tool that allows you to exercise full control over your database operations using plain SQL.
Note: If you can work around a certain limitation but still would like to see an improvement in the way how Prisma handles the situation, we encourage you to create a feature request on GitHub so that our Product and Engineering teams can look into it.
If you don't want to write any code for your backend and just be able to generate your API server and the database out-of-the-box, you might rather choose a Backend-as-a-Service (BaaS) for your project.
With a BaaS, you can typically configure your data model via a high-level API (e.g. GraphQL SDL) or a visual editor. Based on this data model, the BaaS generates a CRUD API and provisions a database for you. With this setup, you typically don't have control over the infrastructure the API server and database are running on.
With Prisma, you are building the backend yourself using Node.js or TypeScript. This means you'll have to do a lot more coding work compared to using a BaaS. The benefit of this approach is that you have full flexibility for building, deploying, scaling and maintaining your backend and are not dependent on 3rd party software for a crucial part of your stack.
While tools like the
typegraphql-prisma allow you to quickly generate CRUD operations for your Prisma models in a GraphQL API, these approaches still require you to set up your GraphQL server manually and do some work to expose GraphQL queries and mutations for the models defined in your Prisma schema.
If you want to get a GraphQL endpoint for your database out-of-the box, other tools might be better suited for your use case.
While Prisma does allow you to send plain SQL queries to your database, it might not be the best fit if you prefer to work with a SQL-based abstraction that you want to be type-safe. Prisma's main benefit is to provide an abstraction layer that makes you more productive compared to writing SQL.
If you're a solo developer that is very comfortable with SQL, and you just want to be sure that your database layer is type-safe, a lower-level TypeScript database library might be better for you.