Home

Compute Add-ons

Every project on the Supabase Platform comes with its own dedicated Postgres instance running inside a virtual machine (VM). The following table describes the base instance with additional compute add-ons available if you need extra performance when scaling up Supabase.

PlanPricingCPUMemoryMaximum Disk IO BandwidthBaseline Disk IO BandwidthConnections: Direct (recommended)Connections: Pooler (recommended)
Free (Included)$02-core ARM (shared)1 GB2,606 Mbps87 Mbps60200
Small$52-core ARM (shared)2 GB2,606 Mbps174 Mbps90200
Medium$502-core ARM (shared)4 GB2,606 Mbps347 Mbps120200
Large$1002-core ARM (dedicated)8 GB4,750 Mbps630 Mbps160300
XL$2004-core ARM (dedicated)16 GB4,750 Mbps1,188 Mbps240700
2XL$4008-core ARM (dedicated)32 GB4,750 Mbps2,375 Mbps3801500
4XL$95016-core ARM (dedicated)64 GB4,750 Mbps4,750 Mbps4803000
8XL$1,86032-core ARM (dedicated)128 GB9,500 Mbps9,500 Mbps4906000
12XL$2,79048-core ARM (dedicated)192 GB14,250 Mbps14,250 Mbps5009000
16XL$3,72064-core ARM (dedicated)256 GB19,000 Mbps19,000 Mbps50012,000

Contact us if you require a custom plan.

Dedicated vs. shared CPU#

All Postgres instances on Supabase are dedicated applications running inside dedicated virtual machines. However, the underlying hardware resources, for example the physical CPU, may be shared between multiple VMs, but appear to the OS as if it is a dedicated hardware CPU. This is commonly referred to as a vCPU (virtual CPU). Cloud providers use these shared hardware resources to save cost—you can upgrade to a larger compute add-on to guarantee a dedicated physical CPU for your instance.

Compute upgrades #

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 or 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 in the Dashboard to monitor your CPU utilization, and upgrade later as needed

Disk IO bandwidth#

SSD Disks are attached to your servers and the disk performance of your workload is determined by the Disk IO bandwidth of this connection. Smaller compute instances can burst up to the maximum disk IO bandwidth for 30 minutes in a day. Beyond that, the performance reverts to the baseline disk IO bandwidth. For example, the free tier can burst up to 2,606 Mbps for 30 minutes a day and reverts to the baseline performance of 87 Mbps. If you need consistent disk performance, choose the 4XL or larger compute add-on which has the same baseline and maximum disk IO bandwidth.

If you're unsure of how many IOPS your application requires, you can load test your project and inspect these metrics in the Dashboard. If the Daily Disk IO Budget % Remaining stat is less than 100%, it indicates that your workload has burst beyond the baseline IO throughput during the day. If this metric drops to zero, the workload has used up all the burst IO throughput minutes during the day and is running at the baseline performance. These projects are good candidates for upgrading to a larger compute add with higher baseline throughput.