🚀 Решение для медленной Prisma

Ускорение медленных запросов Prisma
API ответы в 2–7× быстрее (до 53.5×)

Prisma работает медленно? Любите DX Prisma, но нужна лучшая производительность? Ускорение медленных запросов Prisma в 2–7× (до 53.5× на relation filters в SQLite) без изменения существующих запросов.

Ускорить 🚀 Как это работает
Быстрое чтение из базы
Без изменений запросов
Готово для продакшена
137 E2E-тестов
Ускорьте Prisma одной строкой 
import { PrismaClient, Prisma } from '@prisma/client'
import { speedExtension, convertDMMFToModels } from 'prisma-sql'
import postgres from 'postgres'

const sql = postgres(process.env.DATABASE_URL)
const models = convertDMMFToModels(Prisma.dmmf.datamodel)

const prisma = new PrismaClient().$extends(
  speedExtension({ postgres: sql, models })
)

const users = await prisma.user.findMany({
  where: { status: 'ACTIVE' },
  include: { posts: true }
})
2–7×
Быстрее чтения Prisma
Типичный прирост
0
Изменений запросов
Клиентские Prisma операции без изменений
137
E2E-тестов
Проверенное решение
100%
Типобезопасность
Тот же Prisma API

Почему Prisma работает медленно?

Понимание эволюции и характеристик производительности Prisma помогает объяснить, почему существует это расширение.

Путь Prisma: приоритет пользовательского опыта без учета производительности

🎯 2019: Рождение современной Prisma

Prisma 2 была запущена в 2019 году и изменила ландшафт ORM для TypeScript: типобезопасный доступ к БД и генерация типов из схемы. Архитектура с движком позволила переводить запросы, валидировать их и обеспечивать гарантии API, которые сложно реализовать в чистом JavaScript.

⚡ 2020–2022: Рост и расширение функций

Prisma добавила вложенные записи, транзакции и middleware. Функций стало больше, но каждый запрос всё равно платит цену за удобство использования: представление запроса, валидация, выполнение и формирование результата под API Prisma.

📊 2023: Накладные расходы заметны на масштабе

В высоконагруженных системах фиксированные накладные расходы на запрос стали измеримыми. Обычно это сильнее видно на чтениях, аналитике, агрегациях и больших выборках. Это не баг, а стоимость гарантий и поведения Prisma.

🚀 2024–2025: Оптимизации Prisma продолжаются

Prisma выпускала крупные обновления с фокусом на производительность и изменения движка. Даже при улучшениях остаётся неизбежная цена за обработку запроса и формирование результата по сравнению с прямым выполнением SQL.

🎯 2026: prisma-sql

Расширение нацелено на производительность. Обходит путь выполнения чтений Prisma для findMany, findFirst, findUnique, count, aggregate и groupBy, оставляя Prisma для записей, миграций, управления схемой и генерации типов. Перед деплоем проверьте совместимость с вашей версией Prisma.

💡 Зачем?

Prisma сделала правильный архитектурный выбор: типобезопасность, удобство разработчика и согласованное поведение. Но эти решения добавляют логику, заметную на масштабе. Это расширение не заменяет Prisma — оно ускоряет чтения, сохраняя DX.

Слой трансляции запросов

Prisma переводит входные данные запроса в SQL для конкретной БД. Это даёт универсальное поведение и семантику Prisma, но добавляет время до выполнения SQL в базе.

Валидация и гарантии типов

Prisma валидирует запросы по схеме и обеспечивает гарантии API. Это предотвращает классы ошибок, но добавляет накладные расходы на каждый запрос.

Формирование результата

Результаты приводятся к поведению API Prisma. Это удобно и консистентно, но добавляет задержку, особенно при больших выборках и сложных include.

Это расширение дополняет Prisma, предлагая более быстрый путь для чтений. В типичных случаях вы получаете 2–7× ускорение (и до 53.5× на relation filters в SQLite), сохраняя поведение Prisma.

Насколько быстрее? Реальные бенчмарки

Комплексное сравнение Prisma v6, v7, Drizzle ORM и Prisma-SQL

