5 альтернатив InfluxDB в 2026 году: честный обзор

Прежде чем переходить к альтернативам, стоит честно сказать, почему команды вообще их рассматривают. Причины, которые я вижу чаще всего:

Архитектурная чехарда. Три мажорные версии примерно за девять лет, с разными движками хранения и разными языками запросов (InfluxQL, затем Flux, затем SQL через DataFusion в v3). Команды, поставившие на v2 и Flux, чувствуют себя брошенными. Команды на v1 имеют дело со стареющим кодом. Путь миграции на v3 реален, но нетривиален.

Потолок производительности на масштабе. InfluxDB v3 заметно быстрее v2 на аналитических запросах. Но команды, выходящие за десятки миллионов серий или делающие тяжёлые джойны между измерениями, всё равно упираются в стены. Модель «тег-и-поле», работавшая для IoT-метрик, плохо ложится на задачи корреляции метрик с логами, трейсами и событиями.

Стоимость на масштабе. Цены InfluxDB Cloud растут с кардинальностью и объёмом приёма так, что это удивляет команды по мере роста нагрузок. Цены self-hosted InfluxDB Enterprise за кластеризацию и HA непубличны, но недёшевы.

Лицензии и платные фичи. Community-версия не включает кластеризацию, HA и часть операционных возможностей. Граница между «open source» и «вам стоит заплатить за Cloud или Enterprise» сдвигалась не раз.

Фрагментация языка запросов. InfluxQL, Flux, SQL: в большинстве продакшен-развёртываний InfluxDB запросы написаны минимум на двух из них. Переход на SQL-first альтернативу часто упрощает кодовую базу ещё до того, как вы задумаетесь о движке хранения.

Какой бы ни была ваша причина, вот пять баз, которые стоит оценить.

Прежде чем перечислять варианты, назовём критерии. Разные команды взвесят их по-разному:

С этим на уме:

TimescaleDB — расширение PostgreSQL, добавляющее возможности временных рядов в стандартную базу Postgres. В июне 2025 года компания провела ребрендинг в Tiger Data, но open source-расширение по-прежнему называется TimescaleDB.

В чём сильна. Если команда уже работает на Postgres, TimescaleDB — путь наименьшего сопротивления к нормальной поддержке временных рядов. Hypertables прозрачно партиционируют данные по времени. Continuous aggregates заранее считают свёртки. Экосистема огромна: любой инструмент Postgres, ORM и клиентская библиотека работают.

Командам, которым нужны и транзакционные, и аналитические нагрузки в одной базе (например, данные аккаунтов рядом с телеметрией событий), фундамент на Postgres даёт реальное преимущество. Не нужно держать две базы.

Где проседает. Теперь TimescaleDB поставляет Hypercore — гибридный движок со строковым и колоночным хранением. Горячие данные живут в строковом формате для быстрых записей и обновлений; остывшие автоматически мигрируют в сжатое колоночное хранилище, оптимизированное под аналитику. Часть агрегатных операторов имеет векторизованные пути исполнения. Так что старая критика «всё распаковывается обратно в строки» уже не вполне точна — это настоящий гибрид.

Тем не менее исполнитель по-прежнему преимущественно строковый движок Postgres. Векторизованные пути есть для конкретных операторов, а не для всего плана. На тяжёлых агрегациях над очень большими наборами разрыв с полностью колоночными движками (DuckDB, ClickHouse, Arc) ощутим. Мы это измеряли: на ClickBench Arc был в 4.6x быстрее TimescaleDB по совокупному счёту и в 9.6x быстрее на приёме данных. Обновления и удаления в колоночном хранилище поддерживаются и сильно улучшились, но тяжёлые бэкфилы всё ещё могут стоить дороже, чем на строковом хранилище.

Лицензия. Двойная. Редакция Apache 2.0 включает базовую функциональность hypertable. Фичи, которые реально нужны большинству (Hypercore, continuous aggregates, политики хранения, продвинутые hyperfunctions) — под Timescale License (TSL): source-available, но не OSI-open-source. TSL запрещает предлагать TimescaleDB как управляемый сервис. Self-managed-развёртывания с TSL-фичами бесплатны.

Миграция с InfluxDB. Drop-in поддержки Line Protocol нет. Tiger Data публикует outflux для миграций, но он поддерживает только InfluxDB v1.x. v2 и v3 требуют собственного ETL или пайплайнов на Telegraf. Ждите работы по редизайну схемы.

Кому подходит. Командам, которые уже плотно используют Postgres, ценят SQL превыше всего и имеют нагрузки временных рядов комфортно ниже 100M строк на hypertable.

VictoriaMetrics — Prometheus-совместимая база метрик на Go. Поставляется как единый бинарник или как кластерная версия с отдельными компонентами приёма, хранения и запросов.

