Насколько часто по базе будут крутиться SQL на фетчинг упомянутых 30 - 50 млн записей за неделю?
Если часто (в параллели) я бы сразу смотрел в сторону возможных увеличений read capacity путём организации read only реплик (возможно каскадных), поддержки партицирования и локально партицированных индексов (чтобы не перестраивать весь индекс при дропе старых партиций). Точнее насколько легко это все достигается на СУБД-кандидате. А если совсем Кепа включать, то стоит вложить в стоимость эксплуатации не только стоимость лицензии, но и стоимость профильного ДБА (или легкость самостоятельного администрирования как противоположный вариант).

Кстати, если планируются только большие range запросы по датам (от пары дней), то возможно индексы и не пригодятся в случае достаточной гранулярности партицирования (партиции на день например или меньше). Другое дело если над всеми этими данными будут крутиться еще какие-нибудь запросы

Касаемо самих данных, вот что еще - при таких объемах скорее всего станет вопрос физического разнесения объектов. Умеет ли мускуль хранить архивные партиции (на медленных дисках) отдельно от активных (на быстром диске)? Умеет ли parallel execution в запросах?

Наконец не стоит забывать про такие аспекты как high avaibility - если простой критичен. У того же оракла есть и серверные (standby, data guard + broker), и клиентские средства (taf) для этого. А у мускуля? Disaster recovery опять таки, как и политика резирвирования часто напрямую следуют (ограничены) доступными средствами самой СУБД.

20 полей могут быть 20 number(1) а могут быть varchar2(max)
или тут писькоcount(1)-мер детектед? :)

pkarklin, без обид
Я лишь хотел показать, что вопрос выбора субд это не только "сдюжит или не сдюжит 1,5 млрд записей", это еще и некоторые другие аспекты.