Neon для Supabase: 5 мест, где чаще всего ломают архитектуру

Neon для Supabase: 5 мест, где чаще всего ломают архитектуру

Neon удобен тем, что Postgres можно поднимать быстро и держать ближе к коду. Но в связке с Supabase ошибки обычно не в SQL, а в том, как устроены соединения, миграции и безопасность.

— Не держите много долгоживущих коннектов из serverless: пул нужен почти всегда.
— Не смешивайте ручные правки в базе и миграции без единого источника истины.
— Не полагайтесь на service role там, где должны работать auth и rls.
— Не храните критичные секреты в клиенте: выносите логику в edge-функции или backend.

Отдельно проверьте, что схема и роли в Neon совпадают с тем, что ожидает Supabase-клиент. Частая ошибка — открыть доступ шире, чем надо, а потом пытаться лечить это фильтрами на уровне приложения. В Postgres это почти всегда плохая идея.

Если проект растёт, заведите правило: сначала схема и rls, потом код, потом оптимизация. Так Neon остаётся быстрым слоем для Postgres, а не источником тихих багов в auth и данных.