Time will tell whether customers will prefer to get reamed for Oracle hardware to avoid some Oracle software costs, or simply switch to DBs with less tied pricing models.
SQLServer only runs Windows, their licensing model gets more and more Oracle like every year (for us currently "buying" SQLServer from internal IT isn't much cheaper than Oracle anymore). And you have to maintain you own JDBC driver.
DB2 is just the same thing as Oracle.
PostgreS does not compare.
Then there's the migration itself. Firstly your application will be "tuned for Oracle" over several years. So you'll use every proprietary Oracle feature that gives you additional performance (subpartitions, parallel query execution, optimizer hints, manual column statistics, connect by, listagg, …). Which makes porting fun. You can't assess the performance of your application on the new database until you're done porting. Likely the most performance critical parts will have the most Oracle dependencies. You won't have any experience performance tuning the new database. And you won't have any experience operating the new database (monitoring, trouble shooting, backups, HA, failover, maintenance, …).
Take all this together and we're pretty much locked into Oracle. So I see us go with Oracle hardware rather than switch to some other database. Which has the additional benefit of getting rid of the "engineered" SAN by the internal IT which is slower than a single SSD.
DB2 supports sub-capacity licensing on a wide variety of virtualisation platforms, unlike Oracle. This may or may not matter to you. It does to me under a variety of circumstances.
DB2 also has much more granularity in licensing before you have to ramp up to ASE, which, again, may make a big difference to you (many equivalent features are available a significantly lower price points).
> So you'll use every proprietary Oracle feature that gives you additional performance (subpartitions, parallel query execution, optimizer hints, manual column statistics, connect by, listagg, …).
More than a few of these are trivial conversions to other DBs. CONNECT BY is hardly magic, neither's parallel query execution or listagg.
Operational concerns are probably the biggest one.
> Take all this together and we're pretty much locked into Oracle.
If you're in a business where running your company on whatever schedule Oracle chooses to offer you, that won't be a problem.