Supabase Release Notes

A WAL-G physical restore restores the whole PGDATA directory, including pg_authid, so credentials from the backup snapshot overwrote any password rotated after that backup was taken.

Credential reapplication was previously only queued when a restore was part of an in-progress clone, so a plain restore to the same project, or an unpause (which shares the same completion path), skipped it entirely and could leave db_user with a stale password. Logical restores are unaffected:

pg_dumpall runs with --no-role-passwords, so a logical backup never carries password hashes to begin with.

Supabase now reapplies current credentials after every physical restore completes, regardless of whether it is part of a clone.

A related fix also closes a data-loss path in cloning status tracking: reapplying credentials for a non-clone restore could, on retry exhaustion, flip an unrelated and already-completed clone's status back to failed, which could let a later stray clone request overwrite that project's data. Status transitions are now scoped to clones that are actually in progress.

Original source

The logs.all Management API endpoint is being removed on 23rd September 2026 (Wednesday), two months from this announcement. Log querying moves to a new ClickHouse-backed logs endpoint. The new endpoint accepts ClickHouse SQL only. It returns every source through a single unified logs table instead of a separate table per source.

How Do I Know if This Impacts Me?

You are impacted only if you query the logs.all Management API endpoint (.../analytics/endpoints/logs.all). This includes any scripts, integrations, or tooling that call it directly.

If you do not call this endpoint, no action is needed. Using logs through the dashboard Logs Explorer is not affected.

What Should I Do?

• Update the endpoint path from analytics/endpoints/logs.all to analytics/endpoints/logs.
• Convert your SQL to the ClickHouse dialect. The endpoint only accepts ClickHouse SQL.
• Filter by source_name instead of selecting a source table. All sources now live in one logs table. Filter to a specific source in the WHERE clause.

Before (query a source table directly):

SELECT timestamp, event_message
FROM edge_logs
ORDER BY timestamp DESC
LIMIT 100

After (filter the unified stream by source_name):

SELECT timestamp, event_message
FROM logs
WHERE source_name = 'edge_logs'
ORDER BY timestamp DESC
LIMIT 100

Any query that previously targeted a specific table must now add a source_name filter in its WHERE clause.

Accessing Nested Fields

Nested fields move from the metadata array to a flat log_attributes map. Before, you added one CROSS JOIN unnest() per level of nesting to reach a field. Now you read the field directly from log_attributes with map key access. The joins go away.

Before (unnest each level of metadata):

SELECT timestamp, request.method, header.x_real_ip
FROM edge_logs
CROSS JOIN unnest(metadata) AS m
CROSS JOIN unnest(m.request) AS request
CROSS JOIN unnest(request.headers) AS header

After (read from the log_attributes map):

SELECT
  timestamp,
  log_attributes['request.method'] AS method,
  log_attributes['request.headers.x_real_ip'] AS x_real_ip
FROM logs
WHERE source_name = 'edge_logs'

Timeline

Date Change 23 July 2026 Changelog published 23 September 2026 logs.all endpoint removed for all projects

Learn More

• Management API reference: the logs endpoint and its parameters
• Logs & querying documentation: available sources and ClickHouse SQL query examples

Original source

Starting 2026-08-05, specifying an explicit version when creating or updating a Postgres extension on Supabase is deprecated. Statements like:

1 create extension pgvector version '0.7.0';
2 alter extension pg_graphql update to '1.5.9';

will still succeed, but the requested version is now ignored: the extension is installed at (or updated to) its current default version on your project's Postgres instance, and the statement emits a warning:

WARNING: only superusers can specify extension versions, ignoring version "0.7.0" and installing the default version

In a future release, announced separately in advance, these statements will be rejected with an error instead.

Why we're making this change

Supabase instances ship multiple versions of some extensions side by side. Allowing any role to install or downgrade to an older version means projects can end up running extension versions with known security issues — including reintroducing vulnerabilities that were already patched in the default version. Pinning versions is now reserved for platform operations.

What's not affected

• Extensions you've already installed — nothing changes on running databases.
• create extension / alter extension ... update without a version clause.
• Database backups and restores (pg_dump output never includes version clauses).
• Installing extensions from the dashboard.

Original source

Stream Postgres changes to BigQuery in near real time with Supabase Pipelines, a managed CDC service configured right in the Dashboard. Now in public alpha on all paid plans.

What's new

Supabase Pipelines is a managed change-data-capture service, powered by the open-source Supabase ETL engine, that streams changes from your Supabase Postgres database to external destinations in near real time. You pick a destination in the Dashboard, and Supabase runs and monitors the pipeline that keeps it in sync, reading directly from the Postgres write-ahead log.

What you can do

