# Can SupaHost scale as my app grows?

> SupaHost scales vertically: each plan is a bigger VM, and changing plan resizes it in a minute or two. Capacity guides per plan, what doesn't exist (read replicas), and when to look beyond.

Source: https://supahost.app/kb/scaling · Updated 2026-11-11

Yes, up to the size of one server. SupaHost scales **vertically**: every plan is a bigger VM, and moving up a plan resizes your instance in about a minute or two of downtime. Disks grow automatically as they fill. There are no read replicas or multi-server setups, so if you outgrow the Business plan, the next steps are Enterprise (custom sizing) or a platform built for horizontal scale, such as Supabase Cloud.

## Capacity by plan

Measured with load tests, for a typical app where 5% of monthly users are active in the busiest hour, each making a request every 10 seconds:

| | Builder | Pro | Business |
|---|---|---|---|
| Server | 2 shared vCPU, 4 GB RAM | 2 vCPU, 8 GB RAM (dedicated) | 4 vCPU, 16 GB RAM (dedicated) |
| Monthly active users | about 25,000 | about 50,000 | about 100,000 |
| Concurrent Realtime connections | about 5,000 | about 15,000 | about 30,000 |
| API reads per second | about 300 | about 540 | about 950 |
| Password sign-ins per second | about 19 | about 18 | about 38 |
| Database / files / egress | 8 GB / 100 GB / 250 GB | 25 GB / 250 GB / 500 GB | 50 GB / 500 GB / 1 TB |

These are guides, not limits. A heavy query or a missing index can use more of the server than thousands of light requests. Sign-ins are CPU-bound because password hashing is deliberately slow.

## Scaling levers

- **Change plan.** Dashboard → **Usage & billing** → Change plan. The VM is resized, with a minute or two of downtime, so pick a quiet moment.
- **Add-ons.** Raise database ($1.25 per 10 GB/month), file storage ($1.05 per 50 GB/month) or egress ($12 per 100 GB/month) without changing plan.
- **Make queries cheaper.** Indexes and leaner RLS policies often buy more headroom than a bigger VM:

  ```sql
  -- find the slowest statements
  select calls, round(mean_exec_time::numeric, 1) as avg_ms, left(query, 80) as query
  from pg_stat_statements order by mean_exec_time desc limit 10;
  ```

- **Move work off the request path.** Queue slow jobs and process them in batches with pg_cron and Edge Functions instead of doing them while the user waits.

## What isn't available

No read replicas, no connection pooler, no multi-server failover and no SLA. All projects on an instance share one Postgres server (400 connections) and one VM. Pricing doesn't change with users: there are no per-MAU, per-connection or per-invocation fees.

## FAQ

### How do I know when to upgrade?

Usage alerts email you at 80%, 90% and 100% of your database, file storage and egress quotas. For CPU and memory, watch response times and the [High CPU usage](/kb/high-cpu) and [High memory](/kb/high-memory) guides; live instance metrics in the dashboard are coming later.

### Does upgrading lose data?

No. The same disk is attached to the larger VM; only the machine type changes. Expect a minute or two of downtime.

### Can I add read replicas later?

Not on SupaHost. If you need replicas or horizontal scaling, ask about Enterprise (supahost@volods.com), or consider Supabase Cloud.

## Related

- [Plans and limits](/docs/platform/plans)
- [Changing plans](/docs/platform/changing-plans)
- [Usage, quotas and add-ons](/docs/platform/usage)
- [Speeding up slow queries with indexes](/kb/improve-query-performance)