OLTP и OLAP: почему одна база плохо тянет оба профиля нагрузки?

Профили противоположны почти по всем осям. OLTP — короткие транзакции, точечные обращения по ключу, много мелких записей, требование низкой задержки на каждый запрос; строковое хранение здесь оптимально, потому что нужна вся строка целиком. OLAP — редкие, но тяжёлые запросы, читающие миллионы строк и две-три колонки из сорока; строковое хранение вынуждает читать всё, поэтому выигрывает колоночное. Конфликт не только в структуре хранения: аналитический запрос на прод-базе съедает кэш буферов, удерживает горизонт видимости и мешает вакууму, а сортировка на диске конкурирует за ввод-вывод с транзакциями пользователей. Отсюда стандартное решение — разделить: OLTP в реляционной базе, копия данных в аналитическом хранилище, доставка через CDC или регулярную выгрузку. Промежуточные варианты — реплика для чтения под отчёты и колоночные расширения — снимают часть боли, но не устраняют разницу профилей.