A small project can survive on print, terminal history, and a few screenshots. A research project cannot.

The moment a system starts producing versions, sweeps, candidate traces, evaluator verdicts, latency samples, failed runs, penalty curves, and reproducibility bundles, it stops being only a program. It becomes a source of experimental data.

That is the moment where a DS/ML layer becomes part of engineering hygiene, not decoration.

The problem is not storage. The problem is memory.

Logs answer the question: what happened somewhere?

A research database answers better questions:

• what changed after this commit?
• which backend fails more often?
• which configs converge faster?
• which domains produce evaluator disagreements?
• which successful runs were actually contaminated by shortcuts?
• which result can still be reproduced two months later?

A terminal log is a trace. A dataset is memory.

Postgres is state. ClickHouse is observation.

PostgreSQL is excellent when the system needs consistent state: users, tasks, relations, configs, artifact metadata, queues, permissions, and application objects.

ClickHouse is built for a different type of data: append-only analytical events. Its official documentation describes it as a high-performance, column-oriented SQL DBMS for OLAP. OLAP queries often aggregate over large datasets, and columnar layout helps because analytical queries usually read only a subset of columns.

So the point is not “ClickHouse instead of Postgres”. The point is this:

Postgres stores what the system is. ClickHouse stores what the system did.

Why this matters for research systems

Consider a neuro-symbolic engine or a binary compute router. A single successful run is not enough. You need to know how it behaved across many runs.

For a systems project like Hermes, useful events look like this:

run_id
commit_sha
opcode
payload_bytes
response_bytes
latency_ms
crc_ok
backend = lisp | prolog | apl | fallback
status
error_type

For an evolutionary engine like AGI-lite, events have a different shape:

run_id
version = v7 | v9
domain
seed
candidate_id
ast_size
ast_depth
penalty
fitness
verdict
evaluator
integrity_mode

For a training system like Sonata, the event stream changes again:

epoch
step
loss
tf_answer_acc
parse_success
format_valid
loop_rate
ar_em
gate_status

These are not business records. They are observations.

DS/ML is not only model training

In this context, DS/ML tools are not there to make the project sound fashionable. They are there to stop the researcher from guessing.

A minimal analysis layer can answer questions like:

• did latency actually improve, or did one lucky run look good?
• does a lower penalty correlate with smaller ASTs or only with bloat?
• does a new evaluator reduce invalid candidates or hide them?
• does a deeper model reduce loss while making free generation worse?
• are timeouts clustered around one domain, one opcode, or one commit?

This is not “big data theatre”. It is basic experimental hygiene.

The architecture I want

Engine / Experiment
        ↓
Event logger
        ↓
ClickHouse
        ↓
Python / Polars / notebooks
        ↓
CSV / JSONL / MANIFEST.json
        ↓
verification-lab-1

The corresponding responsibility split is:

Postgres          = state and relations
ClickHouse        = observations and metrics
verification-lab  = evidence and reproducibility bundles

A compact event table is enough for the first iteration:

