Add progressive strategies to help users scale read-heavy workloads

[azarboon]

The current documentation lists various scaling techniques, but users may find it challenging to determine the most appropriate approach for their scenario.

This PR introduces a new section that provides a structured, progressive strategy for scaling read-heavy workloads in Azure SQL Database and Azure SQL Managed Instance. The content is designed to help users start with foundational improvements—such as query tuning and indexing—and progress toward more advanced solutions like read replicas, partitioning, and sharding.

By presenting the options in a clear, step-by-step format, this addition enhances usability and helps users make informed decisions based on complexity, performance impact, and cost.

[prmerger-automator]

@azarboon : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change.

[learn-build-service-prod]

Learn Build status updates of commit c1da735:

✅ Validation status: passed

File	Status	Preview URL	Details
azure-sql/database/scale-resources.md	✅Succeeded

For more details, please refer to the build report.

[ttorble]

@dimitri-furman

Can you review the proposed changes?

IMPORTANT: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

[dimitri-furman]

@azarboon - thanks for your contribution! We sincerely appreciate it, however, we think that this content might belong in a best practices blog rather than in product documentation, for the following reasons:

• This specific article is about database scale up/down, i.e. changing the compute size specifically. The proposed content is much broader.
• The title of the PR references read-heavy workloads, but most suggestions can apply to any workload.
• Characterizing these suggestions as "progressive strategies" is misleading because that implies that the next one depends on the previous ones. But that is generally not the case: the suggestions are largely independent from each other.
• Most of these suggestions apply only in specific scenarios. These scenarios might be admittedly common, but we can't publish a suggestion without also saying when it might not make a difference, or when it might actually make things worse. For example, the suggestion to scale up won't solve all scalability problems, but it can make things worse for a customer by increasing cost.
• Most importantly, these suggestions largely duplicate what's already published in other articles, for example in Tune applications and databases for performance in Azure SQL Database. We recommend that you review existing documentation on each of these topics, and submit individual smaller PRs for each article where you see important content that is missing, or other improvement possibilities.

[rwestMSFT]

Thanks, @dimitri-furman. I'm closing this for now.

@azarboon We appreciate your contribution, and trust that you will find other places to make these suggestions.