🚀 Решение для медленной 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

В среднем 1.99x по сравнению с Prisma В среднем 1.27x по сравнению с Drizzle 25/95 статистически значимых побед 70 в пределах порога шума
Jun 7, 2026
Тест Prisma prisma-sql Drizzle Ускорение Знач. CV% n
findMany basic 0.602ms ±0.020 0.481ms ±0.257 0.357ms ~1.00x ≈ 192.7% 50
findMany where = 0.563ms ±0.015 0.373ms ±0.051 0.456ms ~1.00x ≈ 49.5% 50
findMany where >= 17.20ms ±0.509 4.82ms ±0.358 6.80ms 3.57x 1.41x D *** 26.8% 50
findMany where IN 0.614ms ±0.024 0.417ms ±0.031 0.426ms ~1.00x ≈ 27.0% 50
findMany where null 0.292ms ±0.019 0.158ms ±0.042 0.175ms ~1.00x ≈ 96.9% 50
findMany ILIKE 0.324ms ±0.054 0.271ms ±0.0097 0.295ms ~1.00x ≈ 12.8% 50
findMany AND 3.06ms ±0.169 1.00ms ±0.088 2.64ms 3.06x 2.63x D *** 31.9% 50
findMany OR 14.91ms ±0.409 3.98ms ±0.306 5.57ms 3.75x 1.40x D *** 27.7% 50
findMany NOT 0.614ms ±0.031 0.369ms ±0.023 0.408ms ~1.00x ≈ 22.4% 50
findMany orderBy 3.41ms ±0.074 1.28ms ±0.067 1.35ms 2.67x 1.05x D *** 18.8% 50
findMany pagination 0.323ms ±0.027 0.233ms ±0.026 0.242ms ~1.00x ≈ 39.5% 50
findMany select 0.289ms ±0.018 0.168ms ±0.041 0.199ms ~1.00x ≈ 87.7% 50
findMany relation some 1.24ms ±0.072 0.843ms ±0.069 — ~1.00x ≈ 29.7% 50
findMany relation every 0.717ms ±0.017 0.619ms ±0.062 — ~1.00x ≈ 36.0% 50
findMany relation none 31.99ms ±0.908 6.99ms ±0.368 — 4.58x *** 19.0% 50
findMany nested relation 0.740ms ±0.023 0.959ms ±0.139 — ~1.00x ≈ 52.5% 50
findMany complex 1.19ms ±0.027 0.514ms ±0.013 0.721ms ~1.00x ≈ 8.9% 50
findFirst 0.239ms ±0.016 0.221ms ±0.025 0.209ms ~1.00x ≈ 40.3% 50
findFirst skip 0.291ms ±0.014 0.167ms ±0.0069 0.209ms ~1.00x ≈ 15.2% 50
findUnique id 0.222ms ±0.015 0.163ms ±0.029 0.136ms ~1.00x ≈ 63.8% 50
findUnique email 0.196ms ±0.011 0.114ms ±0.017 0.140ms ~1.00x ≈ 52.8% 50
count 0.127ms ±0.026 0.053ms ±0.0019 0.063ms ~1.00x ≈ 13.9% 50
count where 0.473ms ±0.016 0.271ms ±0.0067 0.297ms ~1.00x ≈ 9.0% 50
aggregate count 0.224ms ±0.014 0.164ms ±0.0097 — ~1.00x ≈ 21.2% 50
aggregate sum/avg 0.326ms ±0.010 0.255ms ±0.0089 — ~1.00x ≈ 12.6% 50
aggregate where 0.486ms ±0.023 0.284ms ±0.0080 — ~1.00x ≈ 10.3% 50
aggregate min/max 0.322ms ±0.0091 0.254ms ±0.0089 — ~1.00x ≈ 12.6% 50
aggregate complete 0.419ms ±0.011 0.304ms ±0.011 — ~1.00x ≈ 12.7% 50
groupBy 0.433ms ±0.013 0.359ms ±0.011 — ~1.00x ≈ 11.1% 50
groupBy count 0.498ms ±0.021 0.412ms ±0.018 — ~1.00x ≈ 15.8% 50
groupBy multi 0.601ms ±0.012 0.460ms ±0.011 — ~1.00x ≈ 8.2% 50
groupBy having 0.560ms ±0.012 0.516ms ±0.028 — ~1.00x ≈ 19.5% 50
groupBy + where 0.559ms ±0.012 0.384ms ±0.016 — ~1.00x ≈ 14.6% 50
_count via include 0.712ms ±0.027 0.698ms ±0.024 — ~1.00x ≈ 12.1% 50
_count via include + relations 1.68ms ±0.041 1.69ms ±0.119 — ~1.00x ≈ 25.5% 50
groupBy aggregates 0.669ms ±0.080 0.452ms ±0.017 — ~1.00x ≈ 13.2% 50
groupBy min/max 0.595ms ±0.045 0.485ms ±0.053 — ~1.00x ≈ 39.7% 50
include list + nested to-one 1.76ms ±0.116 0.448ms ±0.033 — 3.92x *** 26.6% 50
include list + nullable to-one 2.66ms ±0.040 1.83ms ±0.271 — ~1.00x ≈ 53.3% 50
include posts 5.30ms ±1.31 2.13ms ±0.142 5.45ms 2.49x 2.56x D *** 24.1% 50
include profile 0.794ms ±0.088 0.472ms ±0.046 0.580ms ~1.00x ≈ 35.0% 50
include 3 levels 2.56ms ±0.333 1.63ms ±0.142 1.63ms ~1.00x ≈ 31.4% 50
include 4 levels 2.33ms ±0.102 1.07ms ±0.028 1.50ms 2.17x 1.40x D *** 9.5% 50
include + where 1.34ms ±0.038 0.796ms ±0.034 1.85ms ~1.00x ≈ 15.2% 50
include + select nested 1.51ms ±0.076 1.73ms ±0.131 1.76ms ~1.00x ≈ 27.3% 50
findMany startsWith 0.251ms ±0.020 0.178ms ±0.019 0.192ms ~1.00x ≈ 39.4% 50
findMany endsWith 0.745ms ±0.115 0.274ms ±0.039 0.356ms ~1.00x ≈ 52.0% 50
findMany NOT contains 1.00ms ±0.305 0.283ms ±0.040 0.370ms ~1.00x ≈ 50.3% 50
findMany LIKE 0.301ms ±0.079 0.170ms ±0.014 0.211ms ~1.00x ≈ 30.3% 50
findMany < 29.00ms ±0.735 6.89ms ±0.323 10.36ms 4.21x 1.50x D *** 16.9% 50
findMany <= 35.14ms ±3.06 6.75ms ±0.312 11.66ms 5.21x 1.73x D *** 16.7% 50
findMany > 16.68ms ±0.469 4.30ms ±0.211 6.95ms 3.88x 1.62x D *** 17.8% 50
findMany NOT IN 0.628ms ±0.031 0.489ms ±0.123 0.431ms ~1.00x ≈ 90.9% 50
findMany isNot null 0.621ms ±0.015 0.213ms ±0.0086 0.333ms ~1.00x ≈ 14.5% 50
orderBy multi-field 3.10ms ±0.119 0.936ms ±0.093 0.777ms 3.32x 0.83x D *** 35.9% 50
orderBy relation to-one 2.06ms ±0.047 1.52ms ±0.039 — ~1.00x ≈ 9.3% 50
orderBy relation + scalar 2.14ms ±0.049 1.55ms ±0.063 — ~1.00x ≈ 14.7% 50
orderBy nullable relation 1.86ms ±0.034 1.19ms ±0.032 — ~1.00x ≈ 9.9% 50
orderBy deep relation 3.12ms ±0.292 1.70ms ±0.037 — 1.83x *** 7.9% 50
orderBy deep relation + scalar 3.85ms ±0.423 2.68ms ±0.262 — 1.44x *** 35.2% 50
distinct status 10.83ms ±0.417 1.27ms ±0.041 — 8.56x *** 11.8% 50
distinct multi 17.93ms ±2.05 2.72ms ±0.125 — 6.59x *** 16.6% 50
cursor composite tuple 1.77ms ±0.052 1.31ms ±0.039 — ~1.00x ≈ 10.6% 50
cursor composite desc 1.95ms ±0.065 1.82ms ±0.159 — ~1.00x ≈ 31.4% 50
cursor prefix of orderBy 1.80ms ±0.058 1.31ms ±0.043 — ~1.00x ≈ 11.8% 50
select + include 1.16ms ±0.070 0.766ms ±0.132 0.375ms ~1.00x ≈ 62.4% 50
_count relation 0.844ms ±0.034 0.671ms ±0.044 — ~1.00x ≈ 23.9% 50
_count multi-relation 0.256ms ±0.013 0.174ms ±0.0097 — ~1.00x ≈ 20.2% 50
_count inside include 1.32ms ±0.033 1.25ms ±0.051 — ~1.00x ≈ 14.7% 50
_count inside nested select 2.25ms ±0.043 2.00ms ±0.078 — ~1.00x ≈ 14.0% 50
_count deep include 2.05ms ±0.046 1.45ms ±0.077 — ~1.00x ≈ 19.2% 50
ILIKE special chars 0.283ms ±0.015 0.224ms ±0.018 — ~1.00x ≈ 28.6% 50
LIKE case sensitive 0.262ms ±0.028 0.190ms ±0.018 — ~1.00x ≈ 34.6% 50
findMany Date range 0.404ms ±0.025 0.534ms ±0.019 0.603ms ~1.00x ≈ 13.0% 50
count Date range 0.524ms ±0.030 0.411ms ±0.019 0.451ms ~1.00x ≈ 16.8% 50
findMany Date gte 0.413ms ±0.027 0.208ms ±0.0086 0.276ms ~1.00x ≈ 14.7% 50
depth-1 low-fan 0.445ms ±0.017 0.265ms ±0.023 — ~1.00x ≈ 31.4% 50
depth-1 mid-fan 2.76ms ±0.092 2.08ms ±0.080 — ~1.00x ≈ 13.9% 50
depth-1 high-fan 2.38ms ±0.072 1.96ms ±0.059 — ~1.00x ≈ 10.8% 50
depth-1 wide 2.22ms ±0.044 1.41ms ±0.044 — ~1.00x ≈ 11.2% 50
depth-1 unbound 43.88ms ±0.708 10.39ms ±0.320 — 4.22x *** 11.1% 50
depth-2 5.04ms ±0.290 2.91ms ±0.177 — 1.73x *** 22.0% 50
depth-2 paginated Project→tasks 1.78ms ±0.188 1.87ms ±0.183 — ~1.00x ≈ 35.4% 50
depth-2 high-fan 2.85ms ±0.113 1.30ms ±0.083 — 2.19x *** 22.9% 50
depth-2 wide 5.02ms ±0.246 1.94ms ±0.061 — 2.58x *** 11.3% 50
depth-2 unbound 66.25ms ±1.47 14.93ms ±0.817 — 4.44x *** 8.8% 10
depth-3 unbound 18.86ms ±4.30 5.90ms ±0.303 — 3.19x *** 18.5% 50
depth-3 paginated 2.07ms ±0.150 1.40ms ±0.104 — ~1.00x ≈ 26.9% 50
depth-4 unbound 10.24ms ±0.442 4.34ms ±0.168 — 2.36x *** 14.0% 50
depth-4 paginated 2.46ms ±0.193 1.79ms ±0.249 — ~1.00x ≈ 50.2% 50
findFirst depth-2 2.23ms ±0.079 1.71ms ±0.071 — ~1.00x ≈ 15.0% 50
findUnique depth-2 Project→tasks→comment 2.37ms ±0.202 2.05ms ±0.135 — ~1.00x ≈ 23.8% 50
complex nested select 3.56ms ±0.170 3.49ms ±0.440 — ~1.00x ≈ 45.5% 50
ultra deep query 15.31ms ±0.248 6.71ms ±0.310 — 2.28x *** 16.7% 50
transaction: (3 operations) 2.79ms ±0.059 1.36ms ±0.025 — 2.05x *** 6.5% 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