PlanetScale + Prisma: Configure ORM for Vitess (2026)

PlanetScale’s Vitess is a sharded MySQL database that’s great for scaling, and Prisma is a modern ORM that makes database interactions a breeze. Getting them to play nice means configuring Prisma to talk to Vitess, which isn’t quite the same as talking to a regular MySQL instance.

Here’s a Vitess cluster running locally with vttablet instances, and a vtgate endpoint. We’ll connect Prisma to vtgate.

# Assuming you have Vitess running and vtgate is accessible on port 15991
# This is a simplified example; your Vitess setup might differ.

# Example of a Prisma schema file (schema.prisma)
datasource db {
  provider = "mysql"
  url      = env("DATABASE_URL")
}

generator client {
  provider = "prisma-client-js"
}

model User {
  id    Int    @id @default(autoincrement())
  name  String
  email String @unique
}

And your .env file:

DATABASE_URL="mysql://root@localhost:15991/mykeyspace"

This sets up Prisma to use mysql as its provider, which is correct because Vitess speaks MySQL. The key is the DATABASE_URL. For Vitess, you point this to the vtgate service. vtgate acts as the gateway, understanding Vitess’s sharding and routing logic, and presenting a unified MySQL endpoint to clients like Prisma. The root user and mykeyspace are placeholders; you’ll use your actual Vitess user and keyspace.

The real magic happens because Vitess, through vtgate, translates standard MySQL protocol requests from Prisma into Vitess-aware operations. When Prisma issues a SELECT or INSERT statement, vtgate intercepts it, determines which shards hold the relevant data based on your schema and Vitess configuration, and forwards the query to the appropriate vttablet instances. The results are then reassembled by vtgate before being sent back to Prisma. This means you don’t need to modify your Prisma schema or queries to account for sharding; Vitess handles it all transparently.

One thing many people overlook is the mysql provider in schema.prisma. Even though you’re connecting to Vitess, you must use the mysql provider. Prisma’s mysql provider is designed to work with MySQL-compatible endpoints. Vitess, by exposing vtgate as a MySQL endpoint, fits this requirement perfectly. This allows Prisma to use its existing MySQL drivers and query generation logic without needing a separate Vitess-specific provider.

The next hurdle you’ll likely encounter is managing Vitess-specific connection pooling and transaction management, which can differ from standard MySQL setups.