Prisma 7 Datasource url No Longer Supported? Fix It Now

You run npm install on a Monday morning.

You push to Vercel. The build fails.

The error reads: P1012: The datasource property 'url' is no longer supported in Prisma schema files.

You didn't touch schema.prisma. You didn't upgrade Prisma on purpose. But ^6.5.0 in your package.json pulled in v7 overnight.

Now nothing builds.

This is the prisma 7 datasource url no longer supported error. It hits every team upgrading from v6 - often without touching a single config file. Here's the full fix for every failure mode you'll hit, in the order you'll hit them.

If you're also seeing driver adapter errors during migration, read that guide first - then come back here for the CI/CD and Turbopack sections.

Quick Answer

Prisma 7 removed the url property from schema.prisma. Move your database connection to a new prisma.config.ts file. Use a driver adapter like @prisma/adapter-pg. Remove url = env("DATABASE_URL") from your datasource block, install the adapter, create the config file, and update your PrismaClient call. If you're on Next.js with Turbopack, there's a second crash after this one - covered below.

Why Prisma 7 Datasource url No Longer Supported Breaks Your Build

Prisma 7 shipped on November 19, 2025.

The biggest change: connection config moved out of schema.prisma and into prisma.config.ts. Driver adapters became mandatory.

This is not a deprecation warning. url is fully removed. Any project still using it throws P1012 on startup.

The Silent Upgrade Trap

The caret range in your package.json is the root cause for most teams.

json

// Wrong: Caret range - pulls v7 silently on fresh install
{
  "dependencies": {
    "prisma": "^6.5.0",
    "@prisma/client": "^6.5.0"
  }
}

npm reads ^6.5.0 as "6.5.0 or higher, below 7.0.0."

But when a lockfile drifts or a teammate runs npm install fresh, npm can resolve v7.

I hit this on a Next.js 15 + Supabase project. A teammate pulled main and ran npm install. The lockfile had drifted. Prisma 7 resolved. The build failed on the first next dev.

The fix is one line:

json

// Correct: Pinned version - no silent major upgrades
{
  "dependencies": {
    "prisma": "7.0.0",
    "@prisma/client": "7.0.0"
  }
}

Pin it. Whether you stay on v6 or move to v7, use an exact version. Never use ^ across a major version boundary for your ORM.

The P1012 Error - Root Cause and Fix

This is the full error Prisma 7 throws:

Error: P1012

The datasource property 'url' is no longer supported in Prisma schema files.
Please use the prisma.config.ts file to configure your datasource connection instead.

What Your Old schema.prisma Looks Like

prisma

// Wrong: schema.prisma v6 pattern - breaks in Prisma 7
datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

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

Prisma 7 reads the datasource block. It sees url. It throws P1012 and stops.

Step 1 - Clean schema.prisma

prisma

// Correct: schema.prisma v7 pattern
datasource db {
  provider = "postgresql"
}

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

Remove url. Also remove directUrl and shadowDatabaseUrl if you had them.

The provider stays. Only the connection properties go.

Step 2 - Create prisma.config.ts

Create this file at your project root (same level as package.json):

typescript

// Correct: prisma.config.ts - required in Prisma 7
import { defineConfig } from "prisma/config";
import { PrismaPg } from "@prisma/adapter-pg";

export default defineConfig({
  earlyAccess: true,
  schema: "prisma/schema.prisma",
  migrate: {
    async adapter(env) {
      return new PrismaPg({ connectionString: env.DATABASE_URL });
    },
  },
});

The earlyAccess: true flag is required. Without it, Prisma 7 ignores the file. It falls back to schema.prisma, finds no url, and throws P1012 again.

Installing the Driver Adapter

Prisma 7 no longer manages database connections itself. You pick the adapter for your database.

For PostgreSQL (Supabase, Neon, Railway):

bash

npm install @prisma/adapter-pg

For MySQL:

bash

npm install @prisma/adapter-mysql

For SQLite:

bash

npm install @prisma/adapter-better-sqlite3

Install the one that matches your provider in schema.prisma. Only one adapter per project.

Rewriting PrismaClient - The Second Breakage Point

This is where most developers get stuck after fixing P1012.

What Breaks in Prisma 7

typescript

// Wrong: v6 pattern - throws TypeError in Prisma 7
import { PrismaClient } from "@prisma/client";

const prisma = new PrismaClient();
export default prisma;

