To get to the level of scale that oracle can handle we had to build sharding and cluster replication from scratch. It still didn’t get to even 1/10th of a single oracle node. Obviously we made a lot of poor architecture decisions as well - in hindsight, of course.
I believe the mainframe version was first.
There is a version baked into the os/400 operating system (i series).
Then unix/windows Db2 came last, if memory serves.
I came here to say that if you want to understand Oracle's value, think IBM with less history.
IBM is a bit more nuanced. My wife grew up in an IBM town and a lot of her family and her friends’ families used to work there in the 70s and 80s. People, especially the engineers, used to take pride in their work there.
You had to be careful with MySQL back then as constraints were syntactic sugar but not enforced. PostgreSQL was indeed much tougher to manage but more full-featured.
The silent "SHOW WARNINGS" system, nonsense dates like Feb 31, implicit type conversions like converting strings to 0s, non-deterministic group by enabled by default, index corruption, etc.
Can't say the same about Oracle.
DB2, the pattern was "denormalize everything into one gigantic wide table". If you did that it was insanely fast for the time and could handle very large datasets.
For raw performance needs, many financial services schema were going to be denormalized anyway. Compression was a great way to claw some of the resulting inefficient storage back.
My recollection was that DB2 did not support multi version concurrency control like Oracle and Postgres did. The result was a lot of lock contention with DB2 if you were not careful. MVCC was eventually added to DB2, but by then it was too late.
Nobody got fired for buying IBM^W NoSQL
Windows was really picking up steam and there was a move to web development in the Windows-based developer space. Visual Basic and Delphi were popular but desktop development had peaked. ASP was for building your apps and SQL Server was the natural backend. SQL Server fed off this wave. It wasn't dislodging Oracle, but rather than every app being built on Oracle, more apps started to use SQL Server as the backend.
Then ASP.NET appeared on the scene and demand grew even more. It was a well-integrated combo that appealed to a lot of shops. I started my career in a global pharma and there was a split between tech budget. IT was a Windows shop for many reasons and ran as much on SQL Server as possible. R&D was Unix/Linux with Oracle. There was a real battle going on in the .NET vs Java (how about some EJB 1) and the databases followed the growth curves of both rather than competing against each other.
The SQL Slammer worm brought a lot of attention to the product. There were instances running everywhere and IT didn't expect so much adoption. Back then you had a lot more servers running inside offices than you do today. My office was much like my homelab today. This validated the need so the patches got applies, IT got involved in the upkeep, and adoption continued to grow.
Oracle's sales folk and lawyers were horrible to deal with. I had some experience of this directly as they tried pushing Java-related products and my boss dragged me into the evals. One of my in-laws was outside counsel in the IT space doing work with enterprise-sized companies. He claims they are the worst company he's ever had to deal with and wouldn't delegate any decision-making locally which endlessly dragged out deals. They had a good product but felt they could get away with anything. Over time he saw customers run lots of taskforces to chip away Oracle usage. This accelerated with SaaS because you could eliminate the app AND Oracle in one swoop.
Oracle was definitely seen as the more mature and resilient (and expensive!) RDBMS in all the years I worked in that space. It also ran on Unix/Linux whereas SQL Server was windows only. Many enterprises didn't like running Microsoft servers, for lots of (usually good) reasons.
ibms docs and help sites suck butt tho.
Then the two versions split and I don't think that any of the Sybase source code remains in what is SQL Server today.
That said, a lot of the concepts (like a significant number of system stored procedures) and also TSQL remain almost the same, with small differences (except for system functions, which SQL Server has a lot more functionality).
When you come from the Sybase world getting a start on SQL Server is quite straight forward when it comes to handling the database.
Internals and other low level nuts and bolts differ nowadays, of course.
It remains one of the most reliable Microsoft products, but few would claim that is a high bar.
https://news.ycombinator.com/item?id=18464429
The top comment in the post is a long complaint about the code quality of the Oracle database (worth a read).
In my experience in the late 90s and early 00s, besides Oracle and Sybase, DB/2 and Informix were also regarded as good. Oracle was considered the best though.
Naturally our customers aren't companies that care about HN audience.
I think even back then you were usually better off with distributed databases running mysql or postgres over Oracle. Although people liked to think a giant Oracle db was better.
Assume that means 5_000_000/hour. 5M/hr => 83k/min => 1400/s. That is impressive for late 90s. I was generous on what "millions per hour" meant, but even if its 2.5M/hr that would be 700/s, which is still quite good.
MySQL's big breakthrough(not specifically talking about perf) was innodb in 2010.
Just 15+ years ago Postgres had major issues with concurrency as we think about it today.
And just 10+ years ago a LOT of DB drivers weren't thread safe and had their own issues dealing with concurrency.
So nearly 30 years ago? Fuhgeddaboudit.
... and both of them were Postgres.
I used it in the late 90s for the backend for websites written in PHP3, but everyone said this was ridiculous and silly and don't you know that everyone's using the MySQL thing.
So I used this MySQL thing, but by about 2005 I'd gone back to powering my lawnmower with a 500bhp Scania V8 because I just preferred having that level of ridiculous overkill in an engine.
Nowadays? Key/Value store in RAM is probably fine for testing -> Sqlite is often Good Enough -> Ah sod it, fire Postgres into a docker container and warn the neighbours, we're going down the Scanny V8 route yet again.
You'd have to assume businesses were insane/stupid to go with Oracle to the tune of billions and billions of dollars if you believe that they had zero value to sell.