Yeah, used it in a PoC in the past (because it was supposed to be either equal to AWS but cheaper or better but equal cost; spoiler: it was neither). Problems a

Yeah, used it in a PoC in the past (because it was supposed to be either equal to AWS but cheaper or better but equal cost; spoiler: it was neither). Problems are mostly bad integration and older style integration where it exists (think: older API types, very little code generation, unpolished SDK, mostly targeted at integrating with their own non-cloud stuff). Performance was not so bad, but equal performance somehow always came at a higher cost when compared to AWS or Google Cloud (did no comparison with Azure, wasn't used in that case). Not super much, think 1.2x, but enough to make you scratch your head and wonder if the extra effort for something that isn't making developers happy is worth it. The only thing that in some constructions was cheaper was their database offering, but when you build something that needs to work in a cloud, the same effort (depending on your own control of the stack) can be put in to making it work with Postgres. That's mostly because older style database-driven applications expect 1ms latency and less, and you simply can't do that over the internet or with a layered construction in a cloud. If you were migrating local oracle workloads to a hosted oracle setup (i.e. their cloud instead of an MSP) it would make sense. Otherwise not really. One reason we take into account that others might not: our developers and ops simply don't "like" oracle. Doesn't really matter why, because the portion of people that don't like it is large enough that we'd rather spend more to make our teams work well vs. save a few pennies and make them work with sub-par tooling. Unhappy and unproductive teams costs money too.