Supabase → Power BI: подключение, вебхуки и доступ к данным

Обновлено 2 сентября 2026 года.

Supabase предоставляет PostgreSQL и сервисы для приложений, включая Edge Functions и Realtime. Power BI может читать подготовленные таблицы через коннектор PostgreSQL. При этом наличие Realtime в Supabase не превращает отчёт Power BI в подписчика WebSocket и не гарантирует обновление визуализаций через секунду.

Разделите три этапа обновления

1. Приём события. Источник отправляет вебхук; обработчик проверяет запрос, получает нужные данные и сохраняет их.
2. Подготовка витрины. SQL преобразует записи в показатели. Обычное представление вычисляется при запросе, материализованное требует отдельного обновления.
3. Показ в Power BI. Import читает сохранённую копию модели до следующего обновления. DirectQuery отправляет запросы источнику, но открытая страница отчёта также зависит от обновления визуализаций и кэширования.

Согласуйте допустимую задержку для каждого этапа. Если бизнесу достаточно отчёта раз в час, полноценная событийная инфраструктура может оказаться лишней.

Как подключить базу к Power BI

Возьмите реквизиты из панели Connect вашего проекта, сверяясь с документацией Supabase. Direct connection и pooler имеют разные адреса и режимы. Порт 6543 связан с transaction pooling, а не с регионом проекта; для длительных подключений может подойти direct или session mode. Учитывайте доступность IPv4/IPv6 из сети, где работает клиент или шлюз.

Создайте отдельную роль для чтения аналитических представлений. В Power BI выберите PostgreSQL, укажите сервер и базу, затем Import либо DirectQuery. Microsoft описывает поддержку этих режимов и драйвера; устанавливать произвольную новую версию Npgsql поверх встроенной не следует.

После публикации проверьте доступ Power BI Service к источнику, учётные данные и шифрование. Успешное подключение на ноутбуке ещё не доказывает, что обновление выполнится в сервисе.

Что должен делать обработчик вебхука

Edge Function должна проверять подлинность запроса способом, который поддерживает отправитель, разбирать его фактический формат и валидировать поля. Правила авторизации функций зависят от вида клиента; внешний сервис не становится пользователем Supabase автоматически.

Не предполагайте, что событие Битрикс24 содержит готовую полную карточку сделки в JSON. Обработайте документированные параметры события и при необходимости запросите сущность через REST. Храните идентификатор источника и сущности, версию или время изменения и время получения. Повтор доставки не должен добавлять ещё один лид: нужен UPSERT по стабильному ключу либо отдельная дедупликация событий.

Добавьте начальную загрузку и периодическую сверку. Одни вебхуки не восстанавливают всю старую историю и не защищают от пропущенных событий. Длительную обработку выносите в очередь или отдельный процесс с контролем повторов.

Почему RLS требует отдельной проверки

В политиках Supabase RLS выражение auth.uid() связано с пользователем Supabase Auth. Числовой ID сотрудника Битрикс24 — другой идентификатор, и сравнивать их без таблицы соответствий нельзя. Поле, на которое ссылается политика, должно существовать и иметь подходящий тип.

Сервисные ключи и роли с обходом RLS обладают расширенным доступом. SQL-подключение Power BI общей ролью также не получает автоматически JWT каждого зрителя отчёта. Разграничение доступа проектируйте для всего пути: роль источника, представления, модель Power BI и права просмотра. Проверьте результат под обычным пользователем.

Проверка готовности

Создайте тестовую запись, измените её и повторно доставьте событие. Сверьте ключ, сумму и время изменения в базе и отчёте. Затем проверьте удаление, недоступность обработчика и восстановление. Отдельно убедитесь, что читатель одного подразделения не видит данные другого.

В расчёт стоимости входят база, вызовы функций, сетевой трафик, резервное копирование и лицензии BI. Бесплатные квоты меняются и не означают отсутствие расходов на сопровождение.