deployment

428 notes in this subject, read out of this brain and free to use. This is page 4 of 8.

Latest PITR restore point may lag current time

The latest restore point of a project could be significantly behind the current time when the database has had no recent activity and therefore no recent WAL file backups. However, the state of the database at the latest recovery point still reflects the current state, given that no transactions have occurred in between.

Automatic daily backups by plan

Pro Plan projects receive daily backups with access to the last 7 days. Team Plan projects receive daily backups with access to the last 14 days. Enterprise Plan projects receive daily backups with access to the last 30 days.

Free tier backup recommendation

Free tier plan projects do not receive automatic backups. They should regularly export their data using the Supabase CLI `db dump` command and maintain off-site backups.

Project deletion permanently removes all data and backups

When you delete a project, Supabase permanently removes all associated data, including any backups stored in S3. This action is irreversible.

Backup types: logical and physical

Database backups can be categorized into two types: logical and physical. See the Supabase blog post on PostgreSQL physical and logical backups for more details.

Physical backups default for Postgres 15.8.1.079 and newer

All projects on Postgres version 15.8.1.079 and newer use the physical backup process by default. Projects on older Postgres versions must upgrade to transition to physical backups.

Custom role passwords not stored in daily backups

For security purposes, daily backups do not store passwords for custom roles. If you restore from a daily backup and use custom roles, you will need to reset their passwords after restoration completes.

Backups do not include Storage API objects

Database backups do not include objects stored via the Storage API, as the database only includes metadata about these objects. Restoring an old backup does not restore objects you deleted after that backup.

Choose backup closest before restore point

When selecting a backup to restore to, choose the closest available backup made before your desired restore point. You can always choose earlier backups, but consider how many days of data you might lose.

Project inaccessible during restoration

When restoring from a backup, the project is inaccessible during the restoration process. Downtime depends on the size of the database—the larger it is, the longer the downtime will be. Plan for downtime beforehand.

Drop and recreate subscriptions and replication slots before restoration

If your project uses subscriptions or replication slots, you need to drop them before restoration and re-create them afterwards. The slot used by Realtime is handled automatically and does not need to be manually managed.

Point-in-Time Recovery (PITR) overview

Point-in-Time Recovery (PITR) allows you to back up a project at shorter intervals, giving you the option to restore to any chosen point with up to seconds of granularity. PITR is available as an add-on for Pro, Team, and Enterprise Plan projects.

PITR requires Small compute add-on minimum

Projects that want to use PITR must also use at least a Small compute add-on to ensure smooth functioning.

PITR uses physical backups and WAL files

PITR combines physical backups and Write Ahead Log (WAL) file archiving to enable point-in-time recovery. Supabase uses WAL-G, an open source archival and restoration tool, to handle both aspects of PITR.

PITR WAL backup intervals and RPO

By default, WAL files are backed up at two-minute intervals. If files exceed a certain size threshold, they are backed up immediately. During high transaction volume, backups become more frequent. When the database has no activity, no WAL file backups are made. In the worst case scenario, PITR achieves a Recovery Point Objective (RPO) of two minutes.

PITR disables daily backups

If you enable PITR, Supabase will no longer take daily backups. PITR provides finer granularity than daily backups, so running both is unnecessary.

PITR restoration process steps

To restore via PITR: select desired recovery point via date and time picker, review and confirm restoration in the Dashboard, download the latest available physical backup to the project, restore the database partially, download WAL files generated after that physical backup up to the specified point in time, and replay transaction records in those files against the database to complete restoration.

Physical backups not downloadable after disabling PITR

When you disable PITR, new backups are taken as physical backups only. You can still use physical backups for restoration, but they are not available for direct download. To download a backup after disabling PITR, take a manual legacy logical backup using the Supabase CLI or pg_dump.

Clone project feature scope - what requires reconfiguration

When cloning a Supabase project, the following require manual reconfiguration and are not automatically transferred: storage objects and settings (S3/storage files and bucket configurations are NOT copied), edge functions, auth settings and API keys, realtime settings, database extensions and settings, and read replicas.

Clone project feature scope - what transfers

When cloning a Supabase project to a new one, the following will be transferred: database schema (tables, views, procedures), all data and indexes, database roles and permissions and users, auth user data (user accounts, hashed passwords, and authentication records from the auth schema), and encryption root key so Vault secrets and encrypted columns remain readable in the new project.

Clone project performance optimization

The time required to complete a restoration varies depending on the volume of data involved. If you have a large amount of data, you can opt for higher performing disk attributes on the source project before starting a clone operation. These disk attributes will be replicated to the new project but incur additional costs which will be displayed before starting.

