In other words, how should schema design in Azure SQL differ from schema design for SQL on VM or hardware? What additional factors should the DBA consider when designing schemas for Azure SQL databases and managed instances?
In order to narrow the question scope, you can limit your answer to OLTP primary and cluster key selection and design.
For some context for my admittedly broad question, I am not finding a definitive resource for guidance on schema design in the context of Azure SQL PaaS scaling features. When designing a database schema with Azure SQL in mind, what design choices will maximize the utility and ease the future implementation of scaling features, including Sharding, SQL Data Sync, Read Scale-Out and Hyperscale?
It is very likely that 'it depends' is the correct answer (no green checkmark though.)
Even so, I think it an important question and want to start the conversation here in SO and get the most useful answers in one place.
The most correct answers will be practical on a small scale and will also be compatible with Azure SQL scaling features without major refactoring.
Other similar questions have outdated answers and were posted before many of these features were introduced:
