Changelog

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#

@supabase/supabase-js will require TypeScript 5.0 starting January 31, 2027, dropping support for TypeScript 4.7 to 4.9. Upgrade to 5.0 or later before then.

Starting with a minor release on or after January 31, 2027, @supabase/supabase-js and the packages it bundles (postgrest-js, auth-js, realtime-js, storage-js, functions-js) will require TypeScript 5.0 or later. TypeScript 4.7–4.9 will no longer be tested or supported.

Consistent with our existing Support Policy, raising the minimum TypeScript version ships in a minor release and is not considered a breaking change, the same way we handle end-of-life Node.js versions.

Why#

• Our type declarations currently target a TypeScript 4.7 floor (May 2022, ~4 years old) — roughly a dozen releases and two major lines behind current TypeScript.
• Holding the 4.7 floor blocks us from using modern type features that materially improve the SDK's types — const type parameters, the satisfies operator, and (later) NoInfer for the postgrest-js query-builder generics.
• It also pins transitive tooling (e.g. zod) to older releases.

What you need to do#

• On TypeScript 5.0 or newer: nothing. You're already covered.
• On TypeScript 4.7–4.9: upgrade your project's TypeScript to >= 5.0 before the release above. TypeScript 5.x has been stable since March 2023.

Timeline#

• Now: advance notice (this post); our SDKs continues to emit 4.7-compatible types.
• January 31, 2027 (sunset date): TypeScript 4.7–4.9 support ends. A minor release on or after this date raises the floor to TypeScript 5.0. The last version supporting TypeScript 4.7 will be called out in the release notes and the README once that release is cut.

Questions and concerns welcome below.

Affected products: supabase-js Action required before: 2027-01-31