Skip to content
Platform

了解数据库和磁盘大小

磁盘指标是指 Postgres 报告的存储使用情况。这些指标每天都会更新。在阅读本文档时，我们会提到“数据库大小”和“磁盘大小”：

🌐 Disk metrics refer to the storage usage reported by Postgres. These metrics are updated daily. As you read through this document, we will refer to "database size" and "disk size":

  • 数据库大小：显示你 Postgres 数据库中实际数据的大小。可以在数据库报告页面找到。
  • 磁盘大小：显示总体磁盘空间使用情况，包括数据库大小以及 Postgres 正常运行所需的其他文件，如预写日志（WAL）和其他系统日志文件。你可以在数据库设置页面查看。

数据库大小 #

🌐 Database size

这个 SQL 查询会显示你 Postgres 集群中所有数据库的大小：

🌐 This SQL query will show the size of all databases in your Postgres cluster:

1
select
2
  pg_size_pretty(sum(pg_database_size(pg_database.datname)))
3
from pg_database;

这个数值会在数据库报告页面中显示。

🌐 This value is reported in the database report page.

数据库大小主要由你的数据、索引和物化视图占用。你可以通过删除其中的任何一项并运行 Vacuum 操作来减小数据库大小。

🌐 Database size is consumed primarily by your data, indexes, and materialized views. You can reduce your database size by removing any of these and running a Vacuum operation.

磁盘空间使用 #

🌐 Disk space usage

你的数据库大小是你 Supabase 项目磁盘使用的一部分，Postgres 有许多组件会占用额外的磁盘空间。其中一个主要组件是 预写日志 (WAL)。Postgres 会把数据库的变更存储在日志文件中，这些文件在变更应用到数据库后会被清理。这些文件同样也会被 只读副本 或其他复制方法使用。

🌐 Your database size is part of the disk usage for your Supabase project, there are many components to Postgres that consume additional disk space. One of the primary components, is the Write Ahead Log (WAL). Postgres will store database changes in log files that are cleared away after they are applied to the database. These same files are also used by Read Replicas or other replication methods.

如果你想确定存储在磁盘上的 WAL 文件大小，Postgres 提供了 pg_ls_waldir 作为辅助函数；可以运行以下查询：

🌐 If you would like to determine the size of the WAL files stored on disk, Postgres provides pg_ls_waldir as a helper function; the following query can be run:

1
select pg_size_pretty(sum(size)) as wal_size from pg_ls_waldir();

真空操作 #

🌐 Vacuum operations

Postgres 不会立即回收数据库中已死元组（即已删除的行）所占用的物理空间。它们会被标记为“已移除”，直到执行 vacuum 操作。因此，从数据库中删除数据可能不会立即减少报告的磁盘使用量。你可以使用 Supabase CLI 的 inspect db bloat 命令来查看数据库中的所有已死元组。或者，你也可以在 SQL 编辑器 中运行 CLI GitHub 仓库中提供的 查询。

🌐 Postgres does not immediately reclaim the physical space used by dead tuples (i.e., deleted rows) in the DB. They are marked as "removed" until a vacuum operation is executed. As a result, deleting data from your database may not immediately reduce the reported disk usage. You can use the Supabase CLI inspect db bloat command to view all dead tuples in your database. Alternatively, you can run the query found in the CLI's GitHub repo in the SQL Editor

1
# Login to the CLI
2
npx supabase login
3
4
# Initialize a local supabase directory
5
npx supabase init
6
7
# Link a project
8
npx supabase link
9
10
# Detect bloat
11
npx supabase inspect db bloat --linked

如果你找到一张想要立即清理的表，可以在 SQL 编辑器 中运行以下命令：

🌐 If you find a table you would like to immediately clean, you can run the following in the SQL Editor:

1
vacuum full <table name>;

Supabase 项目启用了自动清理功能，这能确保这些操作定期执行，从而保持数据库健康和高效。

🌐 Supabase projects have automatic vacuuming enabled, which ensures that these operations are performed regularly to keep the database healthy and performant.

可以对autovacuum 参数进行微调，或者手动启动 vacuum 操作。在从数据库删除大量数据后运行手动 vacuum 可能有助于减小 Postgres 报告的数据库大小。

