#PI $PI This upgrade is indeed very challenging, not just polite talk. The main reasons are:

1. Triple major version synchronized upgrade
Protocol (22→23), operating system (Ubuntu 20.04→24.04), database (PostgreSQL 12→16) upgraded simultaneously. Any single upgrade carries risks, and the combination of all three means compatibility, dependencies, and configuration file changes will affect each other.
2. Internal data reprocessing required
Many upgrades only involve replacing software, but this time, because the underlying storage format or index logic has changed, nodes need to reprocess existing data with the new logic. This process is very error-prone, and if interrupted, may require recovery from snapshots, which is very time-consuming.
3. Zero tolerance in production environment
If mainnet nodes go offline or data is corrupted, it will affect the entire network’s consensus and block production. Operators must repeatedly verify on testnets and complete operations with no downtime or minimal downtime, which is much more stressful than upgrading a personal computer.
4. Large gap from PostgreSQL 12→16
This version spans several years and introduces many changes such as query optimization, data types, and parallel execution. Database migration often requires export and import, taking hours or even longer, with very tight windows for large nodes.
So, this statement is not an exaggeration but reflects that this upgrade indeed carries high risks and operational complexity. Successfully upgrading more than half of the nodes smoothly already shows that operators are very professional.