CREATE TABLE experiment_events
(
    ts DateTime64(3),
    project LowCardinality(String),
    run_id String,
    commit_sha String,
    event_type LowCardinality(String),

    metric_name LowCardinality(String),
    metric_value Float64,

    domain LowCardinality(String),
    backend LowCardinality(String),
    status LowCardinality(String),

    config_json String,
    payload_json String
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(ts)
ORDER BY (project, run_id, event_type, ts);

This is not the final schema. It is a starting point. In early research infrastructure, stable event writing matters more than perfect normalization.

Why ClickHouse fits the event stream

Research telemetry is usually appended, filtered by time/run/domain/backend/status, aggregated with functions such as count, avg, quantile, and countIf, and wide enough that most queries read only a few columns.

ClickHouse’s MergeTree family is designed for high ingest and large data volumes: inserts create parts, and background merges compact those parts over time. That model is a natural fit for event telemetry.

SELECT
    backend,
    quantile(0.95)(metric_value) AS p95_latency_ms,
    countIf(status = 'error') AS errors
FROM experiment_events
WHERE project = 'hermes'
  AND event_type = 'request_completed'
  AND metric_name = 'latency_ms'
GROUP BY backend
ORDER BY p95_latency_ms DESC;

This is the kind of question I want to ask constantly.

The important boundary: data is not evidence yet

ClickHouse can tell me what happened. It does not prove that the result is publishable.

That is why the analytical layer should export evidence bundles:

verification-lab-1/
  hermes/
    <run_id>/
      MANIFEST.json
      config.json
      events.jsonl
      results.csv
      audit.md
      hashes.txt

ClickHouse is queryable memory. verification-lab-1 is reproducibility evidence.

The real reason to do this

The danger in research projects is not only that a system fails. The danger is that it works once, beautifully, accidentally — and you mistake that for a law.

Not because every project needs enterprise analytics. Not because every graph is science. But because a research system without analytical memory remembers mostly the developer’s last emotion.

A research system with structured telemetry can remember distributions, regressions, failures, and evidence.

References

• ClickHouse: What is ClickHouse?
• ClickHouse: MergeTree table engine
• PostgreSQL: About

Маленький проект может жить на print, истории терминала и паре скриншотов. Исследовательский проект — нет.

Как только в системе появляются версии, sweep-и, traces кандидатов, verdict-ы evaluator-ов, latency, failed runs, penalty curves и воспроизводимые bundle-ы, она перестаёт быть просто программой. Она становится источником экспериментальных данных.

И вот здесь DS/ML-слой становится не украшением, а частью инженерной гигиены.

Проблема не в хранении. Проблема в памяти.

Логи отвечают на вопрос: что где-то произошло?

Исследовательская база отвечает на вопросы лучше:

• что изменилось после этого коммита?
• какой backend чаще падает?
• какие конфиги быстрее сходятся?
• какие домены чаще вызывают расхождение evaluator-ов?
• какие успешные запуски на самом деле загрязнены shortcut-ами?
• какой результат можно воспроизвести через два месяца?

Терминальный лог — это след. Датасет — это память.

Postgres — это состояние. ClickHouse — это наблюдение.

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

ClickHouse рассчитан на другой тип данных: append-only аналитические события. В официальной документации ClickHouse описан как высокопроизводительная колоночная SQL-СУБД для OLAP. OLAP-запросы часто агрегируют большие наборы данных, а колоночное хранение помогает, потому что аналитические запросы обычно читают только часть колонок.

Поэтому мысль не в том, что “ClickHouse вместо Postgres”. Мысль вот в чём:

Postgres хранит то, чем система является. ClickHouse хранит то, что система делала.

Почему это важно для исследовательских систем

Возьмём нейросимвольный движок или бинарный вычислительный маршрутизатор. Одного успешного запуска недостаточно. Нужно понимать, как система ведёт себя на множестве запусков.

Для системного проекта вроде Hermes полезные события выглядят так:

run_id
commit_sha
opcode
payload_bytes
response_bytes
latency_ms
crc_ok
backend = lisp | prolog | apl | fallback
status
error_type

Для эволюционного движка вроде AGI-lite форма другая:

run_id
version = v7 | v9
domain
seed
candidate_id
ast_size
ast_depth
penalty
fitness
verdict
evaluator
integrity_mode

Для обучающей системы вроде Sonata поток снова меняется:

epoch
step
loss
tf_answer_acc
parse_success
format_valid
loop_rate
ar_em
gate_status

Это не бизнес-записи. Это наблюдения.

DS/ML — это не только обучение моделей

В этом контексте DS/ML-инструменты нужны не для модного звучания. Они нужны, чтобы исследователь перестал угадывать.

Минимальный аналитический слой может отвечать на вопросы:

• latency действительно улучшилась или один запуск просто был удачным?
• низкий penalty связан с компактным AST или только с раздуванием дерева?
• новый evaluator реально уменьшил число invalid-кандидатов или просто начал их скрывать?
• большая глубина модели уменьшает loss, но ломает свободную генерацию?
• timeout-ы группируются вокруг одного домена, opcode или коммита?

Это не “big data театр”. Это базовая экспериментальная гигиена.

Архитектура, к которой я хочу прийти

Engine / Experiment
        ↓
Event logger
        ↓
ClickHouse
        ↓
Python / Polars / notebooks
        ↓
CSV / JSONL / MANIFEST.json
        ↓
verification-lab-1

И такое же разделение ответственности:

Postgres          = состояние и связи
ClickHouse        = наблюдения и метрики
verification-lab  = доказательства и reproducibility bundles

Для первой итерации достаточно компактной таблицы событий:

CREATE TABLE experiment_events
(
    ts DateTime64(3),
    project LowCardinality(String),
    run_id String,
    commit_sha String,
    event_type LowCardinality(String),

    metric_name LowCardinality(String),
    metric_value Float64,

    domain LowCardinality(String),
    backend LowCardinality(String),
    status LowCardinality(String),

    config_json String,
    payload_json String
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(ts)
ORDER BY (project, run_id, event_type, ts);

Это не финальная схема. Это стартовая точка. На раннем этапе исследовательской инфраструктуры стабильная запись событий важнее идеальной нормальной формы.

Почему ClickHouse подходит под поток событий

Исследовательская телеметрия обычно дописывается, фильтруется по времени/run/домену/backend/статусу, агрегируется через count, avg, quantile и countIf, и достаточно широка, чтобы большинство запросов читали только часть колонок.

Семейство MergeTree в ClickHouse рассчитано на высокий ingest и большие объёмы: insert-ы создают parts, а фоновые merge-и постепенно объединяют их. Такая модель хорошо подходит для событийной телеметрии.

SELECT
    backend,
    quantile(0.95)(metric_value) AS p95_latency_ms,
    countIf(status = 'error') AS errors
FROM experiment_events
WHERE project = 'hermes'
  AND event_type = 'request_completed'
  AND metric_name = 'latency_ms'
GROUP BY backend
ORDER BY p95_latency_ms DESC;

Вот такие вопросы хочется задавать постоянно.

Важная граница: данные ещё не доказательство

ClickHouse может сказать, что произошло. Но он не доказывает, что результат можно публиковать.

Поэтому аналитический слой должен экспортировать доказательные bundle-ы:

verification-lab-1/
  hermes/
    <run_id>/
      MANIFEST.json
      config.json
      events.jsonl
      results.csv
      audit.md
      hashes.txt

ClickHouse — это запрашиваемая память. verification-lab-1 — это воспроизводимое доказательство.

Настоящая причина всё это делать

Опасность исследовательских проектов не только в том, что система не работает. Опасность в том, что она один раз сработает красиво, случайно — и ты примешь это за закономерность.

Не потому что каждому проекту нужна enterprise-аналитика. Не потому что каждый график — это наука. А потому что исследовательская система без аналитической памяти в основном помнит последнюю эмоцию разработчика.

Исследовательская система со структурированной телеметрией помнит распределения, регрессии, отказы и доказательства.

Источники

• ClickHouse: What is ClickHouse?
• ClickHouse: MergeTree table engine
• PostgreSQL: About