[digitallis42]

Depends on your scale. If you're a startup or even just a small side service, performance isn't going to be a bottleneck and you/the org wants the thing to be fire and forget, including bug fixes and especially security patches. A distro takes care of all of those generally and makes sure the dependencies have the same care taken.

[throw0101c]

> A distro takes care of all of those generally and makes sure the dependencies have the same care taken.

So does using the vendor repos:

* https://apt.postgresql.org/ / https://yum.postgresql.org

* https://dev.mysql.com/downloads/repo/

This way when you upgrade your OS you don't have to worry about suddenly getting a new version (which, in the case of MySQL, may take a long time to convert its database files to the new version format).

[necovek]

> This way when you upgrade your OS you don't have to worry about suddenly getting a new version (which, in the case of MySQL, may take a long time to convert its database files to the new version format).

At least on Ubuntu (and likely Debian), your existing Postgres version is never dropped until you are ready to manually upgrade yourself.

[RealStickman_]

Using third party repos makes upgrading the OS in general more difficult though and is more dangerous than simply using what your distro provides.

[jamespo]

How does that work for python/perl/ruby libs etc?

[danudey]

It's very rare that the client protocol changes dramatically and in an incompatible way, so typically nothing changes and no one notices.

I've seen a few rare cases where an update to the client library is required for improvements to the protocol, e.g. when MySQL switched to the new password/authentication format, but that was also backwards-compatible: the old format was used until an account's password was changed, password changes could be told to use the legacy format instead, and you could set the legacy format by default. The only issue that occurred (and it did occur) was old client libraries + new server password hashes, but, again, in this case it didn't affect existing installations/users/passwords.

[crabbone]

> This way when you upgrade your OS

Don't forget to do this on Friday afternoon! :D

Upgrading OS in production environment... this reminds me of a joke about police academy intake test:

The participants were offered a board with a round and a square hole and two pegs of similar shape. After the test the new recruits were sorted into two groups: very smart and very strong

So, yeah, you ought to be either very smart or very strong to upgrade OS in production environment, and then also discover changes to your database as you go along.

That's not to say that upgrades don't happen at all... but you'd be upgrading in a testing environment ten times before you try that "for real", and at that point you would have probably solved the question of whether you need to (re)install the database and how :)