Platform

Compute and Disk


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.

Compute SizeHourly Price USDMonthly Price USDCPUMemoryMax DB Size (Recommended)1
Nano2$0$0SharedUp to 0.5 GB500 MB
Micro$0.01344~$102-core ARM (shared)1 GB10 GB
Small$0.0206~$152-core ARM (shared)2 GB50 GB
Medium$0.0822~$602-core ARM (shared)4 GB100 GB
Large$0.1517~$1102-core ARM (dedicated)8 GB200 GB
XL$0.2877~$2104-core ARM (dedicated)16 GB500 GB
2XL$0.562~$4108-core ARM (dedicated)32 GB1 TB
4XL$1.32~$96016-core ARM (dedicated)64 GB2 TB
8XL$2.562~$1,87032-core ARM (dedicated)128 GB4 TB
12XL$3.836~$2,80048-core ARM (dedicated)192 GB6 TB
16XL$5.12~$3,73064-core ARM (dedicated)256 GB10 TB

Compute sizes can be changed by first selecting your project in the dashboard here and the upgrade process will incur downtime.

We charge hourly for additional compute based on your usage. Read more about usage-based billing for compute.

Dedicated vs shared CPU

All Postgres databases on Supabase run in isolated environments. Compute instances smaller than Large 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.

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 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

The following sections explain how these attributes affect disk performance.

Compute size

The compute size of your project sets the upper limit for disk throughput and IOPS. The table below shows the limits for each instance size. For instance, an 8XL compute instance has a maximum throughput of 9,500 MiB/s and a maximum IOPS of 40,000.

Compute InstanceDisk ThroughputIOPS
Nano (free)43 MiB/s250 IOPS
Micro87 MiB/s500 IOPS
Small174 MiB/s1,000 IOPS
Medium347 MiB/s2,000 IOPS
Large630 MiB/s3,600 IOPS
XL1,188 MiB/s6,000 IOPS
2XL2,375 MiB/s12,000 IOPS
4XL4,750 MiB/s20,000 IOPS
8XL9,500 MiB/s40,000 IOPS
12XL14,250 MiB/s50,000 IOPS
16XL19,000 MiB/s80,000 IOPS

Smaller compute instances like Nano, Micro, and Small have baseline performance levels that can occasionally be exceeded. Larger compute-instances (4XL and above) are designed for sustained, high performance with specific IOPS and throughput limits. 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. 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 MiB/s and a default IOPS of 3,000. You can provision additional IOPS and throughput from the Database Settings page, but keep in mind that the effective IOPS and throughput will be limited by the compute instance size.

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 CaseGeneral workloads, development environments, small to medium databasesHigh-performance needs, large-scale databases, mission-critical applications
Max Disk Size16 TB60 TB
Max IOPS16,000 IOPS (at 32 GB disk size)80,000 IOPS (at 80 GB disk size)
Throughput125 MiB/s (default) to 1,000 MiB/s (maximum)Automatically scales with IOPS
Best ForGreat value for most use casesLow latency and very high IOPS requirements

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.

Disk size

  • General Purpose (gp3) disks come with a baseline of 3,000 IOPS and 125 MiB/s. You can provision additional 500 IOPS for every GB of disk size and additional 0.25 MiB/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 and WAL Senders are used to enable Postgres 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 instanceMax Replication SlotsMax WAL SendersDatabase Max Connections3Connection Pooler Max Clients
Nano (free)5560200
Micro5560200
Small5590400
Medium55120600
Large88160800
XL24242401,000
2XL80803801,500
4XL80804803,000
8XL80804906,000
12XL80805009,000
16XL808050012,000

Constraints

  • After any disk attribute change, there is a cooldown period of approximately six 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.

Footnotes

  1. 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 for more information.

  2. Compute resources on the Free plan are subject to change.

  3. Database max connections are recommended values and can be customized depending on your use case.