MongoByte MongoDB Logo

Welcome to the new MongoDB Feedback Portal!

{Improvement: "Your idea"}
We’ve upgraded our system to better capture and act on your feedback.
Your feedback is meaningful and helps us build better products.

Add new feedback Subscribe
Status Submitted
Categories Atlas
Created by Guest
Created on May 18, 2020

RELATED FEEDBACK

Allow auto-scale for IOPS.

Allow auto-scale for IOPS.
  • John Lilley
    Jan 22, 2026

    I have a use case: "exploring whether MongoDB Atlas auto-scaling can support a cost-efficient, cache-like key-value workload where demand fluctuates, the dataset is larger than memory, and access patterns are random. You’d like to confirm whether Atlas can automatically scale up from an M40 tier in response to IOPS or disk-bound pressure (rather than CPU or memory usage) to maintain performance during periods of high load."

    Support kindly informed me that it was not possible currently, so I'd like to upvote this feature.

    Reply
  • Guest
    Jul 9, 2024
    We also need this feature to be implemented badly. At this time, the way auto-scaling is configured for Atlas it only takes into account the CPU and memory utilization. My autoscaling is from M30 to M60 but my main parameter is I/O wait as we have some queries which are more like aggregate and they result into sever I/O threads. Would like Auto Scale for IOPs.
    Reply
  • Guest
    Jul 22, 2020
    CSM opening a feature request for additional autoscale configuration on behalf of a customer. The customer requests that they would like to have is the ability to autoscale Provisioned IOPS (once it is enabled) by setting a minimum, target and maximum Provisioned IOPS value for a given Atlas cluster.
    Reply
  • Guest
    Jun 19, 2020
    Hear you there: we are working on designing a very different higher level of abstraction offering that aims to deliver to what you want here. This is going to take time but definitely appreciate the feedback. -Andrew
    Reply
  • Guest
    Jun 17, 2020
    Agreed. The main issue with choosing a fixed value for Provisioned IOPS is you end up paying for IOPS you don't need 90% of the time. For example, if our service typically requires 500 IOPS and occasionally spikes to 2000 IOPS, we have no choice but to pay for 2000 IOPS all month, even though 90% of the time we only need 500 IOPS. I have to choose between paying for IOPS I don't need, or downtime. Both of these options suck. Instead, you should not limit IOPS at all (never cause downtime), and count how many I use per month, and charge me per million. This is a much fairer pay-by-usage model.
    Reply
  • Guest
    May 19, 2020
    Hi Babak, One of the challenges is that it's significantly more expensive to opt into Provisioned IOPS even when not using too many of them -- Can you confirm whether you would be comfortable using Provisioned IOPS all the time (there is a significant premium cost to doing so) in order to leverage auto-scaling for IOPS? Further, what kinds of indicators for your workload would you see as canonical drivers of needing to scale IOPS? We want to learn from you since this is nuanced and difficult to get right. -Andrew
    Reply