[mmt]

> they would solve it for you

That hasn't been my experience, at least not on any suitable time scale.

I strongly suspect that the vast majority of those of us who have worked somewhere "not more capitalized and viable" than the vendor share that experience.

Even when a vendor's support engineer is fully capable of solving the problem, the sense of urgency can't reasonably be expected to match that of a much smaller customer facing potentially catastrophic data loss (or other existential-threat-level consequences).

[manigandham]

Vendors have support plans and SLAs so if you need 24/7 support then make sure that is indeed what you're paying for.

I do not see how having spare engineering talent capable of reading, editing and running a custom database build is the more realistic or faster option for any business in case of issues.

[mmt]

> Vendors have support plans and SLAs so if you need 24/7 support then make sure that is indeed what you're paying for.

Those are totally useless during an existential crisis without associated indemnity (which any vendor would be crazy to provide) against loss due to failur to perform.

> I do not see how having spare engineering talent capable of reading, editing and running a custom database build is the more realistic or faster option for any business in case of issues.

I don't see how it isn't, considering that "custom database build" could be so simple as to be trivial. In the GP's case, it was merely using a specific version.

Even the characterization of the required engineering talent as "spare" seems incongruous, as, in small companies, the talent requird to handle unexpected problems with technlogies fundamenta to running the business is essential, not superfluous.

[jchanimal]

The proof is in the pudding. Plenty/most serious users of open source databases become customers of the relevant companies. The commercial license is usually a small fraction of the potential cost of an outage.