$PI This upgrade is indeed very challenging, and it's not just polite talk. There are several main reasons:

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 indexing 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 exporting and importing, taking hours or even longer. For large nodes, the window is extremely tight.

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.