In theory, Sui’s design doesn’t set a fixed TPS ceiling because its object-centric model allows massive parallelism — the limit is really the available hardware and network bandwidth. In test environments, Sui Labs has shown the system can scale into hundreds of thousands of TPS. Today, the real cap is more practical: validator hardware, network latency, and how many transactions are actually independent (touching different objects) versus shared ones that need global ordering. So the bottleneck isn’t the code, it’s the infrastructure and workload mix.

Use Compatibility Policy: If you’re building public-facing protocols, prefer compatible upgrades to avoid breaking users.

Governance Wrappers: For DAOs or protocols, store the UpgradeCap inside a governance-controlled object (instead of a single wallet).

Versioning: Always maintain a clear versioning sch

1: Build the new version sui move build

Step 2: Propose an upgrade

sui client upgrade --upgrade-cap <UPGRADE_CAP_ID>
--gas-budget 100000000
--with-unpublished-dependencies

Step 3: Commit the upgrade

sui client commit-upgrade --upgrade-cap <

Theoretical max TPS: Hundreds of thousands to over a million transactions per second, thanks to parallel execution of independent objects.

Current limits: Network bandwidth and latency, hardware constraints, consensus communication overhead, transaction complexity, and ecosystem maturity.

As infrastructure and hardware improve, real-world TPS will approach the theoretical maximum.