计算与磁盘

计算 #

🌐 Compute

Supabase 平台上的每个项目都有自己专用的 Postgres 实例。

🌐 Every project on the Supabase Platform comes with its own dedicated Postgres instance.

下表描述了基础实例，Nano（免费计划）和Micro（付费计划），如果你在扩展时需要额外的性能，还可以使用更多的计算实例规范。

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

专用 CPU vs 共享 CPU #

🌐 Dedicated vs shared CPU

Supabase 上的所有 Postgres 数据库都运行在隔离的环境中。计算实例 Nano 到 2XL 的计算规模有可以短时提升性能的 CPU。比 Large 更大的实例性能更可预测，不会有同样的突发行为。

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

计算升级 #

🌐 Compute upgrades [#upgrades]

在考虑计算升级时，先评估你的瓶颈是受硬件限制还是软件限制。例如，你可能想查看优化连接数量或检查查询性能。当你对 Postgres 实例的性能满意时，就可以把注意力转向额外的计算资源。例如，你可以在预发布环境中进行负载测试，以了解你的计算需求。你也可以从较小的级别开始，在仪表板中创建报告来监控 CPU 使用情况，并根据需要进行升级。

🌐 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 的数据库采用高性能 SSD 硬盘支持。_实际性能_取决于以下所有因素的组合：

🌐 Supabase databases are backed by high performance SSD disks. The effective performance depends on a combination of all the following factors:

• 计算大小
• 预配置磁盘吞吐量
• 预配置磁盘 IOPS：每秒输入/输出操作数，用来衡量读写操作的次数。
• 磁盘类型：io2 或 gp3
• 磁盘容量

下面的部分会解释这些属性如何影响磁盘性能。

🌐 The following sections explain how these attributes affect disk performance.

计算大小 #

🌐 Compute size

你项目的计算规模会影响有效的磁盘吞吐量和 IOPS。下表显示了每种实例大小的基线（持续）限制和突发（最大）限制。例如，一个 8XL 计算实例的吞吐量为 1,188 MB/s，IOPS 为 40,000。

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

像 Nano、Micro、Small 和 Medium 这样的小型计算实例可以在短时间内突破基准性能。一旦突发能力用完，性能就会回到基准水平。如果你需要稳定的磁盘性能，考虑升级你的计算实例大小。

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

更大的计算实例（4XL及以上）是为持续的高性能设计的，具有特定的 IOPS 和吞吐量限制，你可以配置。如果达到 IOPS 或吞吐量上限，会发生限流。

🌐 Larger compute instances (4XL and above) are designed for sustained, high performance with specific IOPS and throughput limits which you can configure. If you hit your IOPS or throughput limit, throttling will occur.

选择合适的计算实例以获得稳定的磁盘性能 #

🌐 Choosing the right compute instance for consistent disk performance

如果你需要稳定的磁盘性能，可以选择 4XL 或更大的计算实例。如果你不确定你的应用需要多少吞吐量或 IOPS，可以对你的项目进行负载测试，并在仪表板中查看这些指标。如果 Disk IO % consumed 指标超过 1%，说明你的工作负载在当天已经超过了基础 IO 吞吐量。如果这个指标达到 100%，说明工作负载已经用完了所有可用的磁盘 IO 配额。使用任何磁盘 IO 配额的项目都是升级到吞吐量更高的大型计算实例的好候选。

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

预配置的磁盘吞吐量和 IOPS #

🌐 Provisioned disk throughput and IOPS

默认的磁盘类型是 gp3，基础吞吐量为 125 MB/s，默认 IOPS 为 3,000。你可以在基础设施设置页面中配置额外的 IOPS 和吞吐量，但要注意，实际的 IOPS 和吞吐量会受计算实例大小的限制。这需要大规范计算实例或更高规范。

🌐 The default disk type is gp3, which comes with a baseline throughput of 125 MB/s and a default IOPS of 3,000. You can provision additional IOPS and throughput from the Infrastructure settings page, but keep in mind that the effective IOPS and throughput will be limited by the compute instance size. This requires Large compute size or above.

磁盘类型 #

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

对于日常的一般操作，gp3 应该绰绰有余。如果你需要关键系统的高吞吐量和 IOPS，io2 将提供所需的性能。

🌐 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

• 通用型（gp3）磁盘的基础性能是 3,000 IOPS 和 125 MB/s。你可以为每 GB 的磁盘容量额外预置 500 IOPS，每预置一个 IOPS，还可以额外增加 0.25 MB/s 的吞吐量。
• 高性能（io2）磁盘可以按每GB磁盘大小提供1,000 IOPS。

限制和约束 #

🌐 Limits and constraints

Postgres 复制槽、WAL 发送器和连接 #

🌐 Postgres replication slots, WAL senders, and connections

复制槽 和 WAL 发送器 用于启用 Postgres 复制。每个计算实例对它能处理的数据库连接数和连接池客户端数也有上限。

复制槽、WAL 发送器、数据库连接和连接池客户端的最大数量取决于你的计算实例大小，如下所示：

🌐 The maximum number of replication slots, WAL senders, database connections, and pooler clients depends on your compute instance size, as follows:

限制 #

🌐 Constraints

• 你可以在滚动的24小时内最多修改磁盘属性四次。每次修改完成后，就可以立即进行新的修改。如果达到这个限制，你将会受到限制，需要等到滚动的24小时窗口允许再次调整。
• 你可以增加磁盘大小，但不能减小它。