That reminds me of this hilarious comment of 25 million lines of code in Oracle DB: https://news.ycombinator.com/item?id=18442941

> The only reason why this product is still surviving and still works is due to literally millions of tests!

So basically the same strategy as Hwaci with SQLite, except with precisely opposite results.

> Their RDBMS is an amazing product.

I hope you're referring to MySQL!

The Oracle DB is a crufty old throwback to the bad old days where you needed highly specialized experts to spend dozens of hours to install, configure, and tune a massively admin unfriendly piece of software.

It comes with a command-line tool (psql) with NO command history, NO tab completion, or other interactive help system. Only uncompressed file import/export formats. The need to manually manage data files when creating a table, and even specifying their file sizes. Oracle's DB is quite stable and reliable, but it is practically a biplane or steam locomotive compared to almost any other DB out there. Even the similarly aged PostgreSQL is an absolute joy to work with in comparison.

> Oracle's DB is quite stable and reliable

Can't speak for the OP but I think that's what he/she meant. Tooling might not be the best due to their proprietary nature, but the software itself kicks ass.

It does it really? I’ve worked in a company who had to file bugs against data access components and they point blank refuse to fix the issues.

Tuning an Oracle database is a dark art of undocumented parameters.

Increasingly, you can swap out Oracle with Postgres.

> Increasingly, you can swap out Oracle with Postgres.

Well, there is also a huge decrease of DB competencies around (myself first, not shifting the blame on anyone). So, now finally all you need is "just a db", DBAs are gone. Most people don't even need non-relational DBs but hey that's cool. Don't get me started :) I wouldn't blame it on the software (oracle) itself but on the fact that with microservices (and managed DBs) the role of a specific DB seems to have decreased significantly.

I'd say the 'increasingly' isn't simply because of the loss of DB competency.

I worked at a shop that for years was an 'always oracle' even though every license renewal visit left management paranoid and dejected, that got won over by the level of similarity between the two.

MSSQL doesn't mesh well with oracle because it isn't MVCC by default, so risk of conversion goes WAY up.

MySQL, well it was(is?) missing a number of other features alongside a touchy datatype model and other warts in people's memory.

PG tends to do well at picking the right features from other DBs, and you just pay a quote tax to enjoy the benefits.

> the fact that with microservices (and managed DBs) the role of a specific DB seems to have decreased significantly.

I do think this is the third point in the trident. In some shops (I've yet to see one!) you can get a database per-microservice. More frequently I see 'database-per-ecosystem' which means your microservices share a DB.

Oracle RAC runs rings around pretty much any other RDBMS in highly available database clustering. It’s very good (and very $$$).

Bubkis. SQL Server's high availability is a dream to use and rock solid. Everything else is a joke in that space.

And how do you fix such a mess? Fork postgreSQL.

You need to have database expertise if you want to operate a database at any significant scale. All of those configuration parameters don’t go away just because you’re not asked by the software to configure them. There are a lot of use cases out there where a more simple product would be most suitable, but I’ve seen plenty of instances of choosing a more simple tool and then one by one encountering every single problem that a more sophisticated RDBMs would be capable of easily solving.

Also, I really like Postgres, but it’s a nightmare to work with at scale. Even simply things like execution plan monitoring and management are tedious in Postgres, but incredibly easy to stay on top of with the _tooling_ provided by Oracle.

Having migrated large codebase/product from SQL Server to Postgres, can definitely relate. I love Postgres as a developer, but from DBA/devops perspective, Postgres requires babysitting where SQL Server just works. Things like having to manually customize work_mem for complex queries feels very cumbersome and is very inefficient, - it should be solved by software.