AlloyDB resource scale down

[RavikumarV]

Can we scale down AlloyDB machine type - vCPU and Memory once the cluster got created?

[ms4446]

Hi @RavikumarV ,

Unfortunately, , directly scaling down the virtual CPUs (vCPUs) and memory (i.e., the machine type) of an existing AlloyDB cluster in Google Cloud is not supported.

• AlloyDB is designed for high performance and availability. Reducing the machine type dynamically would require significant internal reconfiguration, potentially disrupting ongoing operations and cluster stability.

Possible Workarounds

Create a New Cluster

• Procedure: Start by creating a new AlloyDB cluster with the desired, smaller machine type. Then, migrate your data from the existing cluster to the new one using data migration tools like pg_dump and pg_restore.

• Considerations: This method will likely involve some downtime during the data migration process, and you'll need to handle the transfer of database connections and configurations.

[RavikumarV]

Thanks Mark Shay for your detailed answer. 

[emirokan]

Hi @RavikumarV, 

I'm a product manager for AlloyDB and am excited to help you with your question. You can absolutely scale down or up any of your instances on your cluster after cluster creation. Scale up and down operations are completed with near zero (<1s) downtime on your primary instances with high availability and with zero downtime on your read pools.  

Best,

Emir

[pshah]

I tested it on our products instance, the primary cluster took ~15 mins minimum to scale up and down which had just 400 MB total storage data.

[emirokan]

Hi pshah, 

Once you initiate a maintenance operation (scale up/down, make a flag change that requires a restart), our non-disruptive maintenance operation workflow first launches a new database server with your desired settings, catches it up to your current server's progress, and partially warm its caches. This part of the operation is what takes up to 15 minutes, and during this time, you can continue to use your database as you've been using it (establish new connection, write, read etc.) -- this is the 15 minutes you're referring to. After cache prewarming completes, we swap the servers, which results in a momentary connection drop (milliseconds) -- which is what I was referring to.

Feel free to give it another test while running your workload or a benchmark, and you'll notice that the database is fully operational during the 15 minutes of operation time. 

Let me know if you have any other questions,

Emir

[ishaankalra16]

Hi emirokan,

Can you share the relevant docs to scale up/down alloydb instances?

[ishaankalra16]

@emirokan any update?

[emirokan]

Hi Ishaan, 

Here's the doc on how to scale instances: https://cloud.google.com/alloydb/docs/instance-read-pool-scale

The non-disruptive maintenance behavior I mentioned above is covered in this doc page: 

https://cloud.google.com/alloydb/docs/overview#maintenance