5 ms·

Lots of dogmatism in this discussion, it seems. A couple of things: 1. Most psql deployments are not exposed to the interwebz, they are typically only accessib

by elric 2y ago

Lots of dogmatism in this discussion, it seems. A couple of things: 1. Most psql deployments are not exposed to the interwebz, they are typically only accessible to the applications that need them by virtue of network setup (firewalls etc). This limits the attack vector to whatever the application does. Good. 2. Distro vendors (RHEL et al) often stick to major psql release for the lifecycle of the OS version. If the OS lives longer than the psql major version, they take on the responsability of backporting critical security issues. 3. While upgrades aren't hard, they're not easy either. 4. Psql is pretty much feature complete for many workloads, and pretty stable in general. For many people, there is little need to chase the latest major version.

xvinci 2y ago
"What the application does" may not be what you think of, as it is dependent on how secure the application or the layers beneath it are. This is how people get everything pwned step by step. The database server may then reveal credentials to other apps etc.
- elric 2y ago
  Sure. Defense in depth is important. But I hope that your application is only able to talk TCP/5432 to psql. No amount of psql upgrading will protect you against SQL injections in shitty application code.
- Dylan16807 2y ago
  If the database server has significant "other apps", which it probably doesn't.
  - xvinci 2y ago
    Sure, but then chances are it's hosted on a nas with other data which you dont want ransomware'd, has access to other parts of the network, etc. - it's easy to underestimate the potential impact
atoav 2y ago
Also: 5. If your IT department is spread thin already and that old version is running fine, the incentive to potentially create more work for yourself is not gigantic.
- Dalewyn 2y ago
  One of the first laws of the universe that a good engineer learns is: Do not fix what is not broken. And no, being old is not broken.
  - sunnybeetroot 2y ago
    I do agree, however I think it’s often easier to upgrade iteratively and deal with smaller issues that arise as opposed to upgrading a huge version diff and struggling to understand and fix all the failing parts.
    - elric 2y ago
      I think there's a balance to be struck there. On large databases, upgrade time can be very slow. Is it worth upgrading iteratively at great expense if there are no benefits to be gained (e.g. no bugfixes that affect you, no critical security issues)? Maybe, maybe not.
  - atoav 2y ago
    This is solid advice, however I would caveat that you can't know if it is broken if you are not checking. E.g. if your old as hell database has a known vulernability that can be expoited, unless you can rule out that it can be used in your setup it is broken by all definitions of the word.
    - Dalewyn 2y ago
      It's not a caveat since checking is a prerequisite to the law that shall not be violated. If you are "fixing" a Schroedinger's Cat, my dude the Supreme Court of the Universe will not be kind.
  - 2y ago
newaccount74 2y ago
> 3. While upgrades aren't hard, they're not easy either I guess it depends on scale? I was surprised how easy it was on Ubuntu. There was an automatic migration script, and it worked. Took less than 5 minutes to upgrade. Sure, there was downtime, but I think most applications out there can live with scheduled downtime of a few minutes. If you can't have downtime, then nothing is easy.
- ForHackernews 2y ago
  Lots of companies pretend like they can't afford 5 minutes of scheduled downtime. Then they end up with 12 hours of unscheduled downtime when shtf.
  - bravetraveler 2y ago
    For SRE (site reliability engineering) the term of art is 'error budget' To others reading, be mindful: database upgrade times depend greatly on the data stored within them/where/who is using them. Your development environment doesn't represent production. If the distinction even exists! A five minute upgrade can become indefinite with a single lock [row/table, depending on the storage engine/etc]
mhd 2y ago
> 3. While upgrades aren't hard, they're not easy either. And in my experience, apart from ease of use there's also a major trust issue here. If you're upgrading your app server framework/language, it's easy enough to do a rollback. With databases, people are worried that they might not notice errors right away and then you have to merge the data accumulated since the upgrade with the last backup in case of a rollback. Not saying that this is entirely rational... Also, new features on the SQL level are hard to sell if all you're doing is lowest common denominator ORM ("New window functions and faster lateral joins? But we're doing all that in our code!").
bravetraveler 2y ago
> 4. Psql is pretty much feature complete for many workloads, and pretty stable in general. For many people, there is little need to chase the latest major version. To drive this a little further, "latest and greatest" doesn't always apply. I've chosen software - even databases - for greenfield deployments one or two releases behind for their known characteristics. Stability doesn't imply perfection, but rather, predictability.
KaiserPro 2y ago
Upgrading a datastore is a massive, massive risk. It requires a lot of work, planned downtime, or some way to smear updates across the estate. The cost of any failure is very high. The benefit of any major upgrade is also vanishingly small. Unless you need a specific feature, its just not worth it.
- ttfkam 2y ago
  Or when the version is EOL, not getting security patches, and/or only compatible with an OS that isn't getting security updates. …or you're on AWS RDS, which will automatically bump your db cluster if it goes EOL and you ignore the notices for more than a year.
