Logs usage-based pricing

[changelog-reporter[bot]]

Supabase Logs is moving to usage-based pricing. We're announcing early so you have time to adjust — 90%+ of projects are within the included limits, with a grace period through early 2027.

When you run a backend on Supabase, we instrument it for you — logs come out of the box so you can monitor your services and debug issues without standing up separate infrastructure. We're continuing to invest in them. We're also announcing usage-based pricing early, because we'd rather give impacted projects time to adjust than hand anyone an unexpected bill. More than 90% of projects are within the included limits and won't be affected; for those that are, the grace period through early 2027 gives you time to understand and tune your usage before enforcement begins.

Background

We've been working for years to bring meaningful observability to Supabase developers — shipping Unified Logs, client trace integration, Log Drains, Observability Auto-Pilot, and Health Check Advisors, among other things. We'll keep going — more ways to surface logs meaningfully, more tools to help you monitor and debug, with or without an agent in the loop.

But as we've scaled to millions of projects, the infrastructure behind logs has scaled with us. Usage-based pricing is how we make sure we can keep building, in a way that's fair for everyone.

Usage-based pricing

That said, there are workloads where logs will scale with usage — and at platform scale, that needs to be priced fairly. We're introducing usage-based pricing for logs ingest (the volume of log data generated by your services) and a quota that scales with ingest for log query (the volume scanned when reading logs).

This is a soft launch: usage is now visible in your project's usage dashboard, but limits are not yet enforced. A grace period for existing organizations as of September 25, 2026 runs through early 2027, giving you time to understand your usage before billing begins. More than 90% of projects are within the included limits and won't be impacted.

The grace period is built for existing orgs as most were started before usage-based pricing existed, and deserve real time to understand and adjust. New orgs created after September 25, 2026 get the same grace period for now, but that benefit isn't guaranteed through early 2027 the way it is for existing orgs. We may end it sooner and set a separate usage-based-billing go-live date for newly created orgs. If and when we do, we'll announce that date directly, the same way we're doing here.

What we've done to control log volume

A significant part of this pre-requsite work to this pricing announcement has been changing default logging behavior across the Supabase stack, and giving you more control over your own logs usage:

• We've shipped fleet-wide changes to reduce noisy defaults — for example, disabling connection logging (log_connections) across most plans, which alone cut tens of millions of log rows per hour fleet-wide.
• Postgres log settings are configurable and often the biggest lever for teams running heavy query workloads. Settings like log_statement, log_min_duration_statement, and log_min_messages can dramatically reduce volume when tuned. See Postgres log settings and the log field reference to understand what each source captures.
• We've published guides to help you understand your usage and take action: Manage Logs Ingest and Manage Logs Query.

We'll keep adding more controls through the soft launch grace period. The goal is that the defaults are right for most projects, and that teams who need to go further have the tools to do it.

What's new in Studio

Your project's usage dashboard will show log ingest and query meters with an "Upcoming" label. If you approach your limits during the grace period, you'll see a warning in Supabase Studio — these are informational only, not billable or applying any enforcement actions.

Why we built this

Supabase has a healthy free tier, and we're committed to keeping it that way. Usage-based pricing makes that possible: when infrastructure costs reflect actual use, high-volume projects pay their share rather than that cost being spread across the fleet. It also lets us keep finding more meaningful ways to surface logs — better tools to understand, access, and act on what they're telling you, with or without an agent in the loop — in a way that's sustainable and fair for everyone, whether you're a hobbyist, a growing startup, or a large enterprise.

Share your feedback

This is a soft launch and we're actively seeking input. If you're notified about your usage during the grace period, or you have thoughts on pricing, limits, or the tooling, we'd love to hear from you. Visit our GitHub Discussion to share feedback directly with the team.

Affected products: Observability

[riglar]

Hey team,

This change looks to grow our Supabase bill by 15-25%.

We pay to drain our logs to Axiom. So would actually like an option to immediately delete logs from Supabase storage following drainage.

Postgres makes up less than 1% of our current SB log volume, so the current guidance on log reduction doesn't help much.

Any tips or advice for a bootstrapped founder would be much appreciated <3

Cheers

[Support-SDL]

Similar for us...

Usage is between 1.5GB and 4GB per day. With a 20GB limit. Last month is said we were $50 over usage!
I have since trimmed our postgres usage and turned log_statements to "none" but almost all of our usage is API Gateway.

It doesn't look like there is a way to turn this off. I don't think we should be billed for a logging service we can't turn off if we don't want it.

Again, any tips or advice around this issue would be appreciated

Thanks