mirror of
https://github.com/supabase/supabase.git
synced 2026-10-06 09:55:06 +03:00
Joshen Lim
fea8b8b41d
## Context Reverts copy changes from the following PRs: - Docs: https://github.com/supabase/supabase/pull/42184 - FE: https://github.com/supabase/supabase/pull/47646 Our platform's disk management configuration limitation still follows the 4 hour cooldown at the moment, doesn't align with AWS's 4 changes in 24 hours rule just yet. This is just to prevent any confusion for now, and we'll need to update the copy again once behaviour matches AWS on our BE <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Updates** * Disk changes are now subject to an approximately four-hour cooldown after each modification, replacing the previous limit of four changes in a rolling 24-hour period. * Disk management screens now show the cooldown status, remaining wait time, and next available update time. * Updated platform guides and troubleshooting instructions to reflect the cooldown and explain available recovery options. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
171 lines
16 KiB
Plaintext
171 lines
16 KiB
Plaintext
---
|
||
id: 'compute-and-disk'
|
||
title: 'Compute and Disk'
|
||
description: "Learn about your project's compute and disk sizing options."
|
||
---
|
||
|
||
## Compute
|
||
|
||
Every project on the Supabase Platform comes with its own dedicated Postgres instance.
|
||
|
||
The following table describes the base instances, Nano (free plan) and Micro (paid plans), with additional compute instance sizes available if you need extra performance when scaling up.
|
||
|
||
<Admonition type="note" title="Nano instances in paid plan organizations">
|
||
|
||
In paid organizations, Nano Compute are billed at the same price as Micro Compute. It is recommended to upgrade your Project from Nano Compute to Micro Compute when it's convenient for you. Compute sizes are not auto-upgraded because of the downtime incurred. See [Supabase Pricing](/pricing) for more information. You cannot launch Nano instances on paid plans, only Micro and above - but you might have Nano instances after upgrading from Free Plan.
|
||
|
||
</Admonition>
|
||
|
||
| Compute Size | Hourly Price USD | Monthly Price USD | CPU | Memory | Max DB Size (Recommended)[^2] |
|
||
| ------------ | ------------------------- | ------------------------------------------------------------------------------------------------------- | -------------------- | ------------ | ----------------------------- |
|
||
| Nano[^3] | <Price price="0" /> | <Price price="0" /> | Shared | Up to 0.5 GB | 500 MB |
|
||
| Micro | <Price price="0.01344" /> | ~<Price price="10" /> | Shared | 1 GB | 10 GB |
|
||
| Small | <Price price="0.0206" /> | ~<Price price="15" /> | Shared | 2 GB | 50 GB |
|
||
| Medium | <Price price="0.0822" /> | ~<Price price="60" /> | Shared | 4 GB | 100 GB |
|
||
| Large | <Price price="0.1517" /> | ~<Price price="110" /> | Dedicated · 2 vCPUs | 8 GB | 200 GB |
|
||
| XL | <Price price="0.2877" /> | ~<Price price="210" /> | Dedicated · 4 vCPUs | 16 GB | 500 GB |
|
||
| 2XL | <Price price="0.562" /> | ~<Price price="410" /> | Dedicated · 8 vCPUs | 32 GB | 1 TB |
|
||
| 4XL | <Price price="1.32" /> | ~<Price price="960" /> | Dedicated · 16 vCPUs | 64 GB | 2 TB |
|
||
| 8XL | <Price price="2.562" /> | ~<Price price="1" />,870 | Dedicated · 32 vCPUs | 128 GB | 4 TB |
|
||
| 12XL | <Price price="3.836" /> | ~<Price price="2" />,800 | Dedicated · 48 vCPUs | 192 GB | 6 TB |
|
||
| 16XL | <Price price="5.12" /> | ~<Price price="3" />,730 | Dedicated · 64 vCPUs | 256 GB | 10 TB |
|
||
| >16XL | - | [Contact Us](/dashboard/support/new?category=sales&subject=Enquiry%20about%20larger%20instance%20sizes) | Custom | Custom | Custom |
|
||
|
||
[^1]: Database max connections are recommended values and can be [customized via `max_connections`](/docs/guides/database/custom-postgres-config) depending on your use case. Be aware of [these considerations](/docs/guides/troubleshooting/how-to-change-max-database-connections-_BQ8P5) before modifying.
|
||
|
||
[^2]: Database size for each compute instance is the default recommendation but the actual performance of your database has many contributing factors, including resources available to it and the size of the data contained within it. See the [shared responsibility model](/docs/guides/deployment/shared-responsibility-model) for more information.
|
||
|
||
[^3]: Compute resources on the Free plan are subject to change.
|
||
|
||
Compute sizes can be changed by first selecting your project in the dashboard [here](/dashboard/project/_/settings/infrastructure) and the upgrade process will [incur downtime](/docs/guides/platform/compute-and-disk#upgrades).
|
||
|
||
<Image
|
||
alt="Compute Size Selection"
|
||
src={{
|
||
light: '/docs/img/guides/platform/compute-size-selection--light.png',
|
||
dark: '/docs/img/guides/platform/compute-size-selection--dark.png',
|
||
}}
|
||
|
||
className="max-w-[500px]"
|
||
|
||
width={2026}
|
||
height={1060}
|
||
/>
|
||
|
||
We charge hourly for additional compute based on your usage. Read more about [usage-based billing for compute](/docs/guides/platform/manage-your-usage/compute).
|
||
|
||
### Dedicated vs shared CPU
|
||
|
||
All Postgres databases on Supabase run in isolated environments. Compute sizes up to `Medium` run on shared CPU, while `Large` and above run on dedicated vCPUs. The burst behavior you can observe on Supabase relates to disk IO rather than CPU — see [Compute size](#compute-size) for the disk limits of each compute size.
|
||
|
||
### Compute upgrades [#upgrades]
|
||
|
||
<Admonition type="caution">
|
||
|
||
Compute instance changes are usually applied with less than 2 minutes of downtime, but can take longer depending on the underlying Cloud Provider.
|
||
|
||
</Admonition>
|
||
|
||
When considering compute upgrades, assess whether your bottlenecks are hardware-constrained or software-constrained. For example, you may want to look into [optimizing the number of connections](/docs/guides/platform/performance#optimizing-the-number-of-connections) or [examining query performance](/docs/guides/platform/performance#examining-query-performance). When you're happy with your Postgres instance's performance, then you can focus on additional compute resources. For example, you can load test your application in staging to understand your compute requirements. You can also start out on a smaller tier, [create a report](/dashboard/project/_/observability) in the Dashboard to monitor your CPU utilization, and upgrade as needed.
|
||
|
||
## Disk
|
||
|
||
Supabase databases are backed by high performance SSD disks. The _effective performance_ depends on a combination of all the following factors:
|
||
|
||
- Compute size
|
||
- Provisioned Disk Throughput
|
||
- Provisioned Disk IOPS: Input/Output Operations per Second, which measures the number of read and write operations.
|
||
- Disk type: io2 or gp3
|
||
- Disk size
|
||
|
||
<Admonition type="note">
|
||
|
||
The disk size and the disk type dictate the maximum IOPS and throughput that can be provisioned. The effective IOPS is the lower of the IOPS supported by the compute size or the provisioned IOPS of the disk. Similarly, the effective throughout is the lower of the throughput supported by the compute size and the provisioned throughput of the disk.
|
||
|
||
</Admonition>
|
||
|
||
The following sections explain how these attributes affect disk performance.
|
||
|
||
### Compute size
|
||
|
||
The compute size of your project affects the effective disk throughput and IOPS. The table below shows the baseline (sustained) limits and the burst (maximum) limits for each compute size. These values are minimums: every project of a given compute size gets at least these limits, and depending on the configuration your project runs on, the actual limits can be higher. For instance, an 8XL compute instance has a throughput of at least 1,188 MB/s and IOPS of at least 40,000.
|
||
|
||
<ComputeDiskLimitsTable />
|
||
|
||
Compute sizes up to 2XL can burst above their baseline for short periods of time, drawing on a disk IO budget. Once the budget is exhausted, performance returns to baseline. If you need consistent disk performance, consider upgrading your compute size.
|
||
|
||
Larger compute instances (4XL and above) are designed for sustained, high performance with specific IOPS and throughput limits which you can [configure](/docs/guides/platform/manage-your-usage/disk-throughput). From 8XL, baseline and maximum are the same, so performance does not depend on burst capacity. If you hit your IOPS or throughput limit, throttling will occur.
|
||
|
||
### Choosing the right compute instance for consistent disk performance
|
||
|
||
If you need consistent disk performance, choose the 4XL or larger compute instance. If you're unsure of how much throughput or IOPS your application requires, you can load test your project and inspect these [metrics in the Dashboard](/dashboard/project/_/observability). If the `Disk IO % consumed` stat is more than 1%, it indicates that your workload has exceeded the baseline IO throughput during the day. If this metric goes to 100%, the workload has used up all available disk IO budget. Projects that use any disk IO budget are good candidates for upgrading to a larger compute instance with higher throughput.
|
||
|
||
### Provisioned disk throughput and IOPS
|
||
|
||
The default disk type is gp3, which comes with a baseline throughput of 125 MB/s and a default IOPS of 3,000. You can provision additional IOPS and throughput from the [Infrastructure settings](/dashboard/project/_/settings/infrastructure) page, but keep in mind that the effective IOPS and throughput will be limited by the compute instance size. This requires Large compute size or above.
|
||
|
||
<Admonition type="caution">
|
||
|
||
Be aware that increasing IOPS or throughput incurs additional charges.
|
||
|
||
</Admonition>
|
||
|
||
### Disk types
|
||
|
||
When selecting your disk, it's essential to focus on the performance needs of your workload. Here's a comparison of our available disk types:
|
||
|
||
| | General Purpose SSD (gp3) | High Performance SSD (io2) |
|
||
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------- |
|
||
| **Use Case** | General workloads, development environments, small to medium databases | High-performance needs, large-scale databases, mission-critical applications |
|
||
| **Max Disk Size** | 64 TB | 60 TB |
|
||
| **Max IOPS** | 80,000 IOPS (at 160 GB disk size) | 80,000 IOPS (at 80 GB disk size) |
|
||
| **Throughput** | 125 MB/s (default) to 2,000 MB/s (maximum) | Automatically scales with IOPS |
|
||
| **Best For** | Great value for most use cases | Low latency and very high IOPS requirements |
|
||
| **Pricing** | Disk: 8 GB included, then <Price price="0.125" /> per GB<br/>IOPS: 3,000 included, then <Price price="0.024" /> per IOPS<br/>Throughput: 125 MB/s included, then <Price price="0.95" /> per MB/s | Disk: <Price price="0.195" /> per GB<br/>IOPS: <Price price="0.119" /> per IOPS<br/>Throughput: Scales with IOPS at no additional cost |
|
||
|
||
For general, day-to-day operations, gp3 should be more than enough. If you need high throughput and IOPS for critical systems, io2 will provide the performance required.
|
||
|
||
<Admonition type="note">
|
||
|
||
Compute instance size changes will not change your selected disk type or disk size, but your IO limits may change according to what your selected compute instance size supports.
|
||
|
||
</Admonition>
|
||
|
||
### Disk size
|
||
|
||
- General Purpose (gp3) disks come with a baseline of 3,000 IOPS and 125 MB/s. You can provision additional 500 IOPS for every GB of disk size and additional 0.25 MB/s throughput per provisioned IOPS.
|
||
- High Performance (io2) disks can be provisioned with 1,000 IOPS per GB of disk size.
|
||
|
||
## Limits and constraints
|
||
|
||
### Postgres replication slots, WAL senders, and connections
|
||
|
||
[Replication Slots](https://postgresqlco.nf/doc/en/param/max_replication_slots) and [WAL Senders](https://postgresqlco.nf/doc/en/param/max_wal_senders/) are used to enable [Postgres Replication](/docs/guides/database/replication). Each compute instance also has limits on the maximum number of database connections and connection pooler clients it can handle.
|
||
|
||
The maximum number of replication slots, WAL senders, database connections, and pooler clients depends on your compute instance size, as follows:
|
||
|
||
| Compute instance | Max Replication Slots | Max WAL Senders | Database Max Connections[^1] | Connection Pooler Max Clients |
|
||
| ---------------- | --------------------- | --------------- | ---------------------------- | ----------------------------- |
|
||
| Nano (free) | 5 | 5 | 60 | 200 |
|
||
| Micro | 5 | 5 | 60 | 200 |
|
||
| Small | 5 | 5 | 90 | 400 |
|
||
| Medium | 5 | 5 | 120 | 600 |
|
||
| Large | 8 | 8 | 160 | 800 |
|
||
| XL | 24 | 24 | 240 | 1,000 |
|
||
| 2XL | 80 | 80 | 380 | 1,500 |
|
||
| 4XL | 80 | 80 | 480 | 3,000 |
|
||
| 8XL | 80 | 80 | 490 | 6,000 |
|
||
| 12XL | 80 | 80 | 500 | 9,000 |
|
||
| 16XL | 80 | 80 | 500 | 12,000 |
|
||
|
||
<Admonition type="caution">
|
||
|
||
As mentioned in the Postgres [documentation](https://postgresqlco.nf/doc/en/param/max_replication_slots/), setting `max_replication_slots` to a lower value than the current number of replication slots will prevent the server from starting. If you are downgrading your compute instance, ensure that you are using fewer slots than the maximum number of replication slots available for the new compute instance.
|
||
|
||
</Admonition>
|
||
|
||
### Constraints
|
||
|
||
- After **any** disk attribute change, there is a cooldown period of approximately four hours before you can make further adjustments. During this time, no changes are allowed. If you encounter throttling, you’ll need to wait until the cooldown period concludes before making additional modifications.
|
||
- You can increase disk size but cannot decrease it.
|