Nikolas Burk, developer relations at Prisma — the database ORM — recently announced that all Prisma tools (Prisma Client, Prisma Studio, Prisma Migrate) are ready for production usage. Prisma Migrate graduated from preview this year and is now generally available.
Burk summarized the rationale behind the Prisma suite of tools as follows:
At Prisma, we found that the Node.js ecosystem — while becoming increasingly popular to build database-backed applications — does not provide modern tools for application developers to deal with these tasks [—data modeling, schema migrations, and writing database queries].
Application developers should care about data — not SQL.
As tools become more specialized, application developers should be able to focus on implementing value-adding features for their organizations instead of spending time plumbing together the layers of their application by writing glue code.
Prisma proposes three tools that cater to different remote data management aspects. The Prisma Client is an auto-generated and type-safe query builder that lets developers perform create, read, update and delete (CRUD) operations on an underlying database. Prisma Studio is a user interface application with which developers may visually explore and manipulate the contents of a database.
The newly generally available Prisma Migrate strives to streamline an iterative development process in which a database schema is modified together with the querying application. Daniel Normal, developer advocate at Prisma, summarizes the goal of Prisma Migrate as follows:
Today’s data-driven applications demand constant change. When working with a relational database, managing a continually evolving schema can be a challenge.
Prisma Migrate is a database schema migration tool that simplifies evolving the database schema in tandem with the application. […] Prisma Migrate treads the balance between productivity and control by automating the repetitive and error-prone aspects of writing database migrations while giving you the final say over how they are executed.
Prisma Migrate features a database schema DSL in which developers may express database entities and relationships between entities:
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}
model User {
id Int @id @default(autoincrement())
email String @unique
name String?
birthdate DateTime @db.Date
activated Boolean @default(false)
}
The schema DSL is translated to SQL migration scripts:
-- The SQL can be edited prior to execution
-- CreateTable
CREATE TABLE "User" (
"id" SERIAL NOT NULL,
"email" TEXT NOT NULL,
"name" TEXT,
"birthdate" DATE NOT NULL,
"activated" BOOLEAN NOT NULL DEFAULT false,
PRIMARY KEY ("id")
);
-- CreateIndex
CREATE UNIQUE INDEX "User.email_unique" ON "User"("email");
As the database schema evolves, Prisma Migrate generates a history of .sql migration files in a dedicated folder:
migrations/
└─ 20210313140442_init/
└─ migration.sql
└─ 20210313140442_added_job_title/
└─ migration.sql
While Prisma Migrate covers commonly occurring schema changes (e.g., adding fields), developers may need to customize the migration scripts to add code specific to a database vendor or provide for an unhandled use case. The Prisma Migrate documentation mentions a few examples: renaming a field, changing the types of field, or changing the direction of a one-to-one relationship.
Developers on Reddit have emphasized that while having an ORM abstraction sit between the database(s) and the application may be useful, they still in practice need to know about SQL and the specifics of the underlying database — in particular for query optimization and performance purposes. This led some developers to advocate bypassing the abstraction altogether. Burk argued back that the cases in which the ORM abstraction leaks are infrequent enough to significantly dent Prisma’s added value:
SQL is complex, it’s easy to shoot yourself in the foot with it, and its data model (relational data/tables) is far away from the one application developers have (nested data/objects) when working in JS/TS. Mapping relational data to objects incurs a mental as well as a practical cost!
[…] In the majority of cases (which for most apps are fairly straightforward CRUD operations) developers shouldn’t pay that cost. They should have an API that feels natural and makes them productive. That being said, for the 5% of queries that need certain optimizations, Prisma allows you to drop down to raw SQL and make sure your desired SQL statements are sent to the DB.
I see Prisma somewhat analogous to GraphQL on the frontend, where a similar claim could be: “Frontend developers should care about data, not REST endpoints”. GraphQL liberates frontend developers from thinking about where to get their data from and how to assemble it into the structures they need.
The Prisma-generated migration history can be version-controlled so that the changes of schema can be tracked together with the rest of the application under development. Prisma Migrate currently supports PostgreSQL, MySQL, SQLite, and SQL Server (in Preview).
A recent crop of frameworks and meta-frameworks have added Prisma to their stack. Redwood, a full-stack framework that seeks to bring the Ruby on Rails experience to JavaScript; Wasp, a web app DSL written in Haskell; and Blitz, a full-stack React Framework built on Next.js, are all using Prisma for their data layer.
The Prisma documentation is available online and contains a conceptual introduction accompanied by tutorials. Prisma is a company backed by venture capital that provides open-source software distributed under the Apache 2.0 license.