For me, it's mostly performance features: Last time I checked, Postgres' query planning was based only on the rather configurable, yet completely static stats t

For me, it's mostly performance features: Last time I checked, Postgres' query planning was based only on the rather configurable, yet completely static stats tables and a few config parameters, and it didn't care very much about its experience running queries. So if for some reason I can't add quite enough stats gathering, and I know a often used query is still slow, my only choice to fix it is to do some really terrifying things to the code so that the join order is dictated by the query. In Oracle, not only is the DB going to actually look at the query's real performance by itself, but i can just tell it to change the way it runs at runtime, if all else fails. There's also data warehousing tricks that, AFAIK, Postgres does not support. In Oracle, if I have a star pattern, I can make the queries run without actually touching the fact table, only querying indices. That said, exadata is voodoo, compared to how much more predictable Postgres' behavior is. But there really is a case for it if you really are building the DB equivalent of the Titanic.