[catblast]

> I would argue that using postgres today sets you up better for HA tomorrow

The point is, if I have the money I can get enterprise grade HA today. Yugabyte and cockroach are promising but they’re small unproven organizations and as history has shown they’re likely to get bought out and then who knows.

Larry Ellison is an asshole, Oracle the company itself makes me want to vomit but they are a pretty known quantity.

> CTO / Architect / whatever is more at risk by choosing Oracle in 2020.

This trope started reaching fever pitch during the first wave of OSS commercialization hype/fervor in 98. It wasn’t true then and I see no evidence it is any more true today.

[rkarthik007]

Hi @catblast,

(I am the CTO of Yugabyte) Your points are all completely valid. Just wanted to add my 2 cents.

With YugabyteDB specifically, we are more than just PostgreSQL wire-compatible, we "reuse" the upper half of PostgreSQL to support almost all PG features (examples: stored procedures, triggers, partial functions, etc). So the aim is to build something that has "almost all PG features" while being able to "run cloud-native - with HA, scale and geo-distribution" - our hope is that this allows YugabyteDB to really become a viable option instead of PostgreSQL when apps are being built for the cloud. Here is a blog post on the benefits we realized reusing PostgreSQL: https://blog.yugabyte.com/why-we-built-yugabytedb-by-reusing...

[thda]

> This trope started reaching fever pitch during the first wave of OSS commercialization hype/fervor in 98. It wasn’t true then and I see no evidence it is any more true today.

It is not. And I know of several major banks leaving oracle "en masse" because of licensing nightmare. The major decision makers are now endangered by their choice of oracle as a database to consider. Oracle in a new project is now a firm NO.

Regarding HA, active/passive and failover is enough for 99% of the use cases. For the rest you'd need citus or patroni, but it's totally manageable. I'd be quite dismissive of an architect who suggests oracle if there are no extreme availability requirements. I'd also prefer a galera or an innodb cluster for active/active architectures.

Let's face it: oracle database is dying an its niche is shrinking.

[catblast]

> oracle database is dying an its niche is shrinking.

This is true, but misleadingly not the whole truth. On prem RDBMS is dying and its niche shrinking (at least in this part of the cycle)... having said that, Oracle cloud offerings are doing very well.

Amazon made a herculean effort, and made some headlines when they migrated most of the business off Oracle last year. That's wonderful, for Amazon. Most of Oracle's enterprise customers are not Amazon.

> I'd also prefer a galera or an innodb cluster

The thing is.. Oracle sells so much more than just an DB engine, and people are buying. Oracle RDBMS is not an inferior product to open source competitors, in most ways superior, and yet, it is really just a proverbial loss leader.

[ntsplnkv2]

I mean, a company with as much data as Amazon leaving is a pretty big deal and obviously is in the news.

Are Oracle cloud offerings actually doing well? What evidence is there of this?

[catblast]

They’re a publicly traded company, this is readily available information. Sure the growth is not a hockey stick, but they’re not exactly dying either. The way people talk on here you’d think they’re filing for bankruptcy tomorrow.

[ntsplnkv2]

Which is about what you expect - Oracle has a sizeable legacy business with which they can exploit. But are they really winning new business without subsidy?

[thda]

> Oracle RDBMS is not an inferior product to open source competitors, in most ways superior

It is also in a lots of extremely critical ways inferior. The huge complexity, the huge footprint, the humongous prices are enough to justify staying far away from it.

[tomnipotent]

Oracle DB is not intended for WordPress and RoR web apps. It's an entirely different beast of an offering, and if your business is in need of what it can do than by this point the "huge complexity" is nothing compared to what your organization is probably already dealing with.

When you have thousands of engineers, "complexity" is very subjective.