Если вы когда-нибудь собирали аналитику по кликам, метрикам или логам, то знаете цену вопроса: хочется SQL за миллисекунды, хранение в дёшёвом объектном хранилище, минимум «танцев» с кластером и—если повезёт—MIT-лицензию без ловушек. На одном берегу — «тяжёлые» распределённые OLAP-системы (ClickHouse, Pinot, Druid), на другом — специализированные TSDB (InfluxDB, TimescaleDB, QuestDB). Между ними набирает силу «озёрный» подход: складывать сырые события в Parquet, а считать — встраиваемым движком с Arrow/FlightSQL поверх.
GigAPI как раз из этой когорты: DuckDB + Parquet, чтение из локального диска или S3, запросы через FlightSQL (gRPC) и HTTP, режимы writeonly/readonly/compaction, один контейнер для старта и понятная философия «делай просто, делай быстро». Проект обещает суб-секундные аналитические запросы, компактизацию и дружбу с FDAP-миром (Arrow/DataFusion/Parquet/Flight) — всё то, что нравится инженерам, уставшим от «зоопарков» сервисов.
В этой статье мы без фанатизма и маркетинга посмотрим, что именно даёт GigAPI и где его «sweet spot»:
разберём архитектуру (ingest → Parquet → компактизация → запрос через DuckDB/FlightSQL);
оценим стоимость владения (TCO) и операционную сложность против классических кластеров;
сравним с ближайшими альтернативами: InfluxDB 3.0 (FDAP), QuestDB, TimescaleDB, ClickHouse, Apache Pinot и Apache Druid;
обсудим, когда «один контейнер + S3» — это благо, а когда вам неизбежно понадобится настоящий распределённый зверь.
Критерии, по которым пойдём:
Производительность запросов (латентность p50/p95 на типичных OLAP-паттернах: фильтры по времени, агрегаты, GROUP BY, downsampling).
Ingest и компактизация (сколько усилий нужно, чтобы поддерживать аккуратные Parquet-партии).
Эксплуатация (сколько сервисов, как настраивать, где «болит» при росте).
Гибкость данных (схема, эволюция, смешанные нагрузки).
Экосистема и интеграции (коннекторы, драйверы, UI).
Лицензия и модель распространения (MIT/Apache vs. ограничения).
В конце вас ждёт сводная таблица по всем системам и практические рекомендации: когда выбирать GigAPI (стартап/продуктовая команда, минимальный DevOps-след, дешёвое хранилище, быстрые прототипы FDAP) и когда сразу смотреть в сторону ClickHouse/Pinot/Druid (жёсткие SLA, высокий параллелизм, распределённые пайплайны) или Timescale/QuestDB (��сли нужны Postgres-экосистема или предельно простой опыт TSDB).
GigAPI — это лёгкий «тайм-серии-лейкхаус» на базе DuckDB + Parquet с FDAP-стеком (Flight/Arrow/DataFusion/Parquet)-совместимым интерфейсом: пишет и компактизирует данные в объектное/файловое хранилище, отдаёт суб-секундные SQL-запросы через HTTP/gRPC (FlightSQL), разворачивается одним контейнером и имеет MIT-лицензию. Ближайшие альтернативы по задачам и архитектуре: InfluxDB 3.0 (FDAP), QuestDB, TimescaleDB, ClickHouse, Apache Pinot/Druid. GigAPI выделяется простотой, низкими накладными и BYODB-подходом (можно «подключить» другой движок), но пока в «открытой бете» и уступает зрелым кластерам по экосистеме и горизонтальному масштабу. (GitHub)
Поехали разбирать без иллюзий и с прицелом на реальную эксплуатацию.
Обзор GigAPI (что это и как устроено)
Назначение и позиционирование
GigAPI — «лейкхаус» для временных рядов и аналитики с упором на реальное время и суб-секундные запросы, построенный на DuckDB (встроенный OLAP-движок) и Parquet (хранение на диске/S3), с FlightSQL поверх gRPC и HTTP API. Проект заявляет себя как «drop-in» альтернатива решениям на FDAP-стеке. Лицензия — MIT, основной язык — Go. Последние релизы активны (например, v2.0.44 от 1 августа 2025). (GitHub)Ключевые особенности
Быстро: DuckDB SQL + Parquet, суб-секундные аналитические запросы.
Гибко: схема-less ingestion в Parquet + встроенная компактизация.
Просто: низкие требования к администрированию; хранение — локальный FS или S3.
Разделение write/read: независимые компоненты записи/компьют.
Расширяемо (BYODB): вместо встроенного DuckDB можно использовать другой движок (ClickHouse, DataFusion и т.п.).
Режимы работы:
readonly,writeonly,compaction,aio; есть .env-настройки и docker-пример для быстрого старта; включаемый UI. (GitHub)
Интерфейсы и инструменты
FlightSQL (gRPC) и HTTP API для запросов.
Отдельные репозитории: GigAPI UI (веб-интерфейс для запросов) и gigapi-querier (Go/FlightSQL+HTTP слой), отмечено предупреждение про «open beta». Есть MCP-сервер для интеграции с Claude Desktop. (GitHub)
Кому подходит
Продуктовым/инженерным командам, которым нужна простая и дёшевая альтернатива тяжёлым OLAP-кластерам: хранить «сырые» события в объектном хранилище (Parquet), выполнять быстрые SQL-запросы без отдельного «монстра-кластера».
Кейсы: телеметрия, логи/метрики, клики/ивенты, IоT-потоки, where TCO и простота важнее, чем максимальная горизонтальная масштабируемость.
Конкуренты и контекст рынка
InfluxDB 3.0 (FDAP) — каноничный представитель FDAP-архитектуры (Apache Arrow/Flight/DataFusion/Parquet): облачные/опен-сорс сборки, быстрый аналитический движок на Parquet + Arrow FlightSQL. (InfluxData)
QuestDB — высокопроизводительная TSDB с нативным колоночным форматом, real-time SQL, ASOF JOIN, SAMPLE BY, materialized views, многопоточная векторизация. (QuestDB)
TimescaleDB — PostgreSQL-расширение для временных рядов (hypertables, компрессия, time-bucket ф-ции) с полной SQL-совместимостью экосистемы Postgres. (GitHub)
ClickHouse — универсальный колоночный OLAP с сильными возможностями по time-series (функции/гайд, движок TimeSeries в статусе экспериментального). (ClickHouse)
Apache Pinot — real-time распределённый OLAP для ultra-low-latency аналитики; ingestion из Kafka/Pulsar/S3 и мн. др. (Apache Pinot™)
Apache Druid — real-time аналитическая БД с millisecond-запросами и SQL-интерфейсом, классика для дашбордов/метрик под нагрузкой. (Apache Druid)
Сводная таблица сравнения
Система | Тип/архитектура | Хранение | Запросный слой | Интерфейсы | Лицензия | Зрелость/экосистема | Сильные стороны | Ограничения/риски |
|---|---|---|---|---|---|---|---|---|
GigAPI | Лёгкий lakehouse для TS; write/read раздельно; компактор | Parquet на FS/S3 | Встроенный DuckDB (по умолчанию) + BYODB (ClickHouse/DataFusion и др.) | HTTP, FlightSQL (gRPC); UI; docker-старт | MIT | Открытая бета, активные релизы | Простота, низкий TCO, суб-секундные SQL, без «open-core», FDAP-совместимая философия | Молодость экосистемы; ограниченная горизонтальная распределённость vs. крупные кластеры; стабильность «беты» (GitHub) |
InfluxDB 3.0 | FDAP-стек (Arrow/Flight/DataFusion/Parquet) | Parquet/Arrow | DataFusion/Arrow; FlightSQL | FlightSQL/HTTP | Открытое ядро + комм. опции | Зрелая экосистема TS | Нативная FDAP-арх., облачные опции, зрелый бренд | Лицензирование/стоимость для энтерпрайза; специфичная экосистема (InfluxData) |
QuestDB | Нативная высокоскоростная TSDB | Собственный колоночный формат; Parquet-портативность | SQL с ASOF/SAMPLE BY, векторизация | PG-wire/HTTP/ILP | Apache-2.0 (core) | Достаточно зрелая | Очень быстрые вставки/SQL по TS, простая эксплуатация | Менее универсален для «озёр»/S3-лейкхаусов, чем FDAP-подход (QuestDB) |
TimescaleDB | Расширение PostgreSQL (Hypertables) | PostgreSQL + компрессия | Полный SQL/Postgres | PostgreSQL протокол | Apache-2.0 | Очень зрелая, экосистема PG | SQL-совместимость, лёгкая интеграция с PG-миром | Вертикальная масштабируемость PG, TCO при больших объёмах/RT ingestion (GitHub) |
ClickHouse | Распределённый колоночный OLAP | Колоночные партиции; (эксп.) TimeSeries engine | SQL, векторизация | HTTP/native/JDBC/… | Apache-2.0 | Очень зрелая | Потрясающая скорость/масштаб, мощные ф-ции для TS | Более сложная эксплуатация; TimeSeries engine ещё экспериментален (ClickHouse) |
Apache Pinot | Real-time распределённый OLAP | Колоночное хранение + индексы | SQL-like | REST/Java/… | Apache-2.0 | Зрелая | Мс-задержки, ingestion из Kafka/Pulsar/S3 | Кластерная сложность, TCO при малых командах (Apache Pinot™) |
Apache Druid | Real-time аналитическая БД | Сегменты + колоночное хранение | Druid SQL | REST/SQL | Apache-2.0 | Зрелая | Быстрые slice-and-dice, надёжно под высокой конкуренцией | Кластерная сложность/операционка (Apache Druid) |
Выводы и рекомендации (практически)
Когда брать GigAPI
Нужен минимальный DevOps-след: single-container, локальный диск/S3, SQL через Flight/HTTP, UI из коробки.
Стоимость критична: храните «сырые» данные как Parquet и избегайте тяжёлых кластеров.
Требуется FDAP-совместимая интеграция и быстрые прототипы real-time аналитики. (GitHub)
Когда смотреть на конкурентов
Максимальная горизонтальная масштабируемость и SLA под высокую конкурентность → Pinot/Druid/ClickHouse. (Apache Pinot™)
Postgres-экосистема/SQL-совместимость без компромиссов → TimescaleDB. (GitHub)
Готовая «каноническая» FDAP-архитектура → InfluxDB 3.0. (InfluxData)
Встроенная TSDB с упором на скорость и простоту → QuestDB. (QuestDB)
Риски при выборе GigAPI сейчас
- «Open beta» (возможны изменения API/поведения); меньше готовых коннекторов и практик эксплуатации, чем у «тяжёлых» кластерных систем. Компенсируется простотой и MIT-лицензией. (GitHub)
