mirror of
https://github.com/supabase/supabase.git
synced 2026-10-14 05:39:11 +03:00
75 lines
3.9 KiB
Plaintext
75 lines
3.9 KiB
Plaintext
import Layout from '~/layouts/DefaultGuideLayout'
|
|
|
|
export const meta = {
|
|
id: 'database-usage',
|
|
title: 'Database usage',
|
|
description: 'Understanding how database usage applies to your subscription.',
|
|
}
|
|
|
|
Database size refers to the _monthly average storage usage_, as reported by Postgres. This metric is reported in your project's [billing usage](https://app.supabase.com/project/_/settings/billing/usage) and is updated daily.
|
|
Database size is the total size of used storage from your database, whereas disk size describes the size of the underlying available storage.
|
|
|
|
For an instantaneous live view of the DB size, you can execute in Postgres:
|
|
|
|
```sql
|
|
select
|
|
sum(pg_database_size (pg_database.datname)) / (1024 * 1024) as db_size_mb
|
|
from
|
|
pg_database;
|
|
```
|
|
|
|
This value is also reported in the [database settings page](https://app.supabase.com/project/_/settings/database).
|
|
|
|
## Database storage management
|
|
|
|
Supabase uses network-attached storage to balance performance with scalability.
|
|
For Pro and Enterprise projects, disk size expands ~1.5x automatically (e.g., 8GB -> 12GB) when you reach 90% of the disk size.
|
|
Disk size expansion can only occur once every six hours.
|
|
Pro projects can store up to 1024TB.
|
|
|
|
All projects enter read-only mode when you reach 95% of the disk size. 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.
|
|
|
|
If you need more than 1024TB of disk size or require multiple storage expansions in a short period of time, [contact us](https://app.supabase.com/support/new) to learn more about the Enterprise plan.
|
|
|
|
### Increasing available disk size
|
|
|
|
1. [Upgrade to the Pro or Enterprise plan](https://app.supabase.com/project/_/settings/billing/subscription) to increase your quota and expand your disk size automatically.
|
|
|
|
2. Delete data from your project's database to lower its disk usage. If your database is already in read-only mode, run the following command to change the transaction mode to read-write for your session:
|
|
|
|
```sql
|
|
SET
|
|
default_transaction_read_only = 'off';
|
|
```
|
|
|
|
This allows you to delete data from within the session.
|
|
|
|
### Preoccupied Space
|
|
|
|
When launching a new project, your database size will be roughly ~40-60mb.
|
|
The space is used up by preinstalled extensions, schema/data used by our services that are offered with each project and default Postgres data.
|
|
|
|
When installing additional extensions, even if you don't actively use them, additional database size is used.
|
|
|
|
## Vacuum operations
|
|
|
|
Postgres does not immediately reclaim the physical space used by dead tuples (i.e., deleted rows) in the DB. Instead, they are internally marked as removed until a [vacuum operation](https://www.postgresql.org/docs/current/routine-vacuuming.html) is executed.
|
|
As a result, deleting data from your database may not immediately reduce the reported disk usage.
|
|
|
|
<Admonition type="note">
|
|
|
|
Vacuum operations can temporarily increase resource utilization, which may adversely impact the observed performance of your project until the maintenance is completed.
|
|
|
|
</Admonition>
|
|
|
|
Supabase projects have automatic vacuuming enabled, which ensures that these operations are performed regularly to keep the database healthy and performant.
|
|
However, it can be necessary to either [fine-tune](https://www.percona.com/blog/2018/08/10/tuning-autovacuum-in-postgresql-and-autovacuum-internals/)
|
|
the [autovacuum parameters](https://www.enterprisedb.com/blog/postgresql-vacuum-and-analyze-best-practice-tips),
|
|
or [manually initiate](https://www.postgresql.org/docs/current/sql-vacuum.html) vacuum operations.
|
|
For example, running a manual vacuum after deleting large amounts of data from your DB could help reduce the reported disk usage by Postgres.
|
|
|
|
export const Page = ({ children }) => <Layout meta={meta} children={children} />
|
|
|
|
export default Page
|