Clone project pitfall - external operation extensions

When cloning a project, all extensions enabled at the source are copied to the new project. If the source project includes extensions configured to carry out external operations (such as pg_net, pg_cron, or wrappers), these should be disabled once the copy process is completed to avoid unwanted actions.

Clone project cost overview and review requirement

Before starting the restoration process, users are presented with an overview of the costs associated with creating the new project. The new project will incur additional monthly expenses based on the mirrored resources from the source project, and it is important to review these costs carefully before proceeding.

Clone project restrictions

Projects created through the restoration process cannot themselves be used as a source for further clones. The feature is only accessible to paid plan users with physical backups enabled.

Clone project automatic configuration replication

When a new project is created through the clone process, Supabase automatically replicates key configurations from the source project, including the compute instance size, disk attributes, SSL enforcement settings, and network restrictions. The data remains in the same region as the source project to ensure compliance with data residency requirements.

Clone project availability and requirements

The restore to new project feature is exclusive to users on paid plans and requires that physical backups are enabled for the source project. For Point-in-Time recovery (PITR), it is an additional add-on available for organizations on a paid plan with physical backups enabled.

Delete project via dashboard

To delete a project via the Supabase dashboard, navigate to Settings > General > Delete project, click Delete Project, enter your project name exactly as it appears to confirm, review the confirmation dialog, and click Delete.

What gets deleted when a project is deleted

When a Supabase project is deleted, all of the following are permanently removed: the entire Postgres database including all tables, schemas, and records; all deployed Edge Functions and their source code; all files in Storage buckets; all automated backups and point-in-time recovery snapshots; user accounts, sessions, and auth logs; all active real-time subscriptions and configurations; all project API keys, service role keys, and webhooks; and any custom domains linked to the project and their SSL certificates.

Project deletion is permanent and irreversible

Deleting a Supabase project is a permanent and irreversible action. All data, backups, and configurations are permanently removed and cannot be recovered.

Monitor project activity before deletion

Before deleting a project, enable audit logging to track who has access to the project, review and revoke unnecessary API keys, and check for any scheduled jobs or integrations that depend on the project.

Restrict project deletion permissions

To prevent accidental deletion by team members, restrict who can delete projects within your organization by setting up role-based access controls to limit deletion permissions, requiring multi-factor authentication (MFA) for sensitive operations, and using the Supabase dashboard to configure team member permissions.

Document configuration before deletion

Before deleting a project, document all configuration by exporting Edge Function code and configurations from the dashboard, saving authentication provider settings (OAuth, SAML, etc.), documenting any custom database functions, triggers, or policies, and recording webhook configurations and integrations.

Backup database before deletion

Before deleting a project, back up your database by following the backup and restore guide. If you are on the Pro, Team, or Enterprise Plan with legacy logical backups, you can download a copy from the Supabase dashboard at Settings > Database > Backups > Scheduled.

Pause project as alternative to deletion

As an alternative to deletion, you can pause a project. Paused projects stop incurring compute charges while data is preserved and can be accessed when you resume the project. You can resume the project at any time without data loss. Currently, only Free Projects can be paused. To pause a project, navigate to Settings > General > Project availability and click Pause Project.

Billing stops immediately after project deletion

Billing for a deleted project will stop immediately. However, deletion does not remove usage that already occurred during the current billing cycle; that usage still counts until the billing period resets.

Project URL becomes inaccessible after deletion

Once a project is deleted, the project URL will no longer be accessible. DNS records will be cleaned up, though this may take up to 24 hours to fully propagate.

Branching compute shown separately on invoice

Compute incurred by Preview branches appears as 'Branching Compute Hours' on the invoice. Other usage items are not shown separately for branches and are rolled up into the main project.

Optimize branching usage recommendations

To optimize branching usage: merge Preview branches as soon as they are ready, delete Preview branches that are no longer in use, and check whether persistent branches need to remain persistent or can be ephemeral instead, since persistent branches remain active even after the underlying PR is closed.

View branching usage on organization usage page

Branching usage can be viewed on the organization's usage page at the /dashboard/org/_/usage path. The page shows usage of all projects by default, and can be filtered to a specific project via dropdown. The Usage Summary section displays the number of hours Preview branches existed during the selected time period, and hovering over 'Branching Compute Hours' provides a detailed breakdown.

Compute Credits do not apply to Branching Compute

Compute Credits are not available for Branching Compute usage, only for the main project compute.

Preview branches charged as separate environments

