From 716be2b8df685f98136a67e300fa4b1b36d6316a Mon Sep 17 00:00:00 2001 From: Greg Date: Wed, 30 Oct 2024 22:45:48 -0400 Subject: [PATCH] Disk and compute docs update (#30194) * Updated compute and disk documentation to better reflect the state of compute and disk customization in the updated dashboard * Update apps/docs/content/guides/platform/compute-and-disk.mdx Co-authored-by: Charis <26616127+charislam@users.noreply.github.com> * update disk docs * update docs * Removed burst from documentation and added table to better outline differences between io2 and gp3 disk types * Deleted compute and disk simple * added more consistency to naming conventions, polished some design elements, removed redundant text * Added limits section. Moved connection info from first table to the limits section table * updated disk names, moved limits to the bottom of the file * resolved merge conflict --------- Co-authored-by: Greg Papas Co-authored-by: Charis <26616127+charislam@users.noreply.github.com> Co-authored-by: Inian --- .../guides/platform/compute-and-disk.mdx | 62 +++++++++---------- 1 file changed, 31 insertions(+), 31 deletions(-) diff --git a/apps/docs/content/guides/platform/compute-and-disk.mdx b/apps/docs/content/guides/platform/compute-and-disk.mdx index d660b9ba145..6965dba9b76 100644 --- a/apps/docs/content/guides/platform/compute-and-disk.mdx +++ b/apps/docs/content/guides/platform/compute-and-disk.mdx @@ -54,34 +54,6 @@ Compute instance changes are usually applied with less than 2 minutes of downtim 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](https://supabase.com/dashboard/project/_/reports) in the Dashboard to monitor your CPU utilization, and upgrade as needed. -## Limits - -### 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 | - - - -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. - - - ## Disk Supabase databases are backed by high performance SSD disks. The _effective performance_ depends on a combination of all the following factors: @@ -138,7 +110,7 @@ Be aware that increasing IOPS or throughput incurs additional charges. 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: -| | gp3 (General Purpose SSD) | io2 (High Performance SSD) | +| | 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** | 16 TB | 60 TB | @@ -156,8 +128,36 @@ Compute instance size changes will not change your selected disk type or disk si ### Disk size -- 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. -- io2 disks can be provisioned with 1,000 IOPS per GB of 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](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 | + + + +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. + + ### Constraints