Среда бенчмарков: MacBook Pro M1 • PostgreSQL 15 • SQLite 3.43 • 137 тест-кейсов на каждую базу данных

PostgreSQL

Среднее по 57 тест-кейсам

Prisma v6
2.10ms
Prisma v7
1.95ms
1.08× faster
Drizzle ORM
1.40ms
1.50× faster
Prisma-SQL ⚡
0.90ms
2.34× faster
6.3×
DISTINCT-запросы
vs Prisma v6
5.5×
Фильтры связей
vs Prisma v6 ("none"-фильтр)

SQLite

Среднее по 56 тест-кейсам

Prisma v6
5.48ms
Prisma v7
4.12ms
1.33× faster
Drizzle ORM
2.11ms
2.60× faster
Prisma-SQL ⚡
0.73ms
7.50× faster
12.6×
Простые запросы
vs Prisma v6
69.7×
Фильтры связей
vs Prisma v6 ("none"-фильтр)

Бенчмарки основаны на 137 E2E тестах на каждую базу данных. Prisma v6.16.3, Prisma v7.2.0, Drizzle ORM latest. Посмотреть полные данные бенчмарка →

Подробные результаты бенчмарков

Статистическое сравнение с использованием t-критерия Уэлча и порога практической значимости 1 мс

Эти результаты отражают режим выполнения, в котором запросы преобразуются в SQL при каждом обращении. В предварительно сгенерированном режиме SQL создаётся на этапе сборки — во время выполнения исполняются «сырые» параметризованные запросы без накладных расходов на преобразование.

PostgreSQL Prisma v6