• Near real-time streaming — a complete initial copy of your selected tables, then near real-time replication of inserts, updates, deletes, and truncates, with at-least-once delivery.
• Granular control over what's replicated — publish specific tables, a whole schema, or all tables. Narrow to column subsets, filter rows with a WHERE clause, and handle partitioned tables.
• Automatic schema change support — supported changes (adding, removing, and renaming columns, and changing nullability and defaults) are detected and applied to the destination automatically.
• Full Dashboard management — create, start, stop, and restart pipelines, add or remove tables without restarting replication from scratch, and tune advanced settings like batch wait time, sync workers, and slot recovery.
• Monitoring — track pipeline status, metrics, and logs from the Dashboard.
• Reliable recovery — replication resumes from the last acknowledged position after a restart, detecting and recovering from many transient failures automatically while surfacing issues that require intervention.
• Workload isolation — replicate to an analytical destination so heavy queries run there, not on your production database.

Destinations: BigQuery is the first destination available to everyone in public alpha. ClickHouse, Snowflake, and DuckLake are available on request through the early access form.

Pricing during the public alpha: $0.053 per hour per active pipeline, $0.60/GB for the initial table copy, and $3/GB for replicated data after that.

How to use it

• Open the Dashboard and choose the tables to replicate.
• Pick a destination — BigQuery, at launch (or request ClickHouse, Snowflake, or DuckLake through the early access form).
• Pipelines runs an initial copy of the selected tables, parallelized across and within tables for faster loading.
• After the copy completes, the pipeline switches to streaming mode. New changes are read from the replication slot, batched, and written to the destination.
• Supported schema changes are detected and applied to the destination automatically.

Data is replicated as-is, without transformation.

Why we built this

Postgres is excellent for transactional workloads: reading a user profile, inserting an order, updating a subscription, or serving your application.

Analytics workloads are different. They often scan large amounts of data, aggregate across many rows, and power dashboards, reports, notebooks, and downstream systems. Running those queries directly on your production database can add load to the same system your application depends on.

Supabase Pipelines gives you a reliable way to move production data into systems built for analytics, while keeping your application workload on Postgres.

Affected products: ETL

Authored by @jhydra12

Original source

What's Changing?

The week of Aug 9, 2026, the default self-hosted Supabase API gateway will change from Kong to Envoy. Envoy has shipped as an optional override (docker-compose.envoy.yml) for the last several releases; it now becomes the default in docker-compose.yml, and Kong moves to an optional override.

This is a breaking change for a subset of self-hosters (see below) - most notably anyone relying on Kong's built-in HTTPS listener, a customized kong.yml, or tooling that references the gateway by service/container name.

• The gateway service in docker-compose.yml becomes api-gw, running Envoy (container supabase-envoy). It keeps kong as a network alias for backward compatibility.
• Kong is now opt-in via a new docker-compose.kong.yml override: sh run.sh config add kong.
• The gateway HTTP port is now configured with API_GW_HTTP_PORT (defaulting to the existing KONG_HTTP_PORT, then 8000), so existing .env files keep working.
• The default gateway listens on plain HTTP only (port 8000). Kong's built-in HTTPS listener on 8443 is not part of the Envoy default. Terminate TLS with the shipped docker-compose.caddy.yml or docker-compose.nginx.yml overrides, or opt back into Kong.
• docker-compose.envoy.yml becomes a no-op shim for one release cycle so existing overrides don't break, then is removed.

Why?

• Kong's open-source line has effectively stopped advancing. The OSS Kong we currently ship (kong:3.9.1) is roughly a year old; subsequent 3.9.x releases have been security/nginx backports only, with no feature cadence, and Kong removed free (unlicensed) mode in 3.10. Continuing on the frozen OSS Kong line carries growing security and compliance risk for self-hosters.
• One gateway, config-as-code. Envoy's routing, filters, and access control live in versioned YAML under volumes/api/envoy/, with no plugin runtime to manage.
• First-class support for the new API keys. The Envoy configuration translates opaque sb_publishable_*/sb_secret_* keys into internal JWTs. See New API Keys and Asymmetric Authentication.
• Hardened defaults. Path normalization, header-smuggling rejection, edge-proxy client-IP handling, and a locked-down admin interface. See the Envoy API Gateway guide.
• Consistency. Aligns the self-hosted default with the direction of the wider Supabase stack.

Am I Affected?

You are affected if you run self-hosted Supabase from the ./docker directory and pull updates from master, and any of the following apply:

