Prisma и Postgres: 5 мест, где ORM тихо ломает схему и запросы

Prisma и Postgres: 5 мест, где ORM тихо ломает схему и запросы

Prisma удобно стартует, но в связке с supabase и postgres важно не отдавать ей полный контроль над базой. Иначе быстро появляются расхождения между схемой, миграциями и тем, как реально живут данные под auth и rls.

• Не полагайся только на auto-generated migration: проверяй SQL руками, особенно индексы, внешние ключи и каскады.
• Явно задавай имена таблиц и полей, чтобы не ловить сюрпризы при рефакторинге.
• Не смешивай Prisma-схему и ручные изменения в базе без правила: кто источник истины.
• Для публичных таблиц сразу думай про rls, а не добавляй его «потом».
• Если нужен нестандартный SQL, не пытайся втиснуть его в ORM-абстракцию — используй raw query.

Отдельная ловушка — типы данных. Prisma любит сглаживать детали, а postgres нет: массивы, jsonb, uuid, timezone, enum и nullable-поля требуют аккуратной проверки на уровне запросов и индексов.

Если проект уже вырос, сделай простое правило: Prisma отвечает за удобство кода, а postgres — за ограничения, безопасность и производительность. Тогда supabase, auth и rls не будут конфликтовать с ORM, а станут частью одной схемы.