DEV Community

Cover image for Prisma: Environment variable not found: DATABASE_URL
Mahdi BEN RHOUMA
Mahdi BEN RHOUMA

Posted on Originally published at iloveblogs.blog

Prisma: Environment variable not found: DATABASE_URL

The exact error you see

A user asked about a PrismaGraphQL query that failed with this output, now viewed over 108 000 times on Stack Overflow:

Environment variable not found: DATABASE_URL.
  -->  schema.prisma:6
   |
 5 |   provider = "postgresql"
 6 |   url      = env("DATABASE_URL")
   |

Validation Error Count: 1
Enter fullscreen mode Exit fullscreen mode

The query itself compiled, but when Prisma tried to reach the database it couldn’t find a connection string, and the error points directly at line 6 of the schema. The url field references env("DATABASE_URL"), so the CLI or the query engine is looking for an environment variable that doesn’t exist — or at least one it cannot see.

  • Symptom: Prisma CLI / query throws Environment variable not found: DATABASE_URL — the schema references env("DATABASE_URL") but the variable is unavailable.
  • Root cause: The .env file is missing, in the wrong directory, not regenerated after changes, or masked by a conflicting .env file.
  • Fix: Run npx prisma generate and place a .env file with DATABASE_URL in your project root. For Next.js .env.local files, load them explicitly with dotenv-cli.
  • Verification: A subsequent prisma studio or a simple query no longer emits the Validation Error; Prisma connects normally.

What’s actually broken

Prisma does not automatically read every .env file on the filesystem. The CLI — and the generated Prisma Client — rely on a specific search order to find the connection string.

The official Prisma environment variables documentation explains the lookup logic: Prisma starts in the same directory as the schema.prisma file, then traverses up into parent directories. For a standard project with prisma/schema.prisma, it checks prisma/.env first, then ./.env. The first .env file found is used; files higher up the directory tree are ignored.

The prisma generate command re‑evaluates the schema and the environment, but the generated client reads DATABASE_URL at runtime — it does not bake the variable into the client. If the variable wasn’t available when the client was last generated, the schema validation step during generation would have flagged it, and the runtime may still fail because the client expects the variable to be present. Running prisma generate again with the .env file in place allows the schema validation to pass, and the client will then read the variable at runtime.

In the reported codebase, the .env file existed — but the Prisma Client hadn’t been regenerated. That’s why simply adding the file wasn’t enough: the new variable was never picked up by the already‑compiled engine.

Fix: regenerate the client and place the .env file

The highest‑voted answer (136 upvotes) on the original question is to run:

npx prisma generate
Enter fullscreen mode Exit fullscreen mode

That alone resolved the issue for the user because it re‑established the link between schema.prisma and the fresh DATABASE_URL inside the .env file.

Step by step:

  1. Confirm the .env file is in your project root — the same level as package.json — not inside a prisma/ subfolder (unless you are deliberately using the fourth lookup location). The file should contain:
DATABASE_URL="postgres://postgres:mypassword@db.pqtgawtgpfhpqxpgidrn.supabase.co:5432/postgres"
Enter fullscreen mode Exit fullscreen mode
  1. Save the file and then regenerate the client:
npx prisma generate
Enter fullscreen mode Exit fullscreen mode
  1. The output should show a success message and list the generated client path, for example with Prisma 4.12.0:
✔ Generated Prisma Client (4.12.0 | library) to ./node_modules/@prisma/client in 123ms
Enter fullscreen mode Exit fullscreen mode
  1. Restart your development server and re‑run the failing GraphQL query; the Environment variable not found error is gone.

Peer dependencies check: Make sure your @prisma/client version matches the prisma dev dependency. Run npm ls @prisma/client to verify. A mismatch can cause unexpected behaviour even after regeneration.

When .env.local still doesn’t work (Next.js projects)

In React projects (especially Next.js), developers often store secrets in .env.local, but Prisma doesn’t load that file automatically. Many developers drop their DATABASE_URL into .env.local, assume it will be picked up, and are surprised when Prisma still can’t see it. The second‑ranked answer on the Stack Overflow thread (65 votes) shows exactly how to load a custom file:

  1. Install dotenv-cli globally:
npm install -g dotenv-cli
Enter fullscreen mode Exit fullscreen mode
  1. Prefix every Prisma command with dotenv -e .env.local -- so the file is loaded into the process before Prisma runs:
dotenv -e .env.local -- npx prisma generate
dotenv -e .env.local -- npx prisma studio
Enter fullscreen mode Exit fullscreen mode
  1. You can also define a script in package.json to avoid retyping:
{
  "scripts": {
    "prisma:generate": "dotenv -e .env.local -- npx prisma generate",
    "prisma:studio": "dotenv -e .env.local -- npx prisma studio"
  }
}
Enter fullscreen mode Exit fullscreen mode

This technique is documented officially in Prisma’s guide on managing .env files manually.

Two patterns that still trip you up

1. Conflicting .env files

If you have a DATABASE_URL defined in both ./.env and ./prisma/.env, the Prisma CLI throws:

Error: There is a conflict between env vars in .env and prisma/.env
Conflicting env vars:
  DATABASE_URL
Enter fullscreen mode Exit fullscreen mode

The fix is to consolidate: move the variable to the project‑root ./.env and delete the duplicate from prisma/.env. Prisma explicitly recommends this in the official documentation.

2. The variable is set, but prisma generate wasn't run after the change

Even when the .env file is correct, if you added or modified DATABASE_URL after the last prisma generate, the generated client still expects the variable but the schema validation may have passed earlier with a missing variable. Simply running npx prisma generate again resolves it. No code change is required — the new connection string is read at runtime after the schema is re‑validated.

Confirm the fix

Once you’ve regenerated the client, a quick health check confirms the environment variable is found:

npx prisma studio
Enter fullscreen mode Exit fullscreen mode

Prisma Studio opens a browser‑based table viewer. If it starts without the validation error, Prisma can read DATABASE_URL and connect. You can also run a minimal database query through your GraphQL endpoint or a script that imports PrismaClient — any query that previously failed with Environment variable not found now completes normally.

Alternatives and ecosystem

If you’re evaluating ORMs, Drizzle ORM (drizzle-orm) handles database connections by passing the connection string directly in code, avoiding environment variable loading issues entirely. For mobile apps using SQLite, op‑sqlite provides a lightweight alternative to Prisma’s SQLite support, with its own synchronous connection handling. Both are worth considering if your project’s environment setup makes Prisma’s .env loading cumbersome.

FAQ

1. Why does Prisma say "Environment variable not found: DATABASE_URL" even though my .env file exists?

Prisma may not be reading the .env file if it’s in the wrong location, the client wasn’t regenerated after changes, or the variable name is misspelled. Run npx prisma generate to rebuild the client and ensure the .env file is in your project root (not inside /prisma). If you’re using a Next.js project with .env.local, load it explicitly with dotenv-cli.

2. How can I use a custom .env file like .env.local with Prisma?

Install dotenv-cli globally and prefix your Prisma command with dotenv -e .env.local -- npx prisma generate. This loads the specified file before running Prisma. For production deployments, set the DATABASE_URL environment variable directly on your host (Vercel, Netlify, etc.) instead of relying on file‑based loading.

Related


Originally published at https://www.iloveblogs.blog

Top comments (0)