• You rely on Kong's built-in :8443 HTTPS listener directly (no reverse proxy in front). The Envoy default does not expose 8443. Put Caddy/Nginx in front for TLS, or opt back into Kong.
• You maintain a customized kong.yml (custom routes, plugins, ACLs). These do not carry over to Envoy and will silently stop applying. Opt back into Kong to keep them, or port the customizations to the Envoy config.
• You have scripts or tooling that reference the gateway by service/container name (kong / supabase-kong) - for example docker compose logs kong or run.sh restart kong. The service is now api-gw and the container is supabase-envoy. The kong hostname still resolves via a network alias.
• You currently run the Envoy override (docker-compose.envoy.yml) in your COMPOSE_FILE. No behavior change now, but you should remove that entry from COMPOSE_FILE once you pull the update, since Envoy is the base default.

You are not affected if you:

• Use the Supabase platform
• Use locally running Supabase services via CLI

What Should I Do?

If you pull the updated docker-compose.yml and .env.example together with no gateway customizations, no action is required beyond being aware that requests now flow through Envoy.

If you want to stay on Kong:

1

sh run.sh config add kong

2

sh run.sh recreate

Kong remains available as an override for compatibility and migration, but note it tracks the frozen OSS 3.9.x line - we recommend it as a transition aid, not a long-term default.

If you customized kong.yml : opt back into Kong (config add kong) to keep your config, or port your routes/rules to the Envoy config under volumes/api/envoy/. See the Envoy API Gateway guide.

If you already run the Envoy override: remove docker-compose.envoy.yml from COMPOSE_FILE (or run sh run.sh config remove envoy) after pulling the update.

If you'd rather defer: pin your checkout, or add the Kong override so your gateway behavior is unchanged. This is a default change, not a removal - but we recommend migrating to Envoy, since the OSS Kong line is no longer actively maintained.

Rollout

Date Change

2026-07-17 This changelog published

[TBD ~Aug 13] Updated self-hosting gateway docs published

[TBD ~Aug 13] Default change ships in the next self-hosted Supabase release

Original source

Here's everything that happened with Supabase in the last month:

OpenCode integrates with Supabase

OpenCode connects your agent to your Supabase database, Edge Functions, and logs. It configures the MCP setup for you.

Read the blog →

TanStack DB syncs with Supabase

@supabase-labs/tanstack-db syncs TanStack DB collections with your Supabase tables over PostgREST and Realtime. It's available in alpha.

Watch the demo →

Wrappers adds a MongoDB foreign data wrapper

Wrappers v0.6.2 lets you query and join MongoDB collections directly from Postgres. It also fixes OpenAPI FDW pagination.

Read the docs →

Multigres supports LISTEN/NOTIFY across pooled connections

Multigres keeps Postgres LISTEN/NOTIFY working even when connections are pooled away from clients.

Read the blog →

Realtime Broadcast supports binary payloads

Realtime Broadcast now sends and receives binary payloads in addition to JSON. Binary payloads cut encoding overhead for cases like sensor telemetry and live screenshot streaming.

The Dart, Kotlin, and Python clients don't support binary payloads yet, and older SDK versions silently drop them. Update your client before you rely on it.

Read the docs →

Quick Product Announcements

• Postgres log_connections now defaults to off for new projects on all tiers as of July 9, and existing Free and Pro projects are being migrated to the new default. [GitHub Discussion]
• pg_graphql v1.6.2 ships with GraphQL schema introspection off by default, so enable it per schema if you use GraphiQL or codegen tools. [GitHub Discussion]
• Audit Log Drains are available, so you can stream your project's audit logs to an external destination. [Docs]
• Connect copies every environment variable @supabase/server needs in a single click. [Demo]
• Self-hosted Docker defaults changed: API_EXTERNAL_URL now includes the /auth/v1 prefix, and the default image moves to Postgres 17. [GitHub Discussion]

Meet the Supabase team

• Supabase Live: Building high quality Supabase apps using TRAE. July 22 at 7 pm PT. [Register]
• Supabase x Claude Community Meetup in Dublin. [Register]
• Hangout with the Supabase team during Casual Wednesdays on Discord at 10:00 am PT. [Join]

Made with Supabase

• Shapeships: A multiplayer browser game using simultaneous-turn mechanics, built on an authoritative Supabase backend. [Website]
• Blind OS: An autonomous outreach and client-management system that finds leads, qualifies them, and follows up on payments. [Website]
• rlsautotest: Generates pgTAP tests and seed data from your Supabase RLS policies to prove, per table and identity, who can read or write which rows. [GitHub] [PyPI]
• Heym: An open-source visual AI workflow automation platform with a native Supabase node for querying and mutating tables through PostgREST. [GitHub]

Community Highlights

• A practical security checklist for non-technical builders, with Row Level Security flagged as the single most important fix. [Read]
• A transparent cost breakdown for a personal life-management system built with Claude Code and Supabase, plus an honest look at the security tradeoffs of self-hosting your own data. [Read]
• A widely-shared guide to vibecoding with Claude Code positions Supabase as the default data layer and login system in its standard setup flow. [Read]

Original source

