Skip to content

Database tiers & scaling

Every database runs on an instance tier that fixes its vCPU, RAM, and disk. Tiers range from a free 0.25 vCPU / 0.5 GB / 1 GiB instance up to dedicated 8 vCPU / 16 GB instances, and you can change tier in both directions after creation.

The instanceType on a database is one of these tier slugs. cpu is vCPU, memory is GB RAM, disk is the provisioned volume in GiB, and monthly is USD per month.

Tier slugLabelvCPURAM (GB)Disk (GiB)$/moFree?
free-tierFree0.250.510yes
standard-tierStandard121018.25no
c1-compute-tierC1-Compute242051.10no
c1-2xcompute-tierC1-2XCompute4840102.20no
c2-compute-tierC2-Compute61260109.50no
c2-2xcompute-tierC2-2XCompute81680219.00no
m1-memory-tierM1-Memory142043.80no
m1-2xmemory-tierM1-2XMemory284087.60no
m2-memory-tierM2-Memory2124094.90no
m2-2xmemory-tierM2-2XMemory42480189.80no

The C-series is compute-optimized (higher vCPU per GB), the M-series is memory-optimized (higher GB per vCPU), and the 2X variants double both. A tier’s serverDetails (cpu, memory, disk) is echoed on every database detail response.

Any tier other than free-tier requires an active paid plan. The same server-side check (isOrgPaid) gates both container and database create/change paths, so a free organization cannot provision or move to a paid tier — a create or change request that violates this returns 402.

A database’s architecture sets how many replicas it runs:

architectureTopologyReplicasAvailabilityPlan
standaloneSingle Zone1No HAAny tier
replicasetMultiple Zone3High availabilityPaid only

The free tier is single-zone only — selecting a free tier snaps architecture back to standalone. High availability requires a paid tier.

POST /v1/databases/:id/tier

changeTier handles all directions — scaling up, scaling down, rescuing a free database to paid, and downgrading paid → free. You never state the direction; the server classifies it from the tier catalog.

Request body (ChangeTierInput):

FieldTypeRequiredNotes
instanceTypestringYesTarget tier slug; must exist in the catalog (else Unknown tier.).
expectedCurrentTierstringNoOptimistic concurrency — the tier you believe is current. If it doesn’t match, the request 409s (stale).
confirmDowngradeToFreebooleanNo (default false)Required acknowledgement to downgrade to free-tier.

Behavior:

  • One change at a time. A change is rejected while the database is in a busy status (updating, deleting, deploying, queued, pending).
  • Intent vs. reality. The row records targetInstanceType as the requested intent; the worker advances the real instanceType only on verified success.
  • Optimistic concurrency. Pass expectedCurrentTier to guard against a racing change — a mismatch returns 409.
  • Topics. A scale-up/down emits database.upgrade; a downgrade to free emits database.downgrade-free, both consumed by worker-v3.
Terminal window
curl -X POST https://api.pandastack.io/v1/databases/903/tier \
-H "Authorization: Bearer $PANDASTACK_TOKEN" \
-H "Content-Type: application/json" \
-d '{ "instanceType": "c1-compute-tier", "expectedCurrentTier": "standard-tier" }'

Downgrading to free-tier requires the explicit confirmDowngradeToFree acknowledgement — it is destructive to billing and re-arms the 30-day suspend/purge lifecycle (see Free-tier lifecycle). It is a compute-only downscale that keeps the existing disk — Kubernetes cannot shrink a PVC, so the volume is not reduced.

Terminal window
curl -X POST https://api.pandastack.io/v1/databases/903/tier \
-H "Authorization: Bearer $PANDASTACK_TOKEN" \
-H "Content-Type: application/json" \
-d '{ "instanceType": "free-tier", "confirmDowngradeToFree": true }'

The number of concurrent connections a database allows scales with your plan:

PlanDB connection limit
Free50
Pro300
Premium1000
Enterpriseunlimited