В чём сильна. Если вы используете Prometheus и упёрлись в лимиты хранения или масштаба — VictoriaMetrics самая чистая замена. Она говорит на PromQL, принимает Prometheus remote-write, работает с вашими дашбордами Grafana и правилами Alertmanager без изменений.

По сравнению с InfluxDB VictoriaMetrics радикально проще операционно. Развёртывание одним бинарником действительно единое. Кластерная версия — больше компонентов, но всё равно сильно проще кластера InfluxDB Enterprise. Сжатие отличное: типичные нагрузки наблюдаемости жмутся в 10x и лучше.

Где проседает. Сама VictoriaMetrics — база метрик. Логи и трейсы она напрямую не обрабатывает. Компания закрывает это родственными продуктами: VictoriaLogs для логов и VictoriaTraces (open source, OTLP-совместимый) для трейсов. Все три — отдельные продукты с отдельными интерфейсами запросов. Если цель — один движок на всё, то здесь это три движка от одного вендора.

PromQL мощен для метрик, но не имеет аналитической глубины SQL. Джойны, оконные функции, сложные агрегации по измерениям — на нагрузках за пределами чистых метрик вы будете тосковать по SQL.

Лицензия. Apache 2.0. Есть Enterprise-версия с дополнительными возможностями (downsampling, продвинутая мультиарендность, audit logs). Базовая мультиарендность есть в OSS-кластере.

Миграция с InfluxDB. vmctl — реальный инструмент миграции, читающий из InfluxDB v1.x. v2.x официально не поддерживается и требует сторонних инструментов. Flux-запросы придётся переписать на PromQL.

Кому подходит. Командам, которые хотят заменить Prometheus и InfluxDB одним стеком для метрик, довольны PromQL и согласны на VictoriaLogs и VictoriaTraces как отдельные продукты для остального.

QuestDB — специализированная база временных рядов, написанная в основном на zero-GC Java и C++ с собственным движком хранения. Позиционируется под высокочастотные нагрузки: финансовые рынки, IoT-телеметрия, аналитика в реальном времени.

В чём сильна. Сырая скорость приёма для простых временных рядов действительно высока. Совместимый с Influx Line Protocol эндпоинт приёма означает, что существующие писатели InfluxDB могут указать на QuestDB с минимальными изменениями, а Telegraf работает через output-плагин InfluxDB. SQL поддерживается с расширениями для временных рядов вроде SAMPLE BY и LATEST ON, удобными для оконных запросов и значений «последнее известное».

Где проседает. Аналитическая глубина ограничена. Джойны поддерживаются, но дороги. Подзапросы и сложные CTE работают, но это не конёк движка. Если запросы выходят за рамки SELECT …​ GROUP BY time, dimension, QuestDB может ощущаться зажатой.

Ситуация с бенчмарками заслуживает сноски. QuestDB публикует очень сильные числа ClickBench. README самого ClickBench различает «прохладные» прогоны и истинно холодные (с рестартом базы) и поощряет переход к истинно холодным, так как «прохладные» выгодны базам с обширными внутренними кэшами. Запускайте собственные бенчмарки на своих нагрузках, прежде чем полагаться на чьи-либо опубликованные числа, включая наши.

Сообщество меньше, чем у InfluxDB или Timescale, хотя активное. Self-serve QuestDB Cloud свёрнут; текущее управляемое предложение — QuestDB Enterprise BYOC (Bring Your Own Cloud) на AWS или Azure.

Лицензия. Apache 2.0 (OSS). Enterprise — коммерческая.

Миграция с InfluxDB. Совместимый с Line Protocol приём — серьёзное преимущество. Существующие агенты Telegraf пишут в QuestDB после смены конфигурации. Переписывание запросов с InfluxQL или Flux на SQL QuestDB обязательно.

Кому подходит. Высокочастотным простым нагрузкам временных рядов, где скорость приёма важнее всего, а аналитические запросы остаются относительно плоскими.

GreptimeDB — новый игрок: cloud-native база на Rust, объединяющая метрики, логи и трейсы в одном движке. v1.0 GA вышел 14 апреля 2026 года.

В чём сильна. GreptimeDB архитектурно ближе всего к тому, куда движется InfluxDB v3 (колоночное хранение, опора на объектное хранилище, поддержка SQL), но построена с нуля без легаси. Поддерживает ANSI SQL и PromQL рядом с потоковым интерфейсом.

Единая модель данных — главная ставка. Greptime продвигает её как «Observability 2.0»: метрики, логи и трейсы как временные широкие события в одном движке, запрашиваемые одним SQL (кросс-сигнальные джойны — явная цель дизайна). Если вы держали Loki под логи, Prometheus или InfluxDB под метрики и Jaeger или Tempo под трейсы — GreptimeDB предлагает всё это консолидировать.

