Environment variable not found: DATABASE_URL (Prisma)
Filed under Supabase & databases
DATABASE_URL is missing from every place Prisma reads — there is no .env it can see locally, or the variable was never set on the host where the app is deployed.
Fastest route
Give your AI this prompt
Copy it, replace the bracketed part with your error, and send it.
Preview the prompt
I am getting a Prisma error: "Environment variable not found: DATABASE_URL". Details: it happens [on my machine / only on my deployed site / when I run Prisma commands like migrate or generate]. My schema.prisma datasource block is: [paste the datasource block]. The env files in my project root are: [list the file names only, e.g. ".env.local exists, no .env" — do NOT paste real passwords]. Please: 1) tell me which of the usual causes fits — variable only in .env.local, missing on the host, name mismatch between schema and env file, or a stale process, 2) tell me exactly which file or settings screen to put DATABASE_URL in and what else to restart or redeploy afterwards, 3) check the datasource block for a second variable like DIRECT_URL that will fail next. Constraints: do not suggest hardcoding the URL in schema.prisma or committing a .env file, and do not ask me to paste my database password into this chat.
Fix it yourself
Follow the repair
- Check the variable exists where Prisma actually looks. Find the file named exactly
.env— no extension, no suffix — in your project root (or besideschema.prisma), open it, and confirm it contains a line like:
If your variable lives only inDATABASE_URL="postgresql://user:password@host:5432/database".env.local, copy the line into.envas well. And run Prisma commands from the project root; running them from a subfolder can leave the file out of sight. - If it fails only when deployed, set it on the host and redeploy. On Vercel: open your project, go to Settings, then Environment Variables, and add
DATABASE_URLwith the same value, for the Production environment (add Preview too if you use preview deployments). Then redeploy — env variable changes never apply to an already-running deployment, which is why "I added it and it still fails" usually means "it has not been redeployed since." - Compare the name character for character. Open
schema.prisma, find the datasource block, and read the exact name insideenv("..."). Compare it against the left-hand side of your.envline. They must be identical —DATABASE_URL, notDATABASE_URI, notDATABASE_URLwith a trailing space before the equals sign. AI builders rename variables while "tidying up" more often than anyone expects. - Restart whatever was running when you edited the file. Programs read environment variables once, at startup. If your dev server or terminal session was open while you fixed
.env, it is still working from the old, empty picture. Stop it, start it again, re-run the command — only then judge the fix. - Confirm the value is a complete connection string. Clearing this error with a placeholder value just trades it for a connection error. The string should begin
postgresql://, contain the real password (not[YOUR-PASSWORD]left in brackets), and name the real host. For Supabase projects, copy it fresh: dashboard, Connect (or Database settings), connection string — and for a deployed serverless app, use the pooled connection string (the one on port 6543) for the app itself. - Never fix this by committing secrets or hardcoding the URL. It is tempting to paste the address straight into
schema.prisma"just to get it working." Do not. Your database password would live in your git history permanently, and the deployed app would still need its own value. The variable-per-environment setup feels slower for ten minutes and saves you from a leaked database.
Why this happensOptional explanation
Your Prisma schema does not contain your database address directly. Instead it contains a pointer — url = env("DATABASE_URL") — and every time Prisma starts, it follows the pointer and reads the variable from its surroundings. Those surroundings are specific: the actual process environment (which is how hosting platforms supply it) and a file named .env in the project root or next to schema.prisma. If neither place has the variable, Prisma stops immediately with this error instead of guessing.
Two traps account for nearly every sighting. The first is the .env.local trap: Next.js reads several env files including .env.local, so a variable placed there works in the running app — but the Prisma command-line tools (the ones you run for migrations and generating the client) read only .env. Same project, same variable, two different readers, one confused afternoon. The second trap is deployment: your .env file is deliberately kept out of git, which means it never reaches Vercel or any other host. Until someone adds the variable in the host's own settings, the deployed app runs in a world where DATABASE_URL simply does not exist.
- The .env.local trap: the variable exists, but in the one env file Prisma's tools skip.
- The deployment gap: works locally, fails on the host, because the variable was never set there.
- A near-miss name:
DATABASE_URIor a stray space is a different variable as far as Prisma is concerned. - A stale process: you fixed the file, but the terminal or server that started before the edit never re-read it.
Quick answers
My .env file exists. Why can't Prisma find the variable?
Most often the file is named or placed slightly wrong, or it is a .env.local — the Prisma command-line tools read .env, not .env.local, even though Next.js itself reads both. Rename or copy the variable into a plain .env in the project root or beside schema.prisma, and run the command from the project root.
Do I need DIRECT_URL as well?
Only the ones your schema asks for. Supabase setups commonly reference DATABASE_URL (the pooler connection, used by the running app) and DIRECT_URL (a direct connection, used for migrations). If the schema reads env("DIRECT_URL"), that variable must exist too — the error will name whichever one is missing.
Should I commit my .env or paste the URL into schema.prisma?
No — and do not. Committing real credentials puts your database password in your repo's history forever, and hardcoding the URL in the schema does the same while also breaking the deployed app, which needs its own value. Set the variable in each environment instead; .env stays on your machine and out of git.