One can choose page size by table. One can choose buffer size by tablespace. One can assign tables to arbitrary tablespaces. One can have covering indexes. And the list goes on.

Again, the number of folks that Oracle/IBM/M$ dedicate to their engines is likely an order of magnitude greater than what PostrgreSQL has.

How an Open Source product moves is, often, a Squeakiest Wheels rather than Grand Vision thing. Python excepted. In the case of PG, the storage model and memory model can be a lot more like DB2 (fur instance) if Enterprise is the way the community wants to go. Or not. But if PG community does want to be an Enterprise DB, then it needs to think seriously along such lines.

You mean flexible, as in requiring one data type for text data 2000 bytes (Oracle). Or flexible as in not running on anything by Windows, with known scalability problems (SQLServer). Or flexible like preventing read SQL while a writes are taking place, and upgrading locks to table level if you lock too many rows (DB2).

Open source gives people what they need by delivering many small usability enhancements and peer review of code means things work the way they should, not the way the marketing department thinks is probably OK.

Alas, that is not an option for me today.

I would add to that “…along with a huge amount of other engineering effort around and within X to get X to do what you really need”.

“PG isn’t immune from having patches and forks.”

Absolutely true. I work for such a company. The difference I think is that postgres, as a community, seems to have a more authoritative mainline offering and less confusion over patches, forks, and even options. Equally as important, the postgresql mainline accepts contributions without copyright assignment.

That being said, I get the impression that MySQL is standardizing on InnoDB for the vast majority of uses now that it’s the default in mainline. I think that’s a very positive step (observing mostly from outside, of course).

I agree that these references get too much credit in the press. They should mean that you can be successful using product X but are misinterpreted to mean that you will be successful using it.

PG isn’t immune from having patches and forks. PGWest was hosted by the vendor of one (EnterpriseDB) and the rebuttal came from JD whose company does Mammoth Replicator, a PG replication fork/patch.

Skype was cited as a company that runs PG at web-scale. I haven’t found many details on that deployment (another company X uses product Y reference). But they also have patches (SkyTools) to make it work for them.

There is a world of difference among these engines. No two of them even have semantically equivalent ACID implementations; although Oracle/PostgreSQL are the two closest. So far as knobs and switches go, the three commercial engines are by far the most flexible. But they should be; they have legions of coders.

Also, this applies to every discussion of the form “Big Company runs on XYZ; therefore XYZ must be good.”. I didn’t mean that yours was the only article that glossed over words like “runs on” — I think it’s quite common, which is why I posted this.

This post wasn’t so much about the statement itself, but how it is being analyzed. That’s why I tried to step away from specific company names, because I just don’t know enough of the details.

The main point is that “using” a DBMS means very different things to different organizations. That’s even more true when it’s an open source DBMS, because the large organization probably modifies it significantly; but it applies to the closed systems as well. While I don’t know much about Facebook specifically, I’m fairly sure that it takes a huge amount of custom code and engineering to go from stock MySQL to the architecture that supports Facebook’s data management.

It doesn’t imply that I think MySQL is better or worse than PG. I think that PG is awesome and rocks (but I have yet to acquire my “PG Rocks” t-shirt).