They're hard if you can't tolerate downtime, which most production users can't.
While that's true for a lot of database systems, some more recently designed are much better. [1]
[1]: https://www.cockroachlabs.com/docs/stable/upgrade-cockroach-...
While that's true for a lot of database systems, some more recently designed are much better. [1]
[1]: https://www.cockroachlabs.com/docs/stable/upgrade-cockroach-...
It's usually the company leadership that can't tolerate it to have downtime.
And it's fact, they are hit an unplanned with downtime of one service or the other every month or so because of an outage. They are used to it.
So if you plan for it, explain it, and limit the scope and time of it, it usually goes very well unless you are a fortune 500, a hospital or something alike.
I once caused a production outage in a retail company that caused all cash registers to stop working. The team that worked on that had pushed in a last minute change and didn't test if it handed going offline gracefully.
Right now I'm on call for an identity provider used by people in various timezones, including logistics workers in places that operate 24/7. Even when we do weekend upgrades, we still cause quite a bit of collateral damage. 10 minutes of time, multiply by the number of employees affected. It adds up fast.
Indeed, but who cares about the system design anymore? How many companies/ teams can claim honestly they even had a person with proper DBA competency, while features over features were added in sprints doing the minimum required to get the feature shipped out at the soonest possible (usually one DB schema change with feature and then one or more to add index due to performance regressions)? DBA competency is only sought when DB schema has fubar'd to an extent that frequent outages are norms or the version used is EOL'd by a few months at least. And by that time the people who "designed" the system are gone, not having documented ever why a given decision was made.
And that is how my friend...
DB upgrades are hard.
Postgres is a tool. It can do many things, but the tool cannot run your entire business.
this is something majority of the decision makers pretend to don't understand (and sometimes really don't).
https://engineering.theblueground.com/blog/zero-downtime-pos...
GP claimed upgrading was a piece of cake, not that zero downtime upgrades are a piece of cake. The two claims aren’t interchangeable. The simple upgrade path is always available, though it may have downtime consequences you personally are unwilling to accept. And the complex upgrade path is complex for reasons that have nothing to do with PostgreSQL - it’s just as complex to do a zero downtime upgrade in any data store, because in all cases it requires logical replication.
So if anything it feels like you’re the one being misleading by acting as though GP made a more specific claim than they actually did, and insisting that the hard case is hard because of PG instead of difficulty that’s inherent to the zero downtime requirement.
If you claim that process X is trivial one has to make some assumptions, right? Otherwise I could claim that going to the moon is trivial but leave out "assuming you have a rocket, resources, people and anything else you may require".
Claiming that something is a piece of cake as a broad statement without any details is meaningless at best.
Incredibly bad-faith comparison, this.
Many, many datastore deployments can tolerate 10 minutes of downtime every 4 or 5 years when their PG install finally transitions out of support. Data loss isn’t even in the same universe of problem. It’s reasonable to talk about how easy it is to upgrade if you can tolerate a tiny bit of downtime every few years, since most people can. It’s utterly asinine to compare that to data deletion.