That second point is a really unnecessarily belittling straw man, and I think such comments are counterproductive to the discussion.

I don't know, if you're going to critique the very talented engineers at Uber, seeing your blog fall over due to capacity doesn't lend you a lot of credibility.

First, it's unlikely that they wrote the blog software. Second, a critique should be based on the merits of the content, not the person delivering it.

On what information do you base your opinion that the engineers at uber are very talented?

So far what i have seen, the only thing Uber is talented at is violating local laws and then throwing sacks of money at it to pay fines or whatever. (and inflating their own (bubble)value, but probably not many people agree with that)

Seeing their blogs mysql-> postgres followed by a postgres -> mysql migration, doesn't give me the idea they are very talented (they still might be, but so far no data has proven me this). Talented would be to forsee these issues and to have avoided encountering them at all. At least that would be my definition of very talented.

I'm not sure what anything you said has to do with their choice of database.

Then with your own reasoning, i'm also not sure that is worth a comment of yours.

I clearly indicate their recent changing of db software twice to avoid issues (experts could solve) is an indication one in my eyes is not very talented.

Actually no, you didn't clearly say that at all. How do the experts solve the fact that Postgres' rewrites entire indexes on row updates?

"Seeing their blogs mysql-> postgres followed by a postgres -> mysql migration" this is not clear to you? Perhaps a visit to an optician is in your best interest.

And why do you make the assumption, i'm a postgresql expert to answer that question.

Though others did, so if you would have bothered to read the other thousands of comments on the matter. You would not have needed to ask this question,

PostgreSQL Heap-Only-Tuples (HOT) from: http://use-the-index-luke.com/blog/2016-07-29/on-ubers-choic...

I disagree. When you put yourself on stage to criticize another, you open yourself up to criticism. And in this case, his little blog didn't scale, and it was rightfully pointed out.

It's not terribly nice, but the comment is true, and relevant.

Criticism is good. Straw men are not ("your opinions and arguments on dbs are irrelevant because your blog fell over"), and being holier-than-thou about it only makes people stop listening to your actual criticism. That's why I think it's unproductive.

If you're stupid enough to think that blog software reflects on the contents of the blog, then you're likely not going have the critical thinking capacity to evaluate any of these criticisms anyway.

An hour or two worth of work with varnish and you pretty much solve that problem. In 2016, that's the sort of thing I'd expect anyone competent rolling their own platform to be doing. If you're not using some off the shelf blogging platform (like blogger, wordpress.com, medium, tumblr, or infinity others that are free and not too bad) then that means you are trying to prove a point in hosting your own thing. If you can't do that very well, that perhaps proves a different point than you intended.

I run varnish even on silly joke websites I set up with no traffic and literal kilobits worth of only static content, it's just so easy to do and it's a good habit to have.

>then that means you are trying to prove a point in hosting your own thing

No it doesn't. Stop projecting.

And these moralizing comments make HN dull and dreary. Compared to 7-10 years ago sometimes I feel that suddenly we're in some sort of new Victorian era.

> static page cache behind cdn

I wouldn't want my page behind a CDN. CDNs make users much more trackable across sites.

My point isn't that CDNs are bad for everyone. My point is, once more, that most questions are not as simple as they may appear.

> CDNs make users much more trackable across sites.

How does has CDN do this in a way that a "regular" web deployment wouldn't?

The same CDN is serving thousands of sites, so they can track a ton of what users do. CDNs are perfectly placed to capture and sell user stats.

A third party (CDN provider) can easily track visits entirely server-side across all of the sites that it serves. Typically this is sites owned by lots of different companies users could otherwise visit without any of those companies knowing of visits to any other companies' sites -- the CDN knows.

This also comes up when the CDN handles SSL termination.

The fact that you can find exceptions do not change the fact that in the common case, tech x is better than tech y. Unless your use case clearly is one of the exceptions most of the time, you still win by choosing the tech that produces the best results most of the time, instead of the one that produces the best results in the exceptional cases only.

So that tech-x versus tech-y is still very relevant.

I agree that you should use the best tools for the current project. That is why we need to discuss which tool is the best and in what cases, which is all we've been doing here: providing the information people need to make reasonable comparisons.

There can be clear winners in such discussions, though this changes over the years. Many people are now concluding that Postgres is a winner at the present time and usage is expanding significantly. The people I meet aren't madly in love with Postgres, they make rational choices with the best information they have. Uber posted their information in the hope others would benefit. I think they have and I thank them for it.

(Whether you forgive me or not, I don't manage our blog site, but I guess they'll be some discussions. ;-) )

re: your second point, this isn't necessarily anything to do with database scalability or tuning.

exactly my point. sometimes the solution has nothing to do with the perceived problem.

I sincerely dislike it when the mods change the positions of comments in a thread.

It's not about being the best, it's just about comparing offerings.

I came here to thank the Postgres developers for their hard work. Also their grace under such trying times.