JeremyNT 2y ago
I think this is a really good take. It all boils down to "if it ain't broke don't fix it." No matter how easy it is, it takes more effort and thought to do an upgrade than it does to not do an upgrade at all, and for most users the upside is basically invisible if it exists at all.

by elric 2y ago

xvinci 2y ago

"What the application does" may not be what you think of, as it is dependent on how secure the application or the layers beneath it are. This is how people get everything pwned step by step. The database server may then reveal credentials to other apps etc.

elric 2y ago
Sure. Defense in depth is important. But I hope that your application is only able to talk TCP/5432 to psql. No amount of psql upgrading will protect you against SQL injections in shitty application code.
Dylan16807 2y ago
If the database server has significant "other apps", which it probably doesn't.
- xvinci 2y ago
  Sure, but then chances are it's hosted on a nas with other data which you dont want ransomware'd, has access to other parts of the network, etc. - it's easy to underestimate the potential impact

atoav 2y ago

Also: 5. If your IT department is spread thin already and that old version is running fine, the incentive to potentially create more work for yourself is not gigantic.

Dalewyn 2y ago
One of the first laws of the universe that a good engineer learns is: Do not fix what is not broken. And no, being old is not broken.
- sunnybeetroot 2y ago
  I do agree, however I think it’s often easier to upgrade iteratively and deal with smaller issues that arise as opposed to upgrading a huge version diff and struggling to understand and fix all the failing parts.
  - elric 2y ago
    I think there's a balance to be struck there. On large databases, upgrade time can be very slow. Is it worth upgrading iteratively at great expense if there are no benefits to be gained (e.g. no bugfixes that affect you, no critical security issues)? Maybe, maybe not.
- atoav 2y ago
  This is solid advice, however I would caveat that you can't know if it is broken if you are not checking. E.g. if your old as hell database has a known vulernability that can be expoited, unless you can rule out that it can be used in your setup it is broken by all definitions of the word.
  - Dalewyn 2y ago
    It's not a caveat since checking is a prerequisite to the law that shall not be violated. If you are "fixing" a Schroedinger's Cat, my dude the Supreme Court of the Universe will not be kind.
- 2y ago

newaccount74 2y ago

> 3. While upgrades aren't hard, they're not easy either I guess it depends on scale? I was surprised how easy it was on Ubuntu. There was an automatic migration script, and it worked. Took less than 5 minutes to upgrade. Sure, there was downtime, but I think most applications out there can live with scheduled downtime of a few minutes. If you can't have downtime, then nothing is easy.

ForHackernews 2y ago
Lots of companies pretend like they can't afford 5 minutes of scheduled downtime. Then they end up with 12 hours of unscheduled downtime when shtf.
- bravetraveler 2y ago
  For SRE (site reliability engineering) the term of art is 'error budget' To others reading, be mindful: database upgrade times depend greatly on the data stored within them/where/who is using them. Your development environment doesn't represent production. If the distinction even exists! A five minute upgrade can become indefinite with a single lock [row/table, depending on the storage engine/etc]

mhd 2y ago

> 3. While upgrades aren't hard, they're not easy either. And in my experience, apart from ease of use there's also a major trust issue here. If you're upgrading your app server framework/language, it's easy enough to do a rollback. With databases, people are worried that they might not notice errors right away and then you have to merge the data accumulated since the upgrade with the last backup in case of a rollback. Not saying that this is entirely rational... Also, new features on the SQL level are hard to sell if all you're doing is lowest common denominator ORM ("New window functions and faster lateral joins? But we're doing all that in our code!").

bravetraveler 2y ago

> 4. Psql is pretty much feature complete for many workloads, and pretty stable in general. For many people, there is little need to chase the latest major version. To drive this a little further, "latest and greatest" doesn't always apply. I've chosen software - even databases - for greenfield deployments one or two releases behind for their known characteristics. Stability doesn't imply perfection, but rather, predictability.

KaiserPro 2y ago

Upgrading a datastore is a massive, massive risk. It requires a lot of work, planned downtime, or some way to smear updates across the estate. The cost of any failure is very high. The benefit of any major upgrade is also vanishingly small. Unless you need a specific feature, its just not worth it.

ttfkam 2y ago
Or when the version is EOL, not getting security patches, and/or only compatible with an OS that isn't getting security updates. …or you're on AWS RDS, which will automatically bump your db cluster if it goes EOL and you ignore the notices for more than a year.

JeremyNT 2y ago

I think this is a really good take. It all boils down to "if it ain't broke don't fix it." No matter how easy it is, it takes more effort and thought to do an upgrade than it does to not do an upgrade at all, and for most users the upside is basically invisible if it exists at all.