Hacker News Reader

Comment by prepend | Hacker News Reader

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.

View on HN

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.

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.

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.

Reply on news.ycombinator.com