В среднем 2.07x по сравнению с Prisma В среднем 1.68x по сравнению с Drizzle 28/95 статистически значимых побед 65 в пределах порога шума
Mar 7, 2026
Тест Prisma prisma-sql Drizzle Ускорение Знач. CV% n
findMany basic 0.536ms ±0.016 0.272ms ±0.043 1.37ms ~1.00x ≈ 57.0% 50
findMany where = 0.596ms ±0.046 0.354ms ±0.022 0.442ms ~1.00x ≈ 22.3% 50
findMany where >= 16.48ms ±0.251 4.89ms ±0.382 6.48ms 3.37x 1.33x D *** 28.2% 50
findMany where IN 0.609ms ±0.034 0.325ms ±0.016 0.436ms ~1.00x ≈ 17.5% 50
findMany where null 0.254ms ±0.0094 0.122ms ±0.0030 0.167ms ~1.00x ≈ 8.7% 50
findMany ILIKE 0.290ms ±0.043 0.231ms ±0.0083 0.296ms ~1.00x ≈ 13.2% 50
findMany AND 2.77ms ±0.076 1.00ms ±0.109 2.12ms 2.77x 2.12x D *** 39.3% 50
findMany OR 14.10ms ±0.361 4.05ms ±0.388 6.96ms 3.48x 1.72x D *** 34.6% 50
findMany NOT 0.631ms ±0.042 0.363ms ±0.026 0.454ms ~1.00x ≈ 26.3% 50
findMany orderBy 2.11ms ±0.080 0.893ms ±0.081 1.12ms 2.36x 1.25x D *** 32.7% 50
findMany pagination 0.248ms ±0.013 0.217ms ±0.0089 0.228ms ~1.00x ≈ 14.9% 50
findMany select 0.309ms ±0.058 0.101ms ±0.0064 0.116ms ~1.00x ≈ 22.6% 50
findMany relation some 0.910ms ±0.030 0.450ms ±0.016 — ~1.00x ≈ 12.6% 50
findMany relation every 0.710ms ±0.026 0.491ms ±0.012 — ~1.00x ≈ 8.7% 50
findMany relation none 31.70ms ±4.16 7.65ms ±0.483 — 4.15x *** 22.8% 50
findMany nested relation 0.952ms ±0.088 1.06ms ±0.138 — ~1.00x ≈ 46.7% 50
findMany complex 1.12ms ±0.029 0.520ms ±0.017 0.651ms ~1.00x ≈ 11.7% 50
findFirst 0.240ms ±0.013 0.195ms ±0.014 0.262ms ~1.00x ≈ 25.0% 50
findFirst skip 0.284ms ±0.018 0.176ms ±0.0080 0.219ms ~1.00x ≈ 16.7% 50
findUnique id 0.220ms ±0.016 0.163ms ±0.028 0.167ms ~1.00x ≈ 61.9% 50
findUnique email 0.180ms ±0.012 0.104ms ±0.0075 0.133ms ~1.00x ≈ 26.0% 50
count 0.124ms ±0.026 0.048ms ±0.0019 0.063ms ~1.00x ≈ 13.8% 50
count where 0.435ms ±0.0094 0.265ms ±0.011 0.273ms ~1.00x ≈ 15.4% 50
aggregate count 0.230ms ±0.0069 0.151ms ±0.0028 — ~1.00x ≈ 6.5% 50
aggregate sum/avg 0.355ms ±0.018 0.263ms ±0.013 — ~1.00x ≈ 18.0% 50
aggregate where 0.438ms ±0.010 0.275ms ±0.014 — ~1.00x ≈ 18.9% 50
aggregate min/max 0.344ms ±0.015 0.289ms ±0.031 — ~1.00x ≈ 38.6% 50
aggregate complete 0.420ms ±0.014 0.317ms ±0.033 — ~1.00x ≈ 37.4% 50
groupBy 0.447ms ±0.015 0.339ms ±0.011 — ~1.00x ≈ 11.4% 50
groupBy count 0.461ms ±0.011 0.381ms ±0.014 — ~1.00x ≈ 13.0% 50
groupBy multi 0.573ms ±0.019 0.431ms ±0.0097 — ~1.00x ≈ 8.1% 50
groupBy having 0.585ms ±0.034 0.473ms ±0.011 — ~1.00x ≈ 8.6% 50
groupBy + where 0.596ms ±0.031 0.431ms ±0.038 — ~1.00x ≈ 31.5% 50
_count via include 0.702ms ±0.023 0.704ms ±0.040 — ~1.00x ≈ 20.4% 50
_count via include + relations 1.86ms ±0.108 1.48ms ±0.072 — ~1.00x ≈ 17.7% 50
groupBy aggregates 0.576ms ±0.027 0.578ms ±0.062 — ~1.00x ≈ 38.8% 50
groupBy min/max 0.571ms ±0.048 0.589ms ±0.073 — ~1.00x ≈ 44.8% 50
include list + nested to-one 1.77ms ±0.103 0.460ms ±0.034 — 3.86x *** 26.9% 50
include list + nullable to-one 2.77ms ±0.100 2.14ms ±0.170 — ~1.00x ≈ 28.6% 50
include posts 2.86ms ±0.201 1.07ms ±0.069 6.00ms 2.66x 5.58x D *** 23.2% 50
include profile 0.533ms ±0.027 0.489ms ±0.030 0.549ms ~1.00x ≈ 21.8% 50
include 3 levels 1.99ms ±0.100 1.70ms ±0.190 1.96ms ~1.00x ≈ 40.2% 50
include 4 levels 2.45ms ±0.103 1.25ms ±0.030 3.81ms 1.96x 3.05x D *** 8.8% 50
include + where 2.61ms ±0.100 0.948ms ±0.100 4.59ms 2.76x 4.84x D *** 38.1% 50
include + select nested 2.27ms ±0.124 1.34ms ±0.106 3.71ms ~1.00x ≈ 28.5% 50
findMany startsWith 0.282ms ±0.031 0.185ms ±0.030 0.230ms ~1.00x ≈ 58.7% 50
findMany endsWith 0.640ms ±0.057 0.296ms ±0.049 0.470ms ~1.00x ≈ 59.0% 50
findMany NOT contains 0.661ms ±0.024 0.329ms ±0.050 0.413ms ~1.00x ≈ 55.1% 50
findMany LIKE 0.257ms ±0.026 0.181ms ±0.0061 0.208ms ~1.00x ≈ 12.3% 50
findMany < 27.72ms ±2.31 6.64ms ±0.325 11.44ms 4.18x 1.72x D *** 17.7% 50
findMany <= 28.41ms ±0.842 6.96ms ±0.419 11.50ms 4.08x 1.65x D *** 21.7% 50
findMany > 18.50ms ±3.09 4.00ms ±0.196 6.24ms 4.63x 1.56x D *** 17.7% 50
findMany NOT IN 0.593ms ±0.032 0.285ms ±0.012 0.351ms ~1.00x ≈ 15.4% 50
findMany isNot null 0.580ms ±0.017 0.194ms ±0.0036 0.294ms ~1.00x ≈ 6.6% 50
orderBy multi-field 5.19ms ±0.480 3.14ms ±1.04 1.51ms 1.66x 0.48x D ** 119.3% 50
orderBy relation to-one 2.38ms ±0.066 1.72ms ±0.131 — ~1.00x ≈ 27.5% 50
orderBy relation + scalar 2.22ms ±0.039 1.69ms ±0.093 — ~1.00x ≈ 19.9% 50
orderBy nullable relation 1.94ms ±0.056 1.30ms ±0.058 — ~1.00x ≈ 16.0% 50
orderBy deep relation 2.45ms ±0.070 1.73ms ±0.040 — ~1.00x ≈ 8.3% 50
orderBy deep relation + scalar 3.38ms ±0.250 2.07ms ±0.053 — 1.63x *** 9.2% 50
distinct status 11.52ms ±2.73 1.38ms ±0.137 — 8.33x *** 35.8% 50
distinct multi 14.12ms ±0.732 2.60ms ±0.054 — 5.43x *** 7.5% 50
cursor composite tuple 1.97ms ±0.081 1.50ms ±0.081 — ~1.00x ≈ 19.4% 50
cursor composite desc 2.91ms ±1.29 1.66ms ±0.135 — 1.75x ns 29.4% 50
cursor prefix of orderBy 2.03ms ±0.074 1.38ms ±0.040 — ~1.00x ≈ 10.4% 50
select + include 1.19ms ±0.081 0.254ms ±0.015 0.415ms ~1.00x ≈ 21.8% 50
_count relation 0.898ms ±0.070 0.648ms ±0.034 — ~1.00x ≈ 19.2% 50
_count multi-relation 0.244ms ±0.014 0.172ms ±0.0080 — ~1.00x ≈ 17.1% 50
_count inside include 1.37ms ±0.055 1.35ms ±0.130 — ~1.00x ≈ 34.7% 50
_count inside nested select 1.91ms ±0.049 1.43ms ±0.057 — ~1.00x ≈ 14.4% 50
_count deep include 1.92ms ±0.040 1.40ms ±0.044 — ~1.00x ≈ 11.4% 50
ILIKE special chars 0.511ms ±0.262 0.177ms ±0.0064 — ~1.00x ≈ 12.8% 50
LIKE case sensitive 0.213ms ±0.012 0.164ms ±0.0053 — ~1.00x ≈ 11.5% 50
findMany Date range 0.368ms ±0.018 0.517ms ±0.019 0.833ms ~1.00x ≈ 13.6% 50
count Date range 0.508ms ±0.016 0.817ms ±0.295 0.438ms ~1.00x ≈ 130.1% 50
findMany Date gte 0.387ms ±0.032 0.184ms ±0.0025 0.242ms ~1.00x ≈ 5.0% 50
depth-1 low-fan 0.502ms ±0.045 0.666ms ±0.303 — ~1.00x ≈ 164.1% 50
depth-1 mid-fan 3.02ms ±0.187 1.26ms ±0.148 — 2.40x *** 42.3% 50
depth-1 high-fan 3.49ms ±0.138 1.01ms ±0.066 — 3.44x *** 23.3% 50
depth-1 wide 6.05ms ±1.65 1.51ms ±0.104 — 4.00x *** 24.8% 50
depth-1 unbound 43.36ms ±2.79 8.43ms ±0.343 — 5.14x *** 14.7% 50
depth-2 3.79ms ±0.176 2.60ms ±0.150 — 1.45x *** 20.8% 50
depth-2 paginated Project→tasks 1.52ms ±0.067 1.66ms ±0.174 — ~1.00x ≈ 37.9% 50
depth-2 high-fan 2.14ms ±0.044 1.21ms ±0.060 — ~1.00x ≈ 18.1% 50
depth-2 wide 5.24ms ±0.307 1.92ms ±0.179 — 2.73x *** 33.8% 50
depth-2 unbound 78.61ms ±23.12 13.71ms ±0.633 — 5.74x *** 7.5% 10
depth-3 unbound 16.38ms ±1.37 6.59ms ±0.241 — 2.49x *** 13.2% 50
depth-3 paginated 2.04ms ±0.117 2.19ms ±0.542 — ~1.00x ≈ 89.3% 50
depth-4 unbound 9.62ms ±0.235 3.27ms ±0.186 — 2.94x *** 20.5% 50
depth-4 paginated 2.56ms ±0.095 1.78ms ±0.230 — ~1.00x ≈ 46.4% 50
findFirst depth-2 3.53ms ±0.968 1.52ms ±0.134 — 2.33x *** 32.0% 50
findUnique depth-2 Project→tasks→comment 2.77ms ±0.164 2.94ms ±0.761 — ~1.00x ≈ 93.5% 50
complex nested select 5.70ms ±0.317 4.49ms ±0.196 — 1.27x *** 15.7% 50
ultra deep query 7.62ms ±0.180 11.97ms ±5.92 — 0.64x ns 178.5% 50
transaction: (3 operations) 2.91ms ±0.054 1.23ms ±0.069 — 2.37x *** 20.4% 50
*** p < 0.001 ** p < 0.01 *  p < 0.05 ns статистически незначимо ≈ в пределах порога шума 1 мс ± 95% ДИ CV% > 15% = высокая вариативность
Режим выполнения протестирован. Предварительно сгенерированный режим полностью пропускает преобразование запроса в SQL во время выполнения — ожидайте меньшую задержку, чем показано здесь, особенно для сложных запросов, где стоимость преобразования относительно выше.
Просмотреть исходные данные бенчмарка на GitHub →
✓ Проверено

