IPv4 pricing
IPv4 addresses cost $0.0055 per hour or approximately $4 per month.
platform
492 notes in this subject, read out of this brain and free to use. This is page 6 of 9.
IPv4 add-on removal stops billing immediately
Project add-ons are billed in arrears based on actual hours of use. If you remove the IPv4 add-on, you are no longer billed from the time of removal onward.
View Logs Ingest usage in Dashboard
You can view Logs Ingest usage on the organization's usage page of the Dashboard at /dashboard/org/_/usage. The page shows the usage of all projects by default. To view the usage for a specific project, select it from the dropdown. You can also select a different time period.
Reduce log-level verbosity to minimize Logs Ingest usage
Reduce log-level verbosity in your Edge Functions and server-side code, for example changing from info to warn in production. Every service in your Supabase project automatically generates logs, and log volume scales with your application's traffic and behavior.
Audit and cap log payloads to optimize Logs Ingest
Audit verbose logging in your application code, as application-level logs forwarded to Supabase services count toward ingest. Additionally, cap log payload size, as large structured payloads can inflate GB-billed volume.
Use Logs Explorer to investigate high ingest volume spikes
Use the Logs Explorer in the Dashboard (at /dashboard/project/_/logs-explorer) to find services or endpoints producing unusually high log volume.
Logs Ingest charged per GB during billing cycle
You are charged for the total volume of log data that Supabase ingests across all your project's services (Postgres, API gateway, Auth, Storage, Realtime, Edge Functions, and others) during the billing cycle, measured in GB. Logs Ingest usage is shown as 'Logs Ingest' on your invoice.
Log Drains are separate from Logs Ingest billing
Log Drains stream logs out of Supabase to external destinations such as Datadog, Better Stack, or S3 buckets, and are billed separately on drain hours and events. Draining logs does not replace or reduce Logs Ingest charges because ingest is metered when Supabase processes logs while drains are metered when Supabase streams them out. These are separate billing primitives and not overlapping charges.
Logs pricing SKUs: Ingest and Query
Logs usage is metered on two separate SKUs: Logs Ingest (total GB of log data Supabase ingests across all project services including Postgres, API gateway, Auth, Storage, Realtime, and Edge Functions during the billing cycle) and Logs Query (total GB of log data scanned when reading logs via Studio UI, Management API, CLI, or other interfaces). Each plan includes a free quota for both SKUs, and usage beyond the quota is billed per GB.
View Logs Query usage in Dashboard
You can view Logs Query usage on the organization's usage page of the Dashboard. The page shows the usage of all projects by default. To view usage for a specific project, select it from the dropdown. You can also select a different time period.
Use Logs Explorer for ad-hoc queries
Using the Logs Explorer in the Dashboard for ad-hoc queries surfaces the most relevant log data without over-scanning, which helps keep Logs Query usage low.
Logs Query charged per GB scanned
You are charged for the volume of log data scanned when you read logs via the Studio UI, the Management API, the CLI, or any other interface. Logs Query is charged per GB of log data scanned during the billing cycle.
Optimize Logs Query usage with time ranges
A 1-day window scans 7× less data than a 7-day window. Keeping time ranges narrow reduces Logs Query usage directly.
Apply service and endpoint filters early to reduce Logs Query
Applying service and endpoint filters early in your queries reduces the volume scanned per query and lowers Logs Query usage.
Use Log Drains instead of programmatic polling
Avoid frequent programmatic polling of logs, as repeated API or CLI log queries accumulate GB rapidly. For continuous log streaming, Log Drains are more cost-effective than polling.
Logs Query usage shown on invoice
Usage is shown as 'Logs Query' on your invoice.
SSO MAU quota and overage pricing
Pro Plan and Team Plan both include a quota of 50 SSO MAU per billing cycle. Overage is charged at $0.015 per additional SSO MAU. Enterprise Plan has custom quota and pricing. The count resets at the start of each billing cycle.
Invoice line item for SSO usage
SSO MAU usage appears on invoices as "Monthly Active SSO Users" and shows the count of distinct users who authenticated via SSO during the billing cycle.
SSO MAU billing definition
Users are charged for the number of distinct users who log in or refresh their token during the billing cycle using a SAML 2.0 compatible identity provider (e.g. Google Workspace, Microsoft Active Directory). Each unique user is counted only once per billing cycle, regardless of how many times they authenticate. These users are referred to as "SSO MAUs".
Egress pricing per GB
Uncached egress costs $0.09 per GB per month. Cached egress costs $0.03 per GB per month. You are only charged for usage exceeding your subscription plan's quota.
Egress quotas by plan
Free plan: 5 GB uncached / 5 GB cached quota. Pro plan: 250 GB uncached / 250 GB cached quota with $0.09 per GB uncached and $0.03 per GB cached over-usage charges per month. Team plan: 250 GB uncached / 250 GB cached quota with $0.09 per GB uncached and $0.03 per GB cached over-usage charges per month. Enterprise plan: Custom quota and custom over-usage charges.
View egress usage on organization usage page
You can view egress usage on the organization's usage page at /dashboard/org/_/usage. The page shows the usage of all projects by default. To view usage for a specific project, select it from the dropdown. You can also select a different time period. In the Total Egress section, you can see the usage for the selected time period and hover over a specific date to view a breakdown by service, which includes cached egress.
View cached egress separately on usage page
Cached egress is displayed separately below the Total Egress section on the organization's usage page at /dashboard/org/_/usage.
Create custom egress reports
To create a custom egress report: 1) On the Observability page at /dashboard/project/_/observability, click New custom report in the left navigation menu. 2) After creating a new report, add charts for one or more Supabase services by clicking Add block.
Debug egress usage with Logs Explorer
In the Logs Explorer at /dashboard/project/_/logs/explorer you can access Edge Logs and review the top paths to identify heavily queried endpoints. These logs currently do not include response byte data, but that data will be available in the future.
Strategies to optimize egress usage
To reduce egress usage: 1) Reduce the number of fields or entries selected when querying your database. 2) Reduce the number of queries or calls by optimizing client code or using caches. 3) For update or insert queries, configure your ORM or queries to not return the entire row if not needed. 4) When running manual backups through Supavisor, remove unneeded tables and/or reduce the frequency. 5) Refer to the Storage Optimizations guide for tips on reducing Storage Egress.
Egress definition and what incurs charges
Egress is network data transmitted out of the Supabase system to a connected client. Egress is incurred by all services: Database, Auth, Storage, Edge Functions, Realtime, and Log Drains. You are charged by gigabyte for egress usage exceeding your subscription plan's quota.
Unified Egress Quota across services
The Unified Egress Quota can be used across all services (Database, Auth, Storage, Edge Functions, Realtime, and Log Drains). Charges apply only for usage exceeding your subscription plan's quota. Egress accumulates over the billing cycle and resets at the start of the next cycle.
Egress billing cycle and restrictions
Egress accumulates over the billing cycle and resets at the start of the next cycle. Usage that has already been served cannot be reduced retroactively, so optimizations lower future egress only. If your organization is restricted for egress, the restriction clears at the start of the next billing cycle, or immediately if you upgrade your plan or disable your Spend Cap.
Database egress definition and example
Database egress is data sent to the client when retrieving data stored in your database. It is incurred when a user views their order history in an online shop and the client application requests the database to retrieve the user's past orders. The order data sent back to the client contributes to Database Egress.
Log Drain egress definition and example
Log Drain egress is data pushed to the connected log drain. When you set up a log drain, each log sent to the log drain is considered egress. You can toggle the GZIP option to reduce egress if your provider supports it.
View Third-Party MAU usage in dashboard
Monthly Active Third-Party Users usage can be viewed on the organization's usage page at /dashboard/org/_/usage. The page shows usage of all projects by default. You can select a specific project from a dropdown to view its usage, and also select a different time period.
How to enable PITR add-on
Point-in-Time Recovery can be configured for a project by enabling the PITR add-on via the project dashboard settings at /dashboard/project/_/settings/addons?panel=pitr.
Pipeline billing example: multiple projects with initial syncs
For multiple projects with configured pipelines for an entire month processing data during initial sync and ongoing replication: Pro Plan costs $25. Project 1: 730 Compute Hours ($15.04), 730 ETL Pipeline Hours ($38.69), 15 GB ETL Replicated Data ($45), 150 GB ETL Copy Backfill Data ($90). Project 2: 730 Compute Hours ($15.04), 730 ETL Pipeline Hours ($38.69), 70 GB ETL Replicated Data ($210), 1,500 GB ETL Copy Backfill Data ($900). Subtotal $1377.46, after $10 compute credits total $1367.46.
Pipeline usage charges overview
Supabase charges for configured pipelines and pipeline data processed. Data processed is billed at different rates during initial sync and ongoing replication. Pipelines are charged by the hour for as long as they are configured, including while stopped. Deleting a pipeline ends the hourly charge. Destination-provider charges are separate and billed independently.
Pipeline hours billing definition
Pipeline hours measure how long each pipeline remains configured. The charge persists for the entire duration a pipeline exists, including periods when it is stopped. To end pipeline-hour charges, the pipeline must be deleted.
Initial sync data processed billing
Initial sync data processed is the Postgres row data accepted by the destination when a table is first synchronized or synchronized again. This is billed at a separate rate from ongoing replication.
Ongoing replication data processed billing
Ongoing replication data processed is the Postgres row data accepted by the destination for subsequent database changes. It depends on how much the published data changes, not on the source table size, WAL size, or the destination's compressed storage size.
How pipeline data processed is measured
Pipeline data processed is the amount of logical row data emitted by Postgres for replication, successfully processed by a pipeline, and accepted by its destination. It is not based on physical table storage or destination-specific encoding. For initial sync and resynchronization, it includes row data emitted by Postgres COPY. For ongoing replication, it includes row values Postgres emits for inserts, updates, and deletes. Updates include new row values and any previous identity values Postgres emits. Deletes include the emitted identity values.
Failed pipeline writes not counted in billing
Failed destination write attempts that Pipelines retries are not counted. Data is counted only after the destination acknowledges successful processing. In rare cases, Pipelines can count an acknowledged batch but crash or be interrupted before its replication checkpoint is persisted, causing recovery to process and count the same data again.
Resynchronization data counted in billing
Data successfully processed again as part of a user-requested resynchronization, table restart, or pipeline reset is counted again for billing purposes.
Pipeline cost estimation in Dashboard
The Dashboard provides a quick planning estimate of initial sync volume and cost using information already available about source tables. This estimate is designed to give useful indication before initial sync begins without first scanning and encoding all the data. The estimate should be used as a planning guide rather than an exact quote, as final volume is measured from data successfully processed during initial sync and can vary based on published data and filters. Actual charges use the logical Postgres row data copied after publication column and row filters and accepted by the destination.
Pipeline usage invoice line items
Usage appears on invoices with three line items: ETL Pipeline Hours, ETL Copy Backfill Data GB, and ETL Replicated Data GB.
Pipeline billing example: delete after one day
For a pipeline deleted after one day of configuration: Pro Plan costs $25, 730 Compute Hours Small Project 1 costs $15.04, and 24 ETL Pipeline Hours costs $1.27, totaling $41.31 before credits and $31.31 after $10 compute credits.
Optimize pipeline usage
To reduce pipeline costs: include only the tables and columns needed at the destination, keep high-churn tables out of the publication when their changes are not needed for analytics, and delete the pipeline through the project's replication settings if replication is no longer required to stop pipeline-hour charges.
View Storage Image Transformations usage
You can view Storage Image Transformations usage on the organization's usage page at /dashboard/org/_/usage. The page shows usage for all projects by default. Select a specific project from the dropdown to view its usage. You can also select a different time period. The Storage Image Transformations section displays how many origin images were transformed during the selected time period.
View storage usage on organization usage page
Storage size usage can be viewed on the organization's usage page at /dashboard/org/_/usage. The page shows the usage of all projects by default. You can select a specific project from the dropdown and also select a different time period to view historical usage.
Organization MFA enforcement permissions
Only organization owners can modify the MFA enforcement setting. The owner must have MFA enabled on their own account.
MFA enforcement backup recommendation
Supabase recommends creating two distinct MFA apps on your user account when enforcing MFA.
MFA enforcement availability
MFA enforcement on the organization level is only available on the Pro, Team, and Enterprise plans.
Personal access tokens and MFA enforcement
Personal access tokens are not affected by MFA enforcement. Personal access tokens are designed for programmatic access and issuing them requires a valid Supabase session backed by MFA if MFA enforcement is enabled on the account.
Effect of enabling MFA enforcement on existing users
When MFA enforcement is enabled, users without MFA immediately lose access to all resources in the organization. These users remain members of the organization and regain their original permissions once they enable MFA on their account.
Enable organization MFA enforcement
To enable MFA on an organization, visit the security settings page and toggle 'Require MFA to access organization' on.
Supabase features compared to Render
Supabase provides a Postgres database, authentication, instant APIs, edge functions, realtime subscriptions, and storage. Postgres is the core of Supabase with support for row-level security and more than 40 Postgres extensions available.
Security recommendation against disabling MFA
Supabase strongly recommends not disabling MFA to avoid unauthorized access to a user account.
MFA support for Supabase user accounts
Supabase supports multi-factor authentication (MFA) to add an additional layer of security to user accounts by requiring a second factor to verify user identity. This guide is specifically for adding MFA to your Supabase user account, not for enabling MFA for users in your Supabase project.
Supported MFA factor type
Supabase currently supports adding a unique time-based one-time password (TOTP) as an additional security factor. TOTP factors can be managed using apps such as 1Password, Authy, Google Authenticator, or Apple's Keychain.
Enable MFA in account settings
MFA can be enabled for a Supabase user account under account settings at the Supabase account security page. Enabling MFA will result in all other user sessions being automatically logged out and forced to sign in again with MFA.
MFA backup factor recommendation
Supabase does not return recovery codes. Instead, it is recommended to register a backup TOTP factor to use in case you lose access to your primary TOTP factor. The backup factor should use a different device and app, or the secret should be stored in a secure location different from the primary one.
MFA account recovery warning
For security reasons, Supabase will not be able to restore access to an account if all two-factor authentication credentials are lost. Users should register a backup factor if necessary.