Azure SQL Hyperscale, Very Large Tables, and lack of explicit partitioning

Question

Hyperscale scales to 100TB when it comes to storage. And I understand the page server concept - each server handling 128GB of data, with its own local cache.

What I do not understand though is how this can scale from a performance perspective, without explicit user sharding/partioning.

If I have a single table, with billions of rows and terabytes of data, my indexes will continue to grow proportionately. Every insert will have to update those as well. Surely any query that does a table scan will crumble eventually, and even those using the indexes will get slower and slower?

Other DB solutions that scale tables infinitely, enforce a partition key, and that key needs to be in any query predicate. How can Hyperscale get away without that requirement? Have I missed something?

Thanks!

Answer 1

I spoke directly to MS on this. Their answer is that there is no promises - the bad situation I described could well happen. They don't give any SLAs on performance on Hyperscale. There is no way to influence how it shards the data between page servers.