Привет, дорогой дайджест! Постараюсь ответить.

Первое, на самом деле, это обе системы не про скорость. Про скорость - Clickhouse, DuckDB, Tarantool. А эти про удобство. Там много где платится скоростью за удобство. За наличие [почти] честных транзакций, или за способность съедать огромные «крокодилы» SQL запросов, где 40 раз написано слово JOIN. Сравнивать по скорости две заранее архитектурно тормозные вещи - забавное упражнение.

Второе. Скорость сети в 100 ГБит/с (12500 мб/сек) сейчас не особо кого удивит. На ноду! Эта скорость вполне сравнима с дисками образца 4-5 летней давности. То есть современные Трины примерно по скорости как немного старые Гринпламы. Терпимо вполне.

Третье. А в какой нагрузке измеряем? Узкое место гринплама в большой организации - число потоков выполнения. А если нам надо concurrency=100? ГП известен своей непроходимостью при большом числе параллельных потоков выполнения. А что если нам надо нарастить внезапно число потоков? Тут нам на помощь и придет разделение compute-storage (на самом деле compute-metastore-storage) и возможность нарастить потоки чтения в конкретный датасет.

Одним словом, есть общее правило - удобство выше перформанса. Мы уже все давно сидим на виртуализации, облаках, с детачнутыми сторажами дисков и т.д. Так же и тут.

И Четвертое. Мы все инженеры, и если стоит задача в «правильном» сравнении, то его всегда можно придумать. Например, адски зажать Гринплам по ресурсам, а у него оверхедов много. Трино более неприхотливае, там одна джава машина вместо 4-8 сегментов-постгресов. Запусти на 6 облачных ядрах это все - вот тебе и будет нужная картинка.

Как мы говорили на самом стриме - только тесты на твоих датасетах под твоей нагрузкой дадут тебе адекватную картину. Любые тесты из интеренетов - булшит.