$PI This upgrade is indeed very challenging, and it's 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 highly error-prone, and if interrupted, it may require restoring 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 far 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, leaving very little window for large nodes.
So, this statement is not an exaggeration but reflects that this upgrade indeed carries high risks and operational complexity. Successfully completing more than half of the nodes' upgrades smoothly already demonstrates that operators are highly professional.