Задал вопрос в чате по ClickHouse (https://t.me/clickhouse_ru):
существует ли там возможность удалять и обновлять строки в синхронном режиме, чтобы сразу увидеть результат в следующей же команде.
Ответил товарищ из ALTINITY. Это видимо конкурирующий или партнерский fork от ClickHouse:

авторВ ClickHouse нет транзакций.
Пока удаления, апдейты асинхронные.

Мы делаем легкие мутации (идея похожа на это https://kb.altinity.com/altinity-kb-queries-and-syntax/delete-via-tombstone-column/) они наверно к лету будут доступны.

ClickHouse inc делают транзакции, но мб тоже к лету будут.

А так тут все зависит от задачи,
https://kb.altinity.com/altinity-kb-queries-and-syntax/altinity-kb-final-clause-speed/
Что то вроде такого тоже возможно, и оно работает в real time

Хотелось бы понять эти мутации это какие-то планы или уже сейчас можно сделать какой-то обходной синхронный вариант обновления данных, а потом, когда будет готов нормальный вариант - перейти на него.

Легко ли обновлять версию ClickHouse на существующей базе. Или это каждый раз боль и страдания?

Пишу здесь, а не в чате, так как там тысячи сообщений - никто потом ответ не найдет.

Документация по ClickHouse: https://clickhouse.com/docs/ru/

Итак, после беглого изучения ClickHouse и просмотра проблем людей в чате пришел к следующему выводу:

update/delete в нём пока ансинхронные. Возможно в будущем появится что-то более дельное.
Процедуры с параметрами, которые выполняют за раз некоторое количество запросов - в самом базе сделать толком нельзя. Только писать какие-то внешние скрипты. Тем самым невозможно инкапсулировать логику в процедуре, выдав права на её запуск пользователям. То есть у пользователей в любом случае есть доступ ко всем данным (у них есть настройка прав на уровне значения полей таблицы, типа x>100, но обычно это не подходит в реальной жизни).
Либо делаешь еще один промежуточный сервис, который обрабатывает запросы.
Кто хоть раз делал хотя бы одну процедуру, состояющую более, чем из одного селекта, поймут, что это не вариант.
Триггеров тоже не нашел (вдруг кому надо).
Из документации про пользовательские функции видно, что поддерживаются только функции вида x=a+b, то есть детерминистические функции, результат которых зависит только от входящих параметров. И не может делать select к таблицам внутри функции.
https://clickhouse.com/docs/ru/sql-reference/statements/create/function/

Однако в чате пишут, что вроде как можно вызывать внешние скрипты, но прямо-таки такого же удобства как в нормальной СУБД не ждите.

Теперь на счет ультра-скорости запросов. Никакой сверхсветовой скорости выполнения запросов не увидел по сравнению с Columnstore таблицами в MS SQL Server. В тестовом облаке Яндекса (https://github.demo.altinity.cloud:8443/play пользователь/пароль demo/demo) запрос с группировкой по трем полям к таблице в 200 млн строк выполняется 1,5 секунды. Хоть первый, хоть 10-й раз.

select OriginStateName ff, OriginState sd, TailNum rr, count(*) c
from default.ontime
group by OriginStateName, OriginState, TailNum

В MS SQL запрос к таблице 500 млн строк с фильтрами по параметрам присоединенных справочников, группировкой, аналитическими функциями, последующим присоединением к справочникам: первый раз занимает 20-30 секунд, второй раз - около секунды.

Плюс множество детских проблем, например:
select round(5, 4) --0 !!!
, round(5.0, 4) --5
, round(toInt32(5), 4) --5
, round(500, 4) --500
, round(500.0, 4) --500
, round(toInt32(500), 4) --500

Нет оптимизатора запросов. Это плюс тем, кто умеет писать оптимальные запросы сам. Но минус новичкам.

В чате по ClickHouse признали, что если речь о 500 млн строк, хорошо структурированных, которые в колоночном виде лезут в оперативную память, то никакой ClickHouse не нужен, особенно, если нужны другие возможности нормальной СУБД. ClickHouse нужен только тем, у кого другие СУБД уже не вывозят, когда данных десятки, сотни, тысячи миллиардов строк. И особенно, если нужен много серверов в кластере.

В общем года через 2-3 можно будет вернуться к этой теме.
А пока на небольших базах лидирует MS SQL,
у PostgreSQL колоночные таблицы пока только в режиме добавления строк (без возможности обновления).
Осталось только выяснить работоспособность columnstore в MariaDB в соседней ветке.