Prisma Data Platform

A quick look at the features and missing pieces

Today, we are going to take a look at Prisma Data Platform. It’s a service from Prisma that does a few nice things for developers who need a database to store data. In this post I’m going to go through the project creation flow, and give you my thoughts as I go.

The first step is landing on the homepage, and signing in with GitHub.

You can head over to cloud.prisma.io to get started. After signing in for the first time, it asks us for a project name and a github org we want to create a repo inside of.

They have a few example templates we can choose from, I chose the URL Shortener one.

On the third step, I chose to setup a MySQL database using PlanetScale. You can link your own database, or choose from Heroku as another option.

It would be nice if you could link AWS or other cloud providers. Even though there isn’t a linking flow, you are able to manually add one yourself.

On the final step, we need to deploy the project to Vercel for this first time:

It’s pretty straight forward, it just involves copying 3 env variables into Vercel after pressing the deploy button pictured above.

One concern so far, is that you must have a GitHub account (fine), a Vercel account (you probably have one of these) and then a third provider if you want a fully hosted flow, PlanetScale, or Heroku. Thankfully these services have quick signup flows, but three services is less than ideal for many people.

Why this platform?

The key reason to use Prisma Data Platform… well, that would be the data proxy!

The Prisma Data Proxy is a connection pooler that sits in front of your database, and allows you to scale database connections in serverless environments.

This is really useful for lambdas / google cloud functions / edge functions… basically any serverless platform! Your functions might be invoked 100 times per second, and the proxy will ensure connections to the database are pooled and you aren’t trying to do more connections than your database can handle.

It’s also a nice place to see the contents of your database, view the prisma schema, and play around with writing queries using Prisma Client.

Initial Setup: Complete!

At this stage, your vercel project should be deployed. You can take a look at mine right now: testapp-hazel.vercel.app.

That was pretty fast, and a very easy way to setup the entire data layer for an application. So far, I like it.

Databases?

If you’re brand new to databases and following along for fun, I highly recommend reading the Prisma data guide. It gives an in depth overview of databases and how they work.

Problems…

I thought Prisma’s project templates would handle automatically migrating our database if you make changes to the prisma schema, but that isn’t the case.

I would say this is the most difficult part of the platform, for new developers.

For experienced developers, this is a pretty easy fix. You need to add this to your package.json build script for Vercel:

"build": "prisma generate --data-proxy && DATABASE_URL=\"$DATABASE_MIGRATE_URL\" prisma migrate deploy"

This will ensure any pending migrations get processed when your application deploys.

The only remaining problem is: you need to setup a local database server to actually create migration files, before you can commit them and deploy to your production one that is linked on Prisma Data Platform.

This is a bit too detailed for those who are brand new to prisma, but the problem is, Prisma requires creating a shadow database in order to compute migration changes.

Ex: you added a new field to prisma.schema, it needs a real database to compare against to create a migration.

PlanetScale doesn’t allow this, so you need to create a separate environment to actually build out your application.

This is probably okay… but the reason I’m explaining all of this, is I couldn’t find any docs on the Data Platform section mentioning anything specific about running migrations, which seems pretty crucial. It would be helpful if they provided strategies specific to the data platform, or included a more automated approach in their templates.

Should I use it?

This depends on two things.

If you are already using Prisma

This is a small upgrade for your setup. You get a hosted database viewer, so you don’t need to run anything locally for the rare times you need to connect to production.

You can see your production schema file, but you could also view it on the main branch on github as well, so it’s not extremely helpful.

The biggest thing you are getting, is the data proxy for your database. If you are using serverless functions with a high load application, this is the real selling point.

If you aren’t using Prisma yet

It’s a great introduction for new developers to the platform. You get a production environment, and you also get a way to test out queries to Prisma client.

You get example templates so you can understand how Prisma works and if it’s the right fit for your company.

Would I use it

Yes. It’s a nice way to add your database environments in one location and easily visualize the data in each environment. It’s safer than running prisma’s viewer manually on your local machine with many environments.

That being said, I do wish there was more being offered.

I think they could build out a more automated way to handling migrations. If the schema file is updated, I would like the data platform to compute and generate migration files automatically. I would also like it to auto migrate the database for me when I commit those changes.

Any way to handle more work that is currently a manual process would make this platform even more enticing to new users.

If this is your first time hearing about Prisma, I highly recommend going to prisma.io and reading up on it. It’s the best database platform in any language, not much can compete with what it can do.