Each Preview branch is a separate Supabase environment with all services (Database, Auth, Storage, etc.). Users are charged for usage within that environment such as Compute, Disk Size, Egress, and Storage, the same as the main project.

Preview branch usage counts toward subscription quota

Usage by Preview branches counts toward the subscription plan's quota. Branches are not covered by the Spend Cap feature.

Gp3 disk pricing and included IOPS

General purpose disks (gp3) are priced at 0.00003288 per IOPS-Hr or 0.024 per IOPS per month. Gp3 disks come with a default IOPS of 3,000. You are only charged for provisioned IOPS exceeding these 3,000 IOPS. Both Pro and Team plans include 3,000 disk IOPS with over-usage charged at 0.024 per IOPS per month or 0.00003288 per IOPS-Hr. Enterprise plans have custom pricing.

Io2 disk pricing and billing from first IOPS

High performance disks (io2) are priced at 0.000163 per IOPS-Hr or 0.119 per IOPS per month. Unlike general purpose disks, high performance disks are billed from the first provisioned IOPS, with no included IOPS. Both Pro and Team plans include 0 disk IOPS and are charged 0.119 per IOPS per month or 0.000163 per IOPS-Hr for all IOPS. Enterprise plans have custom pricing.

Gp3 billing example: Project under included IOPS

A small project with 3,000 IOPS (the included amount) on a Pro plan with gp3 disk incurs no charges for disk IOPS, only for compute hours.

Gp3 billing example: Project exceeding included IOPS

A large project with 3,600 IOPS on a Pro plan with gp3 disk exceeds the included 3,000 IOPS by 600. This excess incurs a charge of 14.40 per month (600 IOPS × 0.024 per IOPS per month).

Io2 billing example: High performance disk

A large project with 8,000 IOPS on a Pro plan with io2 disk is charged from the first IOPS. Total IOPS charge is 952 per month (8,000 IOPS × 0.119 per IOPS per month).

No IOPS charges by default

Unless you explicitly opt in for additional IOPS, no charges apply for disk IOPS.

Disk IOPS charging model

Each database has a dedicated disk and is charged for its provisioned disk IOPS, measured in IOPS-Hrs. 1 IOPS-Hr represents 1 IOPS being provisioned for 1 hour. For example, having 10 IOPS provisioned for 5 hours results in 50 IOPS-Hrs (10 IOPS × 5 hours). Disk IOPS Hours are not covered by the Spend Cap.

Configure log drains location

Log drains are configured in the project settings at /dashboard/project/_/settings/log-drains.

Log drain egress charges

Log drains incur Egress charges for the data transferred during export, which is billed separately from Log Drain Hours and Log Drain Events charges.

Log drain add-on billing in arrears

Project add-ons including log drains are billed in arrears based on how many hours they were used. If you remove the log drain add-on, you stop being billed from the time of removal onward.

Log Drain Events pricing

Log Drain Events cost $0.2 per 1 million events.

Log Drain Events billing calculation

Log Drain Events are billed using package pricing, where each package represents 1 million events. If usage falls between two packages, you are billed for the next whole package. For example, 999,999 events and 1,000,000 events are both billed as 1 package, but 1,000,001 events are billed as 2 packages.

Log Drain Hours pricing

Each log drain costs $0.0822 per hour, or approximately $60 per month.

Log Drain Hours billing calculation

Log Drain Hours are billed hourly. You are charged for each full hour a log drain is configured, even if it is configured for only part of an hour. For example, if a log drain is configured at 4:30 PM, you are charged for the full hour from 4:00 PM to 5:00 PM.

Log Drain pricing and usage components

Log drains are charged on three dimensions: Log Drain Hours (the hours a drain is configured), Log Drain Events (the number of log events exported), and Egress (data transfer cost). Log drains are available as a project add-on for Pro, Team, and Enterprise users.

Log Drains not covered by Spend Cap

Log Drains are not covered by the Spend Cap, meaning costs for log drains are not subject to the spending limit controls.

View log drain usage

Log Drain Events usage can be viewed on the organization's usage page at /dashboard/org/_/usage. The page shows usage for all projects by default, but you can select a specific project from a dropdown menu and choose a different time period.

Retrieve Amazon RDS database credentials steps

To retrieve your Amazon RDS database credentials: (1) Log in to your Amazon RDS account, (2) Select the region where your RDS database is located, (3) Navigate to the Databases tab, (4) Select the database that you want to migrate, (5) In the Connectivity & Security tab, note down the Endpoint and the port number, (6) In the Configuration tab, note down the Database name and the Username, (7) If you do not have the password, create a new one and note it down.

Give your agent this brain