Prisma 7 throws this when you do that:

TypeError: Cannot read properties of undefined (reading '__internal')

This is GitHub issue #28663 - "my prisma 6.18 got upgraded to Prisma 7 then breaks everything." The cause: PrismaClient now needs an adapter at construction time.

The Correct v7 Pattern

typescript

// Correct: lib/db/prisma.ts - Prisma 7 with adapter
import { PrismaClient } from "@prisma/client";
import { PrismaPg } from "@prisma/adapter-pg";

const adapter = new PrismaPg({
  connectionString: process.env.DATABASE_URL!,
});

const globalForPrisma = global as unknown as { prisma: PrismaClient };

export const prisma =
  globalForPrisma.prisma ||
  new PrismaClient({
    adapter,
    log:
      process.env.NODE_ENV === "development"
        ? ["query", "error"]
        : ["error"],
  });

if (process.env.NODE_ENV !== "production") {
  globalForPrisma.prisma = prisma;
}

The globalForPrisma pattern stops hot-reload from creating new PrismaClient instances each time. Same as v6 - only the adapter argument is new.

The Turbopack Secondary Crash

Fix the P1012 error. Run npx prisma generate. Start Next.js with --turbopack.

Then this appears:

Error: Cannot find module '.prisma/client/default'

Why This Happens

Turbopack resolves module paths differently from Webpack.

If your generator block has a custom output path, Turbopack cannot find the client at that location:

prisma

// Wrong: Custom output breaks Turbopack in Prisma 7
generator client {
  provider = "prisma-client-js"
  output   = "../node_modules/.prisma/client"
}

Fix 1 - Remove Custom Output

prisma

// Correct: No custom output - Turbopack resolves correctly
generator client {
  provider = "prisma-client-js"
}

Run npx prisma generate and restart. This works for most projects.

Fix 2 - Use prisma-client Provider (Monorepos)

If you need a custom output path for a monorepo, switch the provider:

prisma

// Correct: prisma-client provider for custom output paths
generator client {
  provider = "prisma-client"
  output   = "../../packages/db/client"
}

The prisma-client provider is new in Prisma 7. It handles Turbopack path resolution correctly.

I found this after 35 minutes of debugging. The prisma generate output looked clean. schema.prisma was correct. Next.js kept throwing the module error. Switching from prisma-client-js to prisma-client in the generator block fixed it.

CI/CD - DATABASE_URL Is No Longer Auto-Read

Local dev works. You push. The deployment fails.

This is the CI/CD version of the same problem.

In Prisma v6, Prisma read your .env file automatically. In v7, prisma.config.ts reads from process.env directly. CI/CD pipelines that pass secrets as env vars still work. But .env files are not loaded unless you load them yourself.

GitHub Actions - What to Change

yaml

# Correct: .github/workflows/deploy.yml - Prisma 7 compatible
name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "20"

      - name: Install dependencies
        run: npm ci

      - name: Generate Prisma client
        run: npx prisma generate
        env:
          DATABASE_URL: ${{ secrets.DATABASE_URL }}

      - name: Run migrations
        run: npx prisma migrate deploy
        env:
          DATABASE_URL: ${{ secrets.DATABASE_URL }}

Set DATABASE_URL in your repo: Settings > Secrets and variables > Actions > New repository secret.

Local Dev With dotenv

If you need .env to work locally while CI uses real env vars:

typescript

// Correct: prisma.config.ts with dotenv for local dev
import { defineConfig } from "prisma/config";
import { PrismaPg } from "@prisma/adapter-pg";
import * as dotenv from "dotenv";

if (process.env.NODE_ENV !== "production") {
  dotenv.config();
}

export default defineConfig({
  earlyAccess: true,
  schema: "prisma/schema.prisma",
  migrate: {
    async adapter(env) {
      return new PrismaPg({ connectionString: env.DATABASE_URL });
    },
  },
});

Install it first: npm install dotenv.

The Complete Migration Checklist

Do these in order. Do not skip steps.

1. Pin your version:

bash

npm install prisma@7.0.0 @prisma/client@7.0.0

2. Install your driver adapter:

bash

npm install @prisma/adapter-pg

3. Clean schema.prisma - remove url from datasource:

prisma

datasource db {
  provider = "postgresql"
}

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

4. Create prisma.config.ts at project root:

typescript

import { defineConfig } from "prisma/config";
import { PrismaPg } from "@prisma/adapter-pg";

export default defineConfig({
  earlyAccess: true,
  schema: "prisma/schema.prisma",
  migrate: {
    async adapter(env) {
      return new PrismaPg({ connectionString: env.DATABASE_URL });
    },
  },
});

5. Update PrismaClient - add the adapter argument (see lib/db/prisma.ts above).

6. Regenerate the client:

bash

npx prisma generate

7. Test migrations:

bash

npx prisma migrate dev

If you hit the Turbopack crash after step 6, remove output from the generator block. Or switch to the prisma-client provider.

For a deeper dive into adapter patterns, see the Prisma 7 migration errors guide.

Key Takeaways

• Prisma 7 fully removes url from the datasource block in schema.prisma - it throws P1012 immediately, not a warning

• The silent upgrade comes from caret ranges like ^6.x in package.json - pin to an exact version to stop it

• new PrismaClient() without an adapter throws TypeError: Cannot read properties of undefined (reading '__internal') in Prisma 7 - always pass the adapter at construction

• The Turbopack crash (Cannot find module '.prisma/client/default') comes from a custom output in the generator block - remove it or switch to the prisma-client provider

• CI/CD pipelines using env secrets still work - v7 reads process.env, not .env files automatically

• The earlyAccess: true flag in prisma.config.ts is not optional - without it, Prisma ignores the file and throws P1012 again

FAQs

• What is the prisma 7 datasource url no longer supported error?

  This is error P1012. It fires when Prisma 7 finds a url property inside the datasource block of schema.prisma. Prisma 7 removed url from the schema entirely. The fix: delete url = env("DATABASE_URL") from your datasource block, create a prisma.config.ts file, and use a driver adapter like @prisma/adapter-pg.

• Why did Prisma 7 upgrade without me doing anything?

  Your package.json likely uses a caret range like ^6.5.0. When a lockfile drifts or a fresh npm install runs without a lockfile, npm can resolve v7. Pinning to an exact version like 7.0.0 (no caret, no tilde) stops this.

• Do I need a driver adapter for every database type?

  Yes. Prisma 7 no longer manages connections. Every database needs an adapter. Use @prisma/adapter-pg for PostgreSQL, @prisma/adapter-mysql for MySQL, and @prisma/adapter-better-sqlite3 for SQLite. Pass it to new PrismaClient({ adapter }).

• What is the earlyAccess flag in prisma.config.ts?

  It tells Prisma 7 to read prisma.config.ts. Without it, Prisma ignores the file. It falls back to schema.prisma, finds no url, and throws P1012 again. Always include earlyAccess: true in v7.

• Why does Prisma crash with "Cannot find module '.prisma/client/default'" with Turbopack?

  A custom output path in the generator block causes this. Turbopack resolves paths differently from Webpack. Remove the output line, run npx prisma generate, and restart. For monorepos, switch the generator provider from prisma-client-js to prisma-client.

• Does Prisma 7 work with Supabase or Neon?

  Yes. Both are PostgreSQL. Install @prisma/adapter-pg and pass the connection string as DATABASE_URL. Migration commands like prisma migrate deploy and prisma migrate dev work the same. Only where the connection string lives has changed - prisma.config.ts, not schema.prisma.

• Do I need to update my GitHub Actions workflow for Prisma 7?

  Only if you relied on .env file loading during CI. If you already pass DATABASE_URL as a GitHub Actions secret, the workflow works. Add env: DATABASE_URL: ${{ secrets.DATABASE_URL }} to both the prisma generate and prisma migrate deploy steps to be explicit.

• Can I use Prisma 7 without TypeScript?

  The prisma.config.ts file needs TypeScript or a build step that handles .ts files. Next.js and Vite both handle this. Plain JavaScript projects need ts-node or a .js version with CommonJS exports. Prisma recommends TypeScript for v7 forward.

Conclusion

Prisma 7's new architecture is cleaner. Connection config belongs in a config file, not a schema file. That separation makes sense.

But the migration is a real wall - not one wall, five. The P1012 error is just the first. The __internal TypeError, the Turbopack module crash, and the CI/CD secret gap are behind it.

Now you know all five. Work through the checklist in order and you're done.

If you're picking between Prisma and Drizzle for your next project, the Prisma vs Drizzle for Next.js guide breaks down when each one is the right call.