GreptimeDB Edge существует для сред с ограниченными ресурсами (Android/ARM, автомобили, IoT). Есть Kubernetes-оператор и Helm-чарты. Поддержка объектного хранилища покрывает S3, GCS, Azure Blob, Aliyun OSS и S3-совместимые вроде MinIO.

Где проседает. Зрелость. GreptimeDB дошёл до 1.0 GA лишь за недели до написания этого материала. Архитектура здравая, но крупных продакшен-развёртываний пока копится мало. Командам с низкой толерантностью к риску стоит подождать полгода.

Экосистема инструментов баз данных на Rust моложе, чем на Go или Java, что может означать меньше интеграций и меньший пул операционной экспертизы. GreptimeDB Enterprise — где живут часть кластеризации, HA и безопасности; цены непубличны.

Лицензия. Apache 2.0 (OSS), проприетарный Enterprise.

Миграция с InfluxDB. У GreptimeDB есть совместимость с Line Protocol для приёма (эндпоинты V1 и V2, совместимо с Telegraf). Миграция запросов зависит от выбора SQL или PromQL.

Кому подходит. Cloud-native, Kubernetes-first командам, которые хотят консолидировать наблюдаемость в один движок и готовы внедрять более новую инфраструктуру.

Arc — колоночная аналитическая база для метрик, логов, трейсов и событий. Я построил её после ухода из InfluxData. Она использует DuckDB как движок запросов и хранит данные как нативный Apache Parquet на S3, Azure Blob, MinIO или локальном диске.

Я включаю Arc сюда, потому что для определённого типа команд это реальная альтернатива InfluxDB. Буду честен о том, где она подходит, а где нет.

В чём сильна. Drop-in совместимость с InfluxDB на уровне приёма — главное практическое преимущество. Существующие агенты Telegraf работают без изменений. Influx Line Protocol — first-class путь приёма. Команды мигрировали продакшен-нагрузки InfluxDB на Arc, просто сменив URL назначения.

SQL DuckDB означает полноценный стандартный SQL с оконными функциями, CTE, сложными джойнами и аналитическими функциями, недоступными в большинстве TSDB. Если команда уже знает SQL Postgres — она уже умеет запрашивать Arc.

Хранение — обычный Apache Parquet в вашем S3 (или Azure Blob, MinIO, локальном диске). Никакого проприетарного формата. Если захотите уйти с Arc — данные уже в формате, читаемом DuckDB, Spark, Polars, ClickHouse, BigQuery. Шага экспорта нет. Vendor lock-in не является значимым риском.

Один бинарник на Go. Без JVM, без отдельных узлов запросов, без оператора для базового развёртывания. Путь приёма протестирован на более чем 18 миллионах записей в секунду на типовом железе.

Где проседает. Arc новее остальных баз в списке. Он живёт с октября 2025 года, примерно за полгода до этого материала. Ранние продакшен-развёртывания есть, но сообщество меньше, чем у InfluxDB, Timescale или даже GreptimeDB.

Лицензия — AGPL-3.0. Это намеренно: она мешает облачным провайдерам форкнуть Arc в коммерческое предложение без вклада обратно. Но некоторые предприятия избегают AGPL по юридическим причинам. Arc Enterprise лицензируется коммерчески и снимает этот вопрос.

Кластеризация и HA — фичи Arc Enterprise, не OSS. Развёртывание одним бинарником готово к продакшену, но активная мультирегиональная репликация — платный путь.

Лицензия. AGPL-3.0 (community), коммерческая (Enterprise).

Миграция с InfluxDB. Drop-in поддержка Line Protocol. Telegraf работает без изменений. Существующие агенты приёма InfluxDB указываются на Arc сменой URL.

Попробовать. Arc запускается в одном контейнере:

Объективно ни одна база не лучшая по всем критериям. Лучший выбор зависит от того, что вы оптимизируете.

Чего вам не говорят про уход с InfluxDB: движок хранения редко самая трудная часть. Труднее всего то, что вы построили вокруг InfluxDB: дашборды, алерты, запросы в коде приложений, агенты в продакшене, runbook’и дежурной смены.

Несколько принципов:

Универсально правильной альтернативы InfluxDB нет. Каждая из пяти баз — верный ответ для своей команды:

Честный совет: не выбирайте базу по статье в блоге. Соберите шорт-лист, прогоните proof-of-concept на своей реальной нагрузке по две недели на каждую и дайте данным решить. Различия на синтетических бенчмарках редко совпадают с различиями на реальных продакшен-данных.