Как мы гарантируем корректность?

Каждый запрос проверяется на соответствие Prisma с помощью 137 сквозных тестов в PostgreSQL и SQLite

Методология тестирования →

Как это оптимизирует Prisma

Обходите путь выполнения чтений Prisma, сохраняя API и типы

1

Перехват запросов Prisma

Расширение перехватывает операции чтения (findMany, findFirst, findUnique, count, aggregate, groupBy) до выполнения

2

Генерация оптимизированного SQL

Преобразует запросы Prisma в быстрый параметризованный SQL с оптимизированными JOIN

3

Прямое выполнение

Выполняет запросы через postgres.js или better-sqlite3, обходя накладные расходы чтения Prisma

4

Возврат совместимых результатов

Результаты соответствуют ожидаемому формату Prisma. Типы, IntelliSense и существующий код запросов остаются без изменений

const users = await prisma.user.findMany({
  where: { status: 'ACTIVE' },
  include: { posts: true }
})

// Прямое выполнение SQL для чтений
// В бенчмарках около ~1.00ms на этой нагрузке
// Тот же код запросов Prisma
🔒 Проверенная безопасность

Как мы предотвращаем SQL-инъекции?

Многоуровневая валидация: привязка параметров, проверка полей по схеме и 137 тестов безопасности (текущий набор)

