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.
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
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.
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.
I don't remember exactly what and why, just that for some specific DML commands another kind of connection was required.
It's notable that 10 was the worst Sybase version, ever.
Source: I worked for Sybase Professional Services from 95 - 99.
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.
It remains one of the most reliable Microsoft products, but few would claim that is a high bar.
ibms docs and help sites suck butt tho.
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.
Do you remember if that was a recent addition?
Full disclosure: I was quite the newbie back then and most of what I "new" about SQL Server was what the more experienced coworkers told me. This was a very IBM-biased place so I'm not surprised they would have stuck to some old shortcoming, like people who still talk about bad MySQL defaults that have been changed for at least 10 years.
Up until that job (which was my second Actual Formal Job), all my DB experience had been with either dBase (I think III plus or IV) and access, so this was a whole new world with me.
It was through MS SQL Server that a colleague taught me about backups and recovery, after I ran an update in prod but forgot to include the where clause ... :)
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).
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.
Starting with version 7.5 it was quite alright, however being Microsoft, it has been mostly used in Microsoft shops, alongside VB, MFC two tier applications, ASP, .NET, Sharepoint, Dynamics,...
I built apps in an active-active bidirectional replication telecom Sybase environment and was deeply involved in migrating it to MS SQL server in the early 2000s. I remember a fair amount of paranoia and effort around the transition as our entire business and customers' phone calls depended on it (for "reasons") but in hindsight it went quite smoothly and there were no regrets afterwards.
The Microsoft went and added a nice BI stack to the whole thing which added a new dimension of value creation at a new low price point.
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.
Imagine the antithesis of Emacs. That's an IBM environment with 3270 terminals and obtuse commands to learn.
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'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.
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.
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.
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.
As I understand it, you would have to script a separate watchdog process for the basic PostgreSQL, to get high availability.
https://www.theregister.com/2016/05/16/salesforce_replace_or...
... 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.
Can't say the same about Oracle.
MS SQL is today stil a very good product, using it now for more than 20 years in different applications.
And: The free version with max up to 50 GB (?) of DB size is a very good option for smaller environments/apps
Visual Studio is also great and widely adopted.
But what else do they have? I had some good experiences with Exchange years ago, but this is just my personal experience, since most people seem to hate it.
What else do they have that is considered a good/solid product that you would recommend to someone?
A very long time ago (circa 2000) there were basically 2 databases that worked for use cases where you needed high availability and vertical scalability and those were Oracle and Sybase and Oracle was really the only game in town if you actually wanted certain features like online backups and certain replication configurations.
At the time, MySQL existed and was popular for things like websites but had really hard scalability caps[1] and no replication so if you wanted HA you were forced to go to oracle pretty much. Postgres also wasn't competitive above certain sizes of tables that seem pretty modest now but felt big back then, and you used to need to shut postgres access down periodically to do backups and vacuum the tables so you couldn't use it for any sort of always-on type of use case.
Oracle also had a lot of features that now we would use other free or cloud-hosted services for like message queues.
[1] in particular if you had multiple concurrent readers they would permanently starve writers so you could get to a situation where everyone could read your data but you could never update. This was due to a priority inversion bug in how they used to lock tables.