Changelog

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?#

1. Update the endpoint path from analytics/endpoints/logs.all to analytics/endpoints/logs.
2. Convert your SQL to the ClickHouse dialect. The endpoint only accepts ClickHouse SQL.
3. 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):

After (filter the unified stream by source_name):

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):

After (read from the log_attributes map):

Timeline#

Learn More#

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

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:

1. 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.
2. 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.
3. Automatic schema change support — supported changes (adding, removing, and renaming columns, and changing nullability and defaults) are detected and applied to the destination automatically.
4. 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.
5. Monitoring — track pipeline status, metrics, and logs from the Dashboard.
6. 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.
7. 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#

1. Open the Dashboard and choose the tables to replicate.
2. Pick a destination — BigQuery, at launch (or request ClickHouse, Snowflake, or DuckLake through the early access form).
3. Pipelines runs an initial copy of the selected tables, parallelized across and within tables for faster loading.
4. After the copy completes, the pipeline switches to streaming mode. New changes are read from the replication slot, batched, and written to the destination.
5. 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

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:

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#