Подробнее о безопасности →

Что это дает?

Скорость ванильного SQL для чтений и всем полюбившийся пользовательский опыт Prisma

Мгновенное ускорение Prisma

Одноразовая настройка ускоряет чтения Prisma. Без рефакторинга, миграции и простоев.

Полная поддержка TypeScript

Весь вывод типов, автодополнение и безопасность времени компиляции сохраняются при ускорении чтений.

Тщательное тестирование

137 E2E-тестов подтверждают совместимость с актуальными версиями Prisma. Используется для ускорения чтений в продакшене.

Поддержка нескольких баз данных

Оптимизируйте чтения Prisma на PostgreSQL (включая Neon, Supabase) и SQLite.

Предварительная компиляция

Опциональный генератор создает SQL во время сборки, снижая накладные расходы до микросекунд для самых горячих запросов.

Serverless-совместимость

Работает в serverless Node-рантаймах. Поддержка Edge зависит от ограничений рантайма и выбранного драйвера.

Когда производительность важнее всего

Сценарии, где это расширение даёт реальный эффект

📊 Аналитика и отчетность

Агрегации и groupBy часто выигрывают от прямого выполнения SQL

  • 5× быстрее groupBy для отчетов
  • Быстрее aggregate-запросы
  • Метрики в реальном времени с меньшей задержкой