We are changing the default value of the Postgres log_connections setting from on to off for new projects, and will be migrating all Free and Pro projects to the new default configuration. This reduces log volume and noise, and aligns with industry-standard defaults (RDS, GCP Cloud SQL also default to off). We will be exposing this configuration to all users via dashboard and API for better log management, with log_connnections and log_disconnections now available via the Update postgres config API route and will take effect from 9 July onwards.

Who's affected

• New projects (all tiers) created after 9 July will have log_connections=off by default.
• Existing Teams + Enterprise customers (including HIPAA add-on customers) - Configuration is unchanged
• Existing Free / Pro customers - log_connections will be turned off from 9 July. This configuration can be re-enabled below

How to re-enable

You can re-enable log_connections via the dashboard under Database > Settings. It can also be re-enabled programmatically via the Management API via the Update postgres config API route. Changes will only take effect from 9 July onwards.

Learn more about PostgreSQL logging settings in our logging documentation.

Original source

What's Changing?

The week of July 6, 2026, the default self-hosted Supabase configuration for API_EXTERNAL_URL will change to include the /auth/v1 path prefix:

• API_EXTERNAL_URL will default to http://localhost:8000/auth/v1 (previously http://localhost:8000)
• GOTRUE_JWT_ISSUER in docker-compose.yml will change to ${API_EXTERNAL_URL} (the actual URL will stay unchanged)
• OAuth redirect configuration placeholders in docker-compose.yml will become ${API_EXTERNAL_URL}/callback
• The API gateway routes for SAML SSO move from /sso/saml/* to /auth/v1/sso/saml/*, so SAML ACS and metadata endpoints become …/auth/v1/sso/saml/acs and …/auth/v1/sso/saml/metadata

This aligns self-hosted Supabase with the platform behavior, and the CLI .

Why?

• Consistency across deployments. API_EXTERNAL_URL behaves identically on platform, self-hosted, and CLI.
• Custom OAuth providers work out of the box. GoTrue builds custom-provider callback URLs as API_EXTERNAL_URL + /callback. With the prefix now in the base URL, that resolves to …/auth/v1/callback and matches the existing API gateway route.
• SAML aligns with the /auth/v1 convention used by every other auth endpoint, rather than living at a bare /sso/saml/* path.
• The docs become accurate. The guidance that "your callback URL is built from API_EXTERNAL_URL" is now literally true, instead of relying on the /auth/v1 prefix being manually prepended in the compose file.

Am I Affected?

You are affected if you run self-hosted Supabase from the ./docker directory and pull updates from master, and any of the following apply:

• You've overridden API_EXTERNAL_URL in your .env (e.g. https://my-domain.com ) - you'll need to change it to https://my-domain.com/auth/v1.
• You maintain a customized docker-compose.yml with OAuth providers - the redirect URIs change from ${API_EXTERNAL_URL}/auth/v1/callback to ${API_EXTERNAL_URL}/callback to avoid a doubled /auth/v1 prefix.
• You use SAML SSO - your IdP points at the old /sso/saml/* endpoints and must be updated to /auth/v1/sso/saml/*. This is the main breaking case.

You are not affected if you:

• Use the Supabase platform
• Have OAuth providers registered with Google/GitHub/etc. - the final callback URL is unchanged (…/auth/v1/callback), so no re-registration in the provider's developer console is needed
• Don't use SAML SSO and pull the new docker-compose.yml and .env.example together without local changes - the defaults stay consistent

What Should I Do?

If you pull the updated docker-compose.yml and .env.example together with no customizations, no action is required unless you use SAML SSO.

If you've customized API_EXTERNAL_URL :

• Append /auth/v1 to your value (e.g. https://my-domain.com → https://my-domain.com/auth/v1 )
• If your override file sets OAuth redirect URIs, change them from ${API_EXTERNAL_URL}/auth/v1/callback to ${API_EXTERNAL_URL}/callback
• Restart the stack

If you use SAML SSO:

• Pull the updated docker-compose.yml (or update your Kong and Envoy routes to /auth/v1/sso/saml/acs and /auth/v1/sso/saml/metadata )
• Restart the stack
• Re-fetch your service provider metadata from {API_EXTERNAL_URL}/auth/v1/sso/saml/metadata and update your IdP (ACS URL, SP entity ID) with the new endpoints
• See the self-hosted SAML SSO guide

If you'd rather defer: keep your existing API_EXTERNAL_URL without the /auth/v1 suffix and retain your current OAuth/SAML configuration. This is a default change, not a removal - but we recommend aligning soon, since custom OAuth providers won't work without it.

Rollout

Date Change

2026-06-18 This changelog published

2026-07-06...10 Updated self-hosting OAuth and SAML SSO docs published

2026-07-06...10 Default change ships in the next self-hosted Supabase release

Original source