Supabase turned connection logs off: keep Postgres observable when the noise disappears

If your Supabase Postgres logs became unusually quiet after July 9, that may be a default change rather than an outage. Supabase switched log_connections to off for new projects and existing Free and Pro projects. Reducing one event per connection is sensible, but teams that quietly promoted those events into a monitoring system can turn less noise into an observability gap.

What changed

Supabase announced the change on June 22, 2026, with effect from July 9. New projects on every tier now default to log_connections=off, and existing Free and Pro projects were moved to the same default. Teams, Enterprise, and HIPAA add-on projects remain unchanged.

log_connections records connection and authentication lifecycle messages. PostgreSQL notes that some clients connect twice while determining whether a password is required, so duplicate connection messages are not automatically incidents. Supabase cites lower log volume and noise as the reason for the change.

Teams can re-enable the option in Database Settings or through the Management API. Supabase documents log_connections and log_disconnections as Management-API-only settings rather than normal CLI-configurable parameters. Verify desired state against pg_settings, not just a dashboard toggle.

Why working teams should care

Connection events are easy to misuse as a universal signal. They can help reveal deployment spikes, stale workers with bad credentials, pooler mistakes, or serverless connection churn, but event volume does not directly describe user impact, query latency, pool saturation, or authentication failure rate.

Rewrite the observability contract around outcomes: API errors and latency, connection utilization, pool saturation, lock waits, slow queries, and transaction state. Connection logs are better treated as supporting evidence during diagnosis.

Audit requirements are different. If the organization must know who connected and when, enable connection and disconnection logging based on the threat model and retention policy. If data changes must be audited, design a scoped pgAudit policy. A connection record is not a query audit trail.

Build a three-layer stack

Layer one is low-cost, always-on telemetry: API golden signals, database connection utilization, pool pressure, locks, transaction state, and pg_stat_statements call and latency data. It should answer whether users are affected.

Layer two is time-bounded diagnosis. When a leak or authentication loop is suspected, enable log_connections and perhaps log_disconnections for a defined window. Record the owner, start time, expected volume, and stop condition.

Layer three is purpose-built audit evidence. Supabase recommends pgAudit for query classes and warns that a broad scope creates noise. Select only required DDL, write, or function classes, and review the risk of copying sensitive query text into a log store.

Community signal: noise and missing context both hurt

Supabase community discussions repeatedly show operators mistaking internal health-check chatter for incidents, while other users struggle when the event they need is absent. A recent thread described internal process messages filling logs without a corresponding service impact.

Those posts do not establish product behavior. They are a narrative signal that operators need classification and correlation, not merely more lines. Use official Supabase and PostgreSQL documentation for defaults, configuration methods, and limits.

Practical checklist

1. Record show log_connections; and show log_disconnections; for every production and staging project.

2. Find dashboards and alerts that depend on connection-log strings or counts, then replace them with metrics or pooler signals.

3. Define API latency and errors, connection utilization, pool saturation, lock waits, and slow queries as baseline signals with owners.

4. Add start conditions, API permissions, expected volume, expiry, and rollback verification to the connection-debug runbook.

5. Separate connection lifecycle logging from pgAudit and review retention, access, and sensitive-data exposure.

6. Check whether serverless, Edge Functions, or workers create a new connection per request; segment by pooler and application name.

7. Never interpret a lower log count as a performance improvement without user and database metrics.

8. Run a game day that enables the setting, confirms log delivery and alerts, then restores and verifies the original state.

Risks and counterarguments

Fewer logs can make diagnosis harder, which is why the answer is layering rather than blindly disabling evidence. Permanent connection events still do not explain query latency or pool wait; baseline metrics must exist first.

Cost concerns are also fair. Supabase cites volume and noise, but does not decide your compliance posture. Data sensitivity and the threat model—not the pricing tier—should decide whether lifecycle logging is re-enabled.

Finally, prevent configuration drift. A console-only change can escape code review. If you automate the Management API, preserve desired state, approval, and readback evidence, and grant only the required database_config_write permission.

Supabase connection-observability checkpoints

✓Record show log_connections; and show log_disconnections; for every production and staging project.

✓Find dashboards and alerts that depend on connection-log strings or counts, then replace them with metrics or pooler signals.

✓Define API latency and errors, connection utilization, pool saturation, lock waits, and slow queries as baseline signals with owners.

✓Add start conditions, API permissions, expected volume, expiry, and rollback verification to the connection-debug runbook.

✓Separate connection lifecycle logging from pgAudit and review retention, access, and sensitive-data exposure.

✓Check whether serverless, Edge Functions, or workers create a new connection per request; segment by pooler and application name.

✓Never interpret a lower log count as a performance improvement without user and database metrics.

✓Run a game day that enables the setting, confirms log delivery and alerts, then restores and verifies the original state.

Bottom line

This is not merely one missing log line. Responsibility moved from a platform default to an explicit team contract: observe user impact with metrics, enable connection evidence narrowly during incidents, and govern audit trails as a separate system.

Sources

• Supabase Changelog: log_connections off by default
• Supabase Docs: Logging
• Supabase Docs: Customizing Postgres configs
• Supabase Management API: Update Postgres config
• PostgreSQL Docs: Error reporting and logging
• Supabase Docs: Database configuration and pg_stat_statements
• Reddit r/Supabase: operational log noise discussion