diff --git a/apps/docs/content/guides/platform/compute-and-disk.mdx b/apps/docs/content/guides/platform/compute-and-disk.mdx
index 64e8f1791b5..6cc108d8f58 100644
--- a/apps/docs/content/guides/platform/compute-and-disk.mdx
+++ b/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
 
diff --git a/apps/docs/content/troubleshooting/exhaust-disk-io.mdx b/apps/docs/content/troubleshooting/exhaust-disk-io.mdx
index 5d7b5451eb2..31613c87049 100644
--- a/apps/docs/content/troubleshooting/exhaust-disk-io.mdx
+++ b/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
 
diff --git a/apps/docs/content/troubleshooting/failed-to-retrieve-tables.mdx b/apps/docs/content/troubleshooting/failed-to-retrieve-tables.mdx
index 6bd2d9327a1..d52be5e7dad 100644
--- a/apps/docs/content/troubleshooting/failed-to-retrieve-tables.mdx
+++ b/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
 
diff --git a/apps/docs/content/troubleshooting/interpreting-supabase-grafana-io-charts-MUynDR.mdx b/apps/docs/content/troubleshooting/interpreting-supabase-grafana-io-charts-MUynDR.mdx
index bdca726ddb9..79e257d575e 100644
--- a/apps/docs/content/troubleshooting/interpreting-supabase-grafana-io-charts-MUynDR.mdx
+++ b/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.
 
diff --git a/packages/shared-data/compute-disk-limits.ts b/packages/shared-data/compute-disk-limits.ts
index 4d5597f4e84..10ecd9075f0 100644
--- a/packages/shared-data/compute-disk-limits.ts
+++ b/packages/shared-data/compute-disk-limits.ts
@@ -1,10 +1,13 @@
 import { z } from 'zod'
 
 /**
- * [Jordi] Use instances.vantage.sh as source of truth for compute disk limits.
- * Eg: https://instances.vantage.sh/aws/ec2/t4g.nano?currency=USD
+ * Size-wide floor values for disk limits.
  *
- * All compute from medium down are t4g and the bigger ones are m6g.
+ * Each value is the minimum across all configurations a compute size can run
+ * on, so every project gets at least these limits; the actual limits of a
+ * given project can be higher. Derived from the AWS EBS-optimized performance
+ * tables (https://instances.vantage.sh, mirroring
+ * `aws ec2 describe-instance-types`). Last verified: 2026-09-04.
  *
  * Throughput values are stored in MB/s (AWS lists Mbps, so we convert with toMBps).
  */
@@ -45,7 +48,7 @@ export const COMPUTE_DISK = {
     name: 'Medium',
     baselineIops: 2000,
     maxIops: 11800,
-    baselineThroughputMBps: toMBps(347),
+    baselineThroughputMBps: toMBps(315),
     maxThroughputMBps: toMBps(2085),
   },
   ci_large: {