🌐 It is possible to fine-tune the autovacuum parameters, or manually initiate vacuum operations. Running a manual vacuum after deleting large amounts of data from your DB could help reduce the database size reported by Postgres.

被占用的空间 #

🌐 Preoccupied space

新的 Supabase 项目的数据库大小大约是 40-60MB。这个空间包括预装的扩展、架构和默认的 Postgres 数据。安装扩展时会使用额外的数据库空间，即使这些扩展没有被激活。

🌐 New Supabase projects have a database size of ~40-60mb. This space includes pre-installed extensions, schemas, and default Postgres data. Additional database size is used when installing extensions, even if those extensions are inactive.

磁盘容量 #

🌐 Disk size

Supabase 使用网络附加存储来平衡性能和可扩展性。磁盘扩展行为取决于你的计费计划。

🌐 Supabase uses network-attached storage to balance performance with scalability. The disk scaling behavior depends on your billing plan.

🌐 Paid plan behavior

Pro 计划及以上的项目都有自动扩展磁盘。

🌐 Projects on the Pro Plan and higher have auto-scaling disks.

当数据库达到分配磁盘大小的90%时，磁盘大小会自动扩展。磁盘会扩展到大约原来的50%（比如，8 GB -> 12 GB）。

🌐 Disk size expands automatically when the database reaches 90% of the allocated disk size. The disk is expanded to be 50% larger (for example, 8 GB -> 12 GB).

自动扩展在滚动的 24 小时窗口内限制为四次修改。虽然上一次修改完成后可以立即启动新的修改，但如果在当前滚动 24 小时窗口内达到了四次调整的配额，之后就无法再进行扩展，直到窗口允许。如果磁盘使用率达到 95% 且你的修改配额已用完，你的项目将进入只读模式。

🌐 Auto-scaling is limited to four modifications within a rolling 24-hour window. While a new modification can be initiated immediately after the previous one completes, reaching the quota of four resizes within the current rolling 24-hour window will prevent further scaling until the window allows it. If you reach 95% disk utilization and have exhausted your modification quota, your project will enter read-only mode.

磁盘大小也可以在数据库设置页面手动扩展。专业版/团队版的最大磁盘大小为60 TB。如果你需要超过这个容量，联系我们了解更多企业版信息。

🌐 Disk size can also be manually expanded on the Database Settings page. The maximum disk size for the Pro/Team Plan is 60 TB. If you need more than this, contact us to learn more about the Enterprise Plan.

免费计划行为 #

🌐 Free Plan behavior

当你的数据库大小超过 500 MB 时，免费计划项目会进入只读模式。请注意，这是 数据库大小 的限制（你的实际 Postgres 数据大小），而不是 磁盘大小。免费计划项目包括 1 GB 的磁盘空间，但只读模式是由 500 MB 的数据库大小配额触发的。一旦进入只读模式，你有以下几种选择：

🌐 Free Plan projects enter read-only mode when your database size exceeds 500 MB. Note that this is the database size limit (the size of your actual Postgres data), not the disk size. Free Plan projects include 1 GB of disk space, but read-only mode is triggered by the 500 MB database size quota. Once in read-only mode, you have these options:

公平使用数据库大小限制 #

🌐 Fair use database size restriction

除了上面每个项目的只读模式之外，当组织的数据库大小超过计划配额时，你的组织可能会被置于公平使用服务限制下（请求会返回402状态码）。这个配额是按组织评估的，会将你所有项目的数据库大小加总计算。

🌐 Separate from the per-project read-only mode above, your organization can be placed under a Fair Use service restriction (requests return a 402 status code) when its database size exceeds the plan quota. This quota is evaluated per organization, summing the database size across all of your projects.

重要的是，它是基于计费周期内的平均每日数据库大小，而不是实时大小。减小数据库大小不会立即解除限制：平均值会保持较高，直到积累了足够多的低使用量日，而且当你的计费周期重置时，它会重新计算。这就是为什么今天数据库远低于限制的项目仍然可能被限制，因为整个周期的平均值仍然超标。

🌐 Importantly, it is based on the average daily database size over the billing period, not the live size. Reducing your database size does not immediately lift the restriction: the average stays elevated until enough lower-usage days accumulate, and it effectively resets when your billing cycle rolls over. This is why a project that is well under the limit today can still be restricted, as its average across the period is still over.

