С переходом на Prisma 7 многие вещи, к которым уже привык, начали вести себя по-другому. Особенно это заметно при работе с PostgreSQL — вроде бы стек тот же, но привычные решения больше не работают, особенно если ты используешь JavaScript.
Я сам на этом споткнулся: делаешь всё «как раньше», а в ответ получаешь ошибки, которые не сразу понятно как исправить. И самое неприятное — проблема не в коде, а в изменившейся логике самого Prisma.
Поэтому если ты сейчас пытаешься разобраться, как правильно выглядит связка Prisma 7 PostgreSQL JavaScript, ты не один — через это проходят почти все после обновления.
В этой статье я покажу рабочий подход: без лишней теории, но с понятным объяснением, что именно изменилось и как это использовать в реальном JavaScript-проекте.
STEP 1: Структура проекта Prisma 7 PostgreSQL JavaScript
Когда мы говорим про Prisma 7 PostgreSQL JavaScript, важно сразу понять одну простую вещь — настройка начинается не с кода и не с подключения к базе, а со структуры проекта.
В Prisma 7 это стало особенно заметно: логика разделилась на несколько уровней, и если пытаться «свалить всё в одну кучу», очень быстро начинаются странные ошибки и ощущение, что что-то работает не так, хотя формально всё сделано правильно.
Поэтому первый шаг — просто разложить проект по ролям.
Минимально это выглядит так:
back/
├── prisma/
│ └── schema.prisma
├── src/config/
│ └── prisma.js
├── prisma.config.ts
├── .env
На этом этапе здесь нет ничего сложного или лишнего. Но важный момент в другом — теперь каждый файл отвечает за свою конкретную часть системы, и это напрямую влияет на то, насколько предсказуемо будет вести себя Prisma в JavaScript-проекте.
И вот это разделение — то, с чего реально начинается нормальная настройка.
STEP 2: Установка зависимостей Prisma 7 PostgreSQL JavaScript
Дальше переходим к базовому шагу — устанавливаем всё, что нужно для работы проекта.
cd back
npm install prisma @prisma/client @prisma/adapter-pg dotenv
На первый взгляд здесь нет ничего необычного. Обычный набор зависимостей, который ты, скорее всего, уже видел в других проектах.
Prisma 7 требует использования адаптера при работе с PostgreSQL в JavaScript проектах.
И вот здесь как раз начинается отличие от старых версий.
Теперь Prisma не работает напрямую с базой «из коробки» так, как это было раньше. Ему нужен адаптер, который явно говорит, как именно подключаться к PostgreSQL и как управлять соединением.
И если его нет — Prisma просто не сможет нормально работать с базой. Это уже не дополнительная настройка и не оптимизация, а обязательная часть всей архитектуры.
STEP 3: Инициализация Prisma проекта
На этом этапе всё выглядит максимально знакомо. Мы просто выполняем команду:
npx prisma init
После этого Prisma создаёт базовые файлы проекта — .env и папку prisma со схемой.
Внешне это тот же самый старт, к которому многие привыкли раньше. И именно в этом и есть небольшой подвох: визуально всё выглядит одинаково, но внутренняя логика работы Prisma 7 уже отличается, и это становится заметно чуть позже, когда начинаешь настраивать подключение и клиент.
STEP 4: Настройка schema.prisma в Prisma 7 PostgreSQL JavaScript
Вот здесь начинается один из ключевых моментов всей настройки.
Если раньше подключение к базе спокойно указывалось прямо в schema.prisma, то в Prisma 7 это больше не работает — такая конфигурация просто не поддерживается.
Теперь схема выглядит проще:
generator client {
provider = "prisma-client-js"
}
datasource db {
provider = "postgresql"
}
При настройке Prisma 7 в нашем случае больше нет строки url, и это не ошибка и не пропуск, а сознательное изменение в архитектуре. Дело в том, что в новой версии Prisma предлагает сгенерировать клиент прямо в проекте в папке src/generated/prisma. При данном сценарии все сгенерированные файлы будут иметь синтаксис TypeScript. Если вы пишите сервер на чистом JS, то вам скорее всего это не подойдет. Поэтому в данной статье я решил опустить этот сценарий.
Для генерации внутри node_modules используем provider=»prisma-client-js». Это означает что сгенерированный клиент будет без проблем работать с js и доступен в коде:
import { PrismaClient } from '@prisma/client'
Смысл в том, что теперь Prisma разделяет ответственность. Схема отвечает только за описание структуры данных, а всё, что связано с подключением к базе, уходит в другое место и больше не смешивается с моделями.
Сначала это может казаться лишним усложнением, потому что раньше всё было в одном файле. Но по факту это убирает путаницу между тем, что ты описываешь, и тем, как именно происходит подключение.
STEP 5: PostgreSQL подключение через DATABASE_URL
После того как схема готова, возникает логичный вопрос: окей, а где теперь вообще указывать подключение к базе?
Раньше всё было просто — закинул url в schema.prisma и забыл. В Prisma 7 это больше не работает, и подключение переехало в .env.
Файл выглядит максимально просто:
DATABASE_URL="postgresql://user:password@localhost:5432/your_db"
На этом этапе ничего необычного нет. Это обычная строка подключения к PostgreSQL.
Но важно осознать что схема больше не знает про базу. Она описывает только структуру, а всё, что связано с подключением, живёт отдельно.
STEP 6: prisma.config.js для Prisma CLI
И вот здесь появляется новый файл, которого раньше в проектах Prisma просто не было — prisma.config.ts.
Если ты пишешь сервер на JavaScript, этот файл можно спокойно назвать prisma.config.js — по сути разницы в роли нет, важнее то, как он используется.
Сначала он может выглядеть как что-то лишнее или дублирующее .env, но на самом деле у него вполне конкретная задача — он даёт Prisma CLI понимание, как работать с базой данных и схемой проекта.
Вот как он выглядит:
import { defineConfig } from 'prisma/config'
import 'dotenv/config'
export default defineConfig({
schema: 'prisma/schema.prisma',
migrations: {
path: "prisma/migrations",
},
datasource: {
url: process.env.DATABASE_URL,
},
})
Здесь важно не столько само содержимое, сколько роль этого файла.
Он используется исключительно инструментами Prisma, например:
- миграциями (
prisma migrate) - визуальным просмотром базы (
prisma studio)
Твое серверное приложение к этому файлу не обращается вообще. Он существует только для того, чтобы CLI понимал контекст проекта и мог корректно работать с базой и схемой.
Происходит чёткое разделение:
prisma.config.ts— используется только для CLI-инструментов- серверное приложение — работает через отдельный Prisma Client в коде
И если попытаться использовать этот конфиг внутри сервера напрямую, ничего не заработает. Он просто не предназначен для runtime-логики.
STEP 7: Prisma Client с адаптером PostgreSQL в JavaScript
Вот мы и подошли к самому важному моменту всей настройки Prisma 7 — созданию клиента и тому, как теперь вообще работает подключение к PostgreSQL. Здесь как раз становится заметно, что Prisma 7 начал вести себя иначе, чем привычные версии.
Если раньше всё сводилось к простой строке:
const prisma = new PrismaClient()
и этого было достаточно, то теперь такой подход уже не работает.
Причина в том, что в Prisma 7 появился обязательный слой — адаптер. Именно он отвечает за то, как клиент подключается к PostgreSQL и как управляет соединением. И теперь это не скрытая логика внутри библиотеки, а явная часть конфигурации. Теперь такой подход используется в Node.js проектах с Prisma 7 PostgreSQL.
Как теперь выглядит создание клиента
Обычно для этого создают отдельный файл:
src/config/prisma.js
И уже внутри него собирается клиент:
import { PrismaClient } from '@prisma/client'
import { PrismaPg } from '@prisma/adapter-pg'
import 'dotenv/config'
const adapter = new PrismaPg({
connectionString: process.env.DATABASE_URL,
})
export const prisma = new PrismaClient({ adapter })
На первый взгляд кажется, что добавился просто ещё один слой. Но по факту это ключевое изменение архитектуры: Prisma больше не «угадывает» способ подключения, а работает строго через явно заданный адаптер.
Почему этого недостаточно
Если остановиться на этом варианте, в простом сценарии всё будет работать. Но в реальном проекте быстро появляется другая проблема.
В режиме разработки приложение часто перезапускается. И каждый такой перезапуск создаёт новое подключение к базе.
Сначала это незаметно, но со временем количество соединений начинает расти, и база может начать выдавать ошибки из-за перегрузки.
И вот здесь появляется следующая часть решения.
STEP 8: Singleton Prisma Client (защита от лишних подключений)
Чтобы избежать множества подключений, используется один и тот же экземпляр Prisma клиента на всё приложение.
Идея простая: если клиент уже создан — переиспользуем его, если нет — создаём один раз и сохраняем.
import { PrismaClient } from '@prisma/client'
import { PrismaPg } from '@prisma/adapter-pg'
import 'dotenv/config'
const globalForPrisma = globalThis
// Создаем адаптер для PostgreSQL
const adapter = new PrismaPg({
connectionString: process.env.DATABASE_URL,
})
// Функция создания клиента с адаптером
const createPrismaClient = () => {
return new PrismaClient({ adapter })
}
// Синглтон: используем существующий или создаём новый
export const prisma = globalForPrisma.prisma || createPrismaClient()
// В dev-режиме сохраняем в global, чтобы избежать множества подключений
if (process.env.NODE_ENV !== "production") {
globalForPrisma.prisma = prisma
}
Смысл здесь довольно простой. Вместо постоянного создания новых подключений ты работаешь с одним стабильным экземпляром клиента. И именно это делает работу с Prisma в реальном проекте предсказуемой и безопасной.
STEP 9: Миграции и генерация Prisma Client
На этом этапе у тебя уже собрана вся основа проекта: схема Prisma, подключение к базе и настроенный клиент. Теперь остаётся финальный шаг — связать всё это в рабочую систему и проверить, что она действительно функционирует.
Первое, с чего начинается запуск, — генерация Prisma Client:
npx prisma generate
Эта команда создаёт актуальный клиент на основе твоей схемы. Именно его ты потом используешь в коде для всех запросов к базе данных.
Следующий шаг — применение миграций:
npx prisma migrate dev --name init
В этот момент Prisma синхронизирует твою схему с PostgreSQL и создаёт необходимые таблицы в базе. Параллельно сохраняется история миграций, чтобы в дальнейшем можно было отслеживать изменения структуры данных. Если команды выполняются без ошибок — значит, база данных и Prisma настроены корректно, и проект готов к работе.
STEP 10: Проверка подключения Prisma 7 PostgreSQL JavaScript
Теперь остаётся самый простой и самый важный шаг — убедиться, что всё действительно собрано правильно.
Сделаем небольшой тест прямо в коде:
import { prisma } from './config/prisma.js'
const users = await prisma.user.findMany()
console.log(users)
Если в консоли появляется массив (даже пустой) — значит Prisma успешно подключился к базе, и всё настроено корректно. Это самый простой способ проверить, что клиент работает, а PostgreSQL отвечает без ошибок.
STEP 11: Запуск проекта Node.js
После этого можно запускать сервер привычной командой:
npm run dev
Если все предыдущие шаги были выполнены правильно, проект стартует без сюрпризов, а подключение к базе будет работать стабильно с первого запуска.
Что в итоге важно понять
Вся настройка Prisma 7 с PostgreSQL сводится к нескольким ключевым вещам.
Не к командам — их можно загуглить. А именно к пониманию:
- схема больше не хранит подключение
- Prisma Client создаётся через адаптер
- подключение к базе идёт через
.env - клиент должен быть один (синглтон)
Когда это укладывается в голове — всё остальное становится очевидным.
Заключение
Prisma 7 действительно немного изменил привычный процесс старта, особенно если ты приходишь с предыдущих версий и ожидаешь старого поведения «из коробки». Но это не усложнение ради усложнения — скорее переход к более явной и контролируемой конфигурации.
На практике такая схема одинаково хорошо подходит как для небольших pet-проектов, так и для более серьёзных приложений с ростом нагрузки и логики.
И самое главное — она убирает случайные ошибки, которые раньше появлялись из-за скрытой магии внутри настроек.