docs: state disk limits as per-size minimums, align burst copy (#50016)

## What kind of change does this PR introduce?

Docs update: states disk limits as per-size minimums and aligns burst
copy across pages. Follow-up to #49996 (compute descriptions).

Fixes PROD-658

## What is the current behavior?

- The disk limits table and surrounding prose describe a narrower set of
configurations than a compute size can run on
- Burst thresholds are inconsistent across pages (three different
variants), and one section contradicts itself
- Burst is described as CPU behavior, when the burst users observe is
disk IO

## What is the new behavior?

- `shared-data/compute-disk-limits.ts`: Medium baseline throughput
adjusted to 39 MB/s: the lowest value across configurations
- `compute-and-disk`: disk limits presented as minimums ("at least");
burst described as disk IO drawing on a disk IO budget; consistent
thresholds: burst available up to 2XL, baseline equals maximum from 8XL
- Troubleshooting guides (`exhaust-disk-io`,
`failed-to-retrieve-tables`, `interpreting-supabase-grafana-io-charts`)
aligned to the same threshold; `failed-to-retrieve-tables` keeps the
~30-minutes-per-day burst window with the corrected size range
- Section anchors unchanged

## Self-review

- Values verified against the AWS EBS-optimized performance data
(`describe-instance-types`) for every configuration per size; content
cross-checked with the internal runbooks (linked in PROD-658)
- `supa-mdx-lint`: no findings in changed files
- `pnpm build:guides-markdown` clean; generated `.md` exports show the
new values and prose
- All changed pages verified rendering in the local dev app
- `pnpm typecheck` passes (shared-data + docs)
- Note: `compute-disk-limits.ts` also feeds Studio (disk validation, IO
budget tooltips). The only value change (Medium 43 → 39 MB/s) surfaces
there as one chart tooltip label; conservative direction.


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

- **Documentation**
- Clarified the differences between shared and dedicated CPU resources.
- Updated disk I/O guidance to explain baseline and burst limits as
minimums.
- Documented disk I/O bursting for compute sizes up to 2XL, including
expected duration and limitations.
- Clarified that 8XL and larger compute sizes have consistent
performance without burst capacity.
- Updated the documented baseline throughput for medium compute
resources.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

apps/docs/content/guides/platform/compute-and-disk.mdx

@@ -56,7 +56,7 @@ We charge hourly for additional compute based on your usage. Read more about [us
 
 ### Dedicated vs shared CPU
 
-All Postgres databases on Supabase run in isolated environments. Compute instances `Nano` to `2XL` compute size have CPUs which can burst to higher performance levels for short periods of time. Instances bigger than `Large` have predictable performance levels and do not exhibit the same burst behavior.
+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]
 
@@ -88,13 +88,13 @@ 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 both the baseline (sustained) limits and the burst (maximum) limits for each instance size. For instance, an 8XL compute instance has a throughput of 1,188 MB/s and IOPS of 40,000.
+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 />
 
-Smaller compute instances like Nano, Micro, Small, and Medium can burst above baseline for short periods of time. Once burst capacity is exhausted, performance returns to baseline. If you need consistent disk performance, consider upgrading your compute size.
+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). If you hit your IOPS or throughput limit, throttling will occur.
+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
 

apps/docs/content/troubleshooting/exhaust-disk-io.mdx

@@ -9,7 +9,7 @@ database_id = "4844905d-1456-44a1-858e-7a4995e5054c"
 
 Disk IO refers to two metrics: throughput in Megabytes per second (MB/s) and IOPS which are Input/Output Operations per Second. Throughput measures how much data you can move each second, while IOPS measures how many read/write operations you can perform each second. Depending on the compute add-on of your instance you will have [different baseline performances](/docs/guides/platform/compute-and-disk#compute-size).
 
-Smaller compute instances can burst and exceed their baseline performance for a short period of time every day. This is represented as your Disk IO Budget and once your Disk IO Budget is consumed, your instance reverts back to its baseline performance. Learn more about [choosing the right compute instance for consistent disk performance](/docs/guides/platform/compute-and-disk#choosing-the-right-compute-instance-for-consistent-disk-performance).
+Compute sizes up to 2XL can burst and exceed their baseline performance for a short period of time every day. This is represented as your Disk IO Budget and once your Disk IO Budget is consumed, your instance reverts back to its baseline performance. Learn more about [choosing the right compute instance for consistent disk performance](/docs/guides/platform/compute-and-disk#choosing-the-right-compute-instance-for-consistent-disk-performance).
 
 ## Depleting your disk IO budget
 

apps/docs/content/troubleshooting/failed-to-retrieve-tables.mdx

@@ -25,8 +25,8 @@ Trying to connect to the project via the API will often result in a 522 or 525 r
 
 Out of memory errors usually happen because of a sudden spike in database activity, or a sustained high level of activity, either due to a high volume of queries or very complex queries (or a combination of both).
 
-Note that Nano, Micro, Small and Medium compute instances have 30 minutes of burst capacity on a daily basis so may be able to handle sustained high activity for a short period of time,
-but not sudden spikes.
+Note that compute sizes up to 2XL can burst disk IO above their baseline for a total of about 30 minutes per day, so they may be able to handle high activity for a short period of time,
+but not sustained spikes.
 
 ## Next steps and preventative measures
 

apps/docs/content/troubleshooting/interpreting-supabase-grafana-io-charts-MUynDR.mdx

@@ -14,11 +14,11 @@ There are two primary values that matter for IO:
 - **Disk Throughput**: how much data can be moved to and from disk per second
 - **IOPS(Input/Output per second)**: how many read/write requests can be performed against your disk per second
 
-Each compute instance has unique IO settings. The current baseline (sustained) and max (burst) limits are listed below.
+Each compute size has its own IO limits. The baseline (sustained) and max (burst) limits below are minimums — depending on the configuration your project runs on, the actual limits can be higher.
 
 <ComputeDiskLimitsTable />
 
-Compute sizes below XL can burst above baseline for short periods before returning back to their baseline behavior.
+Compute sizes up to 2XL can burst above baseline for short periods before returning to their baseline behavior.
 
 There are other metrics that indicate IO strain.