Manage Logs Ingest usage

What you are charged for#

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.

How charges are calculated#

Logs Ingest is charged per byte of log data ingested during the billing cycle.

Usage on your invoice#

Usage is shown as "Logs Ingest" on your invoice.

Pricing#

$0.50 per GB, after your plan's included quota.

Billing examples#

Ingest is billed per byte (bytes ÷ 1,000,000,000 × $0.50), not rounded up to the next GB. These examples use fractional GB to show that precision.

View usage#

You can view Logs Ingest usage on the organization's usage page of the Dashboard. 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.

Optimize usage#

Every service in your Supabase project generates logs automatically. Log volume scales with your application's traffic and behavior.

Reduce the volume of a log type rather than turning it off completely. Raise a threshold rather than disabling logging outright as this prevents you from having information if something goes wrong later. For example a security incident or a slow query may be completely missed.

You change all of the Postgres settings below through Custom Postgres Configuration, either from the SQL Editor or the Supabase CLI. Some changes take effect immediately; others require a database restart. The CLI has a --no-restart option if you want to batch several changes together before restarting. See Postgres log configuration for the full list of configurable log settings and what each one does.

Start with the two biggest levers#

Consider these options first. They are responsible for most log volume on most projects.

• log_statement — set to none if you don't manually read through raw query logs to debug your application, for example if your team relies on an AI coding assistant, an APM tool, or the Query Performance dashboard instead. Keep all on if you routinely read query text in the Logs Explorer to debug issues, or you have a compliance requirement to retain a full statement audit trail; mod is a lighter-volume option if you only need a record of data changes.
• log_min_duration_statement — raise the threshold (for example, from a few milliseconds to 1-2 seconds) if you only care about queries that are slow enough to notice. Keep it low only while you're actively in a performance-tuning phase, and raise it back up once that investigation is done.
• pgAudit, if enabled — this extension can be very verbose independently of log_statement. Turn off a broad pgaudit.log or pgaudit.role configuration if you don't need a dedicated audit trail beyond what log_statement already gives you.

Check these often-overlooked settings#

• log_connections and log_disconnections — turn off if you don't need a record of exactly when every connection opened and closed. Keep on if you're troubleshooting connection exhaustion or spikes, or have a security requirement to log all connection activity. If this setting is generating a lot of volume, your app may not be using a connection pooler such as Supavisor, which Supabase provides by default — connecting through the pooler reduces both log volume and the risk of running out of connections.
• log_autovacuum_min_duration — raise the threshold, or turn it off, if you're not actively diagnosing a table-maintenance problem. Keep it on with a reasonable threshold if you've had autovacuum-related performance issues before.
• log_temp_files — turn off if you're not actively tuning query performance around memory usage. Keep it on if you're investigating slow queries related to sorting or joining large amounts of data.
• log_lock_waits — turn off if you're not seeing symptoms of queries hanging. Keep it on if multiple processes write to the same data concurrently and you've seen unexplained slowdowns before.

Check this if your logs seem unusually large for no clear reason#

log_min_messages controls the verbosity of Postgres's own internal logging, separate from query activity. The default is warning. If this was turned up to a debug level while troubleshooting a specific issue and never turned back down, it can produce a large, ongoing volume of internal messages that aren't useful for day-to-day monitoring — check the current value and reset it if you don't recognize turning it up yourself.

Custom RPC functions and stored procedures are also worth reviewing. A PL/pgSQL function that calls RAISE NOTICE or RAISE LOG produces log output every time it runs, independent of any of the settings above — if a frequently-called function logs on every invocation, it can account for a large, otherwise-unexplained share of your volume.

Settings you can generally leave alone#

log_checkpoints, log_recovery_conflict_waits, log_replication_commands, and log_startup_progress_interval are either low-volume by nature or only relevant if you use specific features such as replication. Unless you know you're using the related feature, these rarely contribute meaningfully to your total ingest.

Checking your new usage baseline#

After you change a setting, give it a day or two, then check your ingest usage trend in the Dashboard or your log volume in the Logs Explorer, to confirm the change had the effect you expected. Volume can be uneven day-to-day depending on traffic, so look at the trend over several days before drawing conclusions. If you're not sure which setting is responsible for your current usage, check which kind of log entries make up most of your volume in the Logs Explorer before changing anything.

Exceeding Quotas#

If you are on a paid plan and have Spend Cap disabled or your organization is on Team Plan or above, you will pay for any overages.

When you are exceeding your quotas while being on a Free Plan or having Spend Cap enabled, you will get a notification to your billing email address and put under a grace period. For more details, refer to our Fair Use Policy.