🚀 Высоконагруженные API

Накладные расходы на запросы накапливаются под нагрузкой, особенно на чтениях

  • Меньше время отклика API
  • Больше запросов на инстанс
  • Снижение затрат на инфраструктуру

☁️ Бессерверные функции

Каждая миллисекунда важна в serverless: снижайте задержку чтений

  • Лучшие p95/p99 на чтениях
  • Меньше затрат за счёт более быстрых чтений
  • Быстрее чтения без рефакторинга

📱 Мобильные бэкенды

Пользователи замечают задержки: более быстрые чтения улучшают UX

  • Быстрее загрузка ленты
  • Быстрее пагинация
  • Более отзывчивые взаимодействия

Оптимизируйте Prisma за 3 шага

Ускорьте чтения Prisma менее чем за 60 секунд

① Установите расширение Prisma 

# PostgreSQL
npm install prisma-sql postgres

# SQLite
npm install prisma-sql better-sqlite3

② Добавьте расширение к Prisma Client 

import { PrismaClient, Prisma } from '@prisma/client'
import { speedExtension, convertDMMFToModels } from 'prisma-sql'
import postgres from 'postgres'

const sql = postgres(process.env.DATABASE_URL)
const models = convertDMMFToModels(Prisma.dmmf.datamodel)

const prisma = new PrismaClient().$extends(
  speedExtension({ postgres: sql, models })
)

③ Используйте Prisma как обычно 

const users = await prisma.user.findMany({
  where: { status: 'ACTIVE' },
  include: { posts: true }
})

Часто задаваемые вопросы о производительности Prisma

Вопросы об оптимизации чтений Prisma

Почему у Prisma есть накладные расходы?

Prisma добавляет накладные расходы, потому что реализует гарантии API: валидацию по схеме, согласованное поведение запросов и формирование результата. Эти слои дают отличный DX, но стоят времени по сравнению с прямым выполнением SQL.

Как оптимизировать запросы Prisma?

Оптимизируйте чтение в Prisma с помощью этого расширения. Оно выполняет чтения через прямой SQL (postgres.js или better-sqlite3), сохраняя API и типы Prisma. Нужна небольшая правка инициализации, без рефакторинга существующих запросов.

Prisma медленнее, чем чистый SQL?

Во многих чтениях — да, из-за архитектурных накладных расходов. Это расширение помогает сохранить DX Prisma и снизить задержку чтений за счет прямого выполнения SQL.

Могу ли я ускорить Prisma без изменения существующих запросов?

Да. Добавьте расширение один раз при инициализации Prisma Client и оставьте существующий код запросов без изменений. Ускоряются чтения, при этом API, типы и схема остаются прежними.

Работает ли это в продакшене?

Да. Есть 137 E2E-тестов и дизайн под продакшен. Перед раскаткой проверьте совместимость с вашей версией Prisma и прогоните собственные регрессионные тесты.

Что вызывает медленные агрегации Prisma?

Агрегации и groupBy часто усиливают фиксированные накладные расходы (обработка запроса и формирование результата) и могут работать с большими промежуточными данными. Это расширение генерирует SQL напрямую и обычно снижает задержку на таких эндпоинтах.

Готовы ускорить Prisma?

Присоединяйтесь к разработчикам, ускорившим чтения Prisma: 2–7× (до 53.5×)

Установить Prisma-SQL Посмотреть на GitHub