要解决这个问题，可以升级你的计划，或者关闭消费上限以立即解除限制。否则，你需要减小数据库的大小，然后等到新的计费周期开始，到时候平均值会从你当前的大小重新计算。

🌐 To resolve it, upgrade your plan or disable your Spend Cap to lift the restriction immediately. Otherwise, reduce your database size and wait for the new billing cycle, at which point the average restarts from your current size.

只读模式 #

🌐 Read-only mode

在某些情况下，Supabase 可能会将你的数据库设为只读模式，以防止数据库超出计费或磁盘限制。

🌐 In some cases Supabase may put your database into read-only mode to prevent your database from exceeding the billing or disk limitations.

在只读模式下，客户端会遇到像 cannot execute INSERT in a read-only transaction 这样的错误。一旦使用量低于磁盘容量的 95%，正常操作（读写模式）会自动恢复。

🌐 In read-only mode, clients will encounter errors such as cannot execute INSERT in a read-only transaction. Regular operation (read-write mode) is automatically re-enabled once usage is below 95% of the disk size,

关闭只读模式 #

🌐 Disabling read-only mode

你可以手动覆盖只读模式来减小磁盘大小。要做到这一点，在SQL 编辑器中运行以下命令：

🌐 You manually override read-only mode to reduce disk size. To do this, run the following in the SQL Editor:

首先，更改 交易访问模式：

🌐 First, change the transaction access mode:

1
set session characteristics as transaction read write;

这允许你在会话中删除数据。删除数据后，考虑运行一次清理（vacuum）以尽可能回收空间：

🌐 This allows you to delete data from within the session. After deleting data, consider running a vacuum to reclaim as much space as possible:

1
vacuum;

一旦你回收了空间，你可以运行以下命令来禁用 只读 模式：

🌐 Once you have reclaimed space, you can run the following to disable read-only mode:

1
set default_transaction_read_only = 'off';

磁盘大小分布 #

🌐 Disk size distribution

你可以在你的项目基础设施页面查看磁盘大小的分布情况。

🌐 You can check the distribution of your disk size on your project's Infrastructure page.

Disk Size Distribution

你的磁盘使用量分为三类：

🌐 Your disk size usage falls in three categories:

  • 数据库 - 数据库的磁盘使用情况。这包括实际数据、索引、物化视图等...
  • WAL - 预写日志的磁盘使用情况。使用量取决于你的 WAL 设置以及写入数据库的数据量。
  • 系统 - 系统保留的磁盘使用空间，用于确保数据库可以顺利运行。用户不能修改，通常只占用很少的空间。

减小磁盘大小 #

🌐 Reducing disk size

磁盘在日常操作中不会自动缩小。一旦你减小了数据库大小，它们在项目升级期间就会自动“调整到合适大小”。升级后的最终磁盘大小是数据库大小的1.2倍，最低为8 GB。例如，如果你的数据库大小是100GB，而你有一个200GB的磁盘，那么项目升级后的大小将是120GB。

🌐 Disks don't automatically downsize during normal operation. Once you have reduced your database size, they will automatically "right-size" during a project upgrade. The final disk size after the upgrade is 1.2x the size of the database with a minimum of 8 GB. For example, if your database size is 100GB, and you have a 200GB disk, the size after a project upgrade will be 120 GB.

如果你的 WAL 目录很大，你可以修改 WAL 设置，比如 max_wal_size。请自行承担风险，因为更改这些设置可能会有副作用。要查询当前的 WAL 大小，请使用 SELECT SUM(size) FROM pg_ls_waldir()。

🌐 In case you have a large WAL directory, you may modify WAL settings such as max_wal_size. Use at your own risk as changing these settings can have side effects. To query your current WAL size, use SELECT SUM(size) FROM pg_ls_waldir().

如果你的项目已经运行在最新版的 Postgres 上，并且担心等待下一次发布才能升级，你可以考虑将数据库迁移到一个新项目，作为替代方案，具体操作可以参考［Supabase 内部迁移指南］(/docs/guides/platform/migrating-within-supabase)。

🌐 In the event that your project is already on the latest version of Postgres and waiting for the next release to allow upgrading is a concern, you can migrate your database to a new project as an alternative following the Migrating within Supabase guide.