supabase-postgres-best-practices

Supabase Postgres Best Practices — официальный навык Supabase для работы с PostgreSQL независимо от того, запускается база в Supabase или в другой среде. Он нужен до изменения того, что живёт в базе: схемы и миграций, типов столбцов, индексов, триггеров, функций, очередей, планировщика pg_cron или pgmq, векторного поиска на pgvector и политик Row-Level Security. Тот же материал полезен при разборе медленных запросов, высокой загрузки CPU, таймаутов, планов EXPLAIN, исчерпания соединений, блокировок, разрастания таблиц и индексов, а также ситуации, когда строки становятся видимыми не тому пользователю или арендатору. Это делает карточку применимой не только к оптимизации скорости: в ней вместе рассматриваются проектирование схемы, SQL, безопасность и проверка изменений. Структура навыка разделена на восемь категорий с явным порядком приоритета. На первом месте находятся query-performance и правила для производительности запросов, рядом с ними — connection-management для соединений и security для RLS; эти направления отмечены как критичные. Далее идут schema-design с высоким влиянием, concurrency-and-locking для конкурентного доступа, data-access-patterns для способов чтения и записи, monitoring-and-diagnostics для наблюдаемости и advanced-features для менее приоритетных возможностей. В репозитории категории отражаются префиксами query-, conn-, security-, schema-, lock-, data-, monitor- и advanced-, поэтому отдельное правило можно искать по названию, а не просматривать весь документ целиком. Каждое правило задумано как практический материал для ревью и генерации изменений. В нём есть краткое объяснение важности, пример ошибочного SQL с разбором проблемы, исправленный вариант и дополнительный контекст; при наличии добавляются вывод EXPLAIN или метрики. Для Supabase-специфичных случаев сохраняются отдельные замечания. Среди направлений, которые навык предлагает проверять, — отсутствующие индексы, частичные индексы, выбор схемы, соединения, RLS и особенности доступа к данным. Такой формат помогает сначала установить причину, затем увидеть корректный шаблон запроса и только после этого переносить решение в проект. Практический сценарий начинается с определения типа работы: при изменении таблицы или миграции сначала сверяют дизайн схемы и типы; при жалобе на скорость — категорию query и план EXPLAIN; при изоляции арендаторов — правила security и RLS; при таймаутах или исчерпании пула — connection-management; при конкурентных обновлениях — locking. Материал ссылается на документацию PostgreSQL, документацию Supabase, разделы о базе данных и RLS, поэтому проверку можно продолжить в официальных первоисточниках. Ограничение навыка также ясно: он даёт правила и примеры для принятия решений, но не выполняет миграции, не измеряет конкретную базу автоматически и не заменяет проверку плана, метрик и политики доступа в целевой системе.