3 ms·
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 b
by prepend 6mo ago
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 6mo agoFor 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 6mo agoThose 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 6mo agoWhat 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.