Documentation
Framework guides

Use Prisma with Renviq

A secure development and production migration workflow without granting CREATEDB.

10 minute read · Updated September 2026

Why Prisma needs two URLs

prisma migrate dev uses a temporary shadow database to detect drift and calculate migration changes. Renviq customer roles intentionally do not receive CREATEDB on shared infrastructure, so the application database cannot create that shadow database itself.

Renviq-native solution

The Connect with Prisma wizard creates a separate, isolated, expiring shadow database and gives you the exact configuration.

Create a Prisma setup

  1. 1Open Console → Databases.
  2. 2Choose Connect on the application database.
  3. 3Select Connect with Prisma.
  4. 4Create the isolated shadow database.
  5. 5Test connectivity.
  6. 6Copy the generated .env and prisma.config.ts snippets into the application.
  7. 7Store both URLs securely; the shadow URL expires and can be renewed or replaced.

Environment variables

.env
DATABASE_URL="postgresql://APP_USER:APP_PASSWORD@db.renviq.com:5432/APP_DATABASE?sslmode=verify-full"
SHADOW_DATABASE_URL="postgresql://SHADOW_USER:SHADOW_PASSWORD@db.renviq.com:5432/SHADOW_DATABASE?sslmode=verify-full"

Prisma configuration

prisma.config.ts
import "dotenv/config";
import { defineConfig, env } from "prisma/config";

export default defineConfig({
  schema: "prisma/schema.prisma",
  migrations: { path: "prisma/migrations" },
  datasource: {
    url: env("DATABASE_URL"),
    shadowDatabaseUrl: env("SHADOW_DATABASE_URL"),
  },
});

Use the right migration command

Development and production
# Development only: creates and tests migrations with the shadow DB
pnpm prisma migrate dev

# Production: applies committed migrations; no shadow DB required
pnpm prisma migrate deploy
Never run migrate dev in production

Commit reviewed migration files from development, then run prisma migrate deploy in CI/CD or the production release job.

Shadow database lifecycle

The wizard records creation, test, renewal, credential rotation, replacement, and deletion in audit history. Renew before expiry when a long development cycle needs it. Replace a shadow database when you want a clean migration baseline.

  • Contains disposable migration state, not production data.
  • Uses separate credentials and isolation.
  • Can be deleted when the development task is complete.
  • Should never be used as the application DATABASE_URL.
Was this guide useful?

If anything is unclear or incorrect, tell the support team.

Get help