PR Edit - Relocated Note

Moved !NOTE to below first paragraph per content owner's request: https://github.com/MicrosoftDocs/azure-docs-pr/pull/83948#pullrequestreview-273767841

Author: Mike-Ubezzi

articles/postgresql/concepts-pricing-tiers.md

@@ -94,10 +94,10 @@ The service automatically takes backups of your server. The minimum retention pe
 
 ## Scale resources
 
-> [!NOTE] The storage size can only be increased, and there is no option to revert back after completion of this task.
-
 After you create your server, you can independently change the vCores, the hardware generation, the pricing tier (except to and from Basic), the amount of storage, and the backup retention period. You can't change the backup storage type after a server is created. The number of vCores can be scaled up or down. The backup retention period can be scaled up or down from 7 to 35 days. The storage size can only be increased. Scaling of the resources can be done either through the portal or Azure CLI. For an example of scaling by using Azure CLI, see [Monitor and scale an Azure Database for PostgreSQL server by using Azure CLI](scripts/sample-scale-server-up-or-down.md).
 
+> [!NOTE] The storage size can only be increased, and there is no option to revert back after completion of this task.
+
 When you change the number of vCores, the hardware generation, or the pricing tier, a copy of the original server is created with the new compute allocation. After the new server is up and running, connections are switched over to the new server. During the moment when the system switches over to the new server, no new connections can be established, and all uncommitted transactions are rolled back. This window varies, but in most cases, is less than a minute.
 
 Scaling storage and changing the backup retention period are true online operations. There is no downtime, and your application isn't affected. As IOPS scale with the size of the provisioned storage, you can increase the IOPS available to your server by scaling up storage.