Supabase Turns Off Connection Logging by Default, No Opt-In

Supabase flipped Postgres’s log_connections setting from on to off by default starting July 9, 2026, and it isn’t just for new projects. Existing Free and Pro tier projects are being auto-migrated to the new default too, per the Supabase changelog. Teams and Enterprise projects keep their current configuration.

---

What actually changed

Every new Supabase project, on any tier, now starts with connection and disconnection logging off. For projects that already existed on the Free or Pro tier before July 9, Supabase is switching the setting on their behalf. There’s no migration step, no dashboard prompt, no email requiring action first. Teams and Enterprise customers are explicitly excluded from the change and keep whatever configuration they already had.

Supabase’s stated reasoning: log_connections was generating log volume most projects didn’t need, and turning it off by default brings Postgres on Supabase in line with the defaults on Amazon RDS and Google Cloud SQL, which also ship with connection logging off (Supabase changelog).

Why the auto-migration matters

Reducing default log noise is a defensible choice on its own. The retroactive part is what matters: it applies to projects already in production, not just to new ones. log_connections is one of the first things a team turns to when diagnosing a connection storm, a leaking connection pool, or an unexplained spike in Postgres client count. It’s also a common input to a security audit trail, since it’s the record of who or what opened a session and when.

A team that has never needed to look at connection logs won’t notice anything changed on July 9. A team that does rely on them will find the signal missing at the worst possible time, say mid-incident, trying to figure out which service is exhausting the connection pool, with the only notice being a changelog entry they’d have had to be watching for.

How to get it back

Supabase left the setting user-controllable. Re-enable log_connections (and its companion log_disconnections) from the dashboard under Database > Settings, or programmatically through the Management API’s Update postgres config route, which Supabase says now exposes both settings for the first time (Supabase changelog).

---

Key Takeaways

• Postgres log_connections now defaults to off for new Supabase projects on every tier, effective July 9, 2026.
• Existing Free and Pro tier projects are being migrated to the off default automatically; Teams and Enterprise projects are unaffected.
• Supabase frames the change as noise reduction and alignment with RDS/Cloud SQL defaults, both of which also default connection logging off.
• Re-enable it via Database > Settings in the dashboard, or the Management API’s Update postgres config route.
• If your incident-response or audit process assumes connection logs exist, check your project’s setting now rather than during the next connection storm.

---

The take

An opt-out default that reduces log noise is a reasonable engineering call, and matching RDS and Cloud SQL is a fair justification. What’s less reasonable is applying it to projects that are already live without any action from the owner. New projects starting with a leaner default is normal product evolution; quietly flipping a debugging and audit signal off on projects already running in production is the kind of change that should ship as an opt-in prompt, not a changelog line discovered after the fact. If you’re on Supabase’s Free or Pro tier, check Database > Settings today. Don’t wait for an incident to find out the logs aren’t there.