This is a translation, the original here: www.prisma.io/docs/unders…

An overview of the

This article will explain our motivation for developing Prisma and its advantages over other database tools, such as ORM and SQL constructors.

When developing Web applications, you spend a lot of time working with relational databases. You can spend hours debugging SQL queries or complex ORM object models.

Prisma provides a concise API that makes it easier to manipulate databases and understand queries. Prisma’s API is type-safe and the data returned is plain old JavaScript objects.



SQL, ORM and other database tools

The main problem with database tools that exist in the Node.js and TypeScript ecosystems is that there is a poor trade-off between productivity and control.



Handwriting SQL: strong control, weak productivity

Writing your own SQL (such as using Node.js database drivers such as PG and mysql) gives you complete control over database operations, but it’s not productive and involves a lot of minutiae (handling links manually, manipulating templates). Another problem with this approach is that you get query results that are not type-safe. You might write these query results by hand, but that would take a lot of time; Also, if you make changes to the database, your type files need to be consistent, which can take a lot of time.

In addition, when constructing SQL strings manually, the editor does not give you any hints (only some SQL keywords), which is extremely inefficient.


SQL constructor: Strong control, mediocre productivity

Many use SQL constructors (such as KNext-js) as a solution to increase productivity. This tool provides a high-level API for building SQL statements. The biggest problem is that such tools require developers to treat data from an SQL perspective, but application data is often relational, which can lead to a cognitive and physical difference in data. Developers often have to switch mental models to write good SQL statements.

Another problem is that developers can often shoot themselves in the foot if they don’t have a good grasp of SQL.

ORM: Weak control, good productivity

ORM allows developers to define all data as a class, a class is a table, and developers do not need to have a deep understanding of SQL.

You can read and write to the database using the class method, which is very convenient and very close to the developer’s mental model.

So what are the downsides?

ORM is like a quagmire that starts out flat but gets more complex over time and soon traps its users in promises with no clear cut-off point, no clear winning conditions, and no clear exit strategy

Developers think of data as a collection of objects, but it’s actually a table.


This cognitive difference leads to an object-relational Impedance mismatch, which is why many developers dislike traditional ORMs.

For example, the two types of cognitive object relationships are handled differently:

  • Relational databases assume that data is flat and use foreign keys to link different entities. If you want to reflect the relationship between two entities, you need to use JOIN statements.
  • Object-oriented believes that an object can be nested and that another entity connected to the entity can be accessed by point matching.

This example exposes a big pitfall of ORM: Using ORM ostensibly to access another entity via point conformance, but secretly constructing SQL Joins has performance traps that can slow down your application, such as the famous N +1 problem.


In summary, ORM has the advantage of abstracting the relational model and manipulating data only against objects. The problem, however, is that relational tables can’t be easily mapped to objects, which leads to a lot of complexity that can lead to pitfalls.

Developers should care about data, not SQL

SQL, born in the 1970s, is a proven language, but as development tools evolve, we have to ask, is SQL really the best way to abstract data?

After all, developers only need to care about the data involved when implementing requirements, rather than spending time figuring out complex SQL queries and structuring the query results to do so.

There’s also the argument that SQL is a powerful tool if you’re proficient in it; However, the LEARNING curve of SQL is steep, and many experienced SQL users will accidentally use the wrong SQL to step into the pit, resulting in performance loss of the application, and spend a lot of time debugging.

A developer needs a tool to get the data he or she needs without worrying about using the wrong SQL. He/she needs a tool to help them make the right choices, which means there needs to be a “healthy constraint” to prevent mistakes.


Prisma makes developers more productive

Prisma’s main goal is to make developers more productive with databases. Prisma has made the following efforts to achieve this goal:

  • Think in terms of objects, rather than mapping relational databases in your head
  • Queries are not classes to avoid complex data models
  • A single source of truth, databases and data models from the same place
  • Healthy constraints to prevent common pitfalls and anti-patterns
  • Make it easy to do the right thing (” The road to Success “)
  • The query result is type safe
  • Use fewer templates so developers can focus on the business
  • The editor completes automatically

Going back to the previous picture, Prisma is positioned like this



The control force is higher than SQL constructor, lower than handwritten SQL;

But the most productive!