Scaling_

Native databases scale in two dimensions: the compute specification (CPU, memory, and connection limit) and storage. Both can change after creation, without dump-and-restore migrations.

List available specifications

Each database runs against a specification that defines its CPU, memory, included storage, and maximum connections. List the specifications available to your plan:

Change the compute specification

From the API, pass the new specification ID:

Resizes apply with zero downtime through a rolling cutover: a new instance is provisioned on the target specification, data is streamed over, and traffic cuts over once it has caught up. The database status shows scaling while the resize is in progress.

Storage

Each specification includes a storage allowance, and storage beyond the allowance is billed per GB. Storage only grows; you cannot shrink a database's storage after it has expanded. To reclaim a smaller footprint, restore a backup into a new database.

Storage autoscaling

With storage autoscaling enabled, Appwrite grows the storage automatically when usage crosses a threshold, so the database never hits a full disk. Configure it through the API:

Set a cap if you want a hard ceiling on storage cost; without one, autoscaling grows storage as needed and the overage is billed per GB.

Picking a specification

Guidelines for choosing a starting tier:

• Connections: count the maximum concurrent connections your application opens, including all replicas of your app server. If it exceeds the specification's connection cap, either move up a tier or put the connection pooler in front.
• Memory: MySQL performs best when the working set fits in memory. Track cache hit ratio with database metrics; a sustained ratio below ~99% for an OLTP workload is a sign to add memory.
• CPU: sustained CPU above 70-80% at normal load leaves no headroom for spikes, migrations, or backups.

Start small and resize up when the metrics say so; resizes are online, so there is no penalty for growing later.