Странно когда спрашиваешь про фичу для хранилищ в других СУБД, а некто приплетает OLTP и специфический сценарий когда фича не работает (для direct-path и unique constraint violation).
Подытоживая это своими ощущениями касательно обесценивания.

Интересно узнать на чем делает хранилища прогрессивное человечество.

Например, требования такие:
- Загрузка
Данные берутся в разной форме из разных источников (при этом загрузка разных порций данных может идти параллельно).
В итоге всё это консолидируется и грузится в звезду с приростом 10 лярдов фактов в сутки.
Здесь именно критично что в звезду (с фактами, измерениями и генерацией ключей для измерений) а не широкую таблицу на 100500 колонок как можно было бы запилить в хадуп.
- Редактирование/Чтение
Пользователи должны иметь возможность получать (и редактировать) наборы данных по определенным критериям [за секунды].
Здесь важно что крайне желательно избежать полного сканирования фактов а значит должен быть аналог subpartitioning (ибо пользователи работают с данными за конкретный день + критерии).
Вместо subpartitioning это может быть даже smart storage когда блоки данных отсекаются на основании фильтров или другая фича которая поможет избавиться от сканирования ненужного.

Мне удалось добиться некоторых успехов на AWS Redshift, но какие будут альтернативы Ораклу on-premises?

В ветке PG никто ничего не может сказать как расследовать проблемы с производительностью в прошлом или стабилизировать планы.
22401619
Это вызывает определенные опасения.

вспоминается бисер

а по теме - денег нет в постгресе, и гнуть спину за эту поделку (да даже и против - не вижу смысли=)Можно придумать узко специализированную задачу для которой PG лучше Оракла.
В частности я отвечал тут ( 22401641 ) про вектора/массивы для ptr128 который хорошо начал, но аргументацию дал ложную.

Если переформулировать реальный use-case:
Бывают ситуции когда число метрик или атрибутов или подставь_свое неизветсно на этапе дизайна.
Представим для простоты что нам приходят сущности с массивом метрик.
В таком случае это можно
- каждую метрику хранить в отдельной строке (читай EAV)
- либо хранить все метрики в одном поле JSON/XML
- либо хранить все метрики в массиве/векторе/nested table/whatever
Проблема Оракла, что при хранении всех метрик в одном атрибуте к ним невозможно достучаться SQL-но так же быстро как если бы они были каждая в отдельном столбце.
Парсинг JSON/XML тяжелые операции по CPU, unnnesting для nested table еще хуже.

В PG элементарно в SQL доступ к элементу массива по индексу. Особо креативные люди могут запилить свои SQL-ные типы , например ассоциативный массив с доступом по тегу типа JSON.

Если не вырывать фразу из контекста я писал что альтернатива в облаке Redshift и вопрос был про альтурнативу on-premises.
Бездумный пиар вызывает скорее отторжение.

И как импала нормально справляется с десятками одновременных запросов?
В 2017 когда я тесно с этим работал, после определенного числа пользователей импала отваливалась с нехваткой памяти (ясное дело, выполняемые запросы тоже имели значение, не только их число).
Потом правда вроде были заметные улучшения по управлению ресурсами.
Но касательно стабильности импалы и масштабируемости по числу пользователей отношение уже очень скептическое.

Стек hadoop + spark абсолютно нежизнеспособен когда есть требования
1) параллельной заливки из разных источников (с генерацией суррогатных айдишников для измерений)
2) возможность редактирования данных

Если загрузку еще можно выставить в очередь, то необходимость редактирования убивает стек технологий на корню.
У нас умельцы пытались разрулить через in-memory cache (читай GridGain), но это добавляло проблем а не решений.

PS. Про delta почитаю, не сталкивался. А какие проблемы этот инуструмент помог решить в вашем случае?