Yes, we use EBS SSD on the backend so we can scale up storage separately from the instance. Our Cloud performance metrics are based on this backend so the short answer is no it doesn't constrain perf. The constraint I see right now is that we are currently mostly GP2 with a planned migration to GP3 which will allow for new independent controls of IOPS and throughput. There are certain, uncommon, situations where customers need to bump up performance beyond what the normal GP2 perf steps allow.

To tie GP2/3 back into the serverless vs. DBaaS concepts we are looking at auto-scale for IOPS/Throughput performance while also allowing more direct access such that a customer could control performance via APIs to manage on your own.

(timescaler here)

And to follow up: Today your IOPS will automatically scale with storage, and you can set storage to autoscale with your usage. Under the covers, we continually look for ways we can optimize that for our users, without them having to think of this.

So for most users, they can "set it and forget it" (easy, scalable): Launch a default cloud database, which starts out small, autoscaling on by default. As they start inserting data, the system automatically detects when it starts to approach current capacity and automatically increases (without any downtime) to more capacity & IOPS.

But for the power user, they have greater control. What that means is that you can manually resize, and as mentioned above, we'll likely also give you independent control over IOPS (independent of capacity). That's the flexibility and control we think developers also want...or at least know is there is they need it.

(Timescaler & post author)

That makes sense to me. Are you saying you're not IO limited usually though?

Some kinds of database workloads would run more efficiently on the local NVMe storage. But that does come with lots of operational considerations.

Bandwidth on vpc peering is free within the same AZ since may 2021