> ## Documentation Index
> Fetch the complete documentation index at: https://www.aptible.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Database Scaling

> Learn about scaling Databases CPU, RAM, IOPS and throughput

## Overview

Scaling your Databases on Aptible is straightforward and efficient. You can scale Database from the Dashboard, CLI, or Terraform to adjust your database resources like CPU, RAM, IOPS, and throughput, and Aptible ensures appropriate hardware is provisioned. All Database scaling operations are performed with **minimal downtime**, typically less than one minute.

## Vertical Scaling

Scale Databases vertically by changing the size of Containers, i.e., changing the [Memory Limits](/core-concepts/scaling/memory-limits) and [CPU Limits](/core-concepts/scaling/container-profiles). The available sizes are determined by the [Container Profile.](/core-concepts/scaling/container-profiles)

## Horizontal Scaling

While Databases cannot be scaled horizontally by adding more Containers, horizontal scaling can be achieved by setting up database replication and clustering. Refer to [Database Replication and Clustering](/core-concepts/managed-databases/managing-databases/replication-clustering) for more information.

## Disk Scaling

Database Disks can be scaled up to 16384GB. Database Disks can be resized at most once a day and can only be resized up (i.e., you cannot shrink your Database Disk).

Cloud block storage can be expanded in place, but it cannot safely be reduced in place. Shrinking a disk would require the storage provider to know which blocks are safe to discard, which is not reliable for a running cloud volume and could cause data loss.

If you need a smaller Database Disk, migrate the data to a new Database with the smaller target disk size:

* Use dump and restore for PostgreSQL or MySQL.
* Use replication and failover when your Database type and migration requirements support it.

<Note>
  For large Databases, especially those in the many tens of gigabytes or larger, dump and restore can take significant time. If the required migration window is too long, replication followed by a planned cutover may be a better fit because the new Database can catch up before you switch application traffic.
</Note>

Refer to [Supported Databases](/core-concepts/managed-databases/supported-databases/overview) to see whether replication and failover are supported for your Database type.

## IOPS Scaling

Database IOPS can be scaled with no downtime. Database IOPS can only be scaled using the [`aptible db:modify`](/reference/aptible-cli/cli-commands/cli-db-modify) command. Refer to [Database Performance Tuning](/core-concepts/managed-databases/managing-databases/database-tuning#database-iops-performance) for more information.

## Throughput performance

All new Databases are provisioned with GP3 volume, with a default throughput performance of 125MiB/s. This can be scaled up to 1,000MiB/s by contacting [Aptible Support](/how-to-guides/troubleshooting/aptible-support). Refer to [Database Performance Tuning](/core-concepts/managed-databases/managing-databases/database-tuning#database-throughput-performance) for more information.

***

## FAQ

<AccordionGroup>
  <Accordion title="Is there downtime from scaling a Database?">
    Yes, all Database scaling operations are performed with **minimal downtime**, typically less than one minute.
  </Accordion>

  <Accordion title="How do I scale a Database">
    See related guide:

    <Card title="How to scale Databases" icon="book-open-reader" iconType="duotone" href="https://www.aptible.com/docs/scale-databases" />
  </Accordion>
</AccordionGroup>