🚀 Решение для медленной 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.83x по сравнению с Prisma В среднем 1.18x по сравнению с Drizzle 22/95 статистически значимых побед 73 в пределах порога шума
Jul 19, 2026
Тест Prisma prisma-sql Drizzle Ускорение Знач. CV% n
findMany basic 0.506ms ±0.014 0.263ms ±0.045 0.328ms ~1.00x ≈ 61.8% 50
findMany where = 0.537ms ±0.031 0.520ms ±0.186 0.406ms ~1.00x ≈ 128.9% 50
findMany where >= 16.63ms ±0.392 5.04ms ±0.245 6.80ms 3.30x 1.35x D *** 17.5% 50
findMany where IN 0.643ms ±0.044 0.349ms ±0.024 0.423ms ~1.00x ≈ 24.3% 50
findMany where null 0.268ms ±0.0078 0.172ms ±0.0100 0.170ms ~1.00x ≈ 20.8% 50
findMany ILIKE 0.265ms ±0.0100 0.255ms ±0.0091 0.261ms ~1.00x ≈ 13.0% 50
findMany AND 2.77ms ±0.136 0.906ms ±0.078 1.60ms 3.06x 1.76x D *** 31.2% 50
findMany OR 14.41ms ±0.382 4.26ms ±0.294 5.31ms 3.38x 1.25x D *** 24.9% 50
findMany NOT 0.594ms ±0.015 0.383ms ±0.045 0.404ms ~1.00x ≈ 42.3% 50
findMany orderBy 1.71ms ±0.026 0.650ms ±0.068 0.567ms 2.63x 0.87x D *** 37.6% 50
findMany pagination 0.225ms ±0.029 0.148ms ±0.020 0.153ms ~1.00x ≈ 48.1% 50
findMany select 0.236ms ±0.0061 0.149ms ±0.026 0.104ms ~1.00x ≈ 61.8% 50
findMany relation some 0.880ms ±0.014 0.477ms ±0.039 — ~1.00x ≈ 29.2% 50
findMany relation every 0.689ms ±0.016 0.463ms ±0.022 — ~1.00x ≈ 17.4% 50
findMany relation none 30.27ms ±1.35 7.71ms ±0.265 — 3.93x *** 12.4% 50
findMany nested relation 0.732ms ±0.022 0.779ms ±0.085 — ~1.00x ≈ 39.5% 50
findMany complex 1.08ms ±0.018 0.448ms ±0.012 0.563ms ~1.00x ≈ 9.4% 50
findFirst 0.220ms ±0.018 0.196ms ±0.019 0.170ms ~1.00x ≈ 34.8% 50
findFirst skip 0.316ms ±0.033 0.188ms ±0.042 0.170ms ~1.00x ≈ 80.6% 50
findUnique id 0.181ms ±0.011 0.119ms ±0.0055 0.149ms ~1.00x ≈ 17.0% 50
findUnique email 0.185ms ±0.0089 0.114ms ±0.0053 0.137ms ~1.00x ≈ 16.7% 50
count 0.132ms ±0.017 0.062ms ±0.0022 0.083ms ~1.00x ≈ 12.9% 50
count where 0.468ms ±0.0089 0.282ms ±0.0047 0.285ms ~1.00x ≈ 6.1% 50
aggregate count 0.246ms ±0.0083 0.160ms ±0.0042 — ~1.00x ≈ 9.5% 50
aggregate sum/avg 0.341ms ±0.014 0.343ms ±0.033 — ~1.00x ≈ 34.6% 50
aggregate where 0.472ms ±0.020 0.289ms ±0.0069 — ~1.00x ≈ 8.7% 50
aggregate min/max 0.321ms ±0.0086 0.276ms ±0.0055 — ~1.00x ≈ 7.1% 50
aggregate complete 0.419ms ±0.011 0.341ms ±0.015 — ~1.00x ≈ 15.6% 50
groupBy 0.410ms ±0.0094 0.368ms ±0.0083 — ~1.00x ≈ 8.1% 50
groupBy count 0.457ms ±0.011 0.413ms ±0.048 — ~1.00x ≈ 41.7% 50
groupBy multi 0.576ms ±0.017 0.458ms ±0.011 — ~1.00x ≈ 8.7% 50
groupBy having 0.502ms ±0.014 0.470ms ±0.023 — ~1.00x ≈ 17.4% 50
groupBy + where 0.513ms ±0.0097 0.345ms ±0.040 — ~1.00x ≈ 41.6% 50
_count via include 0.668ms ±0.019 0.636ms ±0.015 — ~1.00x ≈ 8.6% 50
_count via include + relations 1.58ms ±0.040 1.36ms ±0.059 — ~1.00x ≈ 15.7% 50
groupBy aggregates 0.519ms ±0.021 0.435ms ±0.014 — ~1.00x ≈ 11.7% 50
groupBy min/max 0.495ms ±0.010 0.428ms ±0.013 — ~1.00x ≈ 10.8% 50
include list + nested to-one 1.45ms ±0.047 0.542ms ±0.112 — ~1.00x ≈ 74.4% 50
include list + nullable to-one 2.49ms ±0.044 1.47ms ±0.098 — 1.69x *** 24.0% 50
include posts 2.39ms ±0.026 1.95ms ±0.044 2.43ms ~1.00x ≈ 8.2% 50
include profile 0.480ms ±0.032 0.276ms ±0.010 0.405ms ~1.00x ≈ 13.3% 50
include 3 levels 1.66ms ±0.032 1.20ms ±0.017 1.94ms ~1.00x ≈ 5.1% 50
include 4 levels 1.82ms ±0.028 1.09ms ±0.045 1.43ms ~1.00x ≈ 14.8% 50
include + where 1.34ms ±0.095 0.720ms ±0.058 1.82ms ~1.00x ≈ 28.9% 50
include + select nested 1.20ms ±0.018 1.50ms ±0.027 1.66ms ~1.00x ≈ 6.5% 50
findMany startsWith 0.192ms ±0.017 0.296ms ±0.177 0.135ms ~1.00x ≈ 215.1% 50
findMany endsWith 0.535ms ±0.013 0.213ms ±0.041 0.273ms ~1.00x ≈ 69.4% 50
findMany NOT contains 0.591ms ±0.027 0.228ms ±0.037 0.269ms ~1.00x ≈ 59.3% 50
findMany LIKE 0.200ms ±0.0083 0.128ms ±0.017 0.150ms ~1.00x ≈ 47.3% 50
findMany < 27.75ms ±0.511 6.75ms ±0.182 10.01ms 4.11x 1.48x D *** 9.7% 50
findMany <= 28.51ms ±0.683 7.92ms ±0.560 11.99ms 3.60x 1.51x D *** 25.5% 50
findMany > 18.60ms ±2.68 4.32ms ±0.187 6.21ms 4.31x 1.44x D *** 15.7% 50
findMany NOT IN 0.635ms ±0.024 0.433ms ±0.146 0.663ms ~1.00x ≈ 121.7% 50
findMany isNot null 0.634ms ±0.026 0.279ms ±0.016 0.332ms ~1.00x ≈ 20.1% 50
orderBy multi-field 2.21ms ±0.072 0.862ms ±0.102 0.668ms 2.57x 0.78x D *** 42.6% 50
orderBy relation to-one 2.03ms ±0.054 1.42ms ±0.030 — ~1.00x ≈ 7.6% 50
orderBy relation + scalar 2.12ms ±0.030 1.45ms ±0.015 — ~1.00x ≈ 3.7% 50
orderBy nullable relation 2.22ms ±0.082 1.20ms ±0.053 — 1.85x *** 15.9% 50
orderBy deep relation 3.41ms ±0.076 1.95ms ±0.030 — 1.75x *** 5.6% 50
orderBy deep relation + scalar 3.33ms ±0.195 2.39ms ±0.067 — ~1.00x ≈ 10.1% 50
distinct status 8.60ms ±0.282 1.15ms ±0.026 — 7.49x *** 8.3% 50
distinct multi 12.81ms ±0.175 2.52ms ±0.036 — 5.07x *** 5.2% 50
cursor composite tuple 1.64ms ±0.021 1.27ms ±0.052 — ~1.00x ≈ 14.7% 50
cursor composite desc 1.85ms ±0.039 1.36ms ±0.015 — ~1.00x ≈ 4.0% 50
cursor prefix of orderBy 1.78ms ±0.029 1.29ms ±0.028 — ~1.00x ≈ 7.8% 50
select + include 0.971ms ±0.019 0.782ms ±0.071 0.309ms ~1.00x ≈ 32.8% 50
_count relation 0.752ms ±0.014 0.625ms ±0.020 — ~1.00x ≈ 11.5% 50
_count multi-relation 0.227ms ±0.030 0.154ms ±0.0053 — ~1.00x ≈ 12.2% 50
_count inside include 1.22ms ±0.030 1.05ms ±0.040 — ~1.00x ≈ 13.8% 50
_count inside nested select 1.77ms ±0.057 1.81ms ±0.137 — ~1.00x ≈ 27.2% 50
_count deep include 1.82ms ±0.025 1.36ms ±0.045 — ~1.00x ≈ 11.9% 50
ILIKE special chars 0.229ms ±0.014 0.157ms ±0.013 — ~1.00x ≈ 30.4% 50
LIKE case sensitive 0.205ms ±0.0091 0.130ms ±0.012 — ~1.00x ≈ 34.4% 50
findMany Date range 0.382ms ±0.040 0.470ms ±0.013 0.515ms ~1.00x ≈ 9.8% 50
count Date range 0.457ms ±0.011 0.374ms ±0.012 0.392ms ~1.00x ≈ 11.4% 50
findMany Date gte 0.331ms ±0.0091 0.147ms ±0.0039 0.182ms ~1.00x ≈ 9.6% 50
depth-1 low-fan 0.376ms ±0.016 0.229ms ±0.017 — ~1.00x ≈ 26.9% 50
depth-1 mid-fan 2.46ms ±0.032 2.01ms ±0.065 — ~1.00x ≈ 11.8% 50
depth-1 high-fan 2.17ms ±0.038 1.82ms ±0.029 — ~1.00x ≈ 5.8% 50
depth-1 wide 1.95ms ±0.029 1.37ms ±0.069 — ~1.00x ≈ 18.2% 50
depth-1 unbound 42.23ms ±0.621 10.82ms ±0.343 — 3.90x *** 11.4% 50
depth-2 3.77ms ±0.111 2.51ms ±0.222 — 1.50x *** 31.9% 50
depth-2 paginated Project→tasks 1.51ms ±0.112 1.83ms ±0.228 — ~1.00x ≈ 44.9% 50
depth-2 high-fan 2.09ms ±0.027 1.17ms ±0.079 — ~1.00x ≈ 24.3% 50
depth-2 wide 4.31ms ±0.162 1.29ms ±0.067 — 3.35x *** 18.8% 50
depth-2 unbound 63.87ms ±1.40 16.30ms ±0.669 — 3.92x *** 6.6% 10
depth-3 unbound 14.47ms ±0.261 5.95ms ±0.370 — 2.43x *** 22.5% 50
depth-3 paginated 1.64ms ±0.045 1.98ms ±0.236 — ~1.00x ≈ 43.1% 50
depth-4 unbound 8.78ms ±0.198 4.46ms ±0.197 — 1.97x *** 15.9% 50
depth-4 paginated 1.85ms ±0.072 1.60ms ±0.244 — ~1.00x ≈ 55.2% 50
findFirst depth-2 1.25ms ±0.028 0.991ms ±0.048 — ~1.00x ≈ 17.4% 50
findUnique depth-2 Project→tasks→comment 1.57ms ±0.065 0.962ms ±0.077 — ~1.00x ≈ 28.7% 50
complex nested select 2.90ms ±0.025 1.90ms ±0.112 — ~1.00x ≈ 21.3% 50
ultra deep query 13.63ms ±0.362 8.43ms ±0.169 — 1.62x *** 7.3% 50
transaction: (3 operations) 11.89ms ±0.190 9.51ms ±0.173 — 1.25x *** 6.6% 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