Metabase или Redash: что выгоднее и когда

MAATRIX

Когда команде нужны дашборды и SQL-отчёты, выбор обычно сужается до двух open-source инструментов — Metabase и Redash. Оба бесплатны, оба ставятся за 10 минут через Docker, но за этим сходством прячутся разные архитектуры, разный аппетит к ресурсам и разная логика работы с данными. Если выбрать не под свой сценарий, через полгода придётся либо доплачивать за сервер помощнее, либо мигрировать на другой инструмент — а это боль. Разберём честно, где каждый выигрывает.

Кто есть кто: архитектура и философия

Metabase — это Java-приложение (Clojure на JVM), которое ставит во главу угла простоту для нетехнических пользователей. У него есть визуальный конструктор запросов ("Спросить у данных" через клики, без единой строки SQL) — маркетолог или продажник реально может собрать себе отчёт сам. SQL-редактор тоже есть, но это второй слой, для аналитиков.

Redash — детище Python-стека (Flask + Celery + Redis для очереди задач), сделанное аналитиками для аналитиков. Никакого визуального конструктора запросов нет — вы пишете SQL, а Redash оборачивает результат в таблицу, график или дашборд. Зато у Redash из коробки десятки коннекторов: от PostgreSQL и ClickHouse до Google Sheets, MongoDB, Athena и даже Prometheus.

Разница философий тянет за собой всё остальное: кто будет пользоваться инструментом, сколько он будет есть RAM, и насколько сложно его администрировать.

Требования к серверу: где реальная разница в деньгах

Это первое, что бьёт по кошельку. JVM Metabase печально известна аппетитом к памяти даже в простое.

Metabase — это один процесс, который проще развернуть, но JVM держит в памяти кэши и классы даже без активных запросов: на голом VPS с 2 GB после старта свободно остаётся не так много, и добавление тяжёлых дашбордов с большим числом вопросов быстро толкает вас к апгрейду. Ориентировочно, если у вас больше 20-30 активных дашбордов и десяток одновременных пользователей, комфортнее будет на 4 GB. Подробный разбор памяти под конкретные сценарии — в статье сколько RAM нужно для Metabase.

Redash формально "легче" по процессу веб-сервера, но у него больше отдельных сервисов — это не столько про суммарное потребление RAM, сколько про то, что вы администрируете 3-4 процесса вместо одного.

Итог по деньгам: на старте (2 GB VPS) оба чувствуют себя одинаково стеснённо. На тарифе 4 GB Metabase обычно комфортнее в один клик, Redash комфортнее там, где вы и так уже держите Redis под другие задачи — компонент не пропадает зря.

Кто для кого: аудитория и порог входа

Это ключевой критерий выбора, важнее ресурсов сервера.

Metabase выигрывает, если:

• В компании есть нетехнические пользователи (маркетинг, продажи, поддержка), которым нужно самим строить отчёты без SQL;
• Вы хотите быстро дать доступ "посмотреть цифры" широкому кругу людей без риска, что кто-то напишет DROP TABLE;
• Важен красивый, презентабельный интерфейс "из коробки" — Metabase выглядит опрятнее для нетехнической аудитории.

Redash выигрывает, если:

• В команде только аналитики и разработчики, которые пишут SQL быстрее, чем кликают по конструктору;
• Нужно подключить много разнородных источников одним инструментом (условно: ClickHouse для событий, Postgres для транзакций, Google Sheets для ручных данных) в одном дашборде;
• Нужна гибкость в параметризации запросов — Redash позволяет делать SQL-запросы с параметрами ({{ param }}), которые превращаются в выпадающие списки и фильтры на дашборде, и это удобнее шаблонизировать, чем в Metabase.

Если у вас смешанная команда — часть аналитиков, часть "смотрящих на цифры" менеджеров — иногда практичнее держать оба: Redash для внутренней аналитической кухни, Metabase как витрину для остальных. Благо оба легковесны для теста на отдельном VPS.

Установка: сложность разворачивания

Оба ставятся через docker-compose, но нюансы отличаются.

Metabase — почти буквально:

services:
  metabase:
    image: metabase/metabase:v0.50.8
    ports:
      - "3000:3000"
    environment:
      MB_DB_TYPE: postgres
      MB_DB_DBNAME: metabase
      MB_DB_PORT: 5432
      MB_DB_USER: metabase
      MB_DB_PASS: change_me
      MB_DB_HOST: metabase-db
    depends_on:
      - metabase-db
  metabase-db:
    image: postgres:16
    environment:
      POSTGRES_DB: metabase
      POSTGRES_USER: metabase
      POSTGRES_PASSWORD: change_me
    volumes:
      - metabase-db-data:/var/lib/postgresql/data
volumes:
  metabase-db-data:

Один сервис приложения + одна база под метаданные. Дальше вся настройка — через веб-интерфейс: подключение источников данных, создание пользователей и групп доступа.

Redash сложнее из коробки — нужны postgres, redis, и минимум два процесса приложения (server + worker), плюс шаг инициализации базы командой create_db перед первым запуском:

services:
  redash-server:
    image: redash/redash:24.04.1
    command: server
    ports:
      - "5000:5000"
    environment:
      REDASH_LOG_LEVEL: INFO
      REDASH_REDIS_URL: redis://redash-redis:6379/0
      REDASH_DATABASE_URL: postgresql://redash:change_me@redash-db/redash
      REDASH_COOKIE_SECRET: generate_a_random_string
    depends_on:
      - redash-redis
      - redash-db
  redash-worker:
    image: redash/redash:24.04.1
    command: scheduler
    environment:
      REDASH_REDIS_URL: redis://redash-redis:6379/0
      REDASH_DATABASE_URL: postgresql://redash:change_me@redash-db/redash
    depends_on:
      - redash-redis
      - redash-db
  redash-redis:
    image: redis:7-alpine
  redash-db:
    image: postgres:16
    environment:
      POSTGRES_DB: redash
      POSTGRES_USER: redash
      POSTGRES_PASSWORD: change_me
    volumes:
      - redash-db-data:/var/lib/postgresql/data
volumes:
  redash-db-data:

Полный разбор с шагом инициализации — в как установить и настроить Redash на VPS. Версии образов обязательно фиксируйте — latest в проде для BI-инструмента, к которому привязаны десятки сохранённых дашбордов, плохая идея: обновление может незаметно сломать формат запроса или визуализацию.

Подключение источников данных

Metabase поддерживает популярные СУБД (PostgreSQL, MySQL, MongoDB, ClickHouse через community-драйвер, BigQuery, Snowflake и другие) — список растёт с каждым релизом, но он ограничен официально поддерживаемыми и community-плагинами, которые нужно докидывать вручную (JAR-файл драйвера в volume /plugins).

Redash в этом смысле щедрее: из коробки в образе уже зашиты десятки коннекторов — от классики (Postgres, MySQL, ClickHouse) до нишевых вещей вроде Athena, Google Analytics, Salesforce, Prometheus. Если у вас зоопарк источников данных и вы не хотите возиться с драйверами — это ощутимый плюс Redash.

Если аналитика упирается в вопрос "на чём вообще хранить данные для BI" — отдельная тема выбора базы под аналитическую нагрузку разобрана в статье ClickHouse или PostgreSQL для аналитики: что выбрать для сервера. Оба BI-инструмента одинаково хорошо дружат что с одним, что с другим.

Обслуживание, бэкапы и типичные проблемы

Здесь оба инструмента требуют дисциплины, но грабли разные.

Metabase: вся конфигурация и сохранённые вопросы/дашборды живут в его собственной базе метаданных (в примере выше — metabase-db). Бэкапить нужно именно её через pg_dump, plus не забывайте про volume /metabase-data если используете встроенный H2 вместо внешнего Postgres (для прода — не используйте, только внешняя БД). Частая проблема на практике — JVM упирается в лимит heap на дефолтных настройках и падает с OutOfMemoryError при большом числе одновременных вопросов; лечится явным JAVA_OPTS: "-Xmx2g" под ваш объём RAM. Процедура бэкапа и восстановления разобрана в статье бэкап и восстановление Metabase.

Redash: точек отказа больше — если Redis недоступен, встают все запланированные обновления дашбордов (worker не может забрать задачу из очереди), при этом веб-интерфейс продолжает открываться и создаёт ложное ощущение, что всё работает. Второй частый источник проблем — сама база redash-db разрастается кэшированными результатами запросов (таблица query_results), и без периодической чистки диск может неожиданно кончиться на небольшом VPS.

В обоих случаях бэкап настройте с самого первого дня — потерять неделю накопленных дашбордов и алертов обиднее, чем кажется на старте.

Лицензия и стоимость владения

Оба продукта — open source с ограничениями. Metabase распространяется под AGPL для community-версии, есть платная Pro/Enterprise-версия с SSO, аудитом и белым лейблом — но для большинства команд community-версии достаточно с запасом. Redash был куплен Databricks в 2020 году, и с тех пор публичного облачного продукта фактически нет — актуален только self-hosted community-путь, что для тех, кто и так планирует ставить BI на свой сервер, не проблема, а скорее плюс: код открыт, развитие идёт силами сообщества.

Стоимость владения в обоих случаях сводится к одному — цене VPS, на котором вы это держите, плюс времени на администрирование. Ни один из инструментов не требует лицензионных платежей за community-версию.

Частые вопросы