I disagree as I was running clustered sql server 6.5 and 7 in 1998 for hundreds of concurrent users doing millions of reads per hour on NT basically commodity boxes. Replaced it with Oracle for 100x cost and lost performance.

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.

▲

whatisthiseven 3 days ago | parent | next [-]

For others like me who might be skeptical to hear throughput in any metric other than seconds (and is used to large numbers in hours/days being used to inflate), I think millions per hour is actually quite high for 1998.

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.

	▲	Rapzid 3 days ago \| parent [-]
		Those are big numbers especially for non-enterprise DBs in the 90s. 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.

▲

mike_hearn a day ago | parent | prev [-]

What do you mean a distributed database running mysql or postgres? Even today you can't have a distribute db running (real) Postgres